Oracle® Fusion Middleware

Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド

11g リリース1 (11.1.1.7.0)

B55899-09(原本部品番号:E12036-12)

2014年2月

Oracle SOAコンポーネントのエンタープライズ・デプロイメントへのインストールおよび構成方法を説明するインストール実行者向けのドキュメントです。SOAエンタープライズ・デプロイメント・トポロジのベスト・プラクティスの青写真が含まれています。

Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド, 11g リリース1 (11.1.1.7.0)

B55899-09

Copyright © 2014, Oracle and/or its affiliates. All rights reserved.

原本著者: Joe Paul (ライター), Janga Aliminati (設計者), Fermin Castro Alonso (協力エンジニア)

原本協力著者: Bonnie Vaughn, Rosie Harvey

原本協力者: Pradeep Bhat, Richard Delval, Marek Vinar

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

Oracleは米国Oracle Corporationおよびその子会社、関連会社の登録商標です。その他の名称は、他社の商標の可能性があります。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

目次

タイトルと著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 エンタープライズ・デプロイメントの概要

- 1.1 エンタープライズ・デプロイメント・ガイドについて

- 1.2 エンタープライズ・デプロイメントの用語

- 1.3 Oracle推奨事項のメリット

- 1.3.1 組込みセキュリティ

- 1.3.2 高可用性

2 エンタープライズ・デプロイメント参照用トポロジの紹介

- 2.1 エンタープライズ・デプロイメント参照用トポロジの概要

- 2.1.1 このガイドに記載されている参照用トポロジ

- 2.1.1.1 Oracle Access Managerを使用したMySOACompanyトポロジ

- 2.1.1.2 Oracle Access ManagerとBusiness Activity Monitoringを使用したMySOACompanyトポロジ

- 2.1.1.3 Oracle Access ManagerとOracle BPMを使用したMySOACompanyトポロジ

- 2.1.1.4 Oracle Service Busを使用したMySOACompanyトポロジ

- 2.1.2 Oracle Identity Managementの統合について

- 2.1.3 Web層ノードについて

- 2.1.4 ロード・バランサ要件

- 2.1.5 アプリケーション層について

- 2.1.6 データ層について

- 2.1.7 通信のユニキャスト要件について

- 2.2 Linuxにおけるエンタープライズ・デプロイメントのハードウェア要件

- 2.3 インストールするソフトウェア・コンポーネントの特定

- 2.4 資格証明ストアとポリシー・ストアとしてのLDAPについて

- 2.5 クロックの同期

- 2.6 参照用トポロジのインストールおよび構成のロード・マップ

- 2.6.1 Oracle SOAエンタープライズ・デプロイメント・プロセスのフロー・チャート

- 2.6.2 Oracle SOAエンタープライズ・デプロイメント・プロセスのステップ

- 2.6.3 エンタープライズ・デプロイメントへの増分、モジュラ・アプローチの理解

3 エンタープライズ・デプロイメント用のネットワークの準備

- 3.1 エンタープライズ・デプロイメント用のネットワークの準備の概要

- 3.2 トポロジで使用する仮想サーバー名について

- 3.2.1 soa.mycompany.com

- 3.2.2 admin.mycompany.com

- 3.2.3 osb.mycompany.com

- 3.2.4 soainternal.mycompany.com

- 3.3 ロード・バランサの構成

- 3.3.1 ロード・バランサ要件

- 3.3.2 ロード・バランサ構成の手順

- 3.3.3 ロード・バランサの構成

- 3.4 IPおよび仮想IPについて

- 3.5 管理サーバーの仮想IPアドレスの有効化

- 3.6 ファイアウォールとポートについて

4 エンタープライズ・デプロイメント用のファイル・システムの準備

- 4.1 エンタープライズ・デプロイメント用のファイル・システムの準備の概要

- 4.2 ディレクトリ用語とディレクトリ環境変数

- 4.3 各種ディレクトリの推奨場所について

- 4.3.1 バイナリ(Oracleホーム)ディレクトリに対する共有記憶域の推奨事項

- 4.3.1.1 バイナリ(Oracleホーム)ディレクトリについて

- 4.3.1.2 複数ドメインでの単一Oracleホームの共有について

- 4.3.1.3 冗長なバイナリ(Oracleホーム)ディレクトリの使用について

- 4.3.2 ドメイン構成ファイルに対する共有記憶域の推奨事項

- 4.3.2.1 Oracle WebLogic Server管理および管理対象サーバー・ドメイン構成ファイルについて

- 4.3.2.2 管理対象サーバー・ドメイン構成ファイルに対するローカル記憶域の要件

- 4.3.3 JMSファイル・ストアおよびトランザクション・ログに対する共有記憶域の推奨事項

- 4.3.4 ディレクトリの推奨場所

- 4.3.5 ディレクトリ構造と構成

- 4.4共有記憶域の構成

5 エンタープライズ・デプロイメント用のデータベースの準備

- 5.1 エンタープライズ・デプロイメント用のデータベースの準備の概要

- 5.2 データベース要件について

- 5.2.1 データベース・ホストの要件

- 5.2.2 サポートされているデータベース・バージョン

- 5.2.3 初期化パラメータについて

- 5.3 データベース・サービスの作成

- 5.3.1 10gおよび11g リリース1 (11.1)データベース用のデータベース・サービスの作成

- 5.3.2 11g リリース2 (11.2)データベース用のデータベース・サービスの作成

- 5.4 Oracle RACデータベースへのOracle Fusionメタデータ・リポジトリのロード

- 5.5 トランザクション・リカバリ権限用SOAスキーマの構成

- 5.6 データベースのバックアップ

6 エンタープライズ・デプロイメント用のソフトウェアのインストール

- 6.1 ソフトウェアのインストール・プロセスの概要

- 6.2 Oracle HTTP Serverのインストール

- 6.2.1 Oracle HTTP Serverのインストールの前提条件

- 6.2.2 Oracle HTTP ServerのWEBHOST1およびWEBHOST2へのインストール

- 6.2.3 Oracle Fusion Middlewareインストールのバックアップ

- 6.3 Oracle Fusion Middlewareのインストール

- 6.3.1 Oracle WebLogic ServerのインストールとFusion Middlewareホームの作成

- 6.3.2 Oracle Fusion Middleware SOA Suiteのインストール

- 6.3.3 必要なOracle Service Busバイナリのインストール

- 6.3.4 Fusion Middlewareインストールのバックアップ

7 エンタープライズ・デプロイメント用のWeb層の構成

- 7.1 Web層構成の概要

- 7.2 Web層構成の前提条件

- 7.3 構成ウィザードによるOracle HTTP Serverの構成

- 7.4 構成の検証

- 7.5 HTTPリクエストをルーティングするためのロード・バランサの構成

- 7.6 仮想ホストの定義

- 7.6.1 httpd.confファイルでのIPアドレスとポートの定義

- 7.6.2 <VirtualHost>ディレクティブを定義する.confファイルの作成

- 7.6.3 構成の検証

8 エンタープライズ・デプロイメント用のドメインの作成

- 8.1 ドメイン作成の概要

- 8.2 SOAHOST1でのVIP1の有効化

- 8.3 SOAHOST1での構成ウィザードを使用したドメインの作成

- 8.4 構成後タスクおよび検証タスク

- 8.4.1 SOAHOST1での管理サーバー用boot.propertiesの作成

- 8.4.2 SOAHOST1でのノード・マネージャの起動

- 8.4.3 SOAHOST1での管理サーバーの起動

- 8.4.4 GridLinkデータ・ソースの検証

- 8.4.5 管理サーバー構成の検証

- 8.4.6 管理サーバーと同じノードでの管理対象サーバー用独立ドメイン・ディレクトリの作成

- 8.4.7 WSM-PM_ClusterへのJava Required Files (JRF)テンプレートの適用

- 8.4.8 ホスト名検証の無効化

- 8.4.9 WLS_WSM1管理対象サーバーの起動と検証

- 8.5 SOAHOST2へのドメイン構成の伝播

- 8.5.1 unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播

- 8.5.2 アップロードおよびステージング・ディレクトリの絶対パスへの変更

- 8.5.3 WLS_WSM2管理対象サーバーに対するホスト名検証の無効化

- 8.5.4 SOAHOST2でのノード・マネージャの起動

- 8.5.5 WLS_WSM2管理対象サーバーの起動と検証

- 8.6 Oracle WSMでのJava Object Cacheの構成

- 8.7 WebLogicドメインのOracle HTTP Serverの構成

- 8.7.1 管理サーバーとWLS_WSMn管理対象サーバーについてのOracle HTTP Serverの構成

- 8.7.2 WebLogicプラグイン有効化フラグの有効化

- 8.7.3 WebLogic ServerへのOracle HTTP Serverの登録

- 8.7.4 管理コンソールのフロントエンドURLの設定とリダイレクション・プリファレンスの設定

- 8.7.5 Oracle HTTP Serverを介したアクセスの検証

- 8.8 管理サーバーの手動フェイルオーバーの検証

- 8.9 WebLogicドメイン構成のバックアップ

9 SOAコンポーネントを使用するためのドメインの拡張

- 9.1 SOAコンポーネントを使用するためのドメインの拡張の概要

- 9.2 Oracle SOAコンポーネントを使用するためのドメインの拡張の前提条件

- 9.2.1 SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化

- 9.2.2 システム・クロックの同期

- 9.3 構成ウィザードを使用したSOAコンポーネントを使用するためのドメインの拡張

- 9.4 コンポジットをデプロイするためのOracle Coherenceの構成

- 9.4.1 ユニキャスト通信を使用したデプロイメントの通信の有効化

- 9.4.2 Oracle Coherenceで使用するホスト名の指定

- 9.5 構成後タスクおよび検証タスク

- 9.5.1 WLS_SOAn管理対象サーバーに対するホスト名検証の無効化

- 9.5.2 SOAHOST1でのノード・マネージャの再起動

- 9.5.3 管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播

- 9.5.4 WLS_SOA1管理対象サーバーの起動と検証

- 9.5.5 unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播

- 9.5.5.1 SOAHOST2でのXEngineファイルの抽出

- 9.5.6 WLS_SOA2管理対象サーバーの起動と検証

- 9.5.7 GridLinkデータ・ソースの検証

- 9.6 拡張したドメインでのOracle HTTP Serverの構成

- 9.6.1 WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成

- 9.6.2 Oracle HTTP Serverを介したアクセスの検証

- 9.6.3 フロントエンドHTTPホストおよびポートの設定

- 9.6.3.1 フロントエンドHTTPホストおよびポートの設定

- 9.6.3.2 コールバックURLについて

- 9.7 トランザクション・リカバリ用デフォルト永続ストアの構成

- 9.8 Oracleアダプタの構成

- 9.8.1 OracleファイルとFTPアダプタの高可用性化

- 9.8.1.1 データベースのmutexロック操作の使用

- 9.8.2 Oracleデータベース・アダプタのスケーリング

- 9.9 高可用性を実現するためのB2B構成の更新

- 9.10 SOA構成のバックアップ

10 Oracle BPMを追加するためのドメインの拡張

- 10.1 Oracle BPMを追加するためのドメイン拡張の概要

- 10.2 オプション1: SOAおよびBPMを追加するためのドメインの拡張

- 10.2.1 SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化

- 10.2.2 SOAHOST1での構成ウィザードを使用した現在のドメインの拡張

- 10.2.3 コンポジットをデプロイするためのOracle Coherenceの構成

- 10.2.3.1 ユニキャスト通信を使用したデプロイメントの通信の有効化

- 10.2.3.2 Oracle Coherenceで使用するホスト名の指定

- 10.2.4 WLS_SOAn管理対象サーバーに対するホスト名検証の無効化

- 10.2.5 管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播

- 10.2.6 WLS_SOA1管理対象サーバーの起動と検証

- 10.2.7 unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播

- 10.2.8 SOAHOST2でのXEngineファイルの抽出

- 10.2.9 WLS_SOA2管理対象サーバーの起動と検証

- 10.2.10 GridLinkデータ・ソースの検証

- 10.2.11 WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成

- 10.2.12 Oracle HTTP Serverを介したアクセスの検証

- 10.2.13 フロントエンドHTTPホストおよびポートの設定

- 10.2.14 トランザクション・リカバリ用デフォルト永続ストアの構成

- 10.2.15 OracleファイルとFTPアダプタの高可用性化

- 10.2.15.1 データベースのmutexロック操作の使用

- 10.2.16 Oracle JMSアダプタの高可用性化

- 10.2.17 Oracleデータベース・アダプタのスケーリング

- 10.2.18 高可用性を実現するためのB2B構成の更新

- 10.3 オプション2: Oracle BPMを追加するためのSOAドメインの拡張

- 10.3.1 SOAHOST1での構成ウィザードを使用したBPMを追加するためのSOAドメインの拡張

- 10.3.2 SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播

- 10.3.3 BPM Suiteコンポーネントの起動

- 10.3.4 WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成

- 10.3.5 Oracle HTTP Serverを介したアクセスの検証

- 10.4 Oracle BPM構成のバックアップ

11 Oracle Service Busを追加するためのSOAドメインの拡張

- 11.1 SOAドメインへのOracle Service Busの追加の概要

- 11.1.1 Oracle Service Busを追加するためのSOAドメインの拡張の前提条件

- 11.2 SOAHOST1でのVIP5およびSOAHOST2でのVIP6の有効化

- 11.3 SOAHOST1での構成ウィザードを使用したOracle Service Busを追加するためのSOAドメインの拡張

- 11.4 WLS_OSBn管理対象サーバーに対するホスト名検証の無効化

- 11.5 Oracle Service Busの結果キャッシュのOracle Coherenceの構成

- 11.6 トランザクション・リカバリ用デフォルト永続ストアの構成

- 11.7 SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播

- 11.8 Oracle Service Busサーバーの起動

- 11.9 WLS_OSB管理対象サーバーの検証

- 11.10 WLS_OSBn管理対象サーバーについてのOracle HTTP Serverの構成

- 11.11 OSB_Clusterに対するフロントエンドHTTPのホストおよびポートの設定

- 11.12 Oracle HTTP Serverを介したアクセスの検証

- 11.13 Oracle DB、ファイルおよびFTPのアダプタの高可用性化

- 11.14 WLS_OSBサーバーのサーバー移行の構成

- 11.14.1 サーバー移行リース・テーブルのユーザーおよび表領域の設定

- 11.14.2 ノード・マネージャのプロパティ・ファイルの編集

- 11.14.3 wlsifconfig.shスクリプトの環境およびスーパー・ユーザー権限の設定

- 11.14.4 サーバー移行ターゲットの構成

- 11.14.5 サーバー移行の検証

- 11.15 Oracle Service Bus構成のバックアップ

12 BAMを追加するためのドメインの拡張

- 12.1 ドメインへのBAMの追加の概要

- 12.2 BAMを追加するためのドメイン拡張の前提条件

- 12.3 BAMHOST1でのVIP4の有効化

- 12.4 構成ウィザードを使用したドメインの拡張

- 12.5 トランザクション・リカバリ用デフォルト永続ストアの構成

- 12.6 WLS_BAM2からのBAMサーバー・システムのターゲット設定の解除

- 12.7 管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播

- 12.8 WLS_BAMn管理対象サーバーに対するホスト名検証の無効化

- 12.9 BAMHOST1およびBAMHOST2でのノード・マネージャの起動

- 12.10 BAMシステムの起動

- 12.11 GridLinkデータ・ソースの検証

- 12.12 BAMHOST1でBAMサーバーを使用するためのBAM Webアプリケーションの構成

- 12.13 WLS_BAMn管理対象サーバーについてのOracle HTTP Serverの構成

- 12.14 Oracle HTTP Serverを介したアクセスの検証

- 12.15 WLS_BAM1サーバーのサーバー移行の構成

- 12.15.1 サーバー移行リース・テーブルのユーザーおよび表領域の設定

- 12.15.2 管理コンソールによるリース用のGridlinkデータ・ソースの作成

- 12.15.3 ノード・マネージャのプロパティ・ファイルの編集

- 12.15.4 wlsifconfig.shスクリプトの環境およびスーパー・ユーザー権限の設定

- 12.15.5 BAMHOSTnノードのノード・マネージャと管理サーバーのホスト名検証の有効化

- 12.15.6 サーバー移行ターゲットの構成

- 12.15.7 サーバー移行のテスト

- 12.16 BAMクラスタ内のBAMコンポーネントへの構成変更の適用

- 12.17 BAM構成のバックアップ

13 エンタープライズ・デプロイメント用のノード・マネージャの設定

- 13.1 ノード・マネージャの概要

- 13.2 ノード・マネージャのログの場所の変更

- 13.3 SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化

- 13.3.1 utils.CertGenユーティリティを使用した自己署名証明書の生成

- 13.3.2 utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成

- 13.3.3 keytoolユーティリティを使用した信頼キーストアの作成

- 13.3.4 カスタム・キーストアを使用するためのノード・マネージャの構成

- 13.3.5 共通または共有記憶域インストールの使用

- 13.4 SOAHOST1でのノード・マネージャの起動

- 13.5 SOAHOST2でのノード・マネージャに対するホスト名検証証明書の有効化

- 13.5.1 utils.CertGenユーティリティを使用した自己署名証明書の生成

- 13.5.2 utils.ImportPrivateKeyユーティリティを使用したSOAHOST2のアイデンティティのインポート

- 13.5.3 カスタム・キーストアを使用するためのノード・マネージャの構成

- 13.6 SOAHOST2でのノード・マネージャの起動

- 13.7 カスタム・キーストアを使用するためのWebLogic Serverの構成

14 エンタープライズ・デプロイメント用のサーバー移行の構成

- 14.1 エンタープライズ・デプロイメント用のサーバー移行の概要

- 14.2 サーバー移行リース・テーブルのユーザーおよび表領域の設定

- 14.3 管理コンソールによるリース用のGridlinkデータ・ソースの作成

- 14.4 ノード・マネージャのプロパティ・ファイルの編集

- 14.5 wlsifconfig.shスクリプトの環境およびスーパー・ユーザー権限の設定

- 14.6 サーバー移行ターゲットの構成

- 14.7 サーバー移行のテスト

15 エンタープライズ・デプロイメントとOracle Identity Managementの統合

- 15.1 Oracle Identity Managementとの統合の概要

- 15.2 資格証明ストアの構成

- 15.2.1 LDAP認証プロバイダの作成

- 15.2.2 WebLogic管理者のLDAPへの移行

- 15.2.2.1 LDAPディレクトリでの管理ユーザーおよびグループのプロビジョニング

- 15.2.2.2 管理ロールの管理グループへの割当て

- 15.2.2.3 boot.propertiesファイルの更新およびシステムの再起動

- 15.2.3 ドメインの資格証明ストアの再関連付け

- 15.3 ポリシー・ストアの構成

- 15.3.1 サーバー・ディレクトリでのノードの設定

- 15.3.2 ドメイン・ポリシー・ストアの再関連付け

- 15.4 資格証明およびポリシーの再関連付け

- 15.5 Oracle Access Manager 10g統合

- 15.5.1 Oracle Access Manager統合の概要

- 15.5.2 Oracle Access Managerの前提条件

- 15.5.3 OAM構成ツールの使用

- 15.5.3.1 OAM構成ツールの実行の前提条件

- 15.5.3.2 OAM構成ツールの実行

- 15.5.3.3 ポリシー・ドメインおよびアクセス・ゲートを正常に作成したことの確認

- 15.5.3.4 ホスト識別子の更新

- 15.5.3.5 WebGateプロファイルの更新

- 15.5.3.6 アクセス・サーバーの追加

- 15.5.3.7 委任フォーム認証の構成

- 15.5.4 WebGateのインストールと構成

- 15.5.5 Oracle BAMのSOA_EDG_AGでのCacheControlヘッダーの変更

- 15.5.6 WebgateのIP検証の構成

- 15.5.7 WebLogic認証プロバイダの設定

- 15.5.7.1 構成ファイルのバックアップ

- 15.5.7.2 OAM IDアサータの設定

- 15.5.7.3 プロバイダの順序の設定

- 15.6 Oracle Access Manager 11g統合

- 15.6.1 Oracle Access Manager統合の概要

- 15.6.2 Oracle Access Managerの前提条件

- 15.6.3 WebGateのインストール

- 15.6.3.1 GCCライブラリのインストールの前提条件

- 15.6.3.2 WebGateのインストール

- 15.6.3.3 インストール後の手順

- 15.6.4 WebGateエージェントの登録

- 15.6.4.1 RREGツール

- 15.6.4.2 OAM11gRequestファイルの更新

- 15.6.4.3 oamregツールの実行

- 15.6.4.4 アクセス・ファイルのWEBHOSTへのコピー

- 15.6.5 soa-infraのBPMWorkflowAdminアプリケーション・ロールのロール・メンバーの設定

- 15.6.6 WebLogic認証プロバイダの設定

- 15.6.6.1 構成ファイルのバックアップ

- 15.6.6.2 OAM IDアサータの設定

- 15.6.6.3 プロバイダの順序の設定

- 15.7 Identity Management構成のバックアップ

16 エンタープライズ・デプロイメント用のトポロジの管理

- 16.1 トポロジの管理の概要

- 16.2 SOAエンタープライズ・デプロイメント・トポロジにコンポジットおよびアーティファクトをデプロイする際のヒント

- 16.3 SOAインフラストラクチャ・データベースでの領域の管理

- 16.4 UMSドライバの構成

- 16.5 トポロジのスケールアップ(管理対象サーバーを既存ノードに追加)

- 16.5.1 Oracle SOAのスケールアップ手順

- 16.5.2 Oracle BAMのスケールアップ手順

- 16.5.3 Oracle BAMのスケールアップ手順

- 16.5.4 Oracle Service Busのスケールアップ手順

- 16.6 トポロジのスケールアウト(管理対象サーバーを新しいノードに追加)

- 16.6.1 Oracle SOAのスケールアウト手順

- 16.6.2 BAMトポロジのスケール・アウト

- 16.6.3 Oracle BAMのスケールアウト手順

- 16.6.4 Oracle Service Busのスケールアウト手順

- 16.7 管理サーバーの手動フェイルオーバーの検証

- 16.7.1 別ノードへの管理サーバーのフェイルオーバー

- 16.7.2 Oracle HTTP Serverを介したSOAHOST2へのアクセスの検証

- 16.7.3 SOAHOST1への管理サーバーのフェイルバック

- 16.8 SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行

- 16.9 SQLNet接続のタイムアウト防止

- 16.10 失敗したBPELインスタンスとメディエータ・インスタンスのリカバリ

- 16.11 Webサービスに対するDoS攻撃や再帰的ノード攻撃を防ぐための構成

- 16.12 Oracle Business Activity Monitoring (BAM)構成プロパティ

- 16.13 デプロイメント・プランおよびSOAインフラストラクチャ・アプリケーション更新での共有記憶域の使用

- 16.14 エンタープライズ・デプロイメントのトポロジのトラブルシューティング

- 16.14.1 BAMにアクセスするとHTTPエラー404が発生する

- 16.14.2 soa-infraアプリケーションにロード・バランサ経由でアクセスしたときに「ページが見つかりません」というエラーが発生する

- 16.14.3 Oracle B2Bドキュメント定義の取得時にエラーが発生する

- 16.14.4 デプロイメント・フレームワークの問題が原因でsoa-infraアプリケーションの起動に失敗する(Coherence)

- 16.14.5 SOAサーバーの再起動に失敗したためにポリシー移行が未完になる

- 16.14.6 データベース内の最大プロセス数に達したためにSOA、BAMまたはWMSサーバーの起動に失敗する

- 16.14.7 手動フェイルオーバー後に管理サーバーの起動に失敗する

- 16.14.8 管理コンソールで変更をアクティブ化するときにエラーが発生する

- 16.14.9 サーバー移行後にSOA/BAMサーバーがフェイルオーバーしない

- 16.14.10 サーバー移行後にSOA/BAMサーバーにブラウザからアクセスできない

- 16.14.11 SOAサーバーのアクティブ化後、しばらくの間高い負荷がかかるとサーバーが応答を停止する

- 16.14.12 B2Bコンソールでデプロイ/パージ/インポート操作を実行しているときに例外が発生する

- 16.14.13 OAM構成ツール実行時にURLが削除されない

- 16.14.14 管理コンソールで変更をアクティブ化した後にユーザーがログイン画面にリダイレクトされる

- 16.14.15 OAMに対する変更をアクティブ化した後でユーザーが管理コンソールのホーム・ページにリダイレクトされる

- 16.14.16 構成されたJOCポートがすでに使用中

- 16.14.17 SOAサーバーまたはBAMサーバーの起動に失敗する

- 16.14.18 B2Bデリバリ・チャネル更新のためのJOCの構成

- 16.14.19 同じノードに複数のクラスタがある場合のSOA Coherenceクラスタの不一致

- 16.14.20 サーバー移行時にSudoエラーが発生する

- 16.14.21 トランザクション・タイムアウト・エラー

- 16.14.22 最大サイズ超過エラー・メッセージ

- 16.14.23 同期していないクロックがエラーの原因になる

A Oracle RACでのマルチ・データ・ソースの使用

- A.1 マルチ・データ・ソースとOracle RAC

- A.2 EDGトポロジ用のマルチ・データ・ソースを構成する標準手順

B アプリケーションとリソースのサーバーへのターゲット設定

- B.1 Oracle SOA Suiteのアプリケーション・ターゲット

- B.2 Oracle SOAエンタープライズ・デプロイメント・ライブラリのターゲット

- B.3 Oracle SOAエンタープライズ・デプロイメント起動クラスのターゲット

- B.4 Oracle SOAエンタープライズ・デプロイメント停止クラスのターゲット

- B.5 Oracle SOAエンタープライズ・デプロイメントJMSシステム・リソースのターゲット

- B.6 Oracle SOAエンタープライズ・デプロイメントJDBCシステム・リソースのターゲット

- B.7 Oracle SOAエンタープライズ・デプロイメントWLDFシステム・リソースのターゲット

- B.8 Oracle SOAエンタープライズ・デプロイメント自己チューニング・リソースのターゲット

索引

はじめに

「はじめに」では、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の対象読者、内容および表記規則について説明します。

対象読者

このガイドは、Oracle Fusion Middlewareエンタープライズ・デプロイメントのインストールや構成を担当するシステム管理者を対象としています。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

ドキュメント内のサンプル・コードのアクセシビリティについて

スクリーン・リーダーは、ドキュメント内のサンプル・コードを正確に読めない場合があります。コード表記規則では閉じ括弧のみを行に記述する必要があります。しかし一部のスクリーン・リーダーは括弧のみの行を読まない場合があります。

外部Webサイトのドキュメントのアクセシビリティについて

このドキュメントにはオラクル社およびその関連会社が所有または管理しないWebサイトへのリンクが含まれている場合があります。オラクル社およびその関連会社は、それらのWebサイトのアクセシビリティに関しての評価や言及は行っておりません。

Oracleサポートへのアクセス

お客様は、My Oracle Supportを使用して電子サポートにアクセスできます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

Oracle Fusion Middlewareドキュメント・ライブラリにある次のマニュアルに、エンタープライズ・デプロイメント・アーキテクチャをインストールおよび構成する手順に関する追加情報があります。

- Oracle Fusion Middleware管理者ガイド

- 『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』

- 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するグラフィカル・ユーザー・インタフェース要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、パラグラフ内のコマンド、URL、例に記載されているコード、画面に表示されるテキスト、または入力するテキストを示します。

1 エンタープライズ・デプロイメントの概要

この章では、Oracle SOA Suite用エンタープライズ・トポロジの概要について説明します。この章の項目は次のとおりです。

- 第1.1項「エンタープライズ・デプロイメント・ガイドについて」

- 第1.2項「エンタープライズ・デプロイメントの用語」

- 第1.3項「Oracle推奨事項のメリット」

1.1 エンタープライズ・デプロイメント・ガイドについて

エンタープライズ・デプロイメント・ガイドは、Oracle SOAエンタープライズ・デプロイメントの実証済高可用性テクノロジ、セキュリティ・テクノロジおよび推奨事項に基づいたベスト・プラクティスの青写真です。これらの青写真に示すベスト・プラクティスは、技術スタック全体において多くのOracle製品を対象にしています。それらの製品には、Oracle Database、Oracle Fusion MiddlewareおよびEnterprise Manager Fusion Middleware Controlがあります。

Oracle Fusion Middlewareのエンタープライズ・デプロイメントの特長は、次のとおりです。

- 様々な業務のサービス・レベル合意(SLA)を考慮して、高可用性ベスト・プラクティスをできるだけ広範囲に適用できるようにします。

- データベース・グリッド・サーバーと低コストのストレージを使用したストレージ・グリッドを活用し、回復力に優れ低コストのインフラストラクチャを提供します。

- 様々な構成を対象として広範囲なパフォーマンス影響調査の結果を利用し、ビジネス・ニーズに応じて実行およびスケールできるように高可用性アーキテクチャが最適に構成されます。

- 停止状態からのリカバリ時間と自然災害時に許容可能なデータ損失量を制御できます。

- ベスト・プラクティスと推奨アーキテクチャが使用されます。それらは、ハードウェアとオペレーティング・システムには依存していません。

高可用性の実現の詳細は、Oracle Technology NetworkのOracle Database高可用性ページ(http://www.oracle.com/technetwork/database/features/availability/maa-best-practices-155366.html)を参照してください。

注意:

Oracle SOAのエンタープライズ・デプロイメント・ガイドは、Linux環境におけるエンタープライズ・デプロイメントを中心に説明しています。しかしながら、UNIX環境やWindows環境を使用したエンタープライズ・デプロイメントの実装も可能です。

1.2 エンタープライズ・デプロイメントの用語

この項では、このガイドで使用されているエンタープライズ・デプロイメント用語について説明します。

- Oracleホーム: Oracleホームには、特定の製品をホストするために必要なファイルがインストールされて格納されています。たとえば、SOAのOracleホームには、Oracle SOA Suiteのバイナリとライブラリ・ファイルが格納されているディレクトリがあります。Oracleホームは、ミドルウェア・ホームのディレクトリ構造の内部にあります。各Oracleホームは、複数のOracleインスタンスやOracle WebLogic Serverドメインと関連付けることができます。

- Oracle共通ホーム: この環境変数と関連ディレクトリ・パスは、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files (JRF)に必要なバイナリおよびライブラリ・ファイルが含まれるOracleホームを指しています。

- WebLogic Serverホーム: WebLogic Serverホームには、WebLogic Serverをホストするために必要なファイルがインストールされて格納されています。WebLogic Serverホームのディレクトリは、Oracleホームのディレクトリのピアで、ミドルウェア・ホームのディレクトリ構造の内部にあります。

- ミドルウェア・ホーム: ミドルウェア・ホームは、Oracle WebLogic Serverホームと、オプションとして1つまたは複数のOracleホームで構成されます。ミドルウェア・ホームは、ローカル・ファイルシステムに配置できますし、NFSを介してアクセス可能なリモート共有ディスクにも配置できます。

- Oracleインスタンス: Oracleインスタンスには、アクティブなミドルウェア・システム・コンポーネントが1つ以上あります。コンポーネントの例には、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなどがあります。インストール時かその後でインスタンスの作成と構成を行うときに、インスタンスにどのコンポーネントを含めるかを決定します。Oracleインスタンスには、更新可能なファイルがあります。それらのファイルの例には、構成ファイル、ログ・ファイル、一時ファイルなどがあります。

- フェイルオーバー: 高可用性システムのメンバーで障害(計画外停止時間)が突然発生した場合、システムでは、コンシューマへのサービスの提供を続けるために、フェイルオーバー操作が実行されます。システムがアクティブ/パッシブ型システムの場合、パッシブ・メンバーはフェイルオーバー操作においてアクティブになります。そしてコンシューマは、障害が発生したメンバーではなく、アクティブになったメンバーにリダイレクトされます。フェイルオーバー操作は、手動でも実行できます。また、障害を検出した場合にクラスタのリソースを障害ノードからスタンバイ・ノードに移動するように、ハードウェア・クラスタ・サービスを設定することで、フェイルオーバー操作を自動化することもできます。システムがアクティブ/アクティブ型システムの場合、ロード・バランサのエンティティによりフェイルオーバーが実行されます。このエンティティによって、リクエストがアクティブ・メンバーで処理されます。アクティブ・メンバーに障害が発生すると、ロード・バランサにより障害が検出され、障害メンバーへのリクエストが、正常に動作しているアクティブ・メンバーに自動的にリダイレクトされます。アクティブ/アクティブ型システムとアクティブ/パッシブ型システムの詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

- フェイルバック: システムで正常にフェイルオーバー操作が実行されると、元の障害メンバーはしばらく時間をかけて修復することができ、スタンバイ・メンバーとしてシステムに再導入できます。必要に応じて、フェイルバック処理を開始して、このメンバーをアクティブにし、別のメンバーを非アクティブにすることができます。この処理によりシステムは、障害発生前の構成に戻ります。

- ハードウェア・クラスタ: ハードウェア・クラスタは、ネットワーク・サービス(たとえば、IPアドレス)やアプリケーション・サービス(たとえば、データベース、Webサーバー)を単一のビューでサービスのクライアントに提供するコンピュータのコレクションです。ハードウェア・クラスタの各ノードは、それぞれ固有のプロセスを実行するスタンドアロン・サーバーです。これらのプロセスは互いに通信して、単一のシステムであるかのように動作して、アプリケーション、システム・リソースおよびデータを連携してユーザーに提供できます。
特別なハードウェア(クラスタ・インターコネクト、共有記憶域)とソフトウェア(ヘルス・モニター、リソース・モニター)を使用することで、ハードウェア・クラスタにより高可用性とスケーラビリティが実現されます。クラスタ・インターコネクトは、ハートビート情報でノード障害を検出するハードウェア・クラスタで使用されるプライベート・リンクです。専用のハードウェアとソフトウェアが必要であるため、通常、ハードウェア・クラスタはオラクル社、HP社、IBM社、Dell社などのハードウェア・ベンダーによって提供されます。ハードウェア・クラスタで構成可能なノードの数はベンダーによって異なりますが、Oracle Fusion Middlewareの高可用性を実現するのに必要なノードの数は2つのみです。このため、ハードウェア・クラスタを使用する高可用性ソリューションでは、2つのノードによるハードウェア・クラスタがこのドキュメントで前提にされています。

- クラスタ・エージェント: ハードウェア・クラスタのノード・メンバー上で実行されるソフトウェアであり、可用性とパフォーマンスの操作を他のノードと連携して調整します。クラスタウェアによりリソースのグループ化と監視を行い、サービスを移行できます。クラスタ・エージェントではサービスのフェイルオーバーを自動化できます。

- クラスタウェア: クラスタ・メンバーの操作をシステムとして管理するソフトウェアです。リソースとサービスのセットを定義してから、ハートビートのメカニズムにより複数のクラスタ・メンバー間において監視を行い、これらのリソースとサービスを別のクラスタ・メンバーにできるだけ効率的かつ透過的に移動できます。

- 共有記憶域: エンタープライズ・デプロイメント・ドメイン内のすべてのマシンがアクセスできる記憶域のサブシステムです。共有ディスクには特に次のものが配置されています。

- ミドルウェア・ホームのソフトウェア

- AdminServerドメイン・ホーム

- JMS

- Tlogs(該当する場合)

必要に応じて、管理対象サーバーのホームを共有ディスクに配置できます。共有記憶域は、Network Attached Storage (NAS)またはStorage Area Network (SAN)にすることができます。また、複数のノードが同時にアクセスして読込みと書込みができる他のストレージ・システムにすることもできます。

- 1次ノード: Oracle Fusion Middlewareインスタンスをいつでもアクティブに実行しているノードであり、バックアップ/2次ノードを持つように構成されているノードです。1次ノードに障害が発生すると、Oracle Fusion Middlewareインスタンスでは2次ノードにフェイルオーバーされます。このフェイルオーバーは手動でも実行できますし、管理サーバー用のクラスタウェアを使用して自動的に実行できます。サーバー移行機能に基づいたシナリオでは、WebLogic Whole Server移行機能が自動化フェイルオーバーに使用されています。

- 2次ノード: Oracle Fusion Middlewareインスタンス用のバックアップ・ノードであるノードです。1次ノードが使用できなくなると、アクティブなインスタンスでフェイルオーバーが実行されます。この項で、1次ノードに関する定義を参照してください。

- ネットワーク・ホスト名: ネットワーク・ホスト名は、/etc/hostsファイルやDNS解決によりIPアドレスに割り当てられる名前です。この名前は、参照先マシンに接続する際にネットワークで参照可能です。ネットワーク・ホスト名と物理ホスト名が同一である場合があります。ただし、各マシンには物理ホスト名は1つのみ付与されますが、ネットワーク・ホスト名は複数付与される場合があります。そのため、マシンのネットワーク・ホスト名はその物理ホスト名であるとはかぎりません。

- 物理ホスト名: このガイドでは、物理ホスト名とネットワーク・ホスト名の用語は区別しています。このガイドでは、現在のマシンの内部名を指す場合に物理ホスト名が使用されます。UNIXでは、hostnameコマンドにより返される名前です。
Oracle Fusion Middlewareで使用される物理ホスト名は、ローカル・ホストを示します。インストール中に、インストーラでは物理ホスト名が現在のマシンから自動的に取得され、ディスク上のOracle Fusion Middleware構成メタデータに格納されます。

- 物理IP: 物理IPは、ネットワークにおけるマシンのIPアドレスを指します。ほとんどの場合、マシンの物理ホスト名と関連付けられます(物理ホスト名に関する定義を参照)。仮想IPと対照的に、マシンがネットワークに接続されると、必ず同じマシンと関連付けられます。

- スイッチオーバー: 通常の運用では、システムのアクティブ・メンバーでメンテナンスやアップグレードが必要になることがあります。スイッチオーバー処理を開始して、メンテナンスやアップグレード(計画停止中に実施)が必要なメンバーが処理していたワークロードを、代替メンバーが引き継ぐことができます。スイッチオーバー処理により、システムのコンシューマに対してサービスが続行できるようになります。

- スイッチバック: スイッチバック処理が実行されると、システムのメンバーは非アクティブ化され、メンテナンスやアップグレードができるようになります。メンテナンスやアップグレードが完了すると、システムでスイッチバック処理を実行して、アップグレードしたメンバーをアクティブ化し、スイッチオーバー前の構成にシステムを戻すことがきます。

- 仮想ホスト名: 仮想ホスト名は、ネットワーク・アドレスで参照可能なホスト名で、ロード・バランサやハードウェア・クラスタにより1台以上の物理マシンにマッピングされます。ロード・バランサの場合、このマニュアルでは仮想サーバー名の名前は仮想ホスト名と同じ意味で使用されます。複数のサーバーのセットを代表する仮想ホスト名をロード・バランサに付与でき、クライアントは仮想ホスト名を使用して、間接的にマシンと通信します。ハードウェア・クラスタの仮想ホスト名は、クラスタの仮想IPに割り当てられるネットワーク・ホスト名です。クラスタにある特定ノードにクラスタの仮想IPが永続的に付与されないため、仮想ホスト名も特定ノードに永続的に付与されません。

注意:

仮想ホスト名の用語がこのドキュメントで使用されるときは必ず、仮想IPアドレスで割り当てられることが前提になります。IPアドレスが必要とされたり使用される場合、明示的に言及します。

- 仮想IP: また、クラスタの仮想IPとロード・バランサの仮想IPです。一般的に、仮想IPはハードウェア・クラスタやロード・バランサに割り当てることができます。クラスタにおいて単一のシステム・ビューをネットワークのクライアントに対して実現するために、クラスタのメンバーであるサーバーのグループに対して仮想IPはエントリ・ポイントのIPアドレスとして機能します。仮想IPはハードウェア・クラスタやサーバーのロード・バランサに割り当てることができます。
ハードウェア・クラスタではクラスタの仮想IPが使用され、外部の世界に対してクラスタ(スタンドアロンのマシンにも設定可能)へのエントリ・ポイントを実現します。ハードウェア・クラスタのソフトウェアにより、クラスタにある2台の物理ノード間においてこのIPアドレスの変更が管理されますが、クライアントはこのIPアドレスに接続します。その際、このIPアドレスが現在アクティブである物理ノードを判別する必要はありません。2台のノードによる標準的構成では、各マシンには固有の物理IPアドレスと物理ホスト名が付与されながら、数個のクラスタIPアドレスを付与することもできます。これらのクラスタIPアドレスは、2台のノードおいて切り替わります。クラスタIPアドレスを現在所有しているノードは、そのアドレスでアクティブになります。

また、ロード・バランサでも、複数のサーバーのセットのエントリ・ポイントとして仮想IPが使用されます。これらのサーバーは、同時にアクティブになる傾向があります。この仮想IPアドレスは個々のサーバーには割り当てられませんが、サーバーとクライアントとの間においてプロキシとして動作するロード・バランサに割り当てられます。

1.3 Oracle推奨事項のメリット

このガイドで説明するOracle Fusion Middleware構成では、すべての起動でセキュリティが確保され、ハードウェア・リソースが最大化され、様々なアプリケーションを使用したエンタープライズ・コンピューティングのために、信頼性が高く、標準に準拠したシステムを提供するために設計されています。

Oracle Fusion Middleware構成のセキュリティと高可用性のメリットは、ファイアウォール・ゾーンの分離とソフトウェア・コンポーネントのレプリケーションを通じて実現されます。

この項には次のトピックが含まれます:

- 第1.3.1項「組込みセキュリティ」

- 第1.3.2項「高可用性」

1.3.1 組込みセキュリティ

エンタープライズ・デプロイメントのアーキテクチャは、ソフトウェア・コンポーネントの各機能グループが独自のDMZ内で独立しており、すべてのトラフィックがプロトコルとポートによって制限されているため、保護されています。次の特長により、必要なレベルのすべてのセキュリティが確保され、高レベルの標準の準拠が実現します。

- ポート80で受信した外部通信はすべてポート443にリダイレクトするように、外部のロード・バランサを構成します。

- 外部のクライアントからの通信はロード・バランシング・ルーターを超えたレベルでは発生しません。

- ロード・バランシング・ルーターからデータ層への直接的な通信は許可されません。

- コンポーネントは、Web層、アプリケーション層およびデータ層の異なる保護ゾーンで分離されています。

- 一度に2つのファイアウォールをまたがる直接的な通信は禁止されています。

- 1つのファイアウォール・ゾーンで通信が始まった場合、それは次のファイアウォール・ゾーンで終わる必要があります。

- Oracle Internet Directoryはデータ層内で独立しています。

- アイデンティティ管理コンポーネントは別のサブネットにあります。

- 複数の保護ゾーンにおいて複数のコンポーネント間の通信はすべて、ファイアウォールのルールに従いポートとプロトコルによって制限されます。

1.3.2 高可用性

各コンポーネントまたはソフトウェア・コンポーネントの機能グループが別のコンピュータにレプリケートされており、コンポーネント・レベルでの高可用性を実現するように構成されます。このため、エンタープライズ・デプロイメント・アーキテクチャでは高い可用性が実現されます。

2 エンタープライズ・デプロイメント参照用トポロジの紹介

この章では、このガイドで使用するエンタープライズ・デプロイメント参照用トポロジについて説明します。インストールと構成のロード・マップでは、実行する必要のあるタスクが記載されている章へと導きます。この章を利用してOracle SOAエンタープライズ・デプロイメントを計画してください。

この章の内容は次のとおりです。

- 第2.1項「エンタープライズ・デプロイメント参照用トポロジの概要」

- 第2.2項「Linuxにおけるエンタープライズ・デプロイメントのハードウェア要件」

- 第2.3項「インストールするソフトウェア・コンポーネントの特定」

- 第2.4項「資格証明ストアとポリシー・ストアとしてのLDAPについて」

- 第2.5項「クロックの同期」

- 第2.6項「参照用トポロジのインストールおよび構成のロード・マップ」

2.1 エンタープライズ・デプロイメント参照用トポロジの概要

この項のダイアグラムには、このガイドに記載されている3つの考えられるエンタープライズ・デプロイメント・トポロジが図示されています。この項を使用してエンタープライズ・デプロイメント・トポロジを計画してください。

この項の項目は次のとおりです。

- 第2.1.1項「このガイドに記載されている参照用トポロジ」

- 第2.1.2項「Oracle Identity Managementの統合について」

- 第2.1.3項「Web層ノードについて」

- 第2.1.4項「ロード・バランサの要件」

- 第2.1.5項「アプリケーション層について」

- 第2.1.6項「データ層について」

- 第2.1.7項「通信のユニキャスト要件について」

2.1.1 このガイドに記載されている参照用トポロジ

このガイドでは、サービス指向アーキテクチャ(SOA)を、Oracle Access Manager (図2-1)、Oracle Access ManagerおよびOracle Business Activity Monitoring (BAM)(図2-2)、Oracle Access ManagerおよびBAM (図2-3)またはOracle Service Bus (図2-4)とともに使用する参照用エンタープライズ・トポロジのための構成手順について説明します。

注意:

実際のエンタープライズ・デプロイメントでは、このガイドで説明するトポロジを一部変更して使用する場合もあります。

2.1.1.1 Oracle Access Managerを使用したMySOACompanyトポロジ

図2-1は、Oracle Access Managerが含まれているMySOACompnayトポロジを表しています。

図2-1 Oracle Access Managerを使用したMySOACompanyトポロジ

2.1.1.2 Oracle Access ManagerとBusiness Activity Monitoringを使用したMySOACompanyトポロジ

図2-2は、Oracle Access ManagerおよびBusiness Activity Monitoringが含まれているMySOACompanyトポロジを表しています。

図2-2 Oracle Access ManagerとBusiness Activity Monitoringを使用したMySOACompanyトポロジ

2.1.1.3 Oracle Access ManagerとOracle BPMを使用したMySOACompanyトポロジ

図2-3は、Oracle Access ManagerおよびOracle BPMが含まれているMySOACompanyトポロジを表しています。

図2-3 Oracle Access ManagerとBAMを使用したMySOACompanyトポロジ

2.1.1.4 Oracle Service Busを使用したMySOACompanyトポロジ

図2-4は、Oracle Service Busが含まれているMySOACompanyトポロジを表しています。

図2-4 Oracle Service Busを使用したMySOACompanyトポロジ

2.1.2 Oracle Identity Managementの統合について

Oracle Identity Managementシステムとの統合は、エンタープライズ・デプロイメント・アーキテクチャの重要な側面です。この統合により、シングル・サインオン、Oracle Platform Security Servicesとの統合、一元化されたアイデンティティおよび資格証明ストア、WebLogicドメインにおける認証などの機能が実現されます。IDMエンタープライズ・デプロイメントはこのエンタープライズ・デプロイメントとは別であり、それ自体で別のドメイン内に存在します。エンタープライズ・デプロイメントにおけるOracle Identity Managementの詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

Oracle Identity Managementエンタープライズ・デプロイメントへの主要インタフェースは、LDAPサーバーへのLDAPトラフィック、OAMアクセス・サーバーへのOAP (Oracle Access Protocol)および認証リクエストのHTTPリダイレクトです。

2.1.3 Web層ノードについて

Web層のノードはDMZパブリック・ゾーンにあります。

この層では、WEBHOST1とWEBHOST2という2つのノードが、WebGateおよびmod_wl_ohsとともに構成されているOracle HTTP Serverを実行します。

Oracle HTTP Serverを、ロード・バランサと複数のWebLogic Server間の仲介ポイントとして使用した場合、次のようなメリットが得られます。

- これは犠牲エリア/DMZを提供します。これはセキュリティ監査で求められる一般的な要件であり、ロード・バランサ/WebLogicシステムにおける大きな問題でもあります。ロード・バランサがWebLogic Serverに直接ルーティングされると、リクエストがロード・バランサからアプリケーション層に1回のHTTPジャンプで移動するため、セキュリティ上問題があります。

- Webサーバー構成を変更することなく、WebLogic Serverクラスタ・メンバーシップを再構成(新規サーバーの追加とサーバーの削除)できます(構成したリスト内のサーバーのいくつかがアライブであることが条件)。プラグインはクラスタ・メンバーシップを学習し、それに応じて作業を振り分けます。

- WebLogic Serverインスタンスで障害が発生した場合に、すぐにフェイルオーバーできます。プラグインは、WebLogic Serverインスタンスの障害発生をピアからの情報を利用して積極的に学習します。障害が発生したサーバーは、再び使用可能なったことをピアがプラグインに通知するまでは使用されません。一般的にロード・バランサにはこれよりも多くの制限があります。

- Oracle HTTP Serverは、WebLogic Serverよりも速く効率的に静的コンテンツを配信します。

- WebLogic Serverで提供されているものを超えるHTTPリダイレクション。Oracle HTTP Serverを多数の様々なWebLogic Serverクラスタのフロント・エンドとして使用できるため、たとえば、コンテンツ・ベースのルーティングを実施できます。

- SSOが必要な場合、Oracle Identity ManagementをサポートできるのはOracle HTTP Server (WebLogic Serverではなく)のみです。

Oracle HTTP ServerからWebLogic Serverへのリクエストのプロキシを許可するmod_wl_ohsを通じて、Oracle HTTP Serverはアプリケーション層で実行されているWebLogic Serverにリクエストを転送します。

Oracle HTTP ServerにあるWebGate (Oracle Access Managerコンポーネント)はOracle Access Protocol (OAP)を使用して、アイデンティティ管理DMZ内のOAMHOST2で実行されているOracle Access Managerと通信します。WebゲートとOracle Access Managerは、ユーザー認証などの操作の実行に使用されます。

Web層には外部リクエストを処理するロード・バランサ・ルータも含まれています。外部リクエストは、ロード・バランサで構成されている仮想ホスト名に送信されます。ロード・バランサは、このリクエストをOracle HTTP Serverに転送します。

Oracle HTTP Server内のWebGateモジュールは、Oracle Access Protocol (OAP)を使用してOracle Access Managerと通信し、ユーザー・グループへの問合せなどの操作を実行します。

Web層を保護しているファイアウォールでは、HTTPポート、つまりHTTPS用のポート443とHTTP用のポート80のみが開いています。

2.1.4 ロード・バランサ要件

このエンタープライズ・トポロジは外部のロード・バランサを使用します。この外部ロード・バランサには、次の機能が必要です。

- 仮想ホスト名を使用してトラフィックを実際のサーバーのプールにロード・バランシングする機能: クライアントは仮想ホスト名を使用してサービスにアクセスします(実際のホスト名は使用しない)。ロード・バランサは、リクエストをプールのサーバーにロード・バランスできるようになります。

- ポート変換構成が可能である必要があります。これによって、仮想ホスト名とポートにおける入力リクエストが、バックエンド・サーバーにある別のポートにリダイレクトされます。

- プールにあるサーバーのポートを監視してサービスの可用性を判定する機能。

- 仮想サーバーとポートの構成: 仮想サーバー名とポートを外部ロード・バランサ上で構成できる機能。仮想サーバー名とポートは次の要件を満たす必要があります。

- ロード・バランサは複数の仮想サーバーの構成が可能である必要がある。各仮想サーバーに対して、ロード・バランサは複数のポート上でトラフィック管理の構成を行える必要があります。たとえば、Web層のOracle HTTP Serverの場合、ロード・バランサでは、HTTPとHTTPSのトラフィックに対して仮想サーバーとポートで構成されている必要があります。

- 仮想サーバー名は、IPアドレスに関連付けられていて、DNSの一部である必要がある。クライアントは仮想サーバー名を使用して外部ロード・バランサにアクセスできる必要があります。

- ノードの障害を検出し、障害のあるノードへのトラフィックのルーティングを即時に停止する機能。

- フォルト・トレラント・モード: ロード・バランサをフォルト・トレラント・モードに構成することを強くお薦めします。

- トラフィックの転送先となるバックエンド・サービスが使用不可の場合に、即座にコール元クライアントに戻るようにロード・バランサの仮想サーバーを構成しておくことを強くお薦めします。これは、クライアントのマシンにおけるTCP/IP設定に基づいてタイムアウト後にクライアントを切断する方法よりも望ましい構成です。

- スティッキーなルーティング機能: コンポーネントに対してスティッキーな接続を維持できる機能です。この例には、Cookieベースの永続性やIPベースの永続性などが含まれています。

- ロード・バランサはSSLリクエストをロード・バランサで終了して、同等の非SSLプロトコル(たとえば、HTTPSからHTTP)を使用してトラフィックを実際のバックエンド・サーバーに転送できる必要があります。この機能は一般にSSL終了と呼ばれ、このエンタープライズ・デプロイメントで必要になります。

- SSLアクセラレーション: SSLトランザクションで実行され、公開鍵暗号化アルゴリズムをハードウェア・アクセラレータにオフロードします。この機能は推奨されますが、必須ではありません。

2.1.5 アプリケーション層について

アプリケーション層のノードはDMZセキュア・ゾーンにあります。

この層では、SOAHOST1とSOAHOST2の2つのノードが、BPELプロセス・マネージャやB2BなどのSOAコンポーネントを実行するための管理対象サーバーとともに構成されているOracle WebLogic Serverを実行します。管理対象サーバーは、アクティブ/アクティブで構成されます。

BAMHOST1とBAMHOST2では、BAMサーバーとBAM Webアプリケーションが実行されます。

また、SOAHOST1とSOAHOST2でもOracle WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlが実行されますが、アクティブ/パッシブ構成で動作します。1つのドメイン内で実行できる管理サーバーは1つのみなので、管理サーバーのアクティブ/パッシブ構成が必要です。図では、現在はSOAHOST1上の管理サーバーがアクティブな状態ですが、SOAHOST2上の管理サーバーに手動でフェイルオーバーできます。

詳細は、第8.8項「管理サーバーの手動フェイルオーバーの検証」を参照してください。また、そのかわりに、Oracle WebLogic Server管理コンソールをCFC/CRSで構成して、自動で別のハードウェア・クラスタでフェイルオーバーすることもできます(このアーキテクチャでは記載されていません)。

Oracle Web Services Manager (Oracle WSM)は、エンタープライズ・デプロイメント・トポロジにおけるWebサービスの管理と保護を目的としたポリシー・フレームワークを提供します。また、WSMのポリシー・マネージャでは、さらに2台のWebLogic Serverでアクティブ/アクティブ構成で実行されます。

アプリケーション層を保護しているファイアウォールでは、HTTPポート、OAPポートおよびプロキシ・ポートが開きます。OAPポートは、Web層のOracle HTTP Serverで実行されているWebGateモジュールがOracle Access Managerと通信するためのものです。外部のHTTPアクセスが必要なアプリケーションでは、Oracle HTTP Serverがプロキシとして使用されます。Oracle HTTP Server上のプロキシが有効にされて、このアクセスが許可される必要があります。

2.1.6 データ層について

データ層のノードは、最もセキュアなネットワーク・ゾーン(イントラネット)に配置されます。

この層では、Oracle RACデータベースがCUSTDBHOST1とCUSTDBHOST2のノードで実行されます。データベースには、SOA、BAMおよびOracle Service Busコンポーネントで必要となるスキーマが含まれています。アプリケーション層で実行するSOA、BAMおよびOracle Service Busコンポーネントはこのデータベースにアクセスします。

データ層を保護しているファイアウォールでは、データベース・リスナー・ポート(一般的には1521)が開かれている必要があります。また、IDMエンタープライズ・デプロイメントでLDAP記憶域にアクセスするトラフィックに対して、LDAPポート(一般的には389および636)が開いている必要があります。

2.1.7 通信のユニキャスト要件について

mySOACompanyトポロジにあるノードはユニキャストを使用して通信することをお薦めします。マルチキャスト通信と異なり、ユニキャストではネットワーク間構成は不要です。また、これによって、マルチキャスト・アドレス競合により発生する場合がある潜在的なネットワーク・エラーも減少します。

ユニキャスト・メッセージング・モードでは、チャンネルが構成されていないとサーバーのデフォルトのリスニング・ポートが使用されます。

クラスタ・メンバーは、ブロードキャスト・メッセージ(通常はハートビート・メッセージ)を送信する必要がある場合、グループ・リーダーと通信します。クラスタ・メンバーがグループ・リーダーの障害を検出すると、その次に古いメンバーがグループ・リーダーになります。

ユニキャスト・モードでの通信頻度は、マルチキャスト・ポートでのメッセージの送信頻度と同程度です。

ユニキャストを使用してクラスタ通信を処理する際に次の考慮事項が適用されます。

- WebLogicクラスタのすべてのメンバーでは、同じメッセージ・タイプを使用する必要があります。マルチキャストとユニキャストのメッセージを混在させることはできません。

- 個々のクラスタ・メンバーでは、クラスタのメッセージ・タイプのオーバーライドはできません。

- メッセージ・モードを変更(マルチキャストとユニキャストとの間における切替え)するには、クラスタ全体を停止してから再起動する必要があります。

- マルチキャスト通信用に構成されたJMSトピックは、ユニキャスト通信用に構成されたWebLogicクラスタにアクセスできます。クラスタ・アドレスとは関係なく固有のマルチキャスト・アドレスでJMSトピックがメッセージを発行するためです。ただし、次の考慮事項が適用されます。

- クラスタでユニキャスト通信が可能なルーター・ハードウェア構成では、JMSマルチキャスト・サブスクライバが機能できない場合があります。

- JMSマルチキャスト・サブスクライバでは、マルチキャスト・アクセスが可能なネットワーク・ハードウェア構成で動作する必要があります。つまり、JMSサブスクライバは、マルチキャストのトピックにアクセスするために、マルチキャスト対応ネットワークで動作する必要があります。

2.2 Linuxにおけるエンタープライズ・デプロイメントのハードウェア要件

Oracle Fusion Middlewareのシステム要件および仕様のドキュメントを読み、環境がインストールする製品の最低のインストール要件を満たしていることを確認します。このドキュメントには、ハードウェアとソフトウェアの要件、ディスク領域とメモリーの最小要件、データベース・スキーマの要件、および必要なシステム・ライブラリ、パッケージまたはパッチに関する情報が記載されています。

表2-1は、このLinuxオペレーティング・システム向けガイドで説明するエンタープライズ・デプロイメントで要求される標準的なハードウェア要件です。メモリー容量の数値は、Oracle Fusion Middlewareサーバーのインストールと実行に必要なメモリーを表していますが、ほとんどの本番サイトには4GB以上の物理メモリーを構成してください。

適切なキャパシティ・プランニングを実施して、ノードの数、特定のシステムへの負荷に応じてノードごとにおけるCPUとメモリーに関する要件、スループットとレスポンスに関する要件を決める必要があります。これらは、使用するカスタムSOAシステムやアプリケーションごとに異なります。

表2-1 標準ハードウェア要件

サーバー

ディスク

メモリー

TMPディレクトリ

スワップ

データベース

nXm

n: ディスクの台数(台数は4台以上で、1台のディスクはストライプ)

m: ディスクの容量(30GB以上)

6 - 8GB

デフォルト

デフォルト

WEBHOSTn

10GB

4GB

デフォルト

デフォルト

SOAHOSTn (SOAのみ)

10GB脚注1

4GB

デフォルト

デフォルト

SOAHOSTn (SOAおよびOSB)

11GB脚注2

6GB

デフォルト

デフォルト

BAMHOSTn

10GB脚注3

4GB

デフォルト

デフォルト

脚注 1 共有記憶域のミドルウェア・ホーム構成の場合、2つのインストールでは、スロット数と関係なく合計20GBになるようにすると十分です。

脚注2共有記憶域のミドルウェア・ホーム構成の場合、2つのインストールでは、スロット数と関係なく合計20GBになるようにすると十分です。

脚注3 BAMでは共有記憶域のSOAインストールからミドルウェア・ホーム・バイナリを再利用できます。

2.3 インストールするソフトウェア・コンポーネントの特定

表2-2に、このガイドの手順を開始する前に入手しておく必要のあるOracleソフトウェアを示します。

Oracle Fusion Middlewareソフトウェアのダウンロードの詳細は、Oracle Technology Network (OTN)のOracle Fusion Middlewareのダウンロード、インストールおよび構成のREADMEファイルを参照してください。

表2-2 コンポーネントおよびインストール・ソース

コンポーネント

詳細

Oracle Database 10gまたは11g

AL32UTF8キャラクタ・セットを使用するOracle Database 10gディストリビューション(データベース10.2.0.4以降のSEまたはEEバージョン)

AL32UTF8キャラクタ・セットを使用するOracle Database Server 11gディストリビューション(データベース11.1.0.7以降のSEまたはEEバージョン)

Repository Creation Utility (RCU)

(RCUは様々なLinuxプラットフォームで使用できる汎用ユーティリティです。32ビットおよび64ビットのLinuxに同じビット数のものがインストールされます。)

Oracle Fusion Middleware Repository Creation Utility 11g (11.1.1.7)ディストリビューション

Oracle WebLogic Server (WLS)

Oracle WebLogic Server (10.3.6)ディストリビューション

Oracle HTTP Server (OHS)

Oracle Fusion Middleware WebTier and Utilities 11g (11.1.1.7)ディストリビューション

Oracle SOA Suite

Oracle SOA Suite 11g (11.1.1.7)ディストリビューション

Oracle Access Manager (OAM) WebGate

OAM 10gの場合はWebGate 10g (10.1.4.3)、OAM 11gの場合はWebGate 11g (11.1.1.2以降)

Oracle Virtual Directory (OVD)

Oracle Identity and Access Management 11g (11.1.1.5以降)ディストリビューション

Oracle Internet Directory (OID)

Oracle Identity and Access Management 11g (11.1.1.5以降)ディストリビューション

Oracle Service Bus (OSB)

Oracle Service Bus 11g (11.1.1.7)ディストリビューション

2.4 資格証明ストアとポリシー・ストアとしてのLDAPについて

Oracle Fusion Middlewareでは、WebLogicドメインで異なるタイプの資格証明ストアおよびポリシー・ストアを使用できます。ドメインでは、XMLファイルまたは様々なタイプのLDAPプロバイダに基づいてストアを使用できます。ドメインがLDAPストアを使用する場合は、ポリシーと資格証明のデータはすべて、一元化されたストアで保持および保守されます。ただし、XMLポリシー・ストアを使用している場合、管理対象サーバーへの変更は、同じドメイン・ホームを使用していなければ管理サーバーには伝播されません。

Oracle Fusion Middleware SOA Suiteエンタープライズ・デプロイメント・トポロジは、第4.3項「各種ディレクトリの推奨場所について」の説明のとおり、管理サーバーと管理対象サーバーに対して異なるドメイン・ホームを使用します。そのため、整合性と一貫性を保持するため、Oracle Fusion Middleware SOA Suiteエンタープライズ・デプロイメント・トポロジのコンテキストでは、LDAPをポリシー・ストアおよび資格証明ストアとして使用する必要があります。LDAPを資格証明ストアおよびポリシー・ストアとして使用してOracle Fusion Middleware SOA Suiteエンタープライズ・デプロイメント・トポロジを構成するには、第15.3項「ポリシー・ストアの構成」の手順を実行します。

2.5 クロックの同期

ジョブ、アダプタおよびOracle B2Bを正常に機能させるため、クラスタに参加するすべてのサーバーのクロックを同期させ、クロックの時間差を1秒以内に収める必要があります。これを実現するには、ネットワーク・タイム・サーバーを1つ使用して、各サーバーがそのネットワーク・タイム・サーバーを参照するようにします。

ネットワーク・タイム・サーバーを参照させる手順は、オペレーティング・システムによって異なります。詳細は、オペレーティング・システムのドキュメントを参照してください。

2.6 参照用トポロジのインストールおよび構成のロード・マップ

Oracle SOAエンタープライズ・デプロイメントを開始する前に、図2-5のフロー・チャートを参照してください。このフロー・チャートは、このガイドで説明するエンタープライズ・デプロイメントを完成させるための大まかなプロセスを示しています。表2-3はこのフロー・チャート内の手順を説明するものであり、ここから各手順の項または章にジャンプできます。

この項の項目は次のとおりです。

- 第2.6.1項「Oracle SOAエンタープライズ・デプロイメント・プロセスのフロー・チャート」

- 第2.6.2項「Oracle SOAエンタープライズ・デプロイメント・プロセスのステップ」

- 第2.6.3項「エンタープライズ・デプロイメントへの増分、モジュラ・アプローチの理解」

2.6.1 Oracle SOAエンタープライズ・デプロイメント・プロセスのフロー・チャート

図2-5に、Oracle SOAエンタープライズ・デプロイメント・プロセスのフロー・チャートを示します。このチャートを確認し、既存の環境に基づいた実行手順を理解してください。

図2-5 Oracle SOAエンタープライズ・デプロイメント・プロセスのフロー・チャート

2.6.2 Oracle SOAエンタープライズ・デプロイメント・プロセスのステップ

表2-3は、図2-5に示すOracle SOAのエンタープライズ・デプロイメント・プロセスの各ステップについて説明しています。この表では、処理における各ステップの詳細について、その参照先も示します。

表2-3 Oracle SOAエンタープライズ・デプロイメント・プロセスのステップ

手順

説明

詳細

エンタープライズ・デプロイメント用のネットワークの準備

エンタープライズ・デプロイメント用のネットワークを準備するには、仮想サーバー名、IP、仮想IPSなどの概念を理解し、仮想ホスト名を定義してロード・バランサを構成する必要があります。

第3章「エンタープライズ・デプロイメント用のネットワークの準備」

エンタープライズ・デプロイメント用のファイル・システムの準備

エンタープライズ・デプロイメント用のファイル・システムを準備するには、ディレクトリおよびディレクトリ環境変数の用語を理解し、共有記憶域を構成する必要があります。

第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」

エンタープライズ・デプロイメント用のデータベースの準備

エンタープライズ・デプロイメント用のデータベースを準備するには、データベース要件の確認、データベース・サービスの作成、Oracle RACデータベースへのメタデータ・リポジトリのロード、トランザクション・リカバリ権限用SOAスキーマの構成およびデータベースのバックアップを実行する必要があります。

第5章「エンタープライズ・デプロイメント用のデータベースの準備」

ソフトウェアのインストール

Oracle HTTP Server、Oracle WebLogic ServerおよびOracle Fusion Middlewareをインストールし、Oracle Fusion Middlewareコンポーネントにパッチ・セットを適用します。

第6章「エンタープライズ・デプロイメント用のソフトウェアのインストール」

Web層の構成

ロード・バランサを使用してOracle HTTPサーバーを構成し、仮想ホスト名を構成します。

第7章「エンタープライズ・デプロイメント用のWeb層の構成」

ドメインの作成

構成ウィザードを起動してドメインを作成します。

第8章「エンタープライズ・デプロイメント用のドメインの作成」

SOAのためのドメインの拡張

構成ウィザードを実行してOracle SOAコンポーネントを構成し、既存のWebLogicドメインを拡張します。

第9章「SOAコンポーネントを使用するためのドメインの拡張」

BAMのためのドメインの拡張

Oracle BAMコンポーネントを含めるためのドメイン拡張については2つのオプションがあります。

- Oracle SOA用にドメインを拡張していない場合、構成ウィザードを実行してOracle SOAとOracle BAMを同時に構成できます。

- Oracle SOAを含めるためにドメインをすでに拡張している場合は、構成ウィザードを再度実行し、Oracle BAMを追加するためにドメイン拡張します。

第10章「Oracle BPMを追加するためのドメインの拡張」

BAMのためのドメインの拡張

Oracle BAMコンポーネントを含めるためのドメイン拡張については2つのオプションがあります。

- Oracle SOA用にドメインを拡張していない場合、構成ウィザードを実行してOracle SOAとOracle BAMを同時に構成できます。

- Oracle SOAを含めるためにドメインをすでに拡張している場合は、構成ウィザードを再度実行し、Oracle BAMを追加するためにドメイン拡張します。

第12章「BAMを追加するためのドメインの拡張」

OSBのためのドメインの拡張

構成ウィザードを再度実行し、Oracle Service Busを追加するためにドメイン拡張します。

第11章「Oracle Service Busを追加するためのSOAドメインの拡張」

ノード・マネージャの設定

ホスト名検証を有効化し、ノード・マネージャを起動して、カスタム・キーストアを使用するようにWebLogic Serverを構成し、ノード・マネージャを設定します。

第13章「エンタープライズ・デプロイメント用のノード・マネージャの設定」

サーバー移行の構成

WLS_SOA1およびWLS_SOA2管理対象サーバーのサーバー移行を構成します。WLS_SOA1管理対象サーバーは障害時にSOAHOST2で再起動するように構成されます。WLS_SOA2管理対象サーバーは障害時にSOAHOST1で再起動するように構成されます。

第14章「エンタープライズ・デプロイメント用のサーバー移行の構成」

Identity Managementとの統合

Oracle SOAエンタープライズ・デプロイメントとOracle Identity Management 10gまたは11gを統合できます。

第15章「エンタープライズ・デプロイメントとOracle Identity Managementの統合」

2.6.3 エンタープライズ・デプロイメントへの増分、モジュラ・アプローチの理解

このドキュメントでは増分およびモジュラ・アプローチでエンタープライズ・デプロイメントの設定方法を説明しています。

記憶域、データベース、ネットワーキングおよびWeb層インフラストラクチャの設定手順は、その他のOracle Fusion Middlewareエンタープライズ・デプロイメント・ガイドで説明している手順とほぼ同じです。これらのトポロジ要素は、この後の手順で構成するOracle WebLogic Serverドメインの基盤となるもので、このドメインがエンタープライズ・デプロイメントの土台となります。

ドメインの作成手順はガイドによって異なります。しかし、どのエンタープライズ・デプロイメント・ガイドでも、Oracle WebLogic Serverドメインの作成方法と拡張方法を次のようなモジュラの手順で説明しています。

1. Oracle Fusion Middlewareソフトウェアをディスクにインストールし、必要なバイナリ・ディレクトリを作成します。

2. Oracle Fusion Middleware構成ウィザードを実行してドメインを作成し、管理コンポーネントのみを構成します。
管理コンポーネントには、管理サーバー、Oracle WebLogic Server管理コンソール、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Web Services Managerが含まれます。

3. 構成ウィザードを再度実行し、使用する主なOracle Fusion Middleware製品を追加するためドメインを拡張します。

4. オプションで、構成ウィザードを再度実行して、その他のサポート・コンポーネントおよび製品を追加するためにドメイン拡張します。

この増分アプローチに従うことで、構成ウィザードの各ステップ後に環境を確認できます。また、セットアップ・プロセス中のトラブルシューティングが容易になります。

さらに、このモジュラ・アプローチでは代替トポロジの検討が可能になります。これは特に、管理コンポーネントの構成後、このガイドに記述されているコンポーネントをすべてドメインに含める必要がないことが判明したような場合です。この場合は、ドメイン拡張に関する章を個々に選択して参照し、組織で必要とされるコンポーネントを構成します。

3 エンタープライズ・デプロイメント用のネットワークの準備

この章では、SOAエンタープライズ・トポロジで必要なネットワーク環境の事前構成について説明します。この章を使用して、仮想サーバー名、ロード・バランサ、IPと仮想IP、ファイアウォールおよびポートの構成を計画してください。

この章の内容は次のとおりです。

- 第3.1項「エンタープライズ・デプロイメント用のネットワークの準備の概要」

- 第3.2項「トポロジで使用する仮想サーバー名について」

- 第3.3項「ロード・バランサの構成」

- 第3.4項「IPおよび仮想IPについて」

- 第3.6項「ファイアウォールとポートについて」

3.1 エンタープライズ・デプロイメント用のネットワークの準備の概要

様々な種類のネットワーク・トラフィックや監視に対応するように、仮想サーバーや関連するポートをロード・バランサに構成する必要があります。これらの仮想サーバーは、サービスを実行するために適切な実際のホストおよびポートに対して構成する必要があります。また、ロード・バランサは、可用性を確保するために実際のホストおよびポートを監視するように構成し、サービスがダウンしたときにこれらのホストおよびポートへのトラフィックをできるだけ早く停止できるようにする必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。

後でWeb層の構成および様々なソフトウェア・コンポーネントのインストールを行うときに、仮想ホストおよび関連するポートを構成します。この章を読んだ後、この環境で使用する仮想ホストの名前およびVIPのリストを準備してください。

3.2 トポロジで使用する仮想サーバー名について

SOAエンタープライズ・トポロジでは、次の仮想サーバー名を使用します。

- soa.mycompany.com

- admin.mycompany.com

- osb.mycompany.com

- soainternal.mycompany.com

仮想サーバー名がIPアドレスと関連付けられており、DNSの一部になっていることを確認してください。Oracle Fusion Middlewareを実行するノードは、これらの仮想サーバー名を解決できるようになっている必要があります。

第3.3項「ロード・バランサの構成」の手順に従って、ロード・バランサで仮想サーバー名を定義します。

3.2.1 soa.mycompany.com

soa.mycompany.comは、soa-infra、ワークフロー、B2BなどのランタイムSOAコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして動作する仮想サーバー名です。SSLへのトラフィックが構成されます。クライアントはsoa.mycompany.com:443のアドレスを使用してこのサービスにアクセスします。

3.2.2 admin.mycompany.com

admin.mycompany.comは、WebLogic管理サーバー・コンソールやOracle Enterprise Managerなどの管理サービスに転送されるすべての内部HTTPトラフィックのアクセス・ポイントとして動作する仮想サーバー名です。

クライアントからの入力トラフィックは、SSL対応ではありません。クライアントはadmin.mycompany.com:80のアドレスを使用してこのサービスにアクセスします。そして、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。

3.2.3 osb.mycompany.com

osb.mycompany.comは、ランタイムOracle Service Busリソースおよびプロキシ・サービスに向かうすべてのHTTPトラフィックのアクセス・ポイントとして動作する仮想サーバー名です。SSLへのトラフィックが構成されます。クライアントはosb.mycompany.com:443のアドレスを使用してこのサービスにアクセスします。

3.2.4 soainternal.mycompany.com

soainternal.mycompany.comは、SOAサービスの内部起動に使用される仮想サーバー名です。このURLはインターネットに公開されずに、イントラネットからのみアクセスできます。SOAシステムの場合、実行時に適切なEM/MBeansやコンポジットをモデリングしているときにユーザーはこれを設定できます。URLはサービスの内部起動に使用されます。

クライアントからの入力トラフィックは、SSL対応ではありません。クライアントはsoainternal.mycompany.com:80のアドレスを使用してこのサービスにアクセスします。そして、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。

3.3 ロード・バランサの構成

ロード・バランサ上には、各種のネットワーク・トラフィックおよび監視用に、いくつかの仮想サーバーおよびそれらに関連付けられたポートを構成する必要があります。これらは、実際のホストおよびポートに対して適切に構成し、サービスが継続されるようにする必要があります。また、ロード・バランサは、可用性を確保するために実際のホストおよびポートを監視するように構成し、サービスがダウンしたときにこれらのホストおよびポートへのトラフィックをできるだけ早く停止できるようにする必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。

推奨トポロジ内には、2つのロード・バランサ・デバイスがあります。一方のロード・バランサは外部HTTPトラフィック用に設定し、もう一方のロード・バランサは内部LDAPトラフィック用に設定します。様々な理由から、デプロイメントで使用されるロード・バランサ・デバイスが1つになる場合があります。このような構成もサポートされていますが、これに伴うセキュリティへの影響を考慮する必要があります。その構成が適切であることがわかったら、様々なDMZ間のトラフィックを許可するように、関連するファイアウォール・ポートを開いてください。いずれの場合も、特定のロード・バランサ・デバイスをフォルト・トレラント・モードでデプロイすることを強くお薦めします。

3.3.1 ロード・バランサ要件

エンタープライズ・トポロジでは、外部のロード・バランサを使用します。この外部ロード・バランサは次の機能を備えている必要があります。

- 仮想ホスト名を使用してトラフィックを実際のサーバーのプールにロード・バランシングする機能: クライアントは仮想ホスト名を使用してサービスにアクセスします(実際のホスト名は使用しない)。これにより、ロード・バランサは、プール内のサーバーに対するリクエストをロード・バランシングできます。

- ポート変換の構成。

- ポート(HTTPおよびHTTPS)の監視。

- 仮想サーバーとポートの構成: 外部ロード・バランサの仮想サーバー名とポートを構成する機能。さらに、仮想サーバー名とポートは次の要件を満たしている必要があります。

- ロード・バランサは複数の仮想サーバーの構成が可能である必要がある。各仮想サーバーに対し、ロード・バランサには2つ以上のポートでトラフィック管理を構成できることが必要です。たとえば、Oracle WebLogicクラスタの場合は、1つの仮想サーバーとHTTPおよびHTTPSの両トラフィック用のポートを指定してロード・バランサを構成する必要があります。

- 仮想サーバー名をIPアドレスに関連付け、DNSに含める必要があります。クライアントは仮想サーバー名を使用して外部ロード・バランサにアクセスできる必要があります。

- ノード障害を検出し、障害が発生したノードへのトラフィックのルーティングを即座に停止する機能。

- リソースの監視/ポートの監視/プロセス障害の検出: ロード・バランサは、サービス障害およびノード障害を(通知またはその他の方法によって)検出し、障害のあるノードへの非Oracleネット・トラフィックの転送を停止する必要があります。ご使用の外部ロード・バランサに障害の自動検出機能がある場合、これを使用する必要があります。

- フォルト・トレラント・モード: ロード・バランサはフォルト・トレラント・モードで構成することを強くお薦めします。

- その他: トラフィックの転送先となるバックエンド・サービスが使用できない場合、コール元のクライアントに即座に戻るようにロード・バランサの仮想サーバーを構成することを強くお薦めします。この構成は、クライアント・マシンのTCP/IP設定に基づいてタイムアウト後にクライアント側で接続を切断する構成よりも推奨されます。

- SSLアクセラレーション(この機能はお薦めしますが必須ではありません)。

- TCP接続の接続タイムアウトに大きい値を使用したディレクトリ層に対するロード・バランサの仮想サーバーの構成。この値は、Oracle Access Management Access Managerとディレクトリ層の間でトラフィックがない場合に、その予想される最大時間より大きい必要があります。

- クライアントIPアドレスを保持する機能: ロード・バランサには、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入し、クライアントIPアドレスを保持する機能がある必要があります。

3.3.2 ロード・バランサ構成の手順

ロード・バランサを構成する手順は、ロード・バランサの特定の種類によって異なります。実際の手順については、ベンダーが提供するマニュアルを参照してください。次の手順では、一般的な構成フローを示します。

1. サーバーのプールを作成します。このプールには、ロード・バランシングの定義に含まれているサーバーとポートのリストが格納されます。たとえば、Webホスト間のロード・バランシングの場合、リクエストをポート7777でWEBHOST1およびWEBHOST2のホストに送信するサーバーのプールを作成します。

2. 特定のホストとサービスが使用可能かどうかを決定するルールを作成し、手順1で説明したサーバーのプールに割り当てます。

3. ロード・バランサ上に仮想サーバーを作成します。これは、アプリケーションが使用するリクエストを受信するアドレスとポートです。たとえば、Web層のリクエストをロード・バランシングするには、sso.mycompany.com:80に対する仮想ホストを作成します。

1. ロード・バランサがこれをサポートする場合は、その仮想サーバーが内部、外部またはその両方で使用可能かどうかを指定します。内部アドレスはネットワーク内からのみ解決できることを確認します。

2. 仮想サーバーに対してSSL終端(適用可能な場合)を構成します。

3. 手順1で作成したサーバーのプールを、仮想サーバーに割り当てます。

4. 表3-4「使用されるポート」に示されているように、タイム・アウトの設定を調整します。これには、サービスがダウンするかどうかを検出する時間が含まれます。

3.3.3 ロード・バランサの構成

Oracle SOAデプロイメントの場合、表3-1に示すようにロード・バランサを構成します。

表3-1 ロード・バランサの構成

仮想ホスト

サーバー・プール

プロトコル

SSL終端

外部

その他の必要な構成/コメント

admin.mycompany.com:80

WEBHOST1.mycompany.com:7777

WEBHOST2.mycompany.com:7777

HTTP

いいえ

いいえ

- 内部管理アドレスを仮想サーバーのアドレス(たとえば、admin.mycompany.com)として使用します。

- HTTPをプロトコルとして指定します。

- アドレスとポートの変換を有効にします。

- サービスやノードが停止した場合に接続のリセットを有効にします。

- ステップ1で作成したプールを仮想サーバーに割り当てます。

soa.mycompany.com:443

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

いいえ

はい

- システムのフロントエンド・アドレスを仮想サーバーのアドレス(たとえば、soa.mycompany.com)として使用します。フロントエンド・アドレスは、システムで使用され外部に公開されているホスト名であり、インターネットに公開されます。

- ポート80およびポート443を使用します。ポート80 (非SSLプロトコル)に入力するリクエストはすべて、ポート443 (SSLプロトコル)にリダイレクトされる必要があります。

- ANYをプロトコルとして指定します(B2BではHTTPでないプロトコルが必要)。

- アドレスとポートの変換を有効にします。

- サービスやノードが停止した場合に接続のリセットを有効にします。

- ステップ1で作成したプールを仮想サーバーに割り当てます。

- この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。

soainternal.mycompany.com:80

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

いいえ

いいえ

- 内部管理アドレスを仮想サーバーのアドレス(たとえば、soainternal.mycompany.com)として使用します。このアドレスは一般的に外部化されません。

- HTTPをプロトコルとして指定します。

- アドレスとポートの変換を有効にします。

- サービスやノードが停止した場合に接続のリセットを有効にします。

- ステップ1で作成したプールを仮想サーバーに割り当てます。

- 必要に応じて、この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。

osb.mycompany.com:443

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

いいえ

いいえ

HTTPをプロトコルとして指定します。

3.4 IPおよび仮想IPについて

図3-1に示すように、異なる仮想IPと物理IPでリスニングするように、管理サーバーと管理対象サーバーを構成してください。図に示すように、各仮想IPとIPは、使用するWebLogic Serverに割り当てられます。VIP1は手動でフェイルオーバーされ、管理サーバーがSOAHOST2で再起動されます。Oracle WebLogic Serverの移行機能により、VIP2とVIP3がそれぞれ、SOAHOST1からSOAHOST2にフェイルオーバーし、SOAHOST2からSOAHOST1にフェイルオーバーします。またWLS_BAM1でもサーバー移行機能が使用されて、VIP4をBAMHOST1からBAMHOST2にフェイルオーバーします。

WebLogic Serverの移行機能の詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

物理IP(仮想IPでない)が各ノードに固定的に割り当てられます。IP1はSOAHOST1の物理IPで、WLS_WSM1 WebServicesポリシー・マネージャのサーバーで使用されます。IP2はSOAHOST2の物理IPで、WLS_WSM2 WebServicesポリシー・マネージャのサーバーで使用されます。IP3はBAMHOST2の物理IPで、WLS_BAM2サーバーによりリスニング・アドレスとして使用されます。

図3-1 管理サーバーおよび管理対象サーバーにマップされる仮想IPとIP

表3-2には、様々な仮想ホストの説明が記載されています。

表3-2 仮想ホスト

仮想IP

VIPのマップ先

説明

VIP1

ADMINVHN

ADMINVHNは、管理サーバーのリスニング・アドレスである仮想ホスト名であり、管理サーバーの手動フェイルオーバーによりフェイルオーバーします。管理サーバーのプロセスが実行されているノード(デフォルトはSOAHOST1)で有効にされます。

VIP2

SOAHOST1VHN1

SOAHOST1VHN1は、WLS_SOA1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_SOA1プロセスが実行されているノード(デフォルトはSOAHOST1)で有効化されます。

VIP3

SOAHOST2VHN1

SOAHOST2VHN1は、WLS_SOA2のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_SOA2プロセスが実行されているノード(デフォルトはSOAHOST2)で有効化されます。

VIP4

BAMHOST1VHN1

BAMHOST1VHN1は、WLS_BAM1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_BAM1プロセスが実行されているノード(デフォルトはBAMHOST1)で有効化されます。

VIP5

SOAHOST1VHN2

SOAHOST1VHN2は、WLS_OSB1サーバーのリスニング・アドレスにマップし、このサーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_OSB1プロセスが実行されているノード(デフォルトはSOAHOST1)で有効化されます。

VIP6

SOAHOST2VHN2

SOAHOST2VHN2は、WLS_OSB2サーバーのリスニング・アドレスにマップし、このサーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_OSB2プロセスが実行されているノード(デフォルトはSOAHOST2)で有効化されます。

3.5 管理サーバーの仮想IPアドレスの有効化

他のOracle Fusion Middlewareコンポーネントを後でインストールするかしないかに関係なく、WebLogic管理サーバーのフェイルオーバーを行うにはこの手順が必要であることに注意してください。

管理サーバーを仮想IPアドレスと関連付けます。これにより、プライマリ・ホストに障害が発生した場合でも、別のホストで管理サーバーを起動することができます。

仮想ホストが次のように有効化されていることを確認します。

表3-3 仮想ホスト

VIP

有効化されるホスト

ADMINVHN.mycompany.com

SOAHOST1

SOAHOST1VHN1.mycompany.com

SOAHOST1

SOAHOST2VHN1.mycompany.com

SOAHOST2

BAMHOST1VHN1.mycompany.com

BAMHOST1

SOAHOST1VHN2.mycompany.com

SOAHOST1

SOAHOST2VHN2.mycompany.com

SOAHOST2

注意:

これは、浮動IPアドレスに関連付けられているDNS名です。ロード・バランサで構成された仮想ホストのDNS名ではありません。

Linux

仮想IPアドレスを有効にするには、rootとして次のコマンドを実行します。

/sbin/ifconfig interface:index IPAddress netmask netmask
/sbin/arping -q -U -c 3 -I interface IPAddress

ここで、interfaceはeth0またはeth1、indexは0、1または2です。

例:

/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0

ネットワークを有効化し、仮想IPアドレスの新しい場所を登録します。

/sbin/arping -q -U -c 3 -I eth0 100.200.140.206

別のノードからpingを行って、アドレスが使用可能であることを検証します。次に例を示します。

/bin/ping 100.200.140.206

Windows

仮想IPアドレスを有効にするには、次のコマンドを実行します。

netsh interface ip add address interface IP_Address netmask

ここで、IP_Addressは仮想IPアドレスで、netmaskは関連付けられたネットマスクです。

次の例では、IPアドレスはインタフェースLocal Area Connection上で有効になります。

netsh interface ip add address "Local Area connection" 100.200.140.206 255.255.255.0

3.6 ファイアウォールとポートについて

多くのOracle Fusion Middlewareコンポーネントおよびサービスはポートを使用します。管理者は、これらのサービスが使用するポート番号を把握し、同じポート番号が1つのホスト上の2つのサービスによって使用されないようにする必要があります。

ほとんどのポート番号はインストール中に割り当てられます。

表3-4にはSOAトポロジで使用されるポートの一覧が記載されています。トポロジにあるファイアウォールで開く必要のあるポートも記載されています。

ファイアウォール表記法:

- FW0は外側のファイアウォールを示します。

- FW1は、Web層とアプリケーション層との間におけるファイアウォールを示します。

- FW2は、アプリケーション層とデータ層との間におけるファイアウォールを示します。

表3-4 使用されるポート

タイプ

ファイアウォール

ポートとポート範囲

プロトコル/アプリケーション

インバウンド/アウトバウンド

その他の考慮事項とタイムアウトのガイドライン

ブラウザによるリクエスト

FW0

80

HTTP/ロード・バランサ

インバウンド

タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。

ブラウザによるリクエスト

FW0

443

HTTPS/ロード・バランサ

インバウンド

タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。

ブラウザによるリクエスト

FW1

80

HTTPS/ロード・バランサ

アウトバウンド(イントラネット・クライアント)

タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。

ブラウザによるリクエスト

FW1

443

HTTPS/ロード・バランサ

アウトバウンド(イントラネット・クライアント)

タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。

コールバックおよびアウトバウンド呼出し

FW1

80

HTTPS/ロード・バランサ

アウトバウンド

タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。

コールバックおよびアウトバウンド呼出し

FW1

443

HTTPS/ロード・バランサ

アウトバウンド

タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。

Oracle HTTP Serverへのロード・バランサ

なし

7777

HTTP

なし

第3.3項「ロード・バランサの構成」を参照してください。

管理サーバーによるOHS登録

FW1

7001

HTTP/t3

インバウンド

タイムアウトを短い時間(5から10秒)に設定します。

管理サーバーによるOHS管理

FW1

OPMNポート(6701)とOHS管理ポート(7779)

それぞれTCPとHTTP

アウトバウンド

タイムアウトを短い時間(5から10秒)に設定します。

WSM-PMのアクセス

FW1

7010

範囲: 7010から7999

HTTP / WLS_WSM-PMn

インバウンド

タイムアウトを60秒に設定します。

SOAサーバーのアクセス

FW1

8001

範囲: 8000から8010

HTTP / WLS_SOAn

インバウンド

タイムアウトは、SOAによって使用されるプロセス・モデルのタイプによって異なります。

Oracle Service Busのアクセス

FW1

8011

範囲: 8011から8021

HTTP / WLS_OSBn

インバウンド/
アウトバウンド

タイムアウトを短い時間(5から10秒)に設定します。

BAMのアクセス

FW1

9001

範囲: 9000から9080

HTTP / WLS_BAMn

インバウンド

レポートやブラウザが閉じられるまでBAM WebAppsへの接続は開いたまま維持されます。これによって、ユーザー・セッションの最長持続可能時間と同じ時間のタイムアウトを設定します。

複数のSOAクラスタ・メンバー間における通信

なし

8001

TCP/IPユニキャスト

なし

デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。

複数のWSMクラスタ・メンバー間における通信

なし

7010

TCP/IPユニキャスト

なし

デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。

WebLogic Serverクラスタ内におけるセッション・レプリケーション

なし

なし

なし

なし

デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。

管理コンソールのアクセス

FW1

7001

HTTP/管理サーバーとEnterprise Manager

t3

両方

管理コンソールへのアクセスのタイプ(アプリケーション層のクライアントからOracle WebLogic Server管理コンソールを使用する予定があるか、またはアプリケーション層の外部のクライアントから使用する予定があるか)に基づいてこのタイムアウト時間をチューニングする必要があります。

ノード・マネージャ

なし

5556

TCP/IP

なし

なし

実際の値は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』のファイアウォールとポートに関する項を参照してください。

アクセス・サーバーのアクセス

FW1

6021 (OAM 10g)

5575 (OAM 11g)

OAP

インバウンド

実際の値は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』のファイアウォールとポートに関する項を参照してください。

アイデンティティ・サーバーへのアクセス(OAM 10g)

FW1

6022

OAP

インバウンド

なし

データベースのアクセス

FW2

1521

SQL*Net

両方

タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのデータベース・コンテキストによって異なります。

デプロイメントの一貫性

なし

8088

範囲: 8000から8090

なし

なし

Oracle Internet Directoryのアクセス

FW2

389

LDAP

インバウンド

ロード・バランサに基づいてディレクトリ・サーバーのパラメータをチューニングする必要があります。それ以外の方法ではチューニングしないでください。

Oracle Internet Directoryのアクセス

FW2

636

LDAP SSL

インバウンド

ロード・バランサに基づいてディレクトリ・サーバーのパラメータをチューニングする必要があります。それ以外の方法ではチューニングしないでください。

OWSM用JOC

なし

9991

TCP/IP

なし

なし

Oracle Notification Server (ONS)

FW2

6200

ONS

両方

Gridlinkに必要。各データベース・サーバー上でONSサーバーが実行されます。

注意:

B2BのTCP/IPポートは、ユーザーが構成するポートであり、事前定義されません。同様に、ファイアウォールのポートは、TCP/IPポートの定義によって異なります。

4 エンタープライズ・デプロイメント用のファイル・システムの準備

この章では、Oracle SOAエンタープライズ・デプロイメント用のファイル・システムの準備方法について説明します。推奨されるディレクトリ構造とその場所に関する情報を示し、共有記憶域の構成手順も説明します。

この章の内容は次のとおりです。

- 第4.1項「エンタープライズ・デプロイメント用のファイル・システムの準備の概要」

- 第4.2項「ディレクトリとディレクトリ環境変数の用語」

- 第4.3項「各種ディレクトリの推奨場所について」

- 第4.4項「共有記憶域の構成」

4.1 エンタープライズ・デプロイメント用のファイル・システムの準備の概要

ファイル・システムの設定では、構成と管理が容易でわかりやすいエンタープライズ・デプロイメントを作成できるようにすることが重要です。この章の情報に従ってファイル・システムを設定することをお薦めします。この章で定義されている用語は、このガイド内のダイアグラムおよび手順で使用されます。

この章を参照情報として使用すると、インストールおよび構成手順で使用されているディレクトリ変数について理解できます。その他のディレクトリ・レイアウトも可能であり、サポートされていますが、このマニュアルで採用するモデルは、可用性を最大化するために選択されており、コンポーネントの最良の独立性と構成の対称性の両方を実現し、バックアップおよび災害からのリカバリを容易にします。ドキュメントの残りの部分では、このディレクトリ構造およびディレクトリ用語を使用します。

4.2 ディレクトリとディレクトリ環境変数の用語

この項では、このガイドでOracle SOAエンタープライズ・デプロイメントを構成するために使用しているディレクトリ環境変数について説明します。このガイドでは、インストールして構成するディレクトリを次のディレクトリ変数を使用して説明しています。

- ORACLE_BASE: この環境変数と関連ディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指しています。

- MW_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Fusion Middlewareが配置されている場所を表します。

- WL_HOME: この環境変数と関連ディレクトリ・パスには、WebLogic Serverをホストするために必要なファイルがインストールされて格納されています。

- ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Fusion Middleware SOA Suiteがインストールされている場所を指します。

- ORACLE_COMMON_HOME: この環境変数と関連ディレクトリ・パスは、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files (JRF)に必要なバイナリおよびライブラリ・ファイルが含まれるOracleホームを指しています。

- ORACLE_HOME_OSB: この環境変数および関連するディレクトリ・パスは、Oracle Service Busがインストールされている場所を指します。

- DOMAIN Directory: このディレクトリ・パスは、WebLogic Serverドメイン情報(構成アーティファクト)が格納されている場所を指しています。後述のように同じノード内にある場合でも、個々のOracle WebLogic Serverで異なるドメイン・ディレクトリを使用できます。

- ORACLE_INSTANCE: Oracleインスタンスには、1つ以上のシステム・コンポーネントがあります。コンポーネントの例には、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoyなどがあります。Oracleインスタンス・ディレクトリには、更新可能ファイル(構成ファイル、ログ・ファイル、一時ファイルなど)が含まれています。

- JAVA_HOME: これは、JRockitがインストールされる場所です。

- ASERVER_HOME: これは、ドメイン構成のプライマリの場所です。典型的な例: /u01/oracle/config/domains/domain_name

- MSERVER_HOME: これは、管理対象サーバーの起動と停止に使用されるドメイン構成のコピーです。典型的な例: /u02/private/oracle/config/domains/domain_name

- WEB_ORACLE_HOME: この変数は、Oracle HTTP Serverに必要なバイナリおよびライブラリ・ファイルを格納し、MW_HOME/webにあります。

- WEBGATE_ORACLE_HOME: これは、WebGateインストールの場所です。

ヒント:

この項で説明している場所には、ショートカットとして環境変数を使用し、ディレクトリに簡単に移動できます。たとえば、Linuxでは$ORACLE_BASEという環境変数を使用し、/u01/app/oracle(つまり、推奨されるORACLE_BASEの場所)を参照できます。Windowsでは、%ORACLE_BASE%とWindowsに固有のコマンドを使用できます。

4.3 各種ディレクトリの推奨場所について

次の項では、エンタープライズ・デプロイメント・トポロジに対して共有記憶域を使用する際の基本的な推奨事項について説明します。

- バイナリ(Oracleホーム)ディレクトリに対する共有記憶域の推奨事項

- ドメイン構成ファイルに対する共有記憶域の推奨事項

- JMSファイル・ストアおよびトランザクション・ログに対する共有記憶域の推奨事項

- ディレクトリの推奨場所

- ディレクトリ構造と構成

4.3.1 バイナリ(Oracleホーム)ディレクトリに対する共有記憶域の推奨事項

次の項では、Oracle Fusion Middleware Oracleホーム・ディレクトリに対して共有記憶域を使用する際のガイドラインについて説明します。

- バイナリ(Oracleホーム)ディレクトリについて

- 複数ドメインでの単一Oracleホームの共有について

- 冗長なバイナリ(Oracleホーム)ディレクトリの使用について

4.3.1.1 バイナリ(Oracleホーム)ディレクトリについて

Oracle Fusion Middleware製品をインストールするときには、製品バイナリをOracleホームにインストールします。Oracleホームにインストールされたバイナリ・ファイルは読取り専用であり、Oracleホームがパッチ適用されるか、最新バージョンにアップグレードされる場合を除き、変更されません。

通常の製品環境では、Oracleホーム・ファイルは、Oracle Fusion Middleware構成ウィザードを使用して作成したドメイン構成ファイルとは別の場所に保存されます。

Oracle Fusion MiddlewareインストールのMiddlewareホームには、Oracle WebLogic Serverのバイナリ、Oracle Fusion Middlewareインフラストラクチャ・ファイルおよびOracle Fusion Middleware製品固有のディレクトリが含まれます。

Oracle Fusion Middleware Oracleホームの構成と内容の詳細は、Oracle Fusion Middlewareの概念を参照してください。

4.3.1.2 複数ドメインでの単一Oracleホームの共有について

Oracle Fusion Middlewareでは、単一のOracleホームから複数のOracle WebLogic Serverドメインを構成することができます。これにより、共有ボリューム上の単一の場所にOracleホームをインストールし、複数のホストのインストールにOracleホームを再利用することができます。

1つのOracleホームが、異なるホスト上の複数のサーバーによって共有されている場合、留意すべきベスト・プラクティスがいくつかあります。特に、各ホスト上のOracleインベントリ(oraInventory)が一貫性とパッチの適用のために更新されていることを確認してください。

ホストのoraInventorを更新し、共有記憶域上のOracleホームをアタッチするには、次のコマンドを使用します。

ORACLE_HOME/oui/bin/attachHome.sh

oraInventoryの詳細は、Oracle Universal Installerコンセプト・ガイドのOracle Universal Installerインベントリに関する項を参照してください。

4.3.1.3 冗長なバイナリ(Oracleホーム)ディレクトリの使用について

可用性が最大になるように、共有記憶域上でバイナリの冗長インストールを使用することをお薦めします。

このモデルでは、2つの異なる共有ボリューム上に、Oracle Fusion Middlewareソフトウェアに対する2つの同じOracleホームをインストールします。次に、一方のOracle homeをサーバーの1つのセットにマウントし、もう一方のOracleホームを残りのサーバーにマウントします。各Oracleホームは同じマウント・ポイントを持っているので、サーバーがどのOracleホームを使用しているかに関係なく、Oracleホームは常に同じパスを持っています。

1つのOracleホームが壊れたり使用できなくなった場合は、サーバーの半分のみが影響を受けます。さらに保護を強化するために、これらのボリュームのディスク・ミラーを行うことをお薦めします。

共有記憶域上で別個のボリュームが使用できない場合は、同じボリューム内の異なるディレクトリを使用して別個のボリュームをシミュレートし、これらをホスト側の同じマウント位置にマウントすることをお薦めします。複数のボリュームによって実現する保護は前述の例はNASに特有ですがこれによって保証されませんが、ユーザーによる削除や個々のファイルの破損から保護できます。

4.3.2 ドメイン構成ファイルに対する共有記憶域の推奨事項

次の項では、エンタープライズ・デプロイメントでOracle Fusion Middleware製品を構成するときに作成したOracle WebLogic Serverドメイン構成ファイルに対して共有記憶域を使用する際のガイドラインについて説明します。

- Oracle WebLogic Server管理および管理対象サーバー・ドメイン構成ファイルについて

- 管理対象サーバー・ドメイン構成ファイルに対するローカル記憶域の要件

4.3.2.1 Oracle WebLogic Server管理および管理対象サーバー・ドメイン構成ファイルについて

Oracle Fusion Middleware製品を構成するときには、Oracle WebLogic Serverドメインを作成または拡張します。各Oracle WebLogic Serverドメインは、単一の管理サーバーおよび1つ以上の管理対象サーバーで構成されます。

Oracle WebLogic Serverドメインの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverドメイン構成の理解』を参照してください。

エンタープライズ・デプロイメントでは、ドメイン内の管理対象サーバーをアクティブ/アクティブ高可用性用に構成できることを理解することが重要です。ただし、管理サーバーではできません。管理サーバーはシングルトン・サービスです。つまり、いつでも1つのホストでのみアクティブすることができます。

4.3.2.2 管理対象サーバー・ドメイン構成ファイルに対するローカル記憶域の要件

競合に関連するパフォーマンス上の問題を回避するために、管理対象サーバーの構成ファイルはローカル記憶域上に配置する必要があります。このディレクトリは、MSERVER_HOMEディレクトリと呼ばれます。管理対象サーバー・ドメイン構成ファイルは、ローカル記憶域に配置することを強くお薦めします。

共有記憶域を使用する必要がある場合は、ノードごとに記憶域パーティションを作成し、その記憶域をそのノードに排他的にマウントすることをお薦めします。

このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとに各ノードのローカル・ドメイン・ディレクトリが使用されると想定しています。

4.3.3 JMSファイル・ストアおよびトランザクション・ログに対する共有記憶域の推奨事項

サーバーの障害や移行の場合のリカバリで、JMSファイル・ストアやJTAトランザクション・ログを複数のホストから利用できるようにするには、それらを共有記憶域に配置する必要があります。

JMSおよびJTAに関する情報をファイル・ストアに保存する方法の詳細は、Oracle WebLogic Serverサーバー環境の管理のWebLogic永続ストアの使用に関する項を参照してください。

4.3.4 ディレクトリの推奨場所

この項では、推奨されるディレクトリについて説明します。共有記憶域の場所が直接指定されている場合は必ず、そのディレクトリでは共有記憶域が必要とされることを意味します。ローカル・ディスクが使用されたり共有記憶域がオプションの場合、マウント指定では「共有記憶域を使用している場合」の語句で修飾されます。共有記憶域の場所は例であり、指定のマウント・ポイントが使用されるかぎり、これを変更できます。ただし、共有記憶域デバイスでは整合性と単純化のためこの構造をお薦めします。

ORACLE_BASE

推奨ディレクトリ: /u01/app/oracle

管理サーバー・ドメイン・ディレクトリのドメイン・ディレクトリ:

ORACLE_BASE/admin/domain_name/aserver/domain_name (最後のdomain_nameは、構成ウィザードで追加されます)

- マシンのマウント・ポイント: ORACLE_BASE/admin/domain_name/aserver

- 共有記憶域の場所: ORACLE_BASE/admin/domain_name/aserver

- マウント元: このディレクトリをマウントする必要があるのは、管理サーバーが稼働しているノードのみです。管理サーバーが別のノードに再配置(フェイルオーバー)されたら、そのノードが同じマウント・ポイントで同じ共有記憶域をマウントします。トポロジ内の残りのノードがこの場所をマウントする必要はありません。

管理対象サーバー・ドメイン・ディレクトリのドメイン・ディレクトリ:

ORACLE_BASE/admin/domain_name/mserver/domain_name

- 共有ディスクを使用する場合、マシンのマウント・ポイントは次のとおりです。

ORACLE_BASE/admin/domain_name/mserver

マウント先:

/ORACLE_BASE/admin/domain_name/Noden/mserver/

(各ノードは管理対象サーバーにそれぞれ別のドメイン・ディレクトリを使用します。)

注意:

この手順は実際、共有記憶域によって異なります。前述の例はNASに特有でありますが、他の記憶域タイプでは別のタイプのマッピングによりこの冗長性が実現される場合があります。

JMSファイルベース・ストアとTlogs用の場所(SOAのみ):

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

- マウント・ポイント: ORACLE_BASE/admin/domain_name/soa_cluster_name/

- 共有記憶域の場所: ORACLE_BASE/admin/domain_name/soa_cluster_name/

- マウント元: SOAまたはBAMが稼働するすべてのノードでは、別のノードへのサーバー移行が発生したときにトランザクション・ログおよびJMSストアを使用できるように、この共有記憶域の場所をマウントする必要があります。

管理サーバーのアプリケーション・ディレクトリの場所

ORACLE_BASE/admin/domain_name/aserver/applications

- マウント・ポイント: ORACLE_BASE/admin/domain_name/aserver/

- 共有記憶域の場所: ORACLE_BASE/admin/domain_name/aserver

- マウント元: このディレクトリをマウントする必要があるのは、管理サーバーが稼働しているノードのみです。管理サーバーが別のノードに再配置(フェイルオーバー)されたら、そのノードが同じマウント・ポイントで同じ共有記憶域をマウントします。トポロジ内の残りのノードがこの場所をマウントする必要はありません。

管理対象サーバーのアプリケーション・ディレクトリの場所

ORACLE_BASE/admin/domain_name/mserver/applications

このディレクトリは、SOAエンタープライズ・デプロイメントではローカルになります。

MW_HOME (アプリケーション層)

推奨ディレクトリ: ORACLE_BASE/product/fmw

- マウント・ポイント: ORACLE_BASE/product/fmw

- 共有記憶域の場所: ORACLE_BASE/product/fmw (VOL1とVOL2)

注意:

共有記憶域に利用できるボリュームが1つしかない場合に、誤ってファイルを削除しないように、あるいはパッチを適用できるように、別のディレクトリを使用して冗長に構成することができます。2つのMW_HOMEを使用できます。その場所は、少なくとも1つはORACLE_BASE/product/fmw1、もう一方はORACLE_BASE/product/fmw2とします。これらのMW_HOMEは、すべてのノードで同じマウント・ポイントにマウントされます。

- マウント元: 少なくとも半分のノードで一方のインストールを使用し、もう半分で他方のインストールを使用できるように、ノードではVOL1とVOL2を互換的にマウントします。
SOAエンタープライズ・デプロイメント・トポロジでは、SOAHOST1でVOL1をマウントし、SOAHOST2でVOL2をマウントします。使用可能なボリュームが1つのみの場合は、ノードは共有記憶域において、考えられる2つのディレクトリを互換的にマウントします。たとえば、SOAHOST1ではORACLE_BASE/product/fmw1、SOAHOST2ではORACLE_BASE/product/fmw2を、それぞれ共有記憶域の場所として使用します。

ORACLE_HOME (web層)

推奨ディレクトリ: ORACLE_BASE/product/fmw/web

- マウント・ポイント: ORACLE_BASE/product/fmw

- 共有記憶域の場所: ORACLE_BASE/product/fmw (VOL1とVOL2)

注意:

Web層のインストールは通常、WEBHOSTノードのローカル記憶域で実行されます。共有記憶域を使用する場合は、層を横断する記憶域デバイスへのアクセスには、適切なセキュリティ制限をかけることを検討してください。

このエンタープライズ・デプロイメント・ガイドでは、Oracle Web Tierがローカル・ディスクにインストールされることを想定しています。Oracle Web Tierのバイナリ(およびORACLE_INSTANCE)を共有ディスクにインストールすることもできます。その場合は、共有ディスクがアプリケーション層に使用されるものとは別になっている必要があります。

- マウント元: 共有記憶域のインストールでは、少なくとも半分のノードで一方のインストールを使用し、もう半分で他方のインストールを使用できるように、ノードではVOL1とVOL2を互換的にマウントします。
SOAエンタープライズ・デプロイメント・トポロジでは、WEBHOST1でVOL1をマウントし、WEBHOST2でVOL2をマウントします。使用可能なボリュームが1つのみの場合は、ノードは共有記憶域において、考えられる2つのディレクトリを互換的にマウントします。たとえば、WEBHOST1ではORACLE_BASE/product/fmw1、WEBHOST2ではORACLE_BASE/product/fmw2を、それぞれ共有記憶域の場所として使用します。

WL_HOME

推奨ディレクトリ: MW_HOME/wlserver_10.3

ORACLE_HOME

推奨ディレクトリ: MW_HOME/soa

ORACLE_COMMON_HOME

推奨ディレクトリ: MW_HOME/oracle_common

ORACLE_HOME_OSB

推奨ディレクトリ: /MW_HOME/osb

ORACLE_INSTANCE (OHSインスタンス)

推奨ディレクトリ: ORACLE_BASE/admin/instance_name

- 共有ディスクを使用する場合、マシンのマウント・ポイントは次のとおりです。

ORACLE_BASE/admin/instance_name

マウント先:

ORACLE_BASE/admin/instance_name vol1

注意:

(VOL1)はオプションです。(VOL2)も使用できます。

4.3.5 ディレクトリ構造と構成

この項では、推奨されるディレクトリ構造および共有記憶域の理解に役立つダイアグラムを示します。

図4-1は、ディレクトリ構造を表しています。

図4-1 ディレクトリ構造

図4-1のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。

表4-1は、図において様々な色で識別されている要素の意味に関する説明が記載されています。

表4-1 ディレクトリ構造の要素

要素

説明

管理サーバーのドメイン・ディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSとTXのログ、およびMW_HOME全体は共有記憶域上に配置されます。

管理対象サーバーのドメイン・ディレクトリは、ローカルのディスクにも共有ディスクにも配置できます。さらに、管理対象サーバーのドメイン・ディレクトリを複数のノードで共有する場合、ノード全体において共有ディスクの同じ場所をマウントする必要があります。Web層のinstance_nameディレクトリは、ローカル・ディスクまたは共有ディスクに配置できます。

固定名です。

インストール依存名です。

図4-2は、SOA用に複数のボリュームを持つ共有記憶域の構成例を示しています。BAMデプロイメントの場合、同じ構造によりこれを類推することができます。

図4-2 共有記憶域の構成例

表4-2は、ドメインのディレクトリ構造をまとめたものです。

表4-2 共有記憶域の内容

サーバー

データのタイプ

共有記憶域のボリューム

ディレクトリ

ファイル

WLS_SOA1

Txログ

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

トランザクション・ディレクトリは共通(WebLogic Serverにより決定)ですが、ファイルは別々です。

WLS_SOA2

Txログ

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

トランザクション・ディレクトリは共通(WebLogic Serverにより決定)ですが、ファイルは別々です。

WLS_SOA1

JMSストア

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

トランザクション・ディレクトリは共通(WebLogic Serverにより決定)ですが、ファイルは別々です。たとえば、SOAJMSStore1やUMSJMSStore1などです。

WLS_SOA2

JMSストア

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

トランザクション・ディレクトリは共通(WebLogic Serverにより決定)ですが、ファイルは別々です。たとえば、SOAJMSStore2やUMSJMSStore2などです。

WLS_SOA1

WLSインストール

VOL1

MW_HOME

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_SOA2

WLSインストール

VOL2

MW_HOME

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_SOA1

SOAインストール

VOL1

MW_HOME/soa

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_SOA2

SOAインストール

VOL2

MW_HOME/soa

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_SOA1

ドメイン構成

VOL1

ORACLE_BASE/admin/domain_name/mserver/domain_name

管理対象サーバーのドメイン・ディレクトリが共有記憶域にある構成では、ファイルは各ボリュームで独立したものになりますが、両方のサーバーで同じディレクトリ構造を認識します。このガイドでは、管理対象サーバーのドメイン・ディレクトリにはローカル記憶域が使用されます。

WLS_SOA2

ドメイン構成

VOL2

ORACLE_BASE/admin/domain_name/mserver/domain_name

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_SOA1

ドメイン構成

VOL1

ORACLE_BASE/admin/domain_name/aserver/domain_name

管理サーバーを実行している1つのサーバーのみで使用されます。

4.4 共有記憶域の構成

次のコマンドを使用して、共有記憶域の場所を作成しマウントします。これにより、SOAHOST1とSOAHOST2が2つの別々のボリュームのバイナリ・インストール用に同じ場所を参照できるようになります。

注意:

共有記憶域のファイル・システムの作成に使用されるユーザーIDは、これらのファイルに対する読取り、書込みおよび実行権限を持ちます。オペレーティング・システム・グループにおける他のユーザーは、ファイルの読取りや実行は可能ですが、書込み権限はありません。インストールと構成の権限に関する詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストールと構成の権限とユーザーの理解に関する項を参照してください。

nasfilerは共有記憶域ファイラです。

SOAHOST1から:

mount nasfiler:/vol/vol1/ORACLE_BASE/product/fmw
ORACLE_BASE/product/fmw -t nfs

SOAHOST2から:

mount nasfiler:/vol/vol2/ORACLE_BASE/product/fmw
ORACLE_BASE/product/fmw -t nfs

利用できるボリュームが1つのみの場合、共有記憶域で別々のディレクトリを2つ使用して、それらをSOAサーバーの同じディレクトリにマウントすることで、バイナリの冗長性を実現できます。

SOAHOST1から:

mount nasfiler:/vol/vol1/ORACLE_BASE/product/fmw1
ORACLE_BASE/product/fmw -t nfs

SOAHOST2から:

mount nasfiler:/vol/vol1/ORACLE_BASE/product/fmw2
ORACLE_BASE/product/fmw -t nfs

次のコマンドは、異なるノード間においてSOA TXログを共有する方法を示します。

mount nasfiler:/vol/vol1/ORACLE_BASE/stores/soadomain/soa_cluster/tlogs
/ORACLE_BASE/stores/soadomain/soa_cluster/tlogs -t nfs

mount nasfiler:/vol/vol1/ORACLE_BASE/stores/soadomain/soa_cluster/tlogs
/ORACLE_BASE/stores/soadomain/soa_cluster/tlogs -t nfs

共有ストレージの構成の検証

構成した共有記憶域にテスト・ファイルを作成し、新しくマウントしたディレクトリでファイルの読取りおよび書込みができることを確認します。

例:

$ cd newly mounted directory
$ touch testfile

所有者と権限が正しいことを確認します。

$ ls -l testfile

ファイルを削除します。

$ rm testfile

注意:

共有記憶域にはNASやSANなどのデバイスを使用できます。次は、NASデバイスの記憶域をSOAHOST1から作成する例を示しています。オプションは、具体的な記憶域デバイスに応じて異なる場合があります。

mount nasfiler:/vol/vol1/fmw11shared ORACLE_BASE/wls -t nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

使用する環境に適切なオプションについては、ストレージ・ベンダーとマシン管理者と相談してください。

5 エンタープライズ・デプロイメント用のデータベースの準備

この章では、Oracle SOAエンタープライズ・デプロイメント用のデータベースの準備手順について説明します。この手順には、データベースの初期設定、メタデータ・リポジトリのロードおよびデータベースのバックアップが含まれます。

この章の内容は次のとおりです。

- 第5.1項「エンタープライズ・デプロイメント用のデータベースの準備の概要」

- 第5.2項「データベース要件について」

- 第5.3項「データベース・サービスの作成」

- 第5.4項「Oracle RACデータベースへのOracle Fusionメタデータ・リポジトリのロード」

- 第5.5項「トランザクション・リカバリ権限のSOAスキーマの構成」

- 第5.6項「データベースのバックアップ」

5.1 エンタープライズ・デプロイメント用のデータベースの準備の概要

SOAエンタープライズ・トポロジでは、データベースにはOracle Fusion Middlewareリポジトリが格納されます。これは、様々なOracle Fusion Middlewareコンポーネントによって使用されるスキーマのコレクションです。コンポーネントの例には、SOAコンポーネント、BAMおよびUMSなどがあります。このデータベースはアイデンティティ管理データベースとは別になっています。これは、Oracle Internet DirectoryやDIPなどのコンポーネントによってアイデンティティ管理のエンタープライズ・デプロイメントで使用されます。

Oracle Fusion Middlewareコンポーネントを構成するには、まずOracle Fusion Middlewareリポジトリをインストールする必要があります。Oracle Fusion Middlewareメタデータ・リポジトリは、リポジトリ作成ユーティリティ(RCU)を使用して既存のデータベースにインストールします。RCUはRCUのDVDにあるか、表2-2に記載された場所にあります。エンタープライズ・トポロジでは、Real Application Clusters (Oracle RAC)データベースを強くお薦めします。

SOAコンポーネントを構成すると、メタデータ・リポジトリを含むデータベースへの接続情報を入力するように構成ウィザードで求められます。

5.2 データベース要件について

メタデータ・リポジトリをデータベースにロードする前に、次の各項で説明されている要件をデータベースが満たしていることを確認してください。

- 第5.2.1項「データベース・ホストの要件」

- 第5.2.2項「サポートされているデータベース・バージョン」

- 第5.2.3項「初期化パラメータについて」

5.2.1 データベース・ホストの要件

データ層内のCUSTDBHOST1およびCUSTDBHOST2には、次の要件があります。

- Oracle Clusterware
Linux用11g リリース1 (11.1)については、Oracle Clusterwareのインストレーション・ガイドを参照してください。

- Oracle Real Application Cluster
Linux用11g リリース1 (11.1)については、『Oracle Real Application Clustersインストレーション・ガイドfor Linux and UNIX』を参照してください。Linux用10g リリース2 (10.2)については、Oracle Database Oracle ClusterwareとOracle Real Application Clustersのインストレーション・ガイドを参照してください。

- 自動ストレージ管理(オプション)
ASMでは、ノードが全体としてインストールされます。データベースのOracleホームとは異なるOracleホームにインストールすることをお薦めします。このオプションは、「構成の選択」ページに表示されます。「自動ストレージ管理の構成」オプションを選択して、別のASMホームを作成します。

- Oracle RACデータベース・インスタンス間の時間同期
サーバー移行で構成された、Fusion Middlewareクラスタ内のサーバーで使用されているデータベース・インスタンスのクロックは、同期化されている必要があります。

5.2.2 サポートされているデータベース・バージョン

Oracle SOA Suiteでは、サポートされるデータベースおよびスキーマが存在している必要があります。

- 使用するデータベースが認証されていること、または認証済のすべてのデータベースを確認するには、Oracle Fusion Middleware Supported System ConfigurationsのページにあるOracle Fusion Middleware 11g リリース1 (11.1.1.x)の製品エリアを参照してください。

http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html

データベースのリリースを確認するには、PRODUCT_COMPONENT_VERSIONビューに問い合せます。

SQL> SELECT VERSION FROM SYS.PRODUCT_COMPONENT_VERSION WHERE PRODUCT LIKE 'Oracle%';

注意:

- Oracle SOAは、メタデータ(10gまたは11g)の格納に使用するデータベースにAL32UTF8キャラクタ・セットをサポートするよう要求します。データベースの文字セットの選択に関する情報は、データベースのドキュメントを確認してください。

- Oracle SOAエンタープライズ・デプロイメントでは、Oracle RACデータベースへの接続にGridLinkデータ・ソースを使用することをお薦めします。GridLinkでOracle Single Client Access Name (SCAN)機能を使用するには、Oracle RACデータベースのバージョンがOracle Database 11gR2 (11.2以降、Enterprise Edition)である必要があります。

5.2.3 初期化パラメータについて

必要な最小値に次の初期化パラメータが設定されていることを確認してください。これは、リポジトリ作成アシスタントによってチェックされます。

表5-1 必要な初期化パラメータ

構成

パラメータ

必要な値

パラメータ・クラス

SOA

PROCESSES

300以上

静的

BAM

PROCESSES

100以上

静的

SOAとBAM

PROCESSES

400以上

静的

SOAとOSB

PROCESSES

800以上

静的

SQL*Plusを使用して初期化パラメータの値をチェックするには、SHOW PARAMETERコマンドを次のように使用します。

SYSユーザーとして、SHOW PARAMETERコマンドを次のように発行します。

SQL> SHOW PARAMETER processes;

次のコマンドを使用して初期化パラメータを設定します。

SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE;

データベースを再起動します。

注意:

パラメータの値を変更する方法は、パラメータが静的か動的かによって異なり、データベースがパラメータ・ファイルとサーバー・パラメータ・ファイルのどちらを使用しているかによっても異なります。パラメータ・ファイル、サーバー・パラメータ・ファイルおよびパラメータ値の変更方法の詳細は、Oracle Database管理者ガイドを参照してください。

5.3 データベース・サービスの作成

複数のOracle Fusion Middleware製品で同一データベースを共有する場合は、各製品を個別の専用データベース・サービスに接続するように構成します。また、データベース・サービスはデフォルトのデータベース・サービスとは別のものにしてください。サービスを使用したOracleデータベースへの接続の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のサービスおよびVIPアドレスを使用したOracleデータベースへの接続の概要に関する項を参照してください。データベース・サービスの作成および管理の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』の自動ワークロード管理の紹介に関する項を参照してください。

ランタイム接続のロード・バランシングでは、ロード・バランシングを有効にする各サービスのサービス・レベルの目標を使用してOracle RACロード・バランシング・アドバイザを構成する必要があります。Oracle RACロード・バランシング・アドバイザは、SERVICE_TIMEまたはTHROUGHPUTに対して構成できます。接続ロード・バランシングの目標をSHORTに設定します。10gおよび11g リリース1データベースについては、この変更にDBMS_SERVICEパッケージを使用します。11g リリース2では、かわりにsrvctlコマンド・ユーティリティを使用します。

この項には次のトピックが含まれます:

- 第5.3.1項「10gおよび11g リリース1 (11.1)データベース用のデータベース・サービスの作成」

- 第5.3.2項「11g リリース2 (11.2)データベース用のデータベース・サービスの作成」

5.3.1 10gおよび11g リリース1 (11.1)データベース用のデータベース・サービスの作成

10gおよび11gのデータベース・サービスの作成および変更にはDBMS_SERVICEパッケージを使用します。

データベース・サービスを作成および変更する手順は次のとおりです。

1. SQL*Plusにログオンして、サービスを作成します。

SQL*Plus "sys/password as sysdba"

SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE
(SERVICE_NAME => 'soaedg.mycompany.com',
NETWORK_NAME => 'soaedg.mycompany.com'
);

注意:

Oracle RACデータベースのサービス名には小文字を使用し、続けてドメイン名を指定します。例:

soaedg.mycompany.com

注意:

EXECUTE DBMS_SERVICEコマンドを1行で入力します。

DBMS_SERVICEパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

2. 次のsrvctlコマンドを使用して、データベースにサービスを追加し、それをインスタンスに割り当てます。

srvctl add service -d soadb -s soaedg.mycompany.com -r soadb1,soadb2

3. サービスを起動します。

srvctl start service -d soadb -s soaedg.mycompany.com

注意:

SRVCTLによるデータベース・サービスの作成および管理の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のSRVCTLによるサービスの管理に関する項を参照してください。

4. 適切なサービスの目標用にサービスを変更します。

SQL>EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'soaedg.mycompany.com',goal => DBMS_SERVICE.GOAL_THROUGHPUT, clb_goal =>DBMS_SERVICE.CLB_GOAL_SHORT);

または、

SQL>EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'soaedg.mycompany.com', goal => DBMS_SERVICE.GOAL_SERVICE_TIME, clb_goal =>DBMS_SERVICE.CLB_GOAL_SHORT);

5.3.2 11g リリース2 (11.2)データベース用のデータベース・サービスの作成

11g リリース2 (11.2) のデータベース・サービスの作成および変更には、srvctlユーティリティを使用します。

データベース・サービスを作成および変更する手順は次のとおりです。

1. SQL*Plusにログオンして、サービスを作成します。

sqlplus "sys/password as sysdba"

SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE
(SERVICE_NAME => 'soaedg.mycompany.com',
NETWORK_NAME => 'soaedg.mycompany.com'
);

注意:

Oracle RACデータベースのサービス名には小文字を使用し、続けてドメイン名を指定します。例:

soaedg.mycompany.com

注意:

EXECUTE DBMS_SERVICEコマンドを1行で入力します。

DBMS_SERVICEパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

2. サービスをデータベースに追加し、srvctlを使用してインスタンスに割り当てます。

srvctl add service -d soadb -s soaedg.mycompany.com -r soadb1,soadb2

3. サービスを起動します。

srvctl start service -d soadb -s soaedg.mycompany.com

注意:

SRVCTLによるデータベース・サービスの作成および管理の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のSRVCTLによるサービスの管理に関する項を参照してください。

4. 適切なサービスの目標用にサービスを変更します。

srvctl modify service -d soadb -s soaedg.mycompany.com -B SERVICE_TIME -j SHORT

または、

srvctl modify service -d soadb -s soaedg.mycompany.com -B         THROUGHPUT  -j SHORT

別のサービス定義の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のロード・バランシング・アドバイザに関する項を参照してください。

5.4 Oracle RACデータベースへのOracle Fusionメタデータ・リポジトリのロード

リポジトリ作成ユーティリティ(RCU)はRCU DVDから入手できます。データベースのシードに使用するRCUは、Oracle SOA Suiteインストールのパッチ・セットのレベルと一致している必要があります。つまり、このエンタープライズ・デプロイメントでOracle SOA Suite 11gR1 PS5 (11.1.1.6)をインストールする場合は、RCU 11gR1 PS5 (11.1.1.6)を使用する必要があります。

データベースにOracle Fusion Middlewareリポジトリをロードする手順は次のとおりです。

1. RCUのDVDにあるリポジトリ作成ユーティリティ(RCU)を起動するには、最初にRCUのDVDを挿入します。

2. binディレクトリでRCUを起動します。
./rcu

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードします。「次へ」をクリックします。

5. 「データベース接続の詳細」画面で、データベースの情報を正しく入力します。

1. データベース・タイプ: 「Oracle Database」を選択します。

2. ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合は、次のように仮想IP名またはノード名の1つをホスト名として指定します: CUSTDBHOST1-VIP

注意:

RAC SCANアドレスをホスト名として使用できます。SCANアドレスの使用の詳細は、『Oracle Fusion Middleware高可用性ガイド』のOracle Database 11g (11.2)でのSCANアドレスの使用に関する項を参照してください。

3. ポート: データベースのポート番号を入力します: 1521

4. サービス名: データベースのサービス名を、小文字で入力します。例:
soaedg.mycompany.com

5. ユーザー名: SYS

6. パスワード: SYSユーザーのパスワードを入力します。

7. ロール: SYSDBA

「次へ」をクリックします。

6. 接続しているデータベースにUTF8以外のCharsetが含まれていることを示す警告メッセージが表示された場合、多言語をサポートするためにこのデータベースを使用すると、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。
「無視」または「停止」をクリックします。

7. 「コンポーネントの選択」画面で、次の手順を実行します。

1. 「接頭辞の新規作成」を選択して、データベース・スキーマに使用する接頭辞を入力します。たとえば、DEVまたはPRODなどです。接頭辞は、データベース内の複数リポジトリの論理グループの作成に使用されます。詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

2. 第5.5項の手順で入力する必要があるため、このスキーマ名をメモしておきます。

3. 次を選択します。

- AS共通スキーマ
- Metadata Services

- SOAおよびBPMインフラストラクチャ:
- SOAインフラストラクチャ

- ユーザー・メッセージング・サービス

- Business Activity Monitoring

注意:

Business Activity Monitoring (BAM)はBAMインストールにのみ必要です。

注意:

Oracle Service Busで必要になるオブジェクトはSOA_INFRAスキーマの一部として作成されます。

「次へ」をクリックします。

8. 「スキーマ・パスワード」画面で、「補助スキーマにメイン・スキーマのパスワードを使用」を選択します。次の画面で、すべてのコンポーネントのスキーマ・パスワードを入力します。

9. 「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。
確認のダイアログが表示され、選択したスキーマに存在しない表領域が作成されるという内容のメッセージが表示されます。「OK」をクリックして、このメッセージを確認します。

10. 「サマリー」画面で「作成」をクリックします。

11. 「完了サマリー」画面で「閉じる」をクリックします。

12. 追加した新しいユーザーでデータベースに接続し、必要なスキーマが作成されていることを確認します。

sqlplus  PROD_SOAINFRA/password;

CUBE_INSTANCE表の説明を問い合せて、簡単に検証します。次のような表が表示されます。

SQL> desc CUBE_INSTANCE;
Name                                      Null?    Type
--------------------------------- ---- --------------------------
CIKEY                                     NOT NULL NUMBER(38)
CREATION_DATE                             NOT NULL TIMESTAMP(6)
...

Oracle WSMポリシーとOWSM MDSスキーマについて

Oracle WSMがSOAエンタープライズ・デプロイメントの一部である場合は、Oracle WSMポリシーの格納にアイデンティティ管理データベースを使用することをお薦めします。OWSM MDSスキーマでは、他のSOAスキーマが使用する情報を使用するのではなく、IMデータベース接続情報を使用します。データベースで必要なスキーマを作成するには、IMデータベース情報を使用して前述の手順を繰り返します(RCUを再度実行します)。ただし、手順7の「コンポーネントの選択」画面では「AS共通スキーマ: Metadata Services」のみを選択します。Oracle WSMポリシーの格納にアイデンティティ管理データベースを使用する方法の詳細は、第15章「エンタープライズ・デプロイメントとOracle Identity Managementの統合」を参照してください。

5.5 トランザクション・リカバリ権限のSOAスキーマの構成

WebLogic Serverコンテナのクラッシュ後、進行中のトランザクションをリカバリする際に、Oracle WebLogic Serverトランザクション・マネージャでトランザクション状態の情報を問い合せて該当するコマンド(commitやrollbackなど)を発行するには、適切なデータベース権限が必要です。

これらの権限は、RCUの操作によって決定されるsoainfraスキーマの所有者に付与する必要があります。

トランザクション・リカバリ権限用のSOAスキーマを構成するには:

1. sysdba権限を持つユーザーとしてSQL*Plusにログオンします。例:

sqlplus "/ as sysdba"

2. 次のコマンドを入力します。

SQL> Grant select on sys.dba_pending_transactions to soa_schema_prefix_soainfra;

Grant succeeded.

SQL> Grant force any transaction to soa_schema_prefix_soainfra;

Grant succeeded.

SQL>

5.6 データベースのバックアップ

データベースにメタデータ・リポジトリをロードした後、エンタープライズ・デプロイメントで使用するソフトウェアをインストールする前に、バックアップを作成します。データベースをバックアップする目的は、今後の手順で問題が発生した場合にすぐにリカバリできるようにするためです。この目的のためにデータベースのバックアップ計画を使用することも、オペレーティング・システムのツールやRMANを使用して単純にバックアップすることもできます。データベース用にOracle Recovery Managerを使用することをお薦めします(特に、Oracle ASMを使用してデータベースを作成した場合)。可能な場合、オペレーティング・システムのツール(tarなど)を使用してコールド・バックアップも実行できます。

データベース増大の管理方法

Oracle SOA Suite 11gのインストールでは、Oracle SOA Suiteデータベースの増大の管理など、データベース管理者にとっての課題がいくつかあります。データベースの管理の重要性を過小評価すると、データベースを製品環境に移行したときに問題が生じる可能性があります。適切な方針の決定、および容量、テストおよび監視の計画の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のデータベース増大の計画の概要に関する項を参照してください。

6 エンタープライズ・デプロイメント用のソフトウェアのインストール

この章では、Oracle SOAのエンタープライズ・デプロイメントの参照用トポロジに必要なソフトウェアをインストールする手順を説明します。Oracle HTTP Serverをインストールした後に、Oracle Fusion Middlewareをインストールします。

この章の項目は次のとおりです。

- 第6.1項「ソフトウェアのインストール・プロセスの概要」

- 第6.2項「Oracle HTTP Serverのインストール」

- 第6.3項「Oracle Fusion Middlewareのインストール」

6.1 ソフトウェアのインストール・プロセスの概要

エンタープライズ・デプロイメントのソフトウェアのインストールは、2つの部分に分割できます。最初の部分では必要なWeb層のインストールについて説明し、2番目の部分では必要なFusion Middleware (FMW)コンポーネントについて説明します。以降の章では、Oracle SOAの参照用トポロジを作成するために必要な構成手順を説明します。

ソフトウェアの入手

ソフトウェアを入手する場所の詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のOracle Fusion Middlewareソフトウェアの入手に関する項を参照してください。

ダウンロード場所の1つを選択し、「SOA Suite」をダウンロードします。.zipアーカイブ・ファイルがシステムに保存されます。

アーカイブ・ファイルをダウンロードした後、インストールを実行するマシン上の任意のディレクトリにアーカイブ・ファイルを解凍します。

インストールするソフトウェア

表6-1に、各ホストにインストールする必要があるソフトウェアまたは各ホストからアクセス可能なソフトウェアを示します。

表6-1 各ホストにインストールする必要があるソフトウェアまたは各ホストからアクセス可能なソフトウェア

ホスト

Oracle HTTP Server

Oracle WebLogic Server

Oracle SOA Suite

WEBHOST1

X

WEBHOST2

X

SOAHOST1

X

X

SOAHOST2

X

X

6.2 Oracle HTTP Serverのインストール

この項の項目は次のとおりです。

- 第6.2.1項「Oracle HTTP Serverのインストールの前提条件」

- 第6.2.2項「Oracle HTTP ServerのWEBHOST1およびWEBHOST2へのインストール」

- 第6.2.3項「Oracle Fusion Middlewareインストールのバックアップ」

6.2.1 Oracle HTTP Serverのインストールの前提条件

Oracle HTTP Server (OHS)をインストールする前に、ご使用のマシンが次の要件を満たしていることを確認します。

- 『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』で指定されているように、システム、パッチ、カーネルおよびその他の要件が満たされていることを確認します。

- Oracle HTTP Serverはデフォルトではポート7777にインストールされるので、ノード上のどのサービスでもポート7777を使用していないことを確認する必要があります。このポートが使用中かどうかを確認するには、Oracle HTTP Serverをインストールする前に次のコマンドを実行します。

netstat -an | grep 7777

ポート7777が使用されている場合は解放する必要があります。

- Linuxプラットフォームで、 /etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいことおよびそのディレクトリに対する書込み権限があることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

- インストールを開始する前に、次の環境変数が設定されていないことを確認します。

- LD_ASSUME_KERNEL

- ORACLE_INSTANCE

6.2.2 Oracle HTTP ServerのWEBHOST1およびWEBHOST2へのインストール

Oracle HTTP Serverのインストールでは、Web層をインストールし、ドメインには関連付けません。しかし、Web層をドメインに関連付けなくても、Web層用のMW_HOMEディレクトリを作成する必要があります。

第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のとおり、冗長性を確保するため、Oracle Fusion Middlewareを記憶域上の少なくとも2つの場所にインストールします。

1. インストール・メディアのディスク1からOracle HTTP Serverのインストーラを起動します。

./runInstaller

2. 「インベントリ・ディレクトリの指定」画面で、次の手順を実行します。

1. HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所をお薦めします)。

2. インストールを実行するユーザーのOSグループを入力します。

3. 「OK」をクリックします。

4. 画面上の指示に従い、root権限で/createCentralInventory.shを実行します。

「OK」をクリックします。

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「ソフトウェア更新のインストール」画面で、「ソフトウェアの更新のスキップ」を選択して、「次へ」をクリックします。

5. 「インストール・タイプの選択」画面でインストール - 構成なしを選択し、「次へ」をクリックします。

6. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。

7. 「インストール場所の指定」画面で、Web層ホーム・ディレクトリを含めるMW_HOMEを作成します。2つの新規ディレクトリを作成します。既存のディレクトリは選択しません。この画面で、次のように入力します。

- Fusion Middlewareホームの場所(インストール場所): ORACLE_BASE/product/fmw

- Oracleホーム・ディレクトリ: Web

「次へ」をクリックします。

8. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。

9. 「インストール・サマリー」画面で、選択内容が正しいことを確認します。そうでない場合は、「戻る」をクリックしてそれまでの画面に戻り、選択内容を変更します。問題がなければ、「インストール」をクリックします。
UNIXシステムでoracleRoot.shスクリプトの実行を求められたら、rootユーザーとして実行します。

Oracle HTTP Serverソフトウェアがインストールされます。

10. 「インストール完了」画面で「終了」をクリックして終了します。

6.2.3 Oracle Fusion Middlewareインストールのバックアップ

この時点でFusion Middlewareホームをバックアップする必要があります(この時点ですべてのサーバーが停止していることを確認します)。

WEBHOST1> tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw HOME/oraInventory

6.3 Oracle Fusion Middlewareのインストール

この項では、Oracle SOAのエンタープライズ・デプロイメントの参照用トポロジに必要なOracle Fusion Middlewareソフトウェアをインストールする方法を説明します。インストールするソフトウェア・コンポーネントは、Oracle WebLogic Serverホーム(WL_HOME)およびOracleホーム(ORACLE_HOME)です。第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のとおり、冗長性を確保するため、Oracle Fusion Middlewareを記憶域上の少なくとも2つの場所にインストールします。

注意:

セットアップ・プロセスを開始する前に、リリース・ノートを読み、インストールおよびデプロイメントに関する追加情報を確認してください。これらは、Oracle Fusion Middlewareドキュメント・ライブラリ(http://docs.oracle.com/cd/E28280_01/relnotes.htm)で入手できます。

この項の項目は次のとおりです。

- 第6.3.1項「Oracle WebLogic ServerのインストールとFusion Middlewareホームの作成」

- 第6.3.2項「Oracle Fusion Middleware SOA Suiteのインストール」

- 第6.3.3項「必要なOracle Service Busバイナリのインストール」

- 第6.3.4項「Fusion Middlewareインストールのバックアップ」

6.3.1 Oracle WebLogic ServerのインストールとFusion Middlewareホームの作成

Oracle WebLogic ServerをSOAHOST1およびSOAHOST2にインストールする手順は次のとおりです。

注意:

WebLogic Serverを、64ビットJDKを使用して64ビット・プラットフォームにインストールする場合は、この項の手順ではなく、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』の64ビットJDKを使用した64ビット・プラットフォームへのWebLogic Serverのインストールに関する項を参照してください。

1. Oracle WebLogic Serverのインストーラを次のインストール・メディアから起動します。

$ ./wls1036_linux32.bin

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「ミドルウェア・ホーム・ディレクトリの選択」画面で、次の手順を実行します。

- 「新しいミドルウェア・ホームを作成する」を選択します。

- 「ミドルウェア・ホーム・ディレクトリ」で、ORACLE_BASE/product/fmwと入力します

ORACLE_BASEは、Oracle製品のインストール先であるベース・ディレクトリです。推奨値は/u01/app/oracleです。詳細は、第4.3項「各種ディレクトリの推奨場所について」を参照してください。

「次へ」をクリックします。

4. 「セキュリティ更新のための登録」画面で、セキュリティ更新の通知を受け取る連絡先の情報を入力して、「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。

6. 「製品とコンポーネントの選択」画面で、「次へ」をクリックします。

7. 「JDKの選択」画面で、「Oracle JRockit 1.6.0_<version> SDK」のみを選択して「次へ」をクリックします。

8. 「製品インストール・ディレクトリの選択」画面で、ORACLE_BASE/product/fmw/wlserver_10.3とORACLE_BASE/product/fmw/coherence_3.7ディレクトリを受け入れ、「次へ」をクリックします。

9. 「インストールの概要」画面で「次へ」をクリックします。
Oracle WebLogic Serverソフトウェアがインストールされます。

10. 「インストール完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除して「完了」をクリックします。

11. Oracle WebLogic Serverのインストール後、ORACLE_HOMEディレクトリに次のディレクトリおよびファイルが表示されることを確認し、インストールが成功したことを確認します。

- coherence_version

- jrockit-jdkversion

- modules

- registry.xml

- utils

- domain-registry.xml

- logs

- ocm.rsp

- registry.dat

- wlserver_10.3

6.3.2 Oracle Fusion Middleware SOA Suiteのインストール

Oracle Fusion Middleware SOA SuiteをSOAHOST1およびSOAHOST2にインストールする手順は次のとおりです。

1. Linuxプラットフォームで、 /etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいことおよびそのディレクトリに対する書込み権限があることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

2. インストール・メディアのディスク1からOracle Fusion Middleware SOA Suiteのインストーラを起動します。

./runInstaller

インストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を入力します(例: ORACLE_BASE/product/fmw/jrockit-jdk1.6.0_version)。詳細は、第6.3.1項「Oracle WebLogic ServerのインストールとFusion Middlewareホームの作成」を参照してください。

3. 「インベントリ・ディレクトリの指定」画面で、次の手順を実行します。

1. HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所をお薦めします)。

2. インストールを実行するユーザーのOSグループを入力します。

3. 「OK」をクリックします。

画面の手順に従って、/createCentralInventory.shをrootとして実行します。

「OK」をクリックします。

注意:

「インベントリ・ディレクトリの指定」画面は、UNIXオペレーティング・システムで、Oracle Universal Installerによる初めてのインストール時のみ表示されます。インストーラは、インベントリ・ディレクトリを使用して、マシンにインストールしたすべてのOracle製品を追跡します。

4. 「ようこそ」画面で「次へ」をクリックします。

5. 「ソフトウェア更新のインストール」画面で、「ソフトウェアの更新のスキップ」を選択して、「次へ」をクリックします。

6. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「OK」をクリックします。

7. 「インストール場所の指定」画面で、Oracle Fusion Middleware SOA Suiteのインストール場所を指定します。すでにインストールされているOracleミドルウェア・ホームをドロップダウン・リストから選択します。Oracleホーム・ディレクトリとして、ディレクトリ名soaを入力します。

図6-1 インストーラ・ウィザードの「インストール場所の指定」画面

完了したら、「次」をクリックします。

8. Application Server画面で、WebLogic Serverを選択し、「次へ」をクリックします。

9. 「インストールの概要」画面で「インストール」をクリックします。
Oracle Fusion Middleware SOA Suiteソフトウェアがインストールされます。

10. 「インストール完了」画面で「終了」をクリックします。

11. Oracle WebLogic SeverおよびOracle Fusion Middleware for SOAの両方のインストールが完了したら、ORACLE_HOMEディレクトリに次のディレクトリおよびファイルが表示されることを確認し、インストールが成功したことを確認します。

- coherence_X.X

- jrockit-jdkY.Y

- modules

- oracle_common

- registry.xml

- utils

- domain-registry.xml

- logs

- ocm.rsp

- registry.dat

- soa

- wlserver_10.3

6.3.3 必要なOracle Service Busバイナリのインストール

Oracle Fusion Middleware Oracle Service BusをSOAHOST1およびSOAHOST2にインストールする手順は次のとおりです。

1. Linuxプラットフォームで、 /etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいことおよびそのディレクトリに対する書込み権限があることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

2. Oracle Service Busのインストーラを次のインストール・メディアから起動します。

./runInstaller

インストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を入力します(例: ORACLE_BASE/product/fmw/jrockit-jdk1.6.0_version)。詳細は、第6.3.1項「Oracle WebLogic ServerのインストールとFusion Middlewareホームの作成」を参照してください。

3. 「ようこそ」画面で「次へ」をクリックします。

注意:

SOAHOST1およびSOAHOST2にすでにSOA Suite Oracleホームが含まれているため、Oracleインベントリはすでに存在し、これをインストールで使用するため、「インベントリ・ディレクトリの指定」画面は表示されません。

4. 「ソフトウェア更新のインストール」画面で、「ソフトウェアの更新のスキップ」を選択して、「次へ」をクリックします。

5. 「インストールの場所」画面で、Oracle Service Busのインストール場所を指定します。すでにインストールされているOracleミドルウェア・ホームをドロップダウン・リストから選択します。「Oracleホーム」ディレクトリには、ディレクトリ名(osb)を入力します。「次へ」をクリックします。

6. 「インストール・タイプ」で、「カスタム」を選択して「次へ」をクリックします。

7. 「インストールするコンポーネント」画面で、「Oracle Service Bus IDE」と「Oracle Service Bus Examples」の選択を解除し、「次へ」をクリックします。

8. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「OK」をクリックします。

9. 製品ホームの場所で、インストールしたWebLogic Serverのインストール・ディレクトリを指定し、「次へ」をクリックします。

10. 「インストールの概要」画面で「インストール」をクリックします。

11. 製品ホームの場所で、インストールしたWebLogic Serverのインストール・ディレクトリを指定し、「次へ」をクリックします。

12. 「インストールの概要」画面で「インストール」をクリックします。

13. 「インストール完了」画面で「終了」をクリックします。

14. Oracle Service Busのインストールが完了したら、ORACLE_HOME_OSBディレクトリ(osbの下)に次のディレクトリが表示されることを確認し、インストールが成功したことを確認します。

- 3rdparty

- Common

- Diagnostics

- Install

- Lib

- oraInst.loc

- soa

- bin

- config

- financial

- inventory

- modules

- osb

- cfgtoollogs

- dbscripts

- harvester

- L10N

- OPatch

- oui

15. SOAHOST2に対してこれらの手順を繰り返します。

6.3.4 Fusion Middlewareインストールのバックアップ

この時点でFusion Middlewareホームをバックアップする必要があります(まず、サーバーが停止していることを確認します)。SOHOAST1から:

tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw

Oracle WebLogic ServerおよびOracle Fusion Middlewareコンポーネントの両方のインストール・ファイルのバックアップが作成されます。

7 エンタープライズ・デプロイメント用のWeb層の構成

この章では、Oracle Fusion Middleware SOA Suite実装をサポートするOracle Web層の構成方法を説明します。

この章の項目は次のとおりです。

- 第7.1項「Web層構成の概要」

- 第7.2項「Web層構成の前提条件」

- 第7.3項「構成ウィザードによるOracle HTTP Serverの構成」

- 第7.4項「構成の検証」

- 第7.5項「HTTPリクエストをルーティングするためのロード・バランサの構成」

- 7.6項「仮想ホストの定義」

7.1 Web層構成の概要

Oracle Web層ソフトウェアを構成する前に、第6.2項「Oracle HTTP Serverのインストール」の説明に従ってこのソフトウェアをWEBHOST1とWEBHOST2にインストールし、第7.3項「構成ウィザードによるOracle HTTP Serverの構成」の説明に従って、インスタンス・ホーム、インスタンス名およびOracle HTTP Serverコンポーネント名を定義する必要があります。

最後の項では、両方のOHSサーバーで、httpd.confファイルの<VirtualHost>セクションのディレクティブを定義する方法を説明します。これらの仮想ホスト名は、第3.3項「ロード・バランサの構成」でロード・バランサを構成したときに作成したものです。

7.2 Web層構成の前提条件

Oracle Web層ソフトウェアを構成する前に、第6.2項「Oracle HTTP Serverのインストール」の説明に従ってこのソフトウェアをWEBHOST1とWEBHOST2にインストールする必要があります。構成ウィザードを実行して、インスタンス・ホーム、インスタンス名およびOracle HTTP Serverコンポーネント名を定義します。

7.3 構成ウィザードによるOracle HTTP Serverの構成

Oracle Web層の構成手順は、WEBHOST1とWEBHOST2で同じです。

Oracle Web層を構成する手順は次のとおりです。

1. Oracle Fusion Middleware構成ウィザードの場所にディレクトリを変更します。

WEBHOST1> cd WEB_ORACLE_HOME/bin

2. 構成ウィザードを起動します。

WEBHOST1> ./config.sh

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「コンポーネントの構成」画面で「Oracle HTTP Server」を選択し、「選択されたコンポーネントとWebLogicドメインの関連付け」の選択を解除します。「Oracle Web Cache」は選択されていないことを確認します。
「次へ」をクリックします。

5. 「コンポーネントの詳細の指定」画面で、次の値を指定します。

- インスタンス・ホームの場所: ORACLE_BASE/admin/webn

- ASインスタンス名: webn

- OHSコンポーネント名: ohsn

(ここでnは、インストール上の連番を示します。たとえば、WEBHOST1には1、WEBHOST2には2などです。)

注意:

WEBHOST1とWEBHOST2で、異なるOracle HTTP Serverインスタンス名を指定する必要があります。

「次へ」をクリックします。

6. 「ポートの構成」画面でファイル名を選択し、「表示/編集」をクリックします。
高可用性の実装では、様々なコンポーネントで使用されるポートのすべてを複数のホスト間で同期すると、エンタープライズ・デプロイメントがより簡単になります(必須ではありません)。使用するポートをファイルに指定することで、自動ポート構成をバイパスできます。

ファイルは次のようになります。

[OHS]
#Listen port for OHS component
OHS Port = 7777

[OPMN]
#Process Manager Local port no
OPMN Local Port = 1880

サンプルのstaticports.iniファイルは、インストール・ディスク1のstage/Responseディレクトリにあります。

「次へ」をクリックします。

7. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。

8. 「インストール・サマリー」画面で、選択内容が正しいことを確認します。そうでない場合は、「戻る」をクリックしてそれまでの画面に戻り、選択内容を変更します。準備ができたら、「構成」をクリックします。

9. 複数のConfiguration Assistantが連続して起動されるため、時間がかかることがあります。終了したら、「次へ」をクリックすると、「インストール完了」画面が表示されます。

10. 「インストール完了」画面で「終了」をクリックして終了します。

7.4 構成の検証

インストールが完了したら、Oracle HTTP Serverホーム・ページに、次のURLからアクセスできることを確認します。

http://webhost1.mycompany.com:7777/

7.5 HTTPリクエストをルーティングするためのロード・バランサの構成

Oracle HTTP Server (WEBHOST1、WEBHOST2)を実行するホストへすべてのHTTPリクエストをルーティングするようロード・バランサを構成できます。Oracle HTTP ServerがフロントエンドのOracle WebLogic Serverである場合は、ロード・バランサでスティッキー・セッション(Cookieの挿入)を有効にする必要はありません。このドキュメントで説明するトポロジには該当しませんが、ロード・バランサからOracle WebLogic Serverに直接移動する場合にはスティッキー・セッションが必要です。

使用するロード・バランサによって、構成手順は異なります。具体的な手順は、ロード・バランサのドキュメントを参照してください。

7.6 仮想ホストの定義

このガイドの参照トポロジでは、Oracle HTTPサーバーに対する仮想ホスト・セットを定義する必要があります。各仮想ホストについては、後にWebLogicサーバー・ドメイン内の適切な管理サーバーまたは管理対象サーバーに要求をルーティングするための特定のURLセットを定義する必要があります。

この項には次のトピックが含まれます:

- 第7.6.1項「httpd.confファイルでのIPアドレスとポートの定義」

- 第7.6.2項「<VirtualHost>ディレクティブを定義する.confファイルの作成」

- 第7.6.3項「構成の検証」

7.6.1 httpd.confファイルでのIPアドレスとポートの定義

名前ベースの仮想サーバーを定義します。定義する個々の仮想ホストに対して使用するIPアドレスとポートを定義する必要があるという意味です。一度、httpd.confファイルにIPアドレスとポートを定義すれば、実際の仮想ホスト名(および各々の特定URL)を仮想ホスト専用の.confファイルに定義できます。

IPアドレスおよびポートを定義するには、httpd.confファイルに次のエントリを追加します。

NameVirtualHost *:7777

7.6.2 <VirtualHost>ディレクティブを定義する.confファイルの作成

個々の仮想ホストをホスト自身の.confファイルで定義します。こうすることで、定義する個々の仮想ホストのURLの管理が容易になります。

httpd.confには、ディレクトリ内のすべての*.confをインクルードするINCLUDE文があります。この文により、コンポーネントごとに別個の仮想ホスト・ファイルを作成することが可能になり、仮想ホストの定義の更新、保持およびスケールアウトが簡単になります。

<VirtualHost>のディレクティブを定義するために、次のファイルを新規作成します。

- soa_vh.conf

- soainternal_vh.conf

- admin_vh.conf

- osb_vh.conf (Oracle Service Bus用ドメインの拡張を予定している場合)

次のディレクトリに新規ファイルを作成します。

ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf

個々の仮想ホストをホスト自身の.confファイルに定義する手順は次のとおりです。

1. soa_vh.confファイルを作成し、次のディレクティブを追加します。

<VirtualHost *:7777>
ServerName https://soa.mycompany.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

2. soainternal_vh.confファイルを作成し、次のディレクティブを追加します。

<VirtualHost *:7777>
ServerName soainternal.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

3. admin_vh.confファイルを作成し、次のディレクティブを追加します。

<VirtualHost *:7777>
ServerName admin.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
RewriteRule î/console/jsp/common/logout.jsp "/oamsso/logout.html?end_url=/console" [R]
</VirtualHost>

4. Oracle Service Bus用ドメインの拡張を予定している場合は、osb_vh.confファイルを作成し、次のディレクティブを追加します。

<VirtualHost *:7777>
ServerName https://osb.mycompany.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

5. Oracle HTTPサーバーを両方とも再起動します。

cd ORACLE_BASE/admin/instance_name/bin
opmnctl stopall
opmnctl startall

7.6.3 構成の検証

ロード・バランサから、次のURLにアクセスして、ロード・バランサとOracle HTTP Serverが正しく構成されていることを確認します。

- https://soa.mycompany.com/index.html

- http://admin.mycompany.com/index.html

- http://soainternal.mycompany.com/index.html

- https://osb.mycompany.com/index.html

注意:

これらのURLには、ロード・バランサを介してのみアクセスできます。Webサーバー・ホスト(WEBHOST1またはWEBHOST2)からアクセスしようとすると、これらのURLが原因でエラーが発生します。URLの定義は、ロード・バランサおよび定義済の仮想ホストのURLを介してサーバーにアクセスする場合のみ有効です。

これらのURLにアクセスできない場合は、第3.3項「ロード・バランサの構成」の手順を正しく実行していることを確認してください。

8 エンタープライズ・デプロイメント用のドメインの作成

この章では、構成ウィザード、Oracle WebLogic Server管理コンソール、Oracle Enterprise ManagerおよびOracle WSM Policy Managerを使用してドメインを作成する方法を説明します。ドメインを拡張して、SOAコンポーネントを追加できるほか、必要に応じてOracle Business Activity Monitoringを追加することもできます。

注意:

セットアップのプロセスを開始する前に、Oracle Fusion Middlewareリリース・ノートを読み、インストールとデプロイメントに関する追加情報を確認してください。

この章の項目は次のとおりです。

- 第8.1項「ドメイン作成の概要」

- 第8.2項「SOAHOST1でのVIP1の有効化」

- 第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」

- 第8.4項「構成後タスクおよび検証タスク」

- 第8.5項「SOAHOST2へのドメイン構成の伝播」

- 第8.6項「Oracle WSMでのJava Object Cacheの構成」

- 第8.7項「WebLogicドメインのOracle HTTP Serverの構成」

- 第8.8項「管理サーバーの手動フェイルオーバーの検証」

- 第8.9項「WebLogicドメイン構成のバックアップ」

8.1 ドメイン作成の概要

表8-1に、構成後タスクを含む、WebLogicドメインの作成手順を示します。

表8-1 WebLogicドメインの作成手順

手順

説明

詳細

SOAHOST1でのVIP1の有効化

SOAHOST1ホスト名に対してADMINVHNを有効にします。

第8.2項「SOAHOST1でのVIP1の有効化」

WebLogicドメインの作成

構成ウィザードを起動してWebLogicドメインを作成します。

第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」

構成後タスクおよび検証タスク

構成後タスクおよび検証タスクの手順に従います。

第8.4項「構成後タスクおよび検証タスク」

SOAHOST2へのドメイン構成の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

第8.5項「SOAHOST2へのドメイン構成の伝播」

WebLogicドメインでのOracle HTTP Serverの構成

Oracle HTTP ServerをWebLogicドメインを使用して構成し、構成を検証します。

第8.7項「WebLogicドメインのOracle HTTP Serverの構成」

ドメインのバックアップ

新しく構成したWebLogicドメインをバックアップします。

第8.9項「WebLogicドメイン構成のバックアップ」

一度このドメインを作成および構成すると、次の章で説明するOracle SOAコンポーネント、Oracle BAMまたはOracle BAMをドメインに追加するためのドメイン拡張を実行できます。

8.2 SOAHOST1でのVIP1の有効化

SOAがインストールされているかどうかにかかわらず、この手順は管理サーバーのフェイルオーバーを可能にするために必要です。

管理サーバーは仮想ホスト名(ADMINVHN)に関連付けます。仮想ホスト名は、DNSサーバーとカスタムの/etc/hostエントリのいずれかによって、適切な仮想IP (VIP1)にマップする必要があります。SOAトポロジの必要なノードで、名前解決システム(DNSサーバー、/etc/hosts)に従ってADMINVHNが使用可能であることを確認します。この仮想ホスト名(ADMINVHN1)に関連付けられた仮想IP (VIP1)は、SOAHOST1で有効になっている必要があります。

仮想IPを有効にするには、第3.5項「管理サーバーの仮想IPアドレスの有効化」を参照してください。

8.3 SOAHOST1での構成ウィザードを使用したドメインの作成

Oracle共通ホーム・ディレクトリで構成ウィザードを実行して、管理サーバーとOracle Web Services Managerを含むドメインを作成します。後で、SOAコンポーネントを収めるようにこのドメインを拡張します。

ドメインを作成する手順:

1. リポジトリをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておく必要があります。

2. ディレクトリを構成ウィザードの場所に変更します。これはSOAホーム・ディレクトリ内にあります。SOAHOST1で次のコマンドを実行します。

cd ORACLE_COMMON_HOME/common/bin

3. Oracle Fusion Middleware構成ウィザードを開始します。

./config.sh

4. 「ようこそ」画面で、「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

5. 「ドメイン・ソースの選択」画面が表示されます(図8-1)。

図8-1「ドメイン・ソースの選択」画面

「ドメイン・ソースの選択」画面で、次の手順を実行します。

- 「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。

- 次の製品を選択します。

- WebLogic Serverの基本ドメイン - 10.3.6.0 [wlserver_10.3](これは自動的に選択されます)

- Oracle Enterprise Manager - 11.1.1.0 [oracle_common]

- Oracle WSM Policy Manager 11.1.1.0 [oracle_common]

- Oracle JRF - 11.1.1.0 [oracle_common]

いくつかのターゲットを間違って選択解除した場合は、この画面で次の項目が選択されていることを確認します。

- Oracle Enterprise Manager

- Oracle WSM Policy Manager

- Oracle JRF

「次へ」をクリックします。

6. 「ドメイン名と場所の指定」画面で、ドメイン名(soaedg_domain)を入力します。
ドメイン・ディレクトリが第4章「各種ディレクトリの推奨場所について」で推奨されているディレクトリおよび共有記憶域のマウント・ポイントと一致していることを確認します。ドメイン・ディレクトリには次のように入力します。

ORACLE_BASE/admin/domain_name/aserver/

アプリケーション・ディレクトリには次のように入力します。このディレクトリは共有記憶域内にある必要があります。

ORACLE_BASE/admin/domain_name/aserver/applications

7. 「次へ」をクリックします。

8. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者が使用するユーザー名とパスワードを入力します。
「次へ」をクリックします。

9. 「サーバーの起動モードおよびJDKの構成」画面で、次の手順を実行します。

- 「WebLogicドメインの起動モード」には、「本番モード」を選択します。

- 「JDKの選択」では、「JROCKIT SDK1.6.0_<version>」を選択します。

「次へ」をクリックします。

10. 「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。

- OWSM MDSスキーマを選択します。

- 「コンポーネント・スキーマのOracle RAC構成」については、「GridLinkへ変換」を選択します。

「次へ」をクリックします。

11. 「GridLink RACコンポーネント・スキーマの構成」画面が表示されます(図8-2)。

図8-2 「GridLink RACコンポーネント・スキーマの構成」画面

この画面で、次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: OracleのGridLinkConnections用ドライバ (Thin) バージョン: 10以上を選択します。

- サービス名: データベースのサービス名を、小文字で入力します。例:
soaedg.mycompany.com

- ユーザー名: 対応するコンポーネントのデータベース・スキーマ・オーナーの名前を入力します。

- パスワード: データベース・スキーマ・オーナーのパスワードを入力します。

- 「FANの有効化」を選択します。

- 「SSLの有効化」が選択解除されていることを確認します(暗号化するONS通知にsslが選択されている場合は、適切なウォレットとウォレット・パスワードを指定します)。

- サービス・リスナー: 使用するRACデータベースのためのSCANアドレスとポートを入力します。このアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せれば識別できます。

SQL>show parameter remote_listener;

NAME              TYPE                VALUE
-------------------------------------------------------------
remote_listener   string    db-scan.mycompany.com:1521

注意:

Oracle Database 11g リリース1 (11.1)では、次の例のように、各データベースのインスタンス・リスナーの仮想IPとポートを使用します。

custdbhost1-vip.mycompany.com (port 1521)

および

custdbhost2-vip.mycompany.com (1521)

Oracle Database 10gでは、Oracle RACデータベースへの接続にマルチ・データ・ソースを使用します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- ONSホスト: Oracle RACデータベースのSCANアドレスおよびデータベースから報告されたONSリモート・ポートを入力します。

[orcl@db-scan1 ~]$ srvctl config nodeapps -s

ONS exists: Local port 6100, remote port 6200, EM port 2016

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベースのONSサービスのホスト名とポートを使用します。次に例を示します。

custdbhost1.mycompany.com (port 6200)

および

custdbhost2.mycompany.com (6200)

12. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。

13. 「詳細構成の選択」画面で、次の項目を選択します。

- 管理サーバー

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

「次へ」をクリックします。

14. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: ADMINVHN

- リスニング・ポート: 7001

- SSLリスニング・ポート: 該当なし

- SSL有効: 選択解除

「次へ」をクリックします。

15. 「管理対象サーバーの構成」画面で、「追加」をクリックして次の管理対象サーバーを追加します。

表8-2 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_WSM1

SOAHOST1

7010

なし

いいえ

WLS_WSM2

SOAHOST2

7010

なし

いいえ

「次へ」をクリックします。

16. 「クラスタの構成」画面で、「追加」をクリックして次のクラスタを追加します。

表8-3 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

WSM-PM_Cluster

ユニキャスト

なし

なし

空白

「次へ」をクリックします。

17. 「サーバーのクラスタへの割当」画面で、次のようにサーバーをWSM-PM_Clusterに割り当てます。

- WLS_WSM

- WLS_WSM2

「次へ」をクリックします。

18. 「マシンの構成」画面で、「UNIXマシン」タブをクリックし、「追加」をクリックして次のマシンを追加します。

注意:

「名前」には任意の一意な文字列を指定できます。「ノード・マネージャ・リスニング・アドレス」には解決可能なホスト名を指定する必要があります。

表8-4 マシン

名前

ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINHOST

localhost

他のフィールドはすべてデフォルト値のままにします。

注意:

マシン名は有効なホスト名またはリスニング・アドレスである必要はありません。これはノード・マネージャの場所を示す一意の識別子です。

「次へ」をクリックします。

19. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- SOAHOST1: WLS_WSM1

- SOAHOST2: WLS_WSM2

- ADMINHOST: AdminServer

「次へ」をクリックします。

20. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、wsm-pmアプリケーションがWSM-PM_Clusterのみにターゲット設定されていることを確認します。oracle.wsm.seedpoliciesライブラリは、WSM-PM_Clusterにターゲット設定します。その他すべてのデプロイメントが「AdminServer」にターゲット設定されていることを確認し、「次へ」をクリックします。

21. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のように選択します。

- 左側で「WSM-PM_Cluster」を選択します。右側で「JDBCシステム・リソース」を選択します。これにより、すべてのwsmデータソース(mds-owsm)を自動的に選択できます。

- 左側で「管理サーバー」を選択します。右側で「JDBCシステム・リソース」を選択します。これにより、すべてのwsmデータソース(mds-owsm)を自動的に選択できます。

すべてのJDBCシステム・リソースは、「Admin Server」と「WSM-PM_Cluster」の両方にターゲット設定する必要があります。

- 残りのすべてのサービスが「Admin Server」にターゲット設定されていることを確認します。

- 「次へ」をクリックします。

アプリケーションとリソースのターゲット設定の詳細は、付録B「アプリケーションとリソースのサーバーへのターゲット設定」を参照してください。

22. 「構成サマリー」画面で「作成」をクリックします。

23. 「ドメインの作成」画面で「完了」をクリックします。

8.4 構成後タスクおよび検証タスク

構成ウィザードでドメインを構成したら、次の手順に従って構成後タスクと検証タスクを実行します。

この項には次のトピックが含まれます:

- 第8.4.1項「SOAHOST1での管理サーバー用boot.propertiesの作成」

- 第8.4.2項「SOAHOST1でのノード・マネージャの起動」

- 第8.4.3項「SOAHOST1での管理サーバーの起動」

- 第8.4.4項「GridLinkデータ・ソースの検証」

- 第8.4.5項「管理サーバー構成の検証」

- 第8.4.6項「管理サーバーと同じノードでの管理対象サーバー用独立ドメイン・ディレクトリの作成」

- 第8.4.7項「WSM-PM_ClusterへのJava Required Files (JRF)テンプレートの適用」

- 第8.4.8項「ホスト名検証の無効化」

- 第8.4.9項「WLS_WSM1管理対象サーバーの起動と検証」

8.4.1 SOAHOST1での管理サーバー用boot.propertiesの作成

SOAHOST1上で管理サーバーのboot.propertiesファイルを作成します。ノード・マネージャを使用して管理サーバーを起動するには、この手順を必ず実行する必要があります。

管理サーバーのboot.propertiesファイルを作成する手順は次のとおりです。

1. 次のディレクトリ構造を作成します。

mkdir -p ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/security

2. テキスト・エディタで、次の行を記述したboot.propertiesというファイルを、前の手順で作成した最後のディレクトリに作成します。

username=<adminuser>
password=<password>

注意:

管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順で起動します。

セキュリティ上の理由から、ファイル内のエントリが暗号化されていない時間を短くする必要があります。ファイルを編集した後、できるだけ速やかにサーバーを起動し、エントリを暗号化してください。

3. ファイルを保存してエディタを閉じます。

8.4.2 SOAHOST1でのノード・マネージャの起動

SOAHOST1でノード・マネージャを起動するには、StartScriptEnabledプロパティを'true'に設定し、startNodeManager.shを使用してノード・マネージャを起動します。

SOAHOST1でノード・マネージャを起動する手順は次のとおりです。

1. 次のディレクトリにあるsetNMProps.shスクリプトを実行します。

ORACLE_COMMON_HOME/common/bin

StartScriptEnabledプロパティを'true'に設定してから、ノード・マネージャを起動します。

cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh

注意:

クラスのロードの失敗やその他の問題を回避するには、StartScriptEnabledプロパティを使用します。詳細は、第16.14.5項「SOAサーバーの再起動に失敗したためにポリシー移行が未完になる」も参照してください。

2. ノード・マネージャを起動します。

cd WL_HOME/server/bin
export JAVA_OPTIONS="-DDomainRegistrationEnabled=true"
./startNodeManager.sh

注意:

AdminServerを管理するノード・マネージャの起動時には、-DDomainRegistrationEnabled=trueを設定することが重要です。このマシンにAdminServerが存在せず、このマシンがAdminServerのフェイルオーバー・ノードでもない場合は、SOAHOAST1で次のコマンドを使用してノード・マネージャを起動できます。

./startNodeManager.sh

8.4.3 SOAHOST1での管理サーバーの起動

管理サーバーは、ノード・マネージャを使用して起動および停止します。ただし、初めてノード・マネージャで管理サーバーを起動するときに、構成ウィザードによりノード・マネージャにデフォルトで設定されているユーザー名とパスワードを変更する必要があります。そのため、管理サーバーの初回の起動時に起動スクリプトを使用します。

最初の起動操作には手順1から4が必要ですが、2回目以降の起動には手順4のみが必要です。

ノード・マネージャを使用して管理サーバーを起動する手順は次のとおりです。

1. SOAHOST1上のドメイン・ディレクトリの起動スクリプトを使用して、管理サーバーを起動します。

cd ASERVER_HOME/bin
./startWebLogic.sh

2. 管理コンソールを使用してノード・マネージャの資格証明を更新します。

1. ブラウザで、次のURLにアクセスします。

http://ADMINVHN:7001/console

2. 管理者としてログインします。

3. 「ロックして編集」をクリックします。

4. domain_name→(セキュリティ)タブ→「一般」をクリックして、下部にある「詳細」オプションを開きます。

5. ノード・マネージャの新しいユーザー名を入力するか、既存のユーザー名を書き留めておいてノード・マネージャのパスワードを更新します。

6. 「保存」→「変更のアクティブ化」をクリックします。

3. 管理サーバーのプロセスを停止します。そのためには、そのプロセスが起動したシェルで[Ctrl]キーを押しながら[C]キーを押すか、OSでプロセスを確認してkillコマンドを使用します。

4. WLSTを起動して、nmconnectと前の手順で設定した資格証明により、ノード・マネージャに接続し、nmstartを使用して管理サーバーを起動します。手順2eで入力した、ノード・マネージャのユーザー名とパスワードを入力します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

WLSTシェルを起動したら、次のように指定します。

wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
'SOAHOST1','5556','domain_name','ASERVER_HOME')

wls:/nm/domain_name nmStart('AdminServer')

注意:

このユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバー管理IDおよびパスワードとは無関係であり、次のディレクトリにあるnm_password.propertiesファイルに格納されます。

ORACLE_BASE/admin/domain_name/aserver/domain_name/config/nodemanager

8.4.4 GridLinkデータ・ソースの検証

サーバーが開始したら、GridLinkデーター・ソースが正しく構成され、ONS設定が正しいことを確認します。作成されたすべてのGridLinkデータ・ソースに対して、この手順を実行します。

GridLinkデータ・ソースの構成を検証する手順は次のとおりです。

1. Oracle WebLogic管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

3. 新しいデータ・ソースの内の1つをクリックします。

4. 「監視」タブをクリックし、いずれかのサーバーを選択します。

5. 「統計」タブをクリックし、いずれかのサーバーを選択します。

6. 「ONS」タブをクリックし、「テスト」タブをクリックします。

7. サーバーを選択して、「ONSのテスト」をクリックします。
テストが両方とも成功すれば、正しく構成されています。ONSのテストが失敗した場合は、RACデータベース・ノードでONSサービスが実行されていることを確認します。

orcl@db-scan1 ~]$ srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node db-scan1
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node db-scan2
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node db-scan2

[orcl@db-scan1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

[orcl@db-scan1 ~]$ srvctl status nodeapps | grep ONS
ONS is enabled
ONS daemon is running on node: db-scan1
ONS daemon is running on node: db-scan2

データ・ソースを使用するすべてのWebLogic Serverで、ONSテストを実行します。

8.4.5 管理サーバー構成の検証

ドメインに作成した管理サーバーが正しく構成されているかどうかを確認するため、Oracle WebLogic Server管理コンソールにログインして管理対象サーバーとクラスタが表示されることを確認し、その後Oracle Enterprise Managerにログインします。

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

1. ブラウザで、次のURLにアクセスします。

http://ADMINVHN:7001/console

2. 管理者としてログインします。

3. 管理対象サーバーとしてWLS_WSM1とWLS_WSM2が表示されていることを確認します。

4. WSM-PM_Clusterクラスタが表示されていることを確認します。

5. 次のURLのOracle Enterprise Managerにアクセスできることを確認します。

http://ADMINVHN:7001/em

6. 第8.4.1項「SOAHOST1での管理サーバー用boot.propertiesの作成」で指定したユーザー名とパスワードを使用してEMコンソールにログインします。

8.4.6 管理サーバーと同じノードでの管理対象サーバー用独立ドメイン・ディレクトリの作成

packコマンドおよびunpackコマンドを使用して、管理サーバーが使用するドメイン・ディレクトリを、SOAHOST1で管理対象サーバーが使用するドメイン・ディレクトリから分離します。ディレクトリを分離するこの処理は、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されています。

unpackスクリプトを実行する前に、第4.3項「各種ディレクトリの推奨場所について」の説明のとおり次のディレクトリが存在することを確認してください。

ORACLE_BASE/admin/domain_name/mserver

独立ドメイン・ディレクトリを作成する手順は次のとおりです。

1. 次のように、packコマンドをSOAHOST1上で実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=soadomaintemplate.jar -template_name=soa_domain_template

2. 次のように、unpackコマンドをSOAHOST1上で実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
-template=soadomaintemplate.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

注意:

unpackコマンドを実行するには、次のディレクトリに対する書込み権限が必要です。

/ORACLE_BASE/admin/domain_name

例:

ORACLE_BASE/admin/soaedg_domain/

注意:

このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。

8.4.7 WSM-PM_ClusterへのJava Required Files (JRF)テンプレートの適用

構成ウィザードを使用してドメインが作成された後、WebLogic Serverのインストールに含まれていない多数のリソースをWSM-PM_Clusterにターゲット設定する必要があります。

これらのリソースをターゲット設定する手順は次のとおりです。

1. 第8.4.1項「SOAHOST1での管理サーバー用boot.propertiesの作成」で指定したユーザー名とパスワードを使用してOracle Enterprise Manager Fusion Middleware Controlにログインします。

2. 左側のナビゲーション・ツリーで、「Farm_<domain_name>」→「WebLogicドメイン」→「<domain_name>」を開き「WSM-PM_Cluster」を選択します。

3. 右側で「JRFテンプレートの適用」をクリックします。

4. 確認メッセージが画面に表示されるまで待ちます。
このメッセージで、WSM-PM_ClusterクラスタにJRFテンプレートが正しく適用されていることを確認します。

5. JRFテンプレートも管理サーバーに適用されていることを確認します。そうでない場合は、管理サーバー用のEnterprise Manager画面に「JRFテンプレートの適用」ボタンが表示されます。

アプリケーションとリソースのターゲット設定の詳細は、付録B「アプリケーションとリソースのサーバーへのターゲット設定」を参照してください。

8.4.8 ホスト名検証の無効化

この手順は、管理サーバーで様々なノードを認証するための適切な証明書をまだ設定していないために必要になる手順です(第13章「エンタープライズ・デプロイメント用のノード・マネージャの設定」を参照)。サーバー証明書を構成していないため、様々なWebLogic Serverを管理するときにエラーになります。このエラーを回避するには、トポロジの設定と検証を行う際にホスト名の検証を無効にし、第13章「エンタープライズ・デプロイメント用のノード・マネージャの設定」の説明に従ってエンタープライズ・デプロイメント・トポロジの構成を完了した後に再びホスト名の検証を有効にします。

ホスト名検証を無効化するには:

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

5. 表の「名前」列の「AdminServer(admin)」を選択します。「AdminServer(admin)」の「設定」ページが表示されます。

6. 「SSL」タブをクリックします。

7. 「詳細」をクリックします。

8. 「ホスト名の検証」を「なし」に設定します。

9. 「保存」をクリックします。

10. WLS_WSM1サーバーについてステップ5から9を繰り返します。

11. 変更を保存してアクティブ化します。

12. 変更を有効にするには、管理サーバーを再起動します。
管理サーバーを再起動する手順は次のとおりです。

1. 「サーバーの概要」画面で、「制御」タブを選択します。

2. 表で「AdminServer(admin)」を選択して、「停止」をクリックします。

3. 管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用して再度起動します。

8.4.9 WLS_WSM1管理対象サーバーの起動と検証

管理対象サーバーの構成後、正常に実行されているかどうかを確認します。Oracle WebLogic Server管理コンソールを使用して、管理対象サーバーを起動しそのステータスを確認できます。

WLS_WSM1管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認する手順は次のとおりです。

1. 次の手順に従い、Oracle WebLogic Server管理コンソールを使用してWLS_WSM1管理対象サーバーを起動します。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

2. 「サーバー」を選択します。「サーバーの概要」ページが表示されます。

3. 「制御」タブをクリックします。

4. 「WLS_WSM1」を選択して、「起動」をクリックします。

2. 管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.14項「エンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。

3. 次のURLにアクセスします。

http://SOAHOST1:7010/wsm-pm

4. 「ポリシー・マネージャの検証」をクリックします。
構成が正しい場合は、データ・ストアで使用できるポリシーとアサーション・テンプレートのリストが表示されます。ポリシーやアサーション・テンプレートがまったく表示されない場合は、構成が正しくありません。

8.5 SOAHOST2へのドメイン構成の伝播

SOAHOST1の構成が完了したら、unpackユーティリティを使用してSOAHOST2に構成を伝播し、伝播した構成を検証します。

この項には次のトピックが含まれます:

- 第8.5.1項「unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播」

- 第8.5.2項「アップロードおよびステージング・ディレクトリの絶対パスへの変更」

- 第8.5.3項「WLS_WSM2管理対象サーバーに対するホスト名検証の無効化」

- 第8.5.4項「SOAHOST2でのノード・マネージャの起動」

- 第8.5.5項「WLS_WSM2管理対象サーバーの起動と検証」

8.5.1 unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播

unpackユーティリティを使用してドメイン構成を伝播します。unpackスクリプトを実行する前に、第4.3項「各種ディレクトリの推奨場所について」の説明のとおり次のディレクトリが存在することを確認してください。

ORACLE_BASE/admin/domain_name/mserver

ドメイン構成を伝播する手順は次のとおりです。

1. 次のコマンドをSOAHOST1上で実行して、前の手順で作成したテンプレート・ファイルをコピーします。

cd ORACLE_COMMON_HOME/common/bin

scp soadomaintemplate.jar oracle@SOAHOST2:/ORACLE_COMMON_HOME/common/bin

2. SOAHOST2のWL_HOME/common/binディレクトリではなく、ORACLE_COMMON_HOME/common/binディレクトリからunpackコマンドを実行し、伝播するテンプレートを解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
-template=soadomaintemplate.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

注意:

このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。

8.5.2 アップロードおよびステージング・ディレクトリの絶対パスへの変更

ドメインの作成およびmserverディレクトリへの解凍の後、uploadおよびstageディレクトリを更新します。デフォルトでは次のディレクトリが設定されています。

./servers/AdminServer/upload

および

./servers/server_name/stage

結果として、これらのデフォルト・ディレクトリ・パスにより、リモート・デプロイメントに関する問題およびステージ・モードを使用したデプロイメントに関する問題が発生します。

これらの問題を回避するには、uploadディレクトリを次のディレクトリに更新します。

MSERVER_HOME/servers/AdminServer/upload

また、stageディレクトリを次のディレクトリに更新します。

MSERVER_HOME/servers/server_name/stage

すべてのサーバーについてこれらのディレクトリ・パスを更新します。

これらのディレクトリを更新する手順は次のとおりです。

1. 管理コンソールにアクセスします。

2. 左側のナビゲーション・ツリーで、「ドメイン」、「環境」の順に開きます。

3. 「ロックして編集」をクリックします。

4. 「サーバー」をクリックし、次にサーバーの名前をクリックします。

5. 「構成」の「デプロイメント」セクションで、UploadおよびStageディレクトリを変更します。

8.5.3 WLS_WSM2管理対象サーバーに対するホスト名検証の無効化

このガイドで説明するエンタープライズ・デプロイメントでは、Oracle SOA Suiteを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。WLS_SOA1およびWLS_SOA2管理対象サーバーのホスト名検証を無効化して、様々なWebLogic Serverインスタンスを管理するときにエラーが出ないようにします。詳細は、第8.4.8項「ホスト名検証の無効化」を参照してください。

エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第13.3項「SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。

8.5.4 SOAHOST2でのノード・マネージャの起動

ドメイン構成を伝播しホスト名検証を無効にしたら、StartNodeManager.shスクリプトを使用してノード・マネージャを起動します。

クラスのロードの失敗やその他の問題を回避するには、StartScriptEnabledプロパティを使用します。第16.14.5項「SOAサーバーの再起動に失敗したためにポリシー移行が未完になる」も参照してください。

SOAHOST2でノード・マネージャを起動する手順は次のとおりです。

1. ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。

cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh

2. ノード・マネージャを起動します。

cd WL_HOME/server/bin
./startNodeManager.sh

8.5.5 WLS_WSM2管理対象サーバーの起動と検証

管理コンソールを使用して、WLS_WSM2管理対象サーバーを起動して検証します。

WLS_WSM2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認する手順は次のとおりです。

1. 管理コンソールを使用してWLS_WSM2管理対象サーバーを起動します。

2. 管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.14項「エンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。

3. 次のURLにアクセスします。

http://SOAHOST2:7010/wsm-pm

4. 「ポリシー・マネージャの検証」をクリックします。

8.6 Oracle WSMでのJava Object Cacheの構成

Oracle WSMが稼働するすべてのサーバー間でJavaオブジェクト・キャッシュ(JOC)を構成します。この手順はオプションですが、ローカル・キャッシュを保持することでキャッシュを検索する必要がなくなるため、Oracle WSMのパフォーマンスが向上します。

B2Bアグリーメントの配信チャネルを頻繁に変更する予定の場合は、B2BのMDS更新にJOCを使用します。

次のディレクトリにあるconfigure-joc.pyスクリプトを使用してJavaオブジェクト・キャッシュを構成します。

MW_HOME/oracle_common/bin/

これはWLSTオンライン・モードで実行するPythonスクリプトであるため、管理サーバーが稼働している必要があります。

Oracle製品のJOCポートを構成する場合は、9988から9998の範囲のポートを使用します。

Oracle WSMのJavaオブジェクト・キャッシュを構成する手順は次のとおりです。

1. コマンド行のOracle WebLogic Scripting Tool (WLST)を使用して、SOAHOST1上の管理サーバーに接続します。次に例を示します。

MW_HOME/soa/common/bin/wlst.sh
connect()

入力を求められた場合は、サーバーのURL (t3://ADMINVHN:7001)およびOracle WebLogic Server管理者のユーザー名とパスワードを入力します。

2. wlstを使用して管理サーバーに接続したら、execfileコマンドを次のように使用してスクリプトを起動します。

wls:/mydomain/serverConfig> execfile('MW_HOME/oracle_common/bin/configure-joc.py')

3. 指定されたクラスタのすべての管理対象サーバーのJOCを構成します。
スクリプトでクラスタ名を指定するかどうかを尋ねられたら「y」と入力し、さらにクラスタ名と検出ポートの入力を求められたらそれらも指定します。これによって、指定されたクラスタのすべての管理対象サーバーが検出され、JOCが構成されます。検出ポートは、そのクラスタのJOC構成全体で共通になります。例:

Do you want to specify a cluster name (y/n) <y>
Enter Cluster Name : WSM-PM_Cluster
Enter Discover Port : 9991

次に、HA環境でconfigure-joc.pyを使用したときのやり取りを示します。

execfile('MW_HOME/oracle_common/bin/configure-joc.py')
.
Enter Hostnames (eg host1,host2) : SOAHOST1,SOAHOST2
.
Do you want to specify a cluster name (y/n) <y>y
.
Enter Cluster Name : WSM-PM_Cluster
.
Enter Discover Port : 9991
.
Enter Distribute Mode (true|false) <true> : true
.
Do you want to exclude any server(s) from JOC configuration (y/n) <n> n

4. wlstコマンドまたはconfigure-joc.pyスクリプトを使用してJavaオブジェクト・キャッシュを構成したら、影響を受ける管理対象サーバーをすべて再起動して、その構成を有効にする必要があります。

このスクリプトは、次のオプションのJOC構成の実行にも使用できます。

- 指定された管理対象サーバーすべてのJOCを構成します。
スクリプトでクラスタ名を指定するかどうかを尋ねられたら「n」と入力し、さらに管理対象サーバーと検出ポートの入力を求められたらそれらも指定します。例:

Do you want to specify a cluster name (y/n) <y>n
Enter Managed Server and Discover Port (eg WLS_WSM1:9998, WLS_WSM1:9998) : WLS_WSM1:9991,WLS_WSM2:9991

- 一部の管理対象サーバーでJOC構成を除外します。
このスクリプトにより、JOC構成「DistributeMode」を「false」に設定する管理対象サーバーのリストを指定できます。JOC構成から除外するサーバーがあるかどうかを尋ねるプロンプトが表示されたら'y'を入力し、プロンプトが表示されたら除外する管理対象サーバー名を入力します。例:

Do you want to exclude any server(s) from JOC configuration (y/n) <n>y
Exclude Managed Server List (eg Server1,Server2) : WLS_WSM1,WLS_WSM3

- すべての管理対象サーバーに対して分散モードを無効にします。
このスクリプトにより、指定されたクラスタのすべての管理対象サーバーへの配布が無効になります。スクリプトにより分散モードに対するプロンプトが表示されたら、「false」を指定します。デフォルトでは、分散モードは「true」に設定されています。

CacheWatcherユーティリティを使用し、JOCの構成を確認します。『Oracle Fusion Middleware高可用性ガイド』を参照してください。

『Oracle Fusion Middleware高可用性ガイド』で説明しているように、Oracle WebLogic管理コンソールで「HAパワー・ツール」タブを使用してJavaオブジェクト・キャッシュ(JOC)を構成できます。

8.7 WebLogicドメインのOracle HTTP Serverの構成

この項では、WebLogicドメインのOracle HTTP Serverの構成タスクと、構成の検証タスクについて説明します。

この項には次のトピックが含まれます:

- 第8.7.1項「管理サーバーとWLS_WSMn管理対象サーバーについてのOracle HTTP Serverの構成」

- 第8.7.2項「WebLogicプラグイン有効化フラグの有効化」

- 第8.7.3項「WebLogic ServerへのOracle HTTP Serverの登録」

- 第8.7.4項「管理コンソールのフロントエンドURLの設定とリダイレクション・プリファレンスの設定」

- 第8.7.5項「Oracle HTTP Serverを介したアクセスの検証」

- 第8.8項「管理サーバーの手動フェイルオーバーの検証」

8.7.1 管理サーバーとWLS_WSMn管理対象サーバーについてのOracle HTTP Serverの構成

WLS_WSMn管理対象サーバーが属するWSM-PM_Clusterと管理サーバーにOracle HTTP Serverからルーティングできるようにするには、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定する必要があります。

WebLogicClusterパラメータを設定する手順は次のとおりです。

1. WEBHOST1とWEBHOST2上で、次のディレクトリにあるadmin_vh.confおよびsoainternal_vh.confファイルにディレクティブを追加します。

ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf

第7.6項「仮想ホストの定義」の指示に従って、admin_vh.confおよびsoainternal_vh.confファイルを作成しておく必要があります。

次のディレクティブをadmin_vh.confファイルの<VirtualHost>タグ内に追加します。

# Admin Server and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /em>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

admin_vh.confファイルは、例8-1のように表示されます。

2. 次のディレクティブをsoainternal_vh.confファイルの<VirtualHost>タグ内に追加します。

# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1:7010,SOAHOST2:7010
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

soainternal_vh.confファイルは、例8-2のように表示されます。

3. WEBHOST1およびWEBHOST2の両方で、Oracle HTTP Serverを再起動します。

WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2

例8-1 admin_vh.confファイル

# The admin URLs should only be accessible via the admin virtual host

<VirtualHost *:7777>
ServerName admin.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# Admin Server and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /em>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
</VirtualHost>

例8-2 soainternal_vh.confファイル

<VirtualHost *:7777>
ServerName soainternal.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1:7010,SOAHOST2:7010
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
</VirtualHost>

WebLogicClusterパラメータで指定したサーバーは、起動時のプラグインに対してのみ重要な役割を持ちます。このノードのリストには、実行しているクラスタ・メンバーを1つ以上記述しておく必要があります。記述しておかないと、このプラグインで他のクラスタ・メンバーを検出できません。Oracle HTTP Serverの起動時には、リストに記述したクラスタ・メンバーを実行している必要があります。Oracle WebLogic Serverとこのプラグインの連携により、クラスタに発生した新規のクラスタ・メンバー、失敗したクラスタ・メンバーおよびリカバリしたクラスタ・メンバーを反映してサーバーのリストが自動的に更新されます。

次に例を示します。

- 例1: 2つのノードで構成したクラスタに3番目のメンバーを追加する場合、そのメンバーを追加するために構成を更新する必要はありません。3番目のメンバーは、実行時に自動的に検出されます。

- 例2: クラスタは3つのノードで構成されていても、構成に記述されているノードはそのうちの2つのみであるとします。Oracle HTTP Serverを起動するときにこの2つのノードが両方とも停止していると、プラグインはクラスタを検出できません。Oracle HTTP Serverを起動するときは、リストに記述したノードを1つ以上実行している必要があります。
クラスタのメンバーをすべてリストに記述した場合は、Oracle HTTP Serverの起動時にそのうちの1つ以上を実行しておくことで、クラスタに確実に到達できます。

WebLogic Serverプラグインの構成の詳細は、『Oracle WebLogic ServerにおけるWebサーバー・プラグインの使用』ガイドを参照してください。

8.7.2 WebLogicプラグイン有効化フラグの有効化

セキュリティのため、またロード・バランサがSSLリクエストを終了するため(Oracle HTTP ServerはリクエストをWebLogic Serverに非SSLとしてルーティングします)、ロード・バランサにSSLを構成した場合、そのドメインに対しWebLogicプラグイン有効化フラグをオンにする必要があります。

WebLogicプラグイン有効化フラグを有効にする手順は次のとおりです。

1. 管理コンソールにログインします。

2. 左側のナビゲーション・ツリーからドメイン名をクリックします。

3. 「Webアプリケーション」タブをクリックします。

4. 「ロックして編集」をクリックします。

5. 「WebLogicプラグインの有効化」チェック・ボックスを選択します。

6. 変更を保存してアクティブ化します。

8.7.3 WebLogic ServerへのOracle HTTP Serverの登録

Oracle WebLogicドメインが作成されたら、Oracle Web Tierをドメインに接続できます。これには、Oracle Enterprise Manager Fusion Middleware Controlを使用してOracle Web層を管理および監視できるというメリットがあります。

Oracle Web TierをWebLogicドメインに関連付けるには、次のコマンドを使用します。

WEBHOST1> cd ORACLE_BASE/admin/instance_name/bin

WEBHOST1> ./opmnctl registerinstance -adminHost ADMINVHN -adminPort 7001 -adminUsername weblogic

このコマンドは、OHS2に対してWEBHOST2からも実行する必要があります。

Oracle HTTP Serverの登録後、Oracle Enterprise Managerコンソールで管理可能なターゲットとして表示されます。これを確認するには、Enterprise Managerコンソールにログインします。ナビゲーション・ツリーにある「WebTier」項目に、該当のOracle HTTP Serverが登録されていることが示されます。

8.7.4 管理コンソールのフロントエンドURLの設定とリダイレクション・プリファレンスの設定

ロード・バランサを使用してOracle WebLogic Server管理コンソールにアクセスする場合、管理サーバーのフロントエンドURLを変更し、ユーザーのブラウザが適切なロード・バランサ・アドレスにリダイレクトされるようにする必要があります。

Oracle WebLogic Server管理コンソール・アプリケーションでは、コンソールを使用して、ポート、チャネル、セキュリティに対する変更を追跡します。コンソールを使用して行われた変更をアクティブ化するとき、コンソールは現在のリスニング・アドレス、ポートおよびプロトコルを検証します。このリスニング・アドレス、ポートおよびプロトコルがまだ有効の場合、コンソールはHTTPリクエストをリダイレクトし、ホストとポートの情報を管理サーバーのリスニング・アドレスとポートに置き換えます。

管理サーバーのフロントエンドURLを変更する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「サーバー」をクリックして、「サーバーの概要」ページを開きます。

5. 表の「名前」列で「管理サーバー」を選択します。「AdminServer(admin)」の「設定」ページが表示されます。

6. 「プロトコル」タブをクリックします。

7. 「HTTP」タブをクリックします。

8. 「フロントエンド・ホスト」を「admin.mycompany.com」に設定し、「フロントエンドHTTPポート」を「80」に設定します(管理URLにHTTPSを使用する場合は、適宜変更します)。

9. 変更を保存してアクティブ化します。

10. 変更がアクティブ化されたときにコンソールで構成ページがリロードされないように、Oracle WebLogic Server管理コンソールで構成変更の追跡を無効にします。

1. Oracle WebLogic Server管理コンソールにログインします。

2. バナー内の「プリファレンス」リンクをクリックします。

3. 「共有プリファレンス」タブをクリックします。

4. 「構成変更の追跡」チェック・ボックスの選択を解除します。

注意:

フロントエンド・ホストやポートの設定を変更した後、構成の変更をアクティブ化できない場合は、第16.14.14項「管理コンソールで変更をアクティブ化した後にユーザーがログイン画面にリダイレクトされる」を参照してください。

8.7.5 Oracle HTTP Serverを介したアクセスの検証

Oracle HTTP Serverを介したアクセスを検証する手順は次のとおりです。

管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.14項「エンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。

次のURLを使用し、両方のOracle HTTP Serverを介してWSM-PM_Clusterを検証します。

- http://WEBHOST1:7777/wsm-pm

- http://WEBHOST2:7777/wsm-pm

- http://WEBHOST1:7777/console

- http://WEBHOST2:7777/console

- http://WEBHOST1:7777/em

- http://WEBHOST2:7777/em

- https://soa.mycompany.com/wsm-pm

- http://admin.mycompany.com/console

- http://admin.mycompany.com/em

フロントエンドURLをロード・バランサのアドレスに設定すると、WEBHOSTnアドレスを介したコンソールへのアクセスはコンソールによってフロントエンドURLにリダイレクトされるため、Oracle HTTP Serverとロード・バランサの両方の構成が正しいことを検証できます。

ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。

第8.7.3項「WebLogic ServerへのOracle HTTP Serverの登録」の説明に従ってOracle HTTP Serverを登録すると、そのOracle HTTP Serverは管理可能なターゲットとしてOracle Enterprise Managerコンソールに表示されます。これを確認するには、Enterprise Managerコンソールにログインします。ナビゲーション・ツリーにある「WebTier」項目に、該当のOracle HTTP Serverが登録されていることが示されます。

8.8 管理サーバーの手動フェイルオーバーの検証

ドメインの構成後、第16.7項「管理サーバーの手動フェイルオーバーの確認」の手順に従って、フェイルオーバーをテストします。

8.9 WebLogicドメイン構成のバックアップ

バックアップを実行してドメイン構成を保存します。最初にサーバーが停止していることを確認します。構成ファイルは次のディレクトリにあります。

ORACLE_BASE/admin/domain_name

ドメイン構成をバックアップするには、SOAHOST1で次のコマンドを実行します。

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

次のコマンドを使用して、Web層のインスタンス・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE

9 SOAコンポーネントを使用するためのドメインの拡張

この章では、構成ウィザードを使用して、SOAコンポーネントを扱うことができるようにドメインを拡張する方法を説明します。ドメインは第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成しました。

注意:

セットアップのプロセスを開始する前に、Oracle Fusion Middlewareリリース・ノートを読み、インストールとデプロイメントに関する追加情報を確認してください。

この章の項目は次のとおりです。

- 第9.1項「SOAコンポーネントを使用するためのドメインの拡張の概要」

- 第9.2項「Oracle SOAコンポーネントを使用するためのドメインの拡張の前提条件」

- 第9.3項「構成ウィザードを使用したSOAコンポーネントを使用するためのドメインの拡張」

- 第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」

- 第9.5項「構成後タスクおよび検証タスク」

- 第9.6項「拡張したドメインでのOracle HTTP Serverの構成」

- 第9.7項「トランザクション・リカバリ用デフォルト永続ストアの構成」

- 第9.8項「Oracleアダプタの構成」

- 第9.9項「高可用性を実現するためのB2B構成の更新」

- 第9.10項「SOA構成のバックアップ」

9.1 SOAコンポーネントを使用するためのドメインの拡張の概要

Oracle SOAコンポーネントを追加するためのWebLogicドメインを拡張します。表9-1に、Oracle SOAの構成手順と、Oracle SOAコンポーネントを使用するためのドメインの拡張に必要なタスクを示します。

表9-1 SOAコンポーネントを使用するためのドメインの拡張の手順

手順

説明

詳細

SOAコンポーネントを使用するためのドメインの拡張の準備

各ホスト名で仮想IPマッピングを有効化し、SOA WebLogicクラスタのシステム・クロックを同期します

第9.2項「Oracle SOAコンポーネントを使用するためのドメインの拡張の前提条件」

SOAコンポーネントを使用するためのドメインの拡張

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogicドメインを拡張します。

第9.3項「構成ウィザードを使用したSOAコンポーネントを使用するためのドメインの拡張」

コンポジットをデプロイするためのOracle Coherenceの構成

コンポジットのデプロイにユニキャスト通信を使用するためOracle Coherenceを構成します。

第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」

構成後タスクおよび検証タスク

構成後タスクおよび検証タスクの手順に従います。

第9.5項「構成後タスクおよび検証タスク」

拡張したドメインでのOracle HTTP Serverの構成

管理対象サーバーとともにOracle HTTP Serverを構成し、アクセスの検証、フロントエンドHTTPのホストおよびポートの設定およびSOA_ClusterのWLSクラスタ・アドレスを設定します。

第9.6項「拡張したドメインでのOracle HTTP Serverの構成」

デフォルト永続ストアの構成

トランザクション・リカバリのためのデフォルトの永続ストアを構成します。

第9.7項「トランザクション・リカバリ用デフォルト永続ストアの構成」

Oracleアダプタの構成

OracleファイルおよびFTPアダプタの高可用性およびOracle JMSアダプタの高可用性を有効化し、Oracleデータベース・アダプタをスケーリングします。

第9.8項「Oracleアダプタの構成」

高可用性を実現するためのB2B構成の更新

ファイル、FTPまたは電子メール・トランスポートを高可用性環境で設定します。

第9.9項「高可用性を実現するためのB2B構成の更新」

SOA構成のバックアップ

新しく拡張したドメイン構成をバックアップします。

第9.10項「SOA構成のバックアップ」

9.2 Oracle SOAコンポーネントを使用するためのドメインの拡張の前提条件

構成ウィザードを実行しドメインを拡張する前に、2つのSOAマシン上で各ホスト名の仮想IPマッピングを有効化し、SOA WebLogicクラスタのシステム・クロックを同期します。

この項には次のトピックが含まれます:

- 第9.2.1項「SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化」

- 第9.2.2項「システム・クロックの同期」

9.2.1 SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化

SOAドメインでは、SOA管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのSOAマシンでそれぞれのホスト名の仮想IPマッピングを有効にして(SOAHOST1上のVIP2およびSOAHOST2上のVIP3)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバー、ホスト解決のいずれかで)正しく解決する必要があります(まだこの作業を行っていない場合)。

仮想IPを有効にするには(まだこの作業を行っていない場合)、第3.5項「管理サーバーの仮想IPアドレスの有効化」に記載されている手順を実行します。これらの仮想IPおよびVHNは、SOAサーバーでサーバー移行を有効にするときに必要となります。この後、高可用性を実現するためSOAシステムのサーバー移行を構成できます。SOAサーバーのためのサーバー移行の構成の詳細は、第14章「エンタープライズ・デプロイメント用のサーバー移行の構成」を参照してください。

9.2.2 システム・クロックの同期

Oracle SOAは、クォーツを使用してそのジョブとスケジュールをデータベースで管理します。ジョブ、アダプタおよびOracle B2Bを正常に機能させるため、SOA WebLogicクラスタのシステム・クロックを同期させます。

9.3 構成ウィザードを使用したSOAコンポーネントを使用するためのドメインの拡張

構成ウィザードを使用して、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを、SOAコンポーネントを使用できるように拡張します。

注意:

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインをバックアップしていない場合は、SOAコンポーネントを使用するためのドメイン拡張を実行する前に、現在のドメインをバックアップします。ドメインの拡張時になんらかのエラーが発生した場合は、このバックアップを使用してリカバリできます。詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。

構成ウィザードを使用してドメインを拡張する手順は次のとおりです。

1. ディレクトリを構成ウィザードの場所に変更します。これはSOAHOST1上のSOAホーム・ディレクトリ内にあります。すべてのデータベース・インスタンスを稼働させておくことをお薦めします。

ORACLE_COMMON_HOME/common/bin

2. 構成ウィザードを開始します。

./config.sh

3. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

4. 「WebLogicドメイン・ディレクトリ」画面で、次のWebLogicドメイン・ディレクトリを選択します。

ORACLE_BASE/admin/domain_name/aserver/domain_name

「次へ」をクリックします。

5. 「拡張ソースの選択」画面で、次の手順を実行します。

1. 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

2. 次の製品を選択します: Oracle SOA Suite 11.1.1.0
次の製品はすでに選択されてグレー表示されています。これらは、第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」の手順でドメインを作成したときに選択されたものです。

WebLogic Serverの基本ドメイン

Oracle Enterprise Manager

Oracle WSM Policy Manager

Oracle JRF

「次へ」をクリックします。

6. このドメインではOracle JRFが定義済であることを示す「競合の検出」メッセージが表示された場合は、「既存のコンポーネントを保持する」オプションを選択して、「OK」をクリックします。

7. 「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。

- 「SOAインフラストラクチャ」→「ユーザー・メッセージング・サービス」→SOA MDSスキーマを選択します。

- 「コンポーネント・スキーマのOracle RAC構成」については、「GridLinkへ変換」を選択します。

「次へ」をクリックします。

8. 「GridLink RACコンポーネント・スキーマの構成」画面が表示されます(図9-1)。

図9-1 「GridLink RACコンポーネント・スキーマの構成」画面

この画面で、次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: OracleのGridLinkConnections用ドライバ (Thin) バージョン: 10以上を選択します。

- サービス名: データベースのサービス名を、小文字で入力します。例:
soaedg.mycompany.com

- ユーザー名: 対応するコンポーネントのデータベース・スキーマ・オーナーの名前を入力します。

- パスワード: データベース・スキーマ・オーナーのパスワードを入力します。

- 「FANの有効化」を選択します。

- 「SSLの有効化」が選択解除されていることを確認します(暗号化するONS通知にsslが選択されている場合は、適切なウォレットとウォレット・パスワードを指定します)。

- サービス・リスナー: 使用するRACデータベースのためのSCANアドレスとポートを入力します。このアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せれば識別できます。

SQL>show parameter remote_listener;

NAME              TYPE                VALUE
-------------------------------------------------------------
remote_listener   string    db-scan.mycompany.com:1521

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。次に例を示します。

custdbhost1-vip.mycompany.com (port 1521)

および

custdbhost2-vip.mycompany.com (1521)

Oracle Database 10gでは、Oracle RACデータベースへの接続にマルチ・データ・ソースを使用します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- ONSホスト: Oracle RACデータベースのSCANアドレスおよびデータベースから報告されたONSリモート・ポートを入力します。

[orcl@db-scan1 ~]$ srvctl config nodeapps -s

ONS exists: Local port 6100, remote port 6200, EM port 2016

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベースのONSサービスのホスト名とポートを使用します。次に例を示します。

custdbhost1.mycompany.com (port 6200)

および

custdbhost2.mycompany.com (6200)

9. 「JDBCデータ・ソースのテスト」画面で、すべての接続が正常であることを確認します。
接続のテストは自動的に行われます。「ステータス」列に結果が表示されます。正常でない接続がある場合は、「前へ」をクリックして前の画面に戻り、入力を訂正します。

すべての接続に成功したら「次へ」をクリックします。

10. 「オプションの構成を選択」画面で、次を選択します。

- JMS分散宛先

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

- JMSファイル・ストア

「次へ」をクリックします。

11. 「JMS分散宛先タイプの選択」画面で、すべてのJMSシステム・リソースがUDDとして構成されていることを確認します。これはデフォルトです。

12. 「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。

1. 自動的に作成されたサーバーを選択し、「名前の変更」をクリックして、名前を「WLS_SOA1」に変更します。

2. 「追加」をクリックし他の新規サーバーを追加して、サーバー名として「WLS_SOA2」と入力します。

3. WLS_SOA1およびWLS_SOA2サーバーに、表9-2内の属性を指定します。この画面に表示されている他のサーバーは変更せず、そのままにしておきます。

表9-2 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_SOA1

SOAHOST1VHN1

8001

なし

いいえ

WLS_SOA2

SOAHOST2VHN1

8001

なし

いいえ

WLS_WSM1

SOAHOST1

7010

なし

いいえ

WLS_WSM2

SOAHOST2

7010

なし

いいえ

「次へ」をクリックします。

13. 「クラスタの構成」画面で、次のクラスタを追加します。

表9-3 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

SOA_Cluster

ユニキャスト

なし

なし

SOAHOST1VHN1:8001、SOAHOST2VHN1:8001

WSM-PM_Cluster

ユニキャスト

なし

なし

空白

「次へ」をクリックします。

注意:

直接バインディングを介してリクエスト/レスポンスが非同期でやり取りされるようにするため、SOAコンポジットでは、JNDIプロバイダURLを提供して、呼び出されたサービスが、コールバックするBeanを検索できるようにする必要があります。

soa-infraの構成プロパティは指定されていないがWebLogic Serverクラスタ・アドレスが指定されている場合は、JNDIプロバイダURLのクラスタ・アドレスが使用されます。このクラスタ・アドレスには、クラスタ化されたサーバーのIPアドレスにマップする単一のDNS名を指定することも、サーバーip:portのカンマ区切りリストを指定することもできます。また、ユーザーが明示的に設定していれば、soa-infraの構成プロパティJndiProviderURL/SecureJndiProviderURLを同じ目的に使用することもできます。

14. 「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。

- SOA_Cluster:

- WLS_SOA1

- WLS_SOA2

- WSM-PM_Cluster:

- WLS_WSM1

- WLS_WSM2

「次へ」をクリックします。

15. 「マシンの構成」画面で、デフォルトで表示されるLocalMachineを削除し、「Unixマシン」タブをクリックします。
次のエントリが表示されます(表9-4)。

- 表9-4 マシン

名前

ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINHOST

localhost

他のフィールドはすべてデフォルト値のままにします。

「次へ」をクリックします。

16. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- ADMINHOST:

- AdminServer

- SOAHOST1:

- WLS_SOA1

- WLS_WSM1

- SOAHOST2:

- WLS_SOA2

- WLS_WSM2

「次へ」をクリックします。

17. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で「SOA_Cluster」を選択して、次のものをターゲット設定します。

- usermessagingserverおよびusermessagingdriver-email。(usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです。)

- oracle.sdp.*、oracle.soa.*およびoracle.rules.*ライブラリ

管理サーバー・クラスタを選択して、次のものをターゲット設定します。

oracle.rules.*ライブラリ

「WSM-PM_Cluster」を選択して、次のものをターゲット設定します。

wsm-pmアプリケーション

アプリケーションとリソースのターゲット設定の詳細は、付録B「アプリケーションとリソースのサーバーへのターゲット設定」を参照してください。

「次へ」をクリックします。

18. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- mds-owsmをWSM-PM_ClusterおよびAdminServerの両方にターゲット設定します。

「次へ」をクリックします。

19. 「JMSファイル・ストアの構成」画面で、第4.3項「異なるディレクトリの推奨場所」でお薦めしているように、JMSストアに指定した共有ディレクトリの場所を入力します。例:

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

「次へ」をクリックします。

20. 「構成のサマリ」画面で、「拡張」をクリックします。

注意:

ドメイン構成ポートがホスト・ポートと競合していることを警告するダイアログが表示されますが、「OK」をクリックして閉じてください。この警告は、すでにインストールされているWSM-PMが原因で表示されます。

21. 「ドメインの拡張」画面で、「完了」をクリックします。

22. 管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順で再起動します。

9.4 コンポジットをデプロイするためのOracle Coherenceの構成

コンポジットのデプロイではマルチキャスト通信がデフォルトで使用されますが、SOAエンタープライズ・デプロイメントではユニキャスト通信の使用をお薦めします。セキュリティ上の理由からマルチキャスト通信を無効にしている場合は、ユニキャストを使用します。

ユニキャスト通信を使用した場合、この方法ではノードから他のクラスタ・メンバーを検出できません。したがって、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加した新しいノードから既存ノードのいずれかを検出するために必要な数のノードを指定するだけでかまいません。この結果、クラスタに追加した新しいノードからクラスタにある他のすべてのノードを検出できます。また、同じシステムで複数のIPを使用できるSOAエンタープライズ・デプロイメントなどの構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。

注意:

デプロイメントに使用するOracle Coherenceフレームワークの構成が正しくないと、SOAシステムを起動できないことがあります。SOAシステムを実行するネットワーク環境に応じて、デプロイメント・フレームワークを適切にカスタマイズする必要があります。この項で説明する構成をお薦めします。

9.4.1 ユニキャスト通信を使用したデプロイメントの通信の有効化

tangosol.coherence.wka nシステム・プロパティを使用してノードを指定します(nは1から9の番号)。Well Knownアドレスとして最大9ノードまで指定できますが、クラスタには10以上のノードを作成できます。番号は1から開始します。この番号付けは、連続的で間隙を含まないようにする必要があります。また、Oracle Coherenceでクラスタを作成するために使用するホスト名をtangosol.coherence.localhostシステム・プロパティで指定します。このローカル・ホスト名には、SOAサーバーでリスナーのアドレスとして使用する仮想ホスト名を指定する必要があります(SOAHOST1VHN1とSOAHOST2VHN1)。このプロパティを設定するには、Oracle WebLogic Server管理コンソールの「サーバーの起動」タブにある「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加します(図9-1)。

ヒント:

SOAコンポジットのデプロイメント時に高可用性を確保するには、適切な数のノードを指定して、どの時点でもそのうちのいずれかが必ず稼働しているようにします。

注意:

SOAHOST1VHN1は、SOAHOST1でWLS_SOA1がリスニングする仮想IPにマップされる仮想ホスト名です。SOAHOST2VHN1は、SOAHOST2でWLS_SOA2がリスニングする仮想IPにマップされる仮想ホスト名です。

図9-2 Oracle WebLogic Server管理コンソールの「サーバーの起動」タブを使用したホスト名の設定

9.4.2 Oracle Coherenceで使用するホスト名の指定

管理コンソールを使用して、Oracle Coherenceで使用するホスト名を指定します。

Oracle Coherenceで使用するホスト名を追加する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列でサーバーの名前(WLS_SOA1またはWLS_SOA2、これらはハイパーリンクとして表示されます)をクリックします。選択したサーバーの「設定」ページが表示されます。

5. 「ロックして編集」をクリックします。

6. 「サーバーの起動」タブをクリックします(図9-2を参照)。

7. WLS_SOA1とWLS_SOA2について、「引数」フィールドに次の値を入力します。

注意:

異なる-Dパラメータの間には、空白の行を入れないでください。管理コンソールの引数テキスト・フィールドに、このテキストをコピーまたは貼り付けないでください。Java引数にHTMLタグが挿入される可能性があります。このテキストには、次の例に含まれているテキスト文字以外の文字を入れないでください。

注意:

デプロイメントで使用されるCoherenceクラスタでは、ポート8088をデフォルトで使用します。このポートは、起動パラメータ-Dtangosol.coherence.wkan.portおよび-Dtangosol.coherence.localportで別なポート(8089など)を指定することで変更できます。例:

WLS_SOA1(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST1VHN1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

WLS_SOA2(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST2VHN1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

Coherenceクラスタの詳細は、『Oracle Coherence開発者ガイド』を参照してください。

WLS_SOA1については次の値を入力します。

-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST1VHN1

WLS_SOA2については次の値を入力します。

-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST2VHN1

8. 「保存」→「変更のアクティブ化」をクリックします。

注意:

これらの変数が管理対象サーバーに正しく渡されることを確認する必要があります。(これらの変数はサーバーの出力ログに記録されます。)Oracle Coherenceフレームワークに問題があると、soa-infraアプリケーションを起動できないことがあります。

注意:

このマルチキャスト・アドレスとユニキャスト・アドレスは、WebLogic Serverクラスタでクラスタ通信に使用するものとは異なります。SOAでは、2つのエンティティ(WebLogic Serverクラスタおよびコンポジットのデプロイ先グループ)の通信プロトコルが異なる場合でも、単一のWebLogic Serverクラスタの各メンバーにコンポジットを確実にデプロイできます。

9.5 構成後タスクおよび検証タスク

構成ウィザードでドメインを拡張し、Oracle Coherenceを構成したら、次の手順に従って、構成後タスクと検証を行います。

この項には次のトピックが含まれます:

- 第9.5.1項「WLS_SOAn管理対象サーバーに対するホスト名検証の無効化」

- 第9.5.2項「SOAHOST1でのノード・マネージャの再起動」

- 第9.5.3項「管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播」

- 第9.5.4項「WLS_SOA1管理対象サーバーの起動と検証」

- 第9.5.5項「unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播」

- 第9.5.6項「WLS_SOA2管理対象サーバーの起動と検証」

- 第9.5.7項「GridLinkデータ・ソースの検証」

9.5.1 WLS_SOAn管理対象サーバーに対するホスト名検証の無効化

このガイドで説明するエンタープライズ・デプロイメントでは、Oracle SOA Suiteを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。WLS_SOA1およびWLS_SOA2管理対象サーバーのホスト名検証を無効化して、様々なWebLogic Serverインスタンスを管理するときにエラーが出ないようにします。詳細は、第8.4.8項「ホスト名検証の無効化」を参照してください。

エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第13.3項「SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。

9.5.2 SOAHOST1でのノード・マネージャの再起動

startNodeManager.shスクリプトを使用してノード・マネージャを再起動します。

SOAHOST1でノード・マネージャを再起動するには:

1. ノード・マネージャに関係付けられたプロセスを停止することで、ノード・マネージャを停止します。

- シェルのフォアグラウンドで実行されている場合は、[Ctrl]を押しながら[C]を押します。

- シェルのバックグラウンドで実行されている場合は、関連付けられたプロセスを見つけ、killコマンドを使用して停止します。例:

ps -ef | grep NodeManager
orcl      9139  9120  0 Mar03 pts/6    00:00:00 /bin/sh ./startNodeManager.sh

kill -9 9139

2. ノード・マネージャを起動します。

./startNodeManager.sh

9.5.3 管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

起動スクリプトとクラスパス構成を伝播する手順は次のとおりです。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのコピーを作成します。

2. 次の一連のコマンドを使用し、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name
-template=soadomaintemplateExtSOA.jar -template_name=soa_domain_templateExtSOA

3. 次のようにunpackコマンドをSOAHOST1上で実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
-overwrite_domain=true -template=soadomaintemplateExtSOA.jar
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

注意:

unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

注意:

このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。

9.5.4 WLS_SOA1管理対象サーバーの起動と検証

WLS_SOA1管理対象サーバーを起動する前に、WLS__WSM1管理対象サーバーが起動していて稼働中であることを確認します。それ以外の場合は、WLS_SOA1は起動しません。

管理コンソールを使用してWLS_SOA1管理対象サーバーを起動して、検証します。

SOAHOST1でWLS_SOA1管理対象サーバーを起動する手順は次のとおりです。

1. 次の手順に従い、Oracle WebLogic Server管理コンソールを使用してWLS_SOA1管理対象サーバーを起動します。

1. 次のURLの管理コンソールにアクセスします。

http://ADMINVHN:7001/console

ADMINVHNは、SOAHOST1で管理サーバーがリスニングする仮想IPにマップされる仮想ホスト名です。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。
「サーバーのサマリー」画面が表示されます。

4. 「Control」タブをクリックします。

5. 「WLS_SOA1」を選択して、「起動」をクリックします。

2. サーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.14項「エンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。

3. 次のURLにアクセスして、WLS_SOA1のステータスを確認します。

http://SOAHOST1VHN1:8001/soa-infra/

次のURLにアクセスして、B2Bのステータスを確認します。

http://SOAHOST1VHN1:8001/b2bconsole/

次のURLにアクセスして、ワークリスト・アプリケーションのステータスを確認します。

http://SOAHOST1VHN1:8001/integration/worklistapp/

次のURLにアクセスして、コンポーザ・アプリケーションのステータスを確認します。

http://SOAHOST1VHN1:8001/soa/composer/

アクセスが許可されているか検証する前に、WLS_WSM1管理対象サーバーが起動され実行されていることを確認します。

9.5.5 unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播

unpackユーティリティを使用して、構成したドメインをSOAHOST2に伝播します。

ドメイン構成を伝播する手順は次のとおりです。

1. 次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをSOAHOST2にコピーします。

cd ORACLE_COMMON_HOME/common/bin

scp soadomaintemplateExtSOA.jar oracle@SOAHOST2:ORACLE_COMMON_HOME/common/bin

2. unpackコマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh-domain=ORACLE_BASE/admin/domain_name/mserver/domain_name/
-template=soadomaintemplateExtSOA.jar -overwrite_domain=true
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

注意:

unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

注意:

このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。

9.5.5.1 SOAHOST2でのXEngineファイルの抽出

SOAHOST2でB2BのXEngineを有効にするには、次のようにXEngine tarファイルの内容を手動で抽出します。

XEngine tarファイルの内容を抽出する手順は次のとおりです。

1. 次のコマンドをSOAHOST2から実行します。

cd ORACLE_HOME/soa/thirdparty/edifecs
tar -xzvf XEngine.tar.gz

2. SOAHOST2でノード・マネージャを再起動するには、第9.5.2項「SOAHOST1でのノード・マネージャの再起動」の手順を使用します。

3. 抽出後、次のディレクトリ構造を確認します。

ORACLE_HOME/soa/soa/thirdparty/edifecs/

このディレクトリ内に次のディレクトリが表示されている必要があります。

- Common

- XEngine

XEngineディレクトリ内に、次のディレクトリとファイルが表示されている必要があります。

- bin

- config

- Readme.htm

- EULA.pdf

9.5.6 WLS_SOA2管理対象サーバーの起動と検証

管理コンソールを使用して、WLS_SOA2管理対象サーバーを起動します。soa-infra、b2bconsoleおよびworklistappのURLにアクセスして検証します。

WLS_SOA2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認するには:

1. 管理コンソールを使用してWLS_SOA2管理対象サーバーを起動します。

2. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.14項「エンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。

3. 次のURLでsoa-infraにアクセスします。

http://SOAHOST2VHN1:8001/soa-infra

4. 次のURLにアクセスして、B2Bのステータスを確認します。

http://SOAHOST2VHN1:8001/b2bconsole

5. 次のURLにアクセスして、ワークリスト・アプリケーションのステータスを確認します。

http://SOAHOST2VHN1:8001/integration/worklistapp/

アクセスが許可されているか検証する前に、(WLS_WSM1またはWLS_WSM2の)管理対象サーバーが少なくとも1つ起動され実行されていることを確認します。

注意:

WLS_SOA1サーバーが稼働していても、一部のアプリケーションが失敗した状態になることがあります。そのため、前述のURLを検証し、個別のアプリケーションに関するエラーがないか、サーバーの出力ファイルで確認することをお薦めします。

6. 次のURLにアクセスして、コンポーザ・アプリケーションのステータスを確認します。

http://SOAHOST2VHN1:8001/soa/composer/

9.5.7 GridLinkデータ・ソースの検証

サーバーが開始したら、GridLinkデーター・ソースが正しく構成され、ONS設定が正しいことを確認します。作成されたすべてのGridLinkデータ・ソースに対して、この手順を実行します。

GridLinkデータ・ソースの構成を検証する手順は次のとおりです。

1. Oracle WebLogic管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

3. 新しいデータ・ソースの内の1つをクリックします。

4. 「監視」タブをクリックし、「テスト」サブタブを選択します。

5. サーバーの1つを選択し、「データ・ソースのテスト」をクリックします。

6. 「統計」タブをクリックし、いずれかのサーバーを選択します。

7. 「ONS」タブをクリックし、「テスト」タブをクリックします。

8. サーバーを選択して、「ONSのテスト」をクリックします。
テストが両方とも成功すれば、正しく構成されています。ONSのテストが失敗した場合は、RACデータベース・ノードでONSサービスが実行されていることを確認します。

orcl@db-scan1 ~]$ srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node db-scan1
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node db-scan2
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node db-scan2

[orcl@db-scan1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

[orcl@db-scan1 ~]$ srvctl status nodeapps | grep ONS
ONS is enabled
ONS daemon is running on node: db-scan1
ONS daemon is running on node: db-scan2

データ・ソースを使用するすべてのWebLogicサーバーからONSテストを実行します。

9.6 拡張したドメインでのOracle HTTP Serverの構成

ドメイン構成をSOAHOST2に伝播した後、拡張したドメインでOracle HTTP Serverを構成します。

この項には次のトピックが含まれます:

- 第9.6.1項「WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成」

- 第9.6.2項「Oracle HTTP Serverを介したアクセスの検証」

- 第9.6.3項「フロントエンドHTTPホストおよびポートの設定」

9.6.1 WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成

WLS_SOAn管理対象サーバーが属するSOA_ClusterにOracle HTTP Serverからルーティングできるようにするには、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。

/workflowのエントリは省略可能です。これは、Oracle ADFタスク・フォームと関連付けられたワークフロー・タスク用です。/workflowのURL自体は、フォームに応じた別の値とすることができます。

Oracle HTTP ServerでSOA_Clusterへのルーティングを有効化する手順は次のとおりです。

1. WEBHOST1およびWEBHOST2上で、次のディレクトリにあるsoa.vh.confファイルにディレクティブを追加します。

ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf

第7.6項「仮想ホストの定義」の指示に従って、soa_vh.confファイルを作成している必要があります。

<VirtualHost>タグ内に、次のディレクティブを追加します。

<Location /soa-infra>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Worklist
<Location /integration>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# B2B
<Location /b2bconsole>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /b2b/services/ws/>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Workflow
<Location /workflow>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA composer application
<Location /soa/composer>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /frevvo>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
</VirtualHost>

soa_vh.confファイルは例9-1のように表示されます。

2. WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1
WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2

例9-1 soa_vh.confファイル

<VirtualHost *:7777>
ServerName https://soa.mycompany.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

<Location /soa-infra>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Worklist
<Location /integration>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# B2B
<Location /b2bconsole>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /b2b/services/ws/>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Workflow
<Location /workflow>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA composer application
<Location /soa/composer>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /frevvo>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
</VirtualHost>

注意:

システムで内部呼出しを使用する場合は、soainternal仮想ホストに適切なロケーションを追加してください。

WebLogicClusterパラメータで指定したサーバーは、起動時のプラグインに対してのみ重要な役割を持ちます。このノードのリストには、実行しているクラスタ・メンバーを1つ以上記述しておく必要があります。記述しておかないと、このプラグインで他のクラスタ・メンバーを検出できません。Oracle HTTP Serverの起動時には、リストに記述したクラスタ・メンバーを実行している必要があります。Oracle WebLogic Serverとこのプラグインの連携により、クラスタに発生した新規のクラスタ・メンバー、失敗したクラスタ・メンバーおよびリカバリしたクラスタ・メンバーを反映してサーバーのリストが自動的に更新されます。

次に例を示します。

- 例1: 2つのノードで構成したクラスタに3番目のメンバーを追加する場合、そのメンバーを追加するために構成を更新する必要はありません。3番目のメンバーは、実行時に自動的に検出されます。

- 例2: クラスタは3つのノードで構成されていても、構成に記述されているノードはそのうちの2つのみであるとします。Oracle HTTP Serverを起動するときにこの2つのノードが両方とも停止していると、プラグインはクラスタを検出できません。Oracle HTTP Serverを起動するときは、リストに記述したノードを1つ以上実行している必要があります。
クラスタのメンバーをすべてリストに記述した場合は、Oracle HTTP Serverの起動時にそのうちの1つ以上を実行しておくことで、クラスタに確実に到達できます。

WebLogic Serverプラグインの構成の詳細は、『Oracle WebLogic ServerにおけるWebサーバー・プラグインの使用』ガイドを参照してください。

9.6.2 Oracle HTTP Serverを介したアクセスの検証

管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.14項「エンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。

次のURLにアクセスできることを確認します。'webhostN'には、各Oracle HTTP Serverホストの名前を指定します。これらのURLを、WEBHOST1とWEBHOST2の両方で確認します。

- http://webhostN:7777/soa-infra

- http://webhostN:7777/integration/worklistapp

- http://webhostN:7777/b2bconsole

- http://webhostN:7777/sdpmessaging/userprefs-ui

- http://webhostN:7777/soa/composer

両方のOracle HTTP ServerインスタンスからSOA_Clusterを検証します。

ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。

9.6.3 フロントエンドHTTPホストおよびポートの設定

この項では、フロントエンドHTTPのホストとポートを管理コンソールを使用して設定する手順を示します。コールバックURLがどのように決定されるかについても説明します。

9.6.3.1 フロントエンドHTTPホストおよびポートの設定

Oracle WebLogic Serverクラスタに対してフロントエンドHTTPのホストとポートを設定する手順は次のとおりです。

1. WebLogic Server管理コンソールの「チェンジ・センター」セクションの「ロックして編集」をクリックします。

2. 左ペインの「ドメイン構造」ウィンドウで「環境」を選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。

3. SOA_Clusterクラスタを選択します。

4. 「HTTP」を選択します。

5. 次の値を設定します。

- フロントエンド・ホスト: soa.mycompany.com

- フロントエンドHTTPSポート: 443

- フロントエンドHTTPポート: 80

フロントエンドHTTPのホストとポートを設定していない場合は、Oracle B2Bからドキュメント定義のXSDを取得しようとすると次のメッセージが表示されます。

An error occured while loading the document definitions.
java.lang.IllegalArgumentException: Cluster address must be set when clustering is enabled.

6. 「保存」をクリックします。

7. 変更をアクティブにするには、管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。

8. サーバーを再起動して、クラスタのフロントエンド・ホストの指定を有効化します。

注意:

ロード・バランサでHTTPSが有効になっており、SSLがロード・バランサで終了する場合(SOAサーバーはHTTPSではなくHTTPリクエストのみを受信します)、ここに示しているように、Webサービスのエンドポイント・プロトコルはhttpに設定されます。ロード・バランサはHTTPをHTTPSにリダイレクトするため、Oracle Enterprise Manger Fusion Middleware ControlでWebサービスの機能をテストすると、次の例外が発生します。

(javax.xml.soap.SOAPException: oracle.j2ee.ws.saaj.ContentTypeException)

この例外を解決するには、URLエンドポイントを更新します。

Enterprise Managerの「テスト」ページで、エンドポイントURLの編集を確認します。

「エンドポイントURL」ページで、次の操作を実行します。

- httpをhttpsに変更します。

- 初期設定のポート番号(80など)をSSLポート(443など)に変更します。

9.6.3.2 コールバックURLについて

この項では、SOAシステムでコールバックURLがどのように決定されるかについて説明します。

- SOAへのリクエストが外部または内部のサービスから発行された場合、SOAはクライアントで指定されたコールバックURLを使用します。

- 外部または内部の非同期サービスへのリクエストがSOAから送られると、コールバックURLは次のように、優先度の高い順に決定されます。

- 特定の参照用のバインド・プロパティとして指定されたcallbackServerURLを使用します(このプロパティは、コンポジットのモデリング時または実行時にMBeansを使用して設定できます)。これにより、サービス呼び出しごとに異なるコールバックURLを割り当てることができます。つまり、外部サービスからのコールバックURLには、内部サービスへのコールバックURLとは異なる値を設定できます。エンタープライズ・デプロイメント・アーキテクチャでの一般的なコールバックURLは、外部サービスについてはsoa.mycompany.com (443/https)、内部サービスについてはsoainternal.mycompany.com (7777/http)です。このプロパティは、システムMBeanブラウザに対応するバインドmbeanを通じ、実行時にシステムMBeanブラウザを使用して設定します。特定のURLを追加するには、そのProperties属性にcallbackServerURLプロパティを追加してから保存操作を実行します。

- soa-infra-config.xmlで指定したコールバックURLを使用します。この場合、指定できるアドレスは1つのみです。外部サービスと内部サービスの両方を組み合せて呼び出し可能な場合は、エンタープライズ・デプロイメント・アーキテクチャでこのアドレスをsoa.mycompany.com (443/https)に設定する必要があります。内部サービスのみを呼び出す場合は、このアドレスをsoainternal.mycompany.com (7777/http)に設定します

- SOA_ClusterのWLSで指定するフロントエンド・ホストとして、このコールバックURLを使用します。この場合も指定できるアドレスは1つのみなので、soa-infra-config.xmlの場合と同じ処理をお薦めします。

- WLS MBean APIで指定されたローカル・ホスト名を使用します。これは、エンタープライズ・デプロイメントのような高可用性環境ではお薦めしません。

9.7 トランザクション・リカバリのためのデフォルトの永続ストアの構成

各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。WebLogic Serverでは、システム・クラッシュやネットワーク障害からのリカバリ時にこのトランザクション・ログを使用します。クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセスできる場所にトランザクション・ログを格納します。

注意:

お薦めする場所は、デュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)です。

デフォルトの永続ストアの場所を設定する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」セクションで、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」ノードをクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列にあるサーバーの名前(ハイパーリンクとして表示されています)をクリックします。選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

5. 「構成」タブ、「サービス」タブを順にクリックします。

6. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。パスのディレクトリ構造は次のとおりです。

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

7. WLS_SOA2サーバーについてステップ3、4、5および6を繰り返します。

8. 「保存」をクリックして、「変更のアクティブ化」をクリックします。

9. 両方のSOAサーバーを再起動します。

10. WLS_SOA1とWLS_SOA2を再起動した後、次のディレクトリに次のファイルが作成されていることを確認します。

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

- _WLS_WLS_SOA1000000.DAT

- _WLS_WLS_SOA2000000.DAT

注意:

トランザクション・リカバリ・サービスの移行を有効にするには、クラスタにある他のサーバーが使用できる永続記憶域ソリューションの場所を指定します。WLS_SOA1とWLS_SOA2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。

9.8 Oracleアダプタの構成

Oracleファイル、FTPおよびデータベース・アダプタを、拡張したSOAドメイン用に構成します。

この項には次のトピックが含まれます:

- 第9.8.1項「OracleファイルとFTPアダプタの高可用性化」

- 第9.8.2項「Oracleデータベース・アダプタのスケーリング」

9.8.1 OracleファイルとFTPアダプタの高可用性化

OracleファイルおよびFTPアダプタを使用すると、ローカル・ファイル・システムやリモート・ファイル・システムのファイルをFTP(ファイル転送プロトコル)を使用してBPELプロセスまたはOracle Mediatorで読取りまたは書込みできるようになります。これらのアダプタは、Oracle BPEL Process ManagerおよびOracle Mediatorサービス・エンジンでのアクティブ/アクティブ・トポロジに対する高可用性機能を、インバウンドおよびアウトバウンドの両方の操作でサポートしています。OracleファイルおよびOracle FTPアダプタがアウトバウンド操作に対する高可用性を備えるようにするには、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のアウトバウンド操作での高可用性に関する項に記載されているデータベースのmutexロック操作を使用します。データベースのmutexロック操作を使用すると、複数の参照から同じディレクトリへの書込みが発生しても、これらのアダプタでは相互の上書きを防止できます。

注意:

この項で説明する操作は、これらのアダプタがアプリケーションで必要になる場合にのみ実行する必要があります。

注意:

ファイル・アダプタは、インバウンド・ディレクトリからファイルを取得して処理し、出力ディレクトリにファイルを出力します。ファイル・アダプタでの処理はトランザクション方式ではないので、ファイルは2回処理できます。この結果として、RACバックエンドまたはSOA管理対象サーバーでフェイルオーバーが発生したときに、重複するファイルが得られる可能性があります。

9.8.1.1 データベースのmutexロック操作の使用

データベース表をコーディネータとして使用して、アウトバウンドのOracleファイルやFTPアダプタのサービスに高可用性を実現します。

注意:

FTPアダプタの手順および構成オプションは、フィルタ・アダプタのオプションと完全に同じです。FTP HAの構成に使用する接続ファクトリは、FTPアダプタ・デプロイメントの送信接続プールの下に表示されるeis/Ftp/HAFtpAdapterです。

注意:

データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトを増やします。

アウトバウンドのOracleファイルやFTPアダプタの高可用性を実現するには、Oracle WebLogic Server管理コンソールで、eis/HAFileAdapterに対応するconnection-instanceのOracleファイル・アダプタのデプロイメント・ディスクリプタを変更します。

1. Oracle WebLogic Serverコンソールにログインします。コンソールにアクセスするには、次のURLにナビゲートします。

http://servername:portnumber/console

2. 「ドメイン構造」の左ペインで「デプロイメント」をクリックします。

3. 右ペインの「デプロイメントの概要」で「FileAdapter」をクリックします。

4. 「構成」タブをクリックします。

5. 「アウトバウンド接続プール」タブをクリックして「javax.resource.cci.ConnectionFactory」を開き、構成済の接続ファクトリを表示します。

6. 「eis/HAFileAdapter」をクリックします。高可用性に対応する接続ファクトリの「アウトバウンド接続のプロパティ」が表示されます。

7. 図9-3に示すように、接続ファクトリのプロパティが表示されます。

図9-3 Oracle WebLogic Serverコンソール - 「javax.resource.cci.Connectionfactoryの設定」ページ

「ロックして編集」をクリックします。これにより、プロパティ値の列が編集可能になります(「プロパティ値」列で任意の行をクリックしてその値を変更できます)。

OracleファイルとFTPアダプタの接続ファクトリの新しいパラメータは次のとおりです。

表9-5 OracleファイルとFTPのアダプタ

パラメータ

説明

controlDir

制御ファイルを格納するディレクトリ構造に設定します。1つのクラスタの中で複数のWebLogic Serverインスタンスを実行する場合は、この値を共有場所に設定する必要があります。この共有記憶域のディレクトリは次のような構造にします。

ASERVER_HOME/cluster_name/fadapter

inboundDataSource

値をjdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。以前に作成されたスキーマは次のディレクトリにあります。

ORACLE_HOME/rcu/integration/soainfra/sql/createschema_soainfra_oracle.sql

事前作成スキーマを別の場所で作成する場合は、このスクリプトを使用します。別のスキーマを選択する場合は、それに応じてinboundDataSourceプロパティを設定する必要があります。

outboundDataSource

値をjdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。以前に作成されたスキーマは次のディレクトリにあります。

ORACLE_HOME/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sql

事前作成スキーマを別の場所で作成する場合は、このスクリプトを使用します。その場合は、outboundDataSourceプロパティを設定する必要があります。

outboundDataSourceLocal

値をjdbc/SOALocalTxDataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。

outboundLockTypeForWrite

Oracle Databaseを使用している場合は、この値をoracleに設定します。デフォルトでは、OracleファイルとFTPアダプタはインメモリーmutexを使用してアウトバウンドの書込み操作をロックします。書込み操作を同期化するには、次の値のいずれかを選択する必要があります。

- memory: OracleファイルとFTPアダプタはインメモリーmutexを使用してファイル・システムへのアクセスを同期化します。

- oracle: アダプタは、Oracle Databaseシーケンスを使用します。

- db: アダプタは事前作成されたデータベース表(FILEADAPTER_MUTEX)をロック・メカニズムとして使用します。このオプションは、Oracle Databaseスキーマ以外のスキーマを使用している場合にのみ使用します。

- user-defined: アダプタはユーザー定義のmutexを使用します。ユーザー定義のmutexを構成するには、mutexインタフェースoracle.tip.adapter.file.Mutexを実装し、新しいバインド・プロパティoracle.tip.adapter.file.mutexを構成して、その値にアウトバウンド参照のmutexの完全修飾クラス名を指定します。

8. これらのプロパティを更新した後、「保存」をクリックします。「デプロイメント・プランの保存」ページが表示されます。

9. デプロイメント・プランの共有記憶域場所を入力します。そのディレクトリ構造は次のとおりです。

ORACLE_BASE/admin/domain_name/cluster_name/dp/Plan.xml

10. 「保存してアクティブ化」をクリックします。

11. 一度新しいデプロイメント・プランを保存してアクティブ化すると、FileAdapterデプロイメントをアクティブ化します(まだ開始されていないデプロイメントのステータスは「準備完了」です)。FileAdapterデプロイメント・プランをアクティブ化する手順は次のとおりです。
管理コンソールの「ドメイン構造」の左ペインで「デプロイメント」をクリックします。

右ペインの「デプロイメントのサマリー」でFileAdapterを選択し、「起動」→「すべてのリクエストを処理」を選択します。

12. 次の例のように、(バインディング・コンポーネントのjcaファイル内で)接続ファクトリが使用されるようにBPELプロセスまたはMediatorシナリオを構成します。

<adapter-config name="FlatStructureOut" adapter="File Adapter" xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/HAFileAdapter" adapterRef=""/>
<endpoint-interaction portType="Write_ptt" operation="Write">
<interaction-spec className="oracle.tip.adapter.file.outbound.FileInteractionSpec">
<property../>
<property../>
</interaction-spec>
</endpoint-interaction>
</adapter-config>

注意:

location属性は、接続ファクトリのeis/HAFileAdapterに設定されています。

注意:

同じ手順を実行して、FTPAdapterのcontrol dirを更新します。この変更には、eis/Ftp/HAFtpAdapter接続ファクトリ・インスタンスを使用します。

9.8.2 Oracleデータベース・アダプタのスケーリング

ロックのスキップ機能の導入により、これまでの最善の方法であった、各ポーリング・ノードでLogicalDeletePollingStrategyまたはDeletePollingStrategyと一意のMarkReservedValueを使用し、MaxTransactionSizeを設定する方法は使用できなくなりました。以前にこのアプローチを使用していた場合は、MarkReservedValueを(db.jcaで)削除するか、または(ウィザードの「論理削除」ページで)消去するだけです。それによってロックが自動的にスキップされるようになります。

予約された値に対してロックのスキップを使用することには、次のような利点があります。

- ロックをスキップすると、クラスタにおいて、また負荷がかかっている状態で、スケーリングが向上します。

- (更新/予約→コミットを行ってから新しいトランザクションで選択するのとは反対に)すべての作業が1つのトランザクションで行われるため、高可用性環境でリカバリ不能な状況に直面するリスクが最小に抑えられます。

- 一意のMarkReservedValueを指定する必要がありません。以前は、そのようにするためには、R${weblogic.Name-2}-${IP-2}-${instance}のように、複雑な変数を構成することが必要でした。

論理削除ポーリングを使用していて、MarkReservedValueを設定している場合は、ロックのスキップは使用されません。

以前は、複数のOracle BPEL Process ManagerノードまたはOracle Mediatorノードにデプロイする複数のOracleデータベース・アダプタ・プロセス・インスタンスにおける最善の手法は、基本的に、ポーリング・ノードごとに一意のMarkReservedValueを設定し、さらにMaxTransactionSizeを設定して、LogicalDeletePollingStrategyまたはDeletePollingStrategyを使用することでした。

ただし、ロックのスキップが導入されたことによって、このアプローチは現在使用されなくなりました。以前にこのアプローチを使用していた場合は、MarkReservedValueを(db.jcaで)削除するか、または(ウィザードの「論理削除」ページで)消去するだけです。それによってロックが自動的にスキップされるようになります。

詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のスケーラビリティとポーリング計画に関する項を参照してください。

9.9 高可用性を実現するためのB2B構成の更新

ファイル、FTPまたは電子メールのトランスポートを高可用性環境で設定するには、b2b.HAInstanceName unique_instance_nameを使用して、各インスタンスの一意の名前を指定します。値にServerNameを使用すると、Oracle B2Bは、HAInstanceNameとしてWebLogic Server名を取得します。

一意の名前を指定する手順は次のとおりです。

1. 第8.4.1項「SOAHOST1での管理サーバー用boot.propertiesの作成」で指定したユーザー名とパスワードを使用してOracle Enterprise Manager Fusion Middleware Controlにログインします。

2. 左側のナビゲーション・ツリーで「Farm_<domain_name>」→「SOA」を展開し、「soa-infra<server_name>」を右クリックし、「SOA管理」→「B2Bサーバー・プロパティ」を選択します。

3. 右側の「詳細B2B構成プロパティ」をクリックします。

4. b2b MBeanをクリックします。

5. 「操作」タブをクリックします。

6. 右側のリストの「addProperty」をクリックします。

7. 「キー」フィールドに「b2b.HAInstanceName」を入力します。

8. 値フィールドに「#ServerName#」を入力します。
この値は2つのサーバーのうち1つにのみ入力します。

9. 「起動」をクリックします。

9.10 SOA構成のバックアップ

拡張したドメインが正常に動作していることを確認した後、そのドメイン構成をバックアップします。このバックアップは、この後の手順でエラーが発生した場合にすぐにリストアできるようにすることが目的です。構成をローカル・ディスクにバックアップします。エンタープライズ・デプロイメントが完了すれば、このバックアップは破棄してかまいません。エンタープライズ・デプロイメントが完了すれば、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。情報のリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。

ドメイン構成をバックアップする手順は次のとおりです。

1. Web層をバックアップする手順は次のとおりです。

1. opmnctlを使用してインスタンスを停止します。

ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME

3. 次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

ORACLE_BASE/admin/instance_name/bin/opmnctl startall

2. データベースをバックアップします。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。

3. 管理サーバーのドメイン・ディレクトリをバックアップしてドメイン構成を保存します。構成ファイルは次のディレクトリにあります。

ORACLE_BASE/ admin/domain_name

管理サーバーをバックアップするには、SOAHOST1で次のコマンドを実行します。

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

注意:

ORACLE_HOMEのバックアップは、B2B設定の一部であるXEngine構成が変更されたときに実行する必要があります。これらのファイルは、次のディレクトリにあります。

ORACLE_HOME/soa/thirdparty/edifecs/XEngine

ORACLE_HOMEをバックアップする手順は次のとおりです。

tar -cvpf fmwhomeback.tar MW_HOME

10 Oracle BPMを追加するためのドメインの拡張

この章では、Oracle BPMを追加するためのドメイン拡張の手順を説明します。

この章に含まれる項は、次のとおりです。

- 第10.1項「Oracle BPMを追加するためのドメイン拡張の概要」

- 第10.2項「オプション1: SOAおよびBPMを追加するためのドメインの拡張」

- 第10.3項「オプション2: Oracle BPMを追加するためのSOAドメインの拡張」

- 第10.4項「Oracle BPM構成のバックアップ」

10.1 Oracle BPMを追加するためのドメイン拡張の概要

次の2つの方法で、Fusion MiddlewareインストールにOracle BPMをインストールして構成できます。

- (単一の構成ウィザード・セッションで)管理サーバー(および必要に応じてその他の非SOAサーバー)を含む既存のドメインを拡張して、SOAおよびBPMを組み込みます。表10-1は、このアプローチをまとめたものです。構成手順の詳細は、第10.2項「オプション1: SOAおよびBPMを追加するためのドメインの拡張」を参照してください。

- SOA(および必要に応じてその他の非SOAサーバー)が含まれているドメインをBPMに拡張します。表10-2は、このアプローチをまとめたものです。構成手順の詳細は、第10.3項「オプション2: Oracle BPMを追加するためのSOAドメインの拡張」を参照してください。

表10-1 SOAおよびBPMを追加するための既存ドメインの拡張手順

手順

説明

詳細

SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化

各ホスト名の仮想IPマッピングを有効化します。

第10.2.1項「SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化」

ドメイン拡張のための構成ウィザードの実行

SOAホーム・ディレクトリで構成ウィザードを実行して、管理サーバーとOracle Web Services Managerを持つドメインを拡張し、SOAおよびBPMのコンポーネントをサポートするようにします。

第10.2.2項「SOAHOST1での構成ウィザードを使用した現在のドメインの拡張」

コンポジットをデプロイするためのOracle Coherenceの構成

コンポジットのデプロイにユニキャスト通信を使用するためOracle Coherenceを構成します。

第10.2.3項「コンポジットをデプロイするためのOracle Coherenceの構成」

WLS_SOAn管理対象サーバーに対するホスト名検証の無効化

Oracle BPMを使用するためのドメイン拡張手順を実行した後、管理サーバーで様々なノードを認証するための適切な証明書を設定します。

第10.2.4項「WLS_SOAn管理対象サーバーに対するホスト名検証の無効化」

管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

第10.2.5項「管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播」

WLS_SOA1管理対象サーバーの起動と検証

Oracle WebLogic Server管理コンソールを使用してWLS_SOA1管理対象サーバーを起動して、検証します。

第10.2.6項「WLS_SOA1管理対象サーバーの起動と検証」

SOAHOST2へのドメイン構成の伝播

Unpackユーティリティを使用してSOAHOST2にドメイン構成を伝播します。

第10.2.7項「unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播」

SOAHOST2でのXEngineファイルの抽出

SOAHOST2でB2BのXEngineを有効にするには、XEngine tarの内容を手動で抽出します。

第10.2.8項「SOAHOST2でのXEngineファイルの抽出」

WLS_SOA2管理対象サーバーの起動と検証

WLS_SOA2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認します。

第10.2.9項「WLS_SOA2管理対象サーバーの起動と検証」

WLS_SOAn管理対象サーバーに対するOracle HTTP Serverの構成

Oracle HTTP ServerでSOA_Clusterへのルーティングを有効化します。

第10.2.11項「WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成」

Oracle HTTP Serverを介したアクセスの検証

サーバーのステータスが「実行中」であることを確認します。

第10.2.12項「Oracle HTTP Serverを介したアクセスの検証」

フロントエンドHTTPホストおよびポートの設定

Oracle WebLogic Serverクラスタに対してフロントエンドHTTPのホストとポートを設定します。

第10.2.13項「フロントエンドHTTPホストおよびポートの設定」

トランザクション・リカバリのためのデフォルトの永続ストアの構成

クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセスできる場所にトランザクション・ログを格納します。

第10.2.14項「トランザクション・リカバリ用デフォルト永続ストアの構成」

OracleファイルとFTPアダプタの高可用性化

OracleファイルとFTPアダプタのアウトバウンド操作に対する高可用性を、データベースのmutexロック操作を使用して実現します。

第10.2.15項「OracleファイルとFTPアダプタの高可用性化」

表10-2 すでにSOAが含まれている既存ドメインの拡張手順

手順

説明

詳細

SOAHOST1での構成ウィザードを使用したBPMを追加するためのSOAドメインの拡張

SOAホーム・ディレクトリで構成ウィザードを実行して、管理サーバーとOracle Web Services Managerを持つドメインを拡張し、SOAおよびBPMのコンポーネントをサポートするようにします。

第10.3.1項「SOAHOST1での構成ウィザードを使用したBPMを追加するためのSOAドメインの拡張」

SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播

Oracle BPM Suiteでは、WebLogic Serverの起動スクリプトに多少の更新が必要です。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。

第10.3.2項「SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播」

BPM Suiteコンポーネントの起動

構成変更および起動スクリプトを有効にするため、BPMが追加されたWLS_SOAnサーバーを再起動します。

第10.3.3項「BPM Suiteコンポーネントの起動」

WLS_SOAn管理対象サーバーに対するOracle HTTP Serverの構成

BPM WebアプリケーションにOracle HTTP Serverからルーティングできるようにするため、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。

第10.3.4項「WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成」

Oracle HTTP Serverを介したアクセスの検証

URLを検証して、HTTP ServerからBPM Suiteコンポーネントへのルーティングとフェイルオーバーが適切に機能することを確認します。

第10.3.5項「Oracle HTTP Serverを介したアクセスの検証」

Oracle BPMを追加するためのドメイン拡張の前提条件

現在のドメインを拡張する前に、既存のデプロイメントが次の前提条件を満たしていることを確認します。

- インストールのバックアップ - 既存のFusion Middlewareホームとドメインをバックアップしていない場合は、今すぐバックアップすることをお薦めします。
既存のFusion Middlewareホームおよびドメインをバックアップするには、次のコマンドをSOAHOST1で実行します。

tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw
tar -cvpf domainhomeback.tar ORACLE_BASE/admin/domain_name/aserver/domain_name

これらのコマンドにより、Oracle WebLogic ServerとOracle Fusion Middlewareの両方のインストール・ファイルのバックアップ、およびドメイン構成が作成されます。

- 前の章でインストールしたWL_HOMEおよびORACLE_HOMEが共有記憶域にあります。

10.2 オプション1: SOAおよびBPMを追加するためのドメインの拡張

この項では、構成ウィザードを使用してドメインを拡張し、SOAおよびBPMのコンポーネントを追加する方法について説明します。さらにそのドメインを拡張してBPMを追加できます。ここでは、SOA ORACLE_HOME(バイナリ)がすでにインストールされ、該当する場合はパッチが適用されて最新のパッチ・セットになっており、SOAHOST1およびSOAHOST2からアクセスできると想定しています。また、管理サーバーを含むドメインが作成されていることも想定しています。これが、SOAコンポーネントをサポートする、この章で拡張されるドメインになります。

注意:

セットアップのプロセスを開始する前に、リリース・ノートに目を通してインストールとデプロイメントに関する補足の考慮事項を確認しておくことを強くお薦めします。

この項には次のトピックが含まれます:

- 第10.2.1項「SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化」

- 第10.2.2項「SOAHOST1での構成ウィザードを使用した現在のドメインの拡張」

- 第10.2.3項「コンポジットをデプロイするためのOracle Coherenceの構成」

- 第10.2.4項「WLS_SOAn管理対象サーバーに対するホスト名検証の無効化」

- 第10.2.5項「管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播」

- 第10.2.6項「WLS_SOA1管理対象サーバーの起動と検証」

- 第10.2.7項「unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播」

- 第10.2.8項「SOAHOST2でのXEngineファイルの抽出」

- 第10.2.9項「WLS_SOA2管理対象サーバーの起動と検証」

- 第10.2.10項「GridLinkデータ・ソースの検証」

- 第10.2.11項「WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成」

- 第10.2.12項「Oracle HTTP Serverを介したアクセスの検証」

- 第10.2.13項「フロントエンドHTTPホストおよびポートの設定」

- 第10.2.14項「トランザクション・リカバリ用デフォルト永続ストアの構成」

- 第10.2.15項「OracleファイルとFTPアダプタの高可用性化」

- 第10.2.16項「Oracle JMSアダプタの高可用性化」

- 第10.2.17項「Oracleデータベース・アダプタのスケーリング」

- 第10.2.18項「高可用性を実現するためのB2B構成の更新」

10.2.1 SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化

WLS_SOA1サーバーおよびWLS_SOA2を仮想ホスト名(SOAHOST1VHN1およびSOAHOST2VHN1)に関連付けます。これらの仮想ホスト名がDNSまたはシステム内の/etc/hosts解決で有効になっていること、およびそれらが適切な仮想IP (VIP2およびVIP3)にマップされていることを確認します。サーバー移行を行うには次の手順を実行する必要があります。

仮想IPを有効にするには、第3.5項「管理サーバーの仮想IPアドレスの有効化」を参照してください。

10.2.2 SOAHOST1での構成ウィザードを使用した現在のドメインの拡張

SOAホーム・ディレクトリで構成ウィザードを実行して、管理サーバーとOracle Web Services Managerを持つドメインを拡張し、SOAおよびBPMのコンポーネントをサポートするようにします。

Oracle BPMを使用するためのドメイン拡張手順は次のとおりです。

1. リポジトリをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. ディレクトリを構成ウィザードの場所に変更します。これはSOAホーム・ディレクトリ内にあります。

cd ORACLE_COMMON_HOME/common/bin

3. Oracle Fusion Middleware構成ウィザードを開始します。

./config.sh

4. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

5. WebLogicドメイン・ディレクトリ画面で、WebLogicドメイン・ディレクトリORACLE_BASE/admin/domain_name/aserver/domain_nameを選択し、「次へ」をクリックします。

6. 「拡張ソースの選択」画面で、次の手順を実行します。

- 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。次の製品を選択します。

- 次の製品を選択します。

- Oracle BPM Suite - 11.1.1.0 [soa]

- Oracle SOA Suite - 11.1.1.0 [soa](これは、Oracle BPM Suiteを選択すると自動的に選択されます)

- Oracle WSM Policy Manager 11.1.1.0 [oracle_common](これは、Oracle BPM Suiteを選択すると自動的に選択されます)

- Oracle Enterprise Manager - 11.1.1.0 [oracle_common]

- Oracle JRF - 11.1.1.0 [oracle_common](これは自動的に選択されてグレー表示されます)

いくつかのターゲットを間違って選択解除した場合は、次の項目が選択されていることを確認します。

- Oracle SOA

- Oracle BPM Suite

「次へ」をクリックします。

7. 「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。

- 「SOAインフラストラクチャ」→「ユーザー・メッセージング・サービス」→SOA MDSスキーマを選択します。

- 「コンポーネント・スキーマのOracle RAC構成」については、「GridLinkへ変換」を選択します。

「次へ」をクリックします。

8. 「GridLink RACコンポーネント・スキーマの構成」画面が表示されます(図10-1)。

図10-1 「GridLink RACコンポーネント・スキーマの構成」画面

この画面で、次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: OracleのGridLinkConnections用ドライバ (Thin) バージョン: 10以上を選択します。

- サービス名: データベースのサービス名を、小文字で入力します。例:
soaedg.mycompany.com

- ユーザー名: 対応するコンポーネントのデータベース・スキーマ・オーナーの名前を入力します。(replace table reference)に表示されたユーザー名は、RCUからのスキーマ作成の接頭辞としてsoedgが使用されたことを示しています。

- パスワード: データベース・スキーマ・オーナーのパスワードを入力します。

- 「FANの有効化」を選択します。

- 「SSLの有効化」が選択解除されていることを確認します(暗号化するONS通知にsslが選択されている場合は、適切なウォレットとウォレット・パスワードを指定します)。

- サービス・リスナー: 使用するRACデータベースのためのSCANアドレスとポートを入力します。このアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せれば識別できます。

SQL>show parameter remote_listener;

NAME              TYPE                VALUE
-------------------------------------------------------------
remote_listener   string    db-scan.mycompany.com:1521

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。次に例を示します。

custdbhost1-vip.mycompany.com (port 1521)

および

custdbhost2-vip.mycompany.com (1521)

Oracle Database 10gでは、Oracle RACデータベースへの接続にマルチ・データ・ソースを使用します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- ONSホスト: Oracle RACデータベースのSCANアドレスおよびデータベースから報告されたONSリモート・ポートを入力します。

[orcl@db-scan1 ~]$ srvctl config nodeapps -s

ONS exists: Local port 6100, remote port 6200, EM port 2016

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベースのONSサービスのホスト名とポートを使用します。次に例を示します。

custdbhost1.mycompany.com (port 6200)

および

custdbhost2.mycompany.com (6200)

9. 「JDBCデータ・ソースのテスト」画面で、各接続のテストが自動的に行われます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。

10. オプションの構成の画面で、次の項目を選択します。

- JMS分散宛先

- JMSファイル・ストア

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

「次へ」をクリックします。

11. 一度新しいデプロイメント・プランを保存してアクティブ化すると、FileAdapterデプロイメントをアクティブ化します(まだ開始されていないデプロイメントのステータスは「準備完了」です)。
FileAdapterデプロイメント・プランをアクティブ化する手順は次のとおりです。

1. 管理コンソールの「ドメイン構造」の左ペインで「デプロイメント」をクリックします。

2. 右ペインの「デプロイメントのサマリー」で「FileAdapter」を選択します。

3. 「開始」→「すべてのリクエストを処理」を選択します。

12. 「JMS分散宛先タイプの選択」画面で、すべてのFusion MiddlewareコンポーネントのJMSモジュールのドロップダウン・リストから「UDD」を選択します。

注意:

Fusion MiddlewareコンポーネントでのWDDの使用はサポートされません。

13. 「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。
soa_server1というサーバーが自動的に作成されます。このサーバーの名前をWLS_SOA1に変更し、WLS_SOA2という新しいサーバーを追加します。表10-3に示す属性をこれらのサーバーに指定します。この画面に表示されている他のサーバーは、このまま変更しません。

表10-3 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_SOA1

SOAHOST1VHN1

8001

なし

いいえ

WLS_SOA2

SOAHOST2VHN1

8001

なし

いいえ

「次へ」をクリックします。

14. 「クラスタの構成」画面で、表10-4に示すクラスタを追加します。この画面に表示されている他のクラスタは、このまま変更しません。

表10-4 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

SOA_Cluster

ユニキャスト

なし

なし

SOAHOST1VHN1:8001、SOAHOST2VHN1:8001

「次へ」をクリックします。

15. 「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。

- SOA_Cluster:

- WLS_SOA1

- WLS_SOA2

「次へ」をクリックします。

16. 「マシンの構成」画面で、次の手順を実行します。

- 「削除」をクリックして、デフォルトの「LocalMachine」を削除します。

- 「Unixマシン」タブをクリックします。SOAHOST1マシンとSOAHOST2マシンには、次のエントリが表示されます(表10-5)。

表10-5 マシン

名前

ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINHOST

localhost

他のフィールドはすべてデフォルト値のままにします。

「次へ」をクリックします。

17. 「サーバーのマシンへの割当」画面で、次の表に従ってサーバーをマシンに割り当てます。

表10-6 マシンへのサーバーの割当て

サーバー

マシン

AdminServer

ADMINHOST

WLS_SOA1

SOAHOST1

WLS_SOA2

SOAHOST2

WLS_WSM1

SOAHOST1

WLS_WSM2

SOAHOST2

「次へ」をクリックします。

18. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- WSM-PMはWSM-PM_Clusterにのみターゲット設定します。

- oracle.sdp.*、oracle.bpm.*およびoracle.soa.*の各デプロイメントは、SOA_Clusterにのみターゲット設定します。

- oracle.rules.*ライブラリは、管理サーバーおよびSOA_Clusterにのみターゲット設定します。

「次へ」をクリックします。

19. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、mds-owsm、mdw-owsm-rac0およびmds-owsm-rac1データソースを、WSM-PM_ClusterとAdminServerにターゲット設定し、「次へ」をクリックします。
アプリケーションとリソースのターゲット設定の詳細は、付録B「アプリケーションとリソースのサーバーへのターゲット設定」を参照してください。

20. 「JMSファイル・ストアの構成」画面で、第4.3項「異なるディレクトリの推奨場所」でお薦めしているように、JMSストアに指定した共有ディレクトリの場所を入力します。例:

ASERVER_HOME/soa_cluster_name/jms

すべてのストアに対してDirect-writeポリシーを選択します。

「次へ」をクリックします。

21. 「構成のサマリ」画面で、「拡張」をクリックします。

22. 「ドメインの作成中」画面で、「完了」をクリックします。
この構成を有効にするには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用して、管理サーバーを再起動する必要があります。

10.2.3 コンポジットをデプロイするためのOracle Coherenceの構成

コンポジットのデプロイではマルチキャスト通信がデフォルトで使用されますが、SOAエンタープライズ・デプロイメントではユニキャスト通信の使用をお薦めします。セキュリティ上の理由からマルチキャスト通信を無効にしている場合は、ユニキャストを使用します。

ユニキャスト通信を使用した場合、この方法ではノードから他のクラスタ・メンバーを検出できません。したがって、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加した新しいノードから既存ノードのいずれかを検出するために必要な数のノードを指定するだけでかまいません。この結果、クラスタに追加した新しいノードからクラスタにある他のすべてのノードを検出できます。また、同じシステムで複数のIPを使用できるSOAエンタープライズ・デプロイメントなどの構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。

注意:

デプロイメントに使用するOracle Coherenceフレームワークの構成が正しくないと、SOAシステムを起動できないことがあります。SOAシステムを実行するネットワーク環境に応じて、デプロイメント・フレームワークを適切にカスタマイズする必要があります。この項で説明する構成をお薦めします。

10.2.3.1 ユニキャスト通信を使用したデプロイメントの通信の有効化

tangosol.coherence.wka<n>システム・プロパティを使用してノードを指定します。<n>は、1から9の数字です。指定できるノードは最大9個です。番号は1から開始します。この番号付けは、連続的で間隙を含まないようにする必要があります。また、Oracle Coherenceでクラスタを作成するために使用するホスト名をtangosol.coherence.localhostシステム・プロパティで指定します。このローカル・ホスト名には、SOAサーバーでリスナーのアドレスとして使用する仮想ホスト名を指定する必要があります(SOAHOST1VHN1とSOAHOST2VHN1)。このプロパティを設定するには、Oracle WebLogic Server管理コンソールの「サーバーの起動」タブにある「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加します(図10-2)。

ヒント:

SOAコンポジットのデプロイメント時に高可用性を確保するには、適切な数のノードを指定して、どの時点でもそのうちのいずれかが必ず稼働しているようにします。

注意:

SOAHOST1VHN1は、SOAHOST1でWLS_SOA1がリスニングする仮想IPにマップされる仮想ホスト名です。SOAHOST2VHN1は、SOAHOST2でWLS_SOA2がリスニングする仮想IPにマップされる仮想ホスト名です。

図10-2 Oracle WebLogic Server管理コンソールの「サーバーの起動」タブを使用したホスト名の設定

10.2.3.2 Oracle Coherenceで使用するホスト名の指定

管理コンソールを使用して、Oracle Coherenceで使用するホスト名を指定します。この手順は、WLS_SOA1およびWLS_SOA2の両方のサーバーに必要です。

Oracle Coherenceで使用するホスト名を追加する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。
選択したサーバーの「設定」ページが表示されます。

5. 「ロックして編集」をクリックします。

6. 「サーバーの起動」タブをクリックします(図10-2を参照)。

7. WLS_SOA1とWLS_SOA2について、「引数」フィールドに次の値を入力します。

注意:

異なる-Dパラメータの間には、空白の行を入れないでください。管理コンソールの引数テキスト・フィールドに、このテキストをコピーまたは貼り付けないでください。Java引数にHTMLタグが挿入される可能性があります。このテキストには、前述の例に含まれているテキスト文字以外の文字を入れないでください。

注意:

デプロイメントで使用されるCoherenceクラスタでは、ポート8088をデフォルトで使用します。このポートは、起動パラメータ-Dtangosol.coherence.wkan.portおよび-Dtangosol.coherence.localportで別なポート(8089など)を指定することで変更できます。例:

WLS_SOA1(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST1VHN1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

WLS_SOA2(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST2VHN1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

Coherenceクラスタの詳細は、『Oracle Coherence開発者ガイド』を参照してください。

WLS_SOA1については次の値を入力します。

-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST1VHN1

WLS_SOA2については次の値を入力します。

-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST2VHN1

8. 「保存」→「変更のアクティブ化」をクリックします。

注意:

これらの変数が管理対象サーバーに正しく渡されることを確認する必要があります。(これらの変数はサーバーの出力ログに記録されます。)Oracle Coherenceフレームワークに問題があると、soa-infraアプリケーションを起動できないことがあります。

注意:

このマルチキャスト・アドレスとユニキャスト・アドレスは、WebLogic Serverクラスタでクラスタ通信に使用するものとは異なります。SOAでは、2つのエンティティ(WebLogic Serverクラスタおよびコンポジットのデプロイ先グループ)の通信プロトコルが異なる場合でも、単一のWebLogic Serverクラスタの各メンバーにコンポジットを確実にデプロイできます。

10.2.4 WLS_SOAn管理対象サーバーに対するホスト名検証の無効化

このガイドで説明するエンタープライズ・デプロイメントでは、Oracle SOA Suiteを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。WLS_SOA1およびWLS_SOA2管理対象サーバーのホスト名検証を無効化して、様々なWebLogic Serverインスタンスを管理するときにエラーが出ないようにします。詳細は、第8.4.8項「ホスト名検証の無効化」を参照してください。

エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第13.3項「SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。

10.2.5 管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

注意:

解凍前にサーバー移行を構成すると(BPMが含まれるようにドメインを拡張すると)、wlsifconfigスクリプトは上書きされるため、-overwriteオプションが提供するコピーからリストアする必要があります。

起動スクリプトとクラスパス構成を伝播する手順は次のとおりです。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのコピーを作成します。

2. SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ASERVER_HOME
-template=soadomaintemplateExtSOABPM.jar
-template_name=soa_domain_templateExtSOABPM

3. SOAHOST1でunpackコマンドを実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

./unpack.sh -domain=MSERVER_HOME
-overwrite_domain=true
-template=soadomaintemplateExtSOABPM.jar
-app_dir=MSERVER_HOME/applications

注意:

unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

注意:

このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。

10.2.6 WLS_SOA1管理対象サーバーの起動と検証

Oracle WebLogic Server管理コンソールを使用してWLS_SOA1管理対象サーバーを起動して、検証します。

WLS_SOA1管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認するには:

1. 次の手順に従い、Oracle WebLogic Server管理コンソールを使用してWLS_SOA1管理対象サーバーを起動します。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

2. 「サーバー」を選択します。
「サーバーのサマリー」画面が表示されます。

3. 「制御」タブをクリックします。

4. 「WLS_SOA1」を選択して、「起動」をクリックします。

2. サーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16章の「エンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。

3. 次のURLにアクセスします。
http://SOAHOST1VHN1:8001/soa-infra/(WLS_SOA1のステータスを確認する場合)。

http://SOAHOST1VHN1:8001/soa/composer/(SOAプロセス・コンポーザのステータスを確認する場合)。

http://SOAHOST1VHN1:8001/integration/worklistapp/(ワークリスト・アプリケーションのステータスを確認する場合)。

http://SOAHOST1VHN1:8001/b2bconsole/(B2Bのステータスを確認する場合)。

http://SOAHOST1VHN1:8001/sdpmessaging/userprefs-ui/(メッセージング・システム・プリファレンスのステータスを確認する場合)。

http://SOAHOST1VHN1:8001/bpm/composer/にアクセスしてコンポーザ・アプリケーションにログインします。

http://SOAHOST1VHN1:8001/bpm/workspace/にアクセスしてワークスペース・アプリケーションにログインします。

10.2.7 unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播

unpackユーティリティを使用してSOAHOST2にドメイン構成を伝播します。

注意:

解凍前にサーバー移行を構成すると(BPMが含まれるようにドメインを拡張すると)、wlsifconfigスクリプトは上書きされるため、-overwriteオプションが提供するコピーからリストアする必要があります。

SOAHOST2にドメイン構成を伝播させるには:

1. 次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをSOAHOST2にコピーします。

cd ORACLE_COMMON_HOME/common/bin

scp soadomaintemplateExtSOABPM.jar oracle@node2:ORACLE_COMMON_HOME/common/bin

2. unpackコマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME
-overwrite_domain=true -template=soadomaintemplateExtSOABPM.jar
-app_dir=MSERVER_HOME/applications

注意:

unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

注意:

このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。

10.2.8 SOAHOST2でのXEngineファイルの抽出

SOAHOST2でB2BのXEngineを有効にするには、次のようにXEngine tarの内容を手動で抽出する必要があります。

1. 次のコマンドをSOAHOST2から実行します。

cd ORACLE_HOME/soa/thirdparty/edifecs
tar -xzvf XEngine.tar.gz

2. SOAHOST2でノード・マネージャを再起動するには、第9.5.2項「SOAHOST1でのノード・マネージャの再起動」の手順を使用します。

3. 抽出後、次のディレクトリ構造を確認します。

ORACLE_HOME/soa/soa/thirdparty/edifecs/

このディレクトリ内に次のディレクトリが表示されている必要があります。

- Common

- XEngine

XEngineディレクトリ内に、次のディレクトリとファイルが表示されている必要があります。

- bin

- config

- Readme.htm

- EULA.pdf

10.2.9 WLS_SOA2管理対象サーバーの起動と検証

WLS_SOA2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認するには:

1. 次の手順に従い、Oracle WebLogic Server管理コンソールを使用してWLS_SOA2管理対象サーバーを起動します。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

2. 「サーバー」を選択します。
「サーバーのサマリー」画面が表示されます。

3. 「制御」タブをクリックします。

4. 「WLS_SOA2」を選択して、「起動」をクリックします。

2. サーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16章の「エンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。

3. 次のURLにアクセスします。
http://SOAHOST2VHN1:8001/soa-infra (WLS_SOA2のステータスを確認する場合)。

http://SOAHOST2VHN1:8001/soa/composer (SOAプロセス・コンポーザのステータスを確認する場合)。

注意:

ポリシーやアサーション・テンプレートがまったく表示されない場合は、構成が正しくありません。

http://SOAHOST2VHN1:8001/integration/worklistapp(ワークリスト・アプリケーションのステータスを確認する場合)。

http://SOAHOST2VHN1:8001/b2bconsole (B2Bのステータスを確認する場合)。

http://SOAHOST2VHN1:8001/sdpmessaging/userprefs-ui(メッセージング・システム・プリファレンスのステータスを確認する場合)。

http://SOAHOST2VHN1:8001/bpm/composerにアクセスしてコンポーザ・アプリケーションにログインします。

http://SOAHOST2VHN1:8001/bpm/workspaceにアクセスしてワークスペース・アプリケーションにログインします。

10.2.10 GridLinkデータ・ソースの検証

サーバーが開始したら、GridLinkデーター・ソースが正しく構成され、ONS設定が正しいことを確認します。作成されたすべてのGridLinkデータ・ソースに対して、この手順を実行します。

GridLinkデータ・ソースの構成を検証する手順は次のとおりです。

1. Oracle WebLogic管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

3. 新しいデータ・ソースの内の1つをクリックします。

4. 「監視」タブをクリックし、いずれかのサーバーを選択します。

5. 「統計」タブをクリックし、いずれかのサーバーを選択します。

6. 「ONS」タブをクリックし、「テスト」タブをクリックします。

7. サーバーを選択して、「ONSのテスト」をクリックします。
テストが両方とも成功すれば、正しく構成されています。ONSのテストが失敗した場合は、RACデータベース・ノードでONSサービスが実行されていることを確認します。

orcl@db-scan1 ~]$ srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node db-scan1
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node db-scan2
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node db-scan2

[orcl@db-scan1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

[orcl@db-scan1 ~]$ srvctl status nodeapps | grep ONS
ONS is enabled
ONS daemon is running on node: db-scan1
ONS daemon is running on node: db-scan2

データ・ソースを使用するすべてのWebLogicサーバーからONSテストを実行します。

10.2.11 WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成

WLS_SOAn管理対象サーバーが属するSOA_ClusterにOracle HTTP Serverからルーティングできるようにするには、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。

Oracle HTTP ServerでSOA_Clusterへのルーティングを有効化する手順は次のとおりです。

1. WEBHOST1およびWEBHOST2上で、次のディレクトリにあるsoa.vh.confファイルにディレクティブを追加します。

ORACLE_INSTANCE/config/OHS/component_name/moduleconf

第7.6項「仮想ホストの定義」の指示に従って、soa_vh.confファイルを作成している必要があります。

<VirtualHost>タグ内に、次のディレクティブを追加します。

# BPM
<Location /bpm/composer>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# BPM
<Location /bpm/workspace>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

soa_vh.confファイルは、例10-1のように表示されます。

2. WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

WEBHOST1> ORACLE_INSTANCE/bin/opmnctl restartproc ias-component=ohs1
WEBHOST2> ORACLE_INSTANCE/bin/opmnctl restartproc ias-component=ohs2

例10-1 soa_vh.confファイル

<VirtualHost *:7777>
ServerName https://soa.mycompany.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

<Location /soa-infra>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Worklist
<Location /integration>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# B2B
<Location /b2bconsole>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Workflow
<Location /workflow>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA composer application
<Location /soa/composer>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# BPM
<Location /bpm/composer>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# BPM
<Location /bpm/workspace>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
</VirtualHost>

WebLogicClusterパラメータで指定したサーバーは、起動時のプラグインに対してのみ重要な役割を持ちます。このノードのリストには、実行しているクラスタ・メンバーを1つ以上記述しておく必要があります。記述しておかないと、このプラグインで他のクラスタ・メンバーを検出できません。Oracle HTTP Serverの起動時には、リストに記述したクラスタ・メンバーを実行している必要があります。

Oracle WebLogic Serverとこのプラグインの連携により、クラスタに発生した新規のクラスタ・メンバー、失敗したクラスタ・メンバーおよびリカバリしたクラスタ・メンバーを反映してサーバーのリストが自動的に更新されます。

次に例を示します。

- 例1: 2つのノードで構成したクラスタに3番目のメンバーを追加する場合、そのメンバーを追加するために構成を更新する必要はありません。3番目のメンバーは、実行時に自動的に検出されます。

- 例2: クラスタは3つのノードで構成されていても、構成に記述されているノードはそのうちの2つのみであるとします。Oracle HTTP Serverを起動するときにこの2つのノードが両方とも停止していると、プラグインはクラスタを検出できません。Oracle HTTP Serverを起動するときは、リストに記述したノードを1つ以上実行している必要があります。
クラスタのメンバーをすべてリストに記述した場合は、Oracle HTTP Serverの起動時にそのうちの1つ以上を実行しておくことで、クラスタに確実に到達できます。

WebLogic Serverプラグインの構成の詳細は、『Oracle WebLogic ServerにおけるWebサーバー・プラグインの使用』ガイドを参照してください。

10.2.12 Oracle HTTP Serverを介したアクセスの検証

サーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.14項「エンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。

次のURLにアクセスできることを確認します。webhostNには、各Oracle HTTP Serverホストの名前を指定します(WEBHOST1やWEBHOST2など)。

- http://WEBHOST1:7777/soa-infra

- http://WEBHOST2:7777/soa-infra

- http://WEBHOST1:7777/soa/composer

- http://WEBHOST2:7777/soa/composer

- http://WEBHOST1:7777/integration/worklistapp

- http://WEBHOST2:7777/integration/worklistapp

- http://WEBHOST1:7777/sdpmessaging/userprefs-ui

- http://WEBHOST2:7777/sdpmessaging/userprefs-ui

- http://WEBHOST1:7777/b2bconsole

- http://WEBHOST2:7777/b2bconsole

- http://WEBHOST1:7777/bpm/composer

- http://WEBHOST2:7777/bpm/composer

- http://WEBHOST1:7777/bpm/workspace

- http://WEBHOST2:7777/bpm/workspace

これらのURLは、ロード・バランサ・アドレスを使用して確認することもできます。

- http://soa.mycompany.com:80/soa-infra

- http://soa.mycompany.com:80/soa/composer

- http://soa.mycompany.com:80/integration/worklistapp

- http://soa.mycompany.com:80/sdpmessaging/userprefs-ui

- http://soa.mycompany.com:80/b2bconsole

- http://soa.mycompany.com:80/bpm/composer

- http://soa.mycompany.com:80/bpm/workspace

ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。

10.2.13 フロントエンドHTTPホストおよびポートの設定

Oracle WebLogic Serverクラスタについて、フロントエンドHTTPのホストとポートを設定する必要があります。

1. WebLogic Server管理コンソールの「チェンジ・センター」セクションの「ロックして編集」をクリックします。

2. 左ペインの「ドメイン構造」ウィンドウで「環境」を選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。

3. SOA_Clusterクラスタを選択します。

4. 「HTTP」を選択します。

5. 次の値を設定します。

- フロントエンド・ホスト: soa.mycompany.com

- フロントエンドHTTPSポート: 443

- フロントエンドHTTPポート: 80

フロントエンドHTTPのホストとポートを設定していない場合は、Oracle B2Bからドキュメント定義のXSDを取得しようとすると次のメッセージが表示されます。

An error occured while loading the document definitions.
java.lang.IllegalArgumentException: Cluster address must be set when clustering is enabled.

6. 「保存」をクリックします。

7. 変更を有効にするために、管理コンソールの「チェンジ・センター」セクションの「変更のアクティブ化」をクリックします。

8. サーバーを再起動して、クラスタのフロントエンド・ホストの指定を有効化します。

注意:

ロード・バランサでHTTPSが有効になっており、SSLがロード・バランサで終了する場合(SOAサーバーはHTTPSではなくHTTPリクエストのみを受信します)、ここに示しているように、Webサービスのエンドポイント・プロトコルはhttpに設定されます。ロード・バランサはHTTPをHTTPSにリダイレクトするため、Oracle Enterprise Manger Fusion Middleware ControlでWebサービスの機能をテストすると、次の例外が発生します。

(javax.xml.soap.SOAPException: oracle.j2ee.ws.saaj.ContentTypeException)

この例外を解決するには、URLエンドポイントを更新します。

Enterprise Managerの「テスト」ページで、エンドポイントURLの編集を確認します。

「エンドポイントURL」ページで、次の操作を実行します。

- httpをhttpsに変更します。

- 初期設定のポート番号(80など)をSSLポート(443など)に変更します。

注意:

フロントエンドHTTPのホストとポートを設定していない場合は、Oracle B2Bからドキュメント定義のXSDを取得しようとすると次のメッセージが表示されます。

An error occured while loading the document definitions.
java.lang.IllegalArgumentException: Cluster address must be set when clustering is enabled.

コールバックURL

SOAシステムでは、次のようにコールバックURLを計算します。

- SOAへのリクエストが外部または内部のサービスから発行された場合、SOAはクライアントで指定されたコールバックURLを使用します。

- 外部または内部の非同期サービスへのリクエストがSOAから発行された場合は、次の方法でコールバックURLが決定されます。ここでは決定方法の優先度が高い順に示しています。

- 特定の参照用のバインド・プロパティとして指定されたcallbackServerURLを使用します(このプロパティは、コンポジットのモデリング時または実行時にMBeansを使用して設定できます)。これにより、サービス呼び出しごとに異なるコールバックURLを割り当てることができます。つまり、外部サービスからのコールバックURLには、内部サービスへのコールバックURLとは異なる値を設定できます。エンタープライズ・デプロイメント・アーキテクチャでの一般的なコールバックURLは、外部サービスについてはsoa.mycompany.com (443/https)、内部サービスについてはsoainternal.mycompany.com (7777/http)です。このプロパティは、システムMBeanブラウザに対応するバインドmbeanを通じ、実行時にシステムMBeanブラウザを使用して設定します。特定のURLを追加するには、そのProperties属性にcallbackServerURLプロパティを追加してから保存操作を実行します。

- soa-infra-config.xmlで指定したコールバックURLを使用します。この場合、指定できるアドレスは1つのみです。外部サービスと内部サービスの両方を組み合せて呼び出し可能な場合は、エンタープライズ・デプロイメント・アーキテクチャでこのアドレスをsoa.mycompany.com (443/https)に設定する必要があります。内部サービスのみを呼び出す場合は、このアドレスをsoainternal.mycompany.com (7777/http)に設定します。

- SOA_ClusterのWLSで指定するフロントエンド・ホストとして、このコールバックURLを使用します。この場合も指定できるアドレスは1つのみなので、soa-infra-config.xmlの場合と同じ処理をお薦めします。

- WLS MBean APIで指定されたローカル・ホスト名を使用します。エンタープライズ・デプロイメントのような高可用性環境では、この方法はお薦めできません。

10.2.14 トランザクション・リカバリ用デフォルト永続ストアの構成

各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。WebLogic Serverでは、システム・クラッシュやネットワーク障害からのリカバリ時にこのトランザクション・ログを使用します。クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセスできる場所にトランザクション・ログを格納します。

注意:

お薦めする場所は、デュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)です。

デフォルトの永続ストアの場所を設定する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」ノードをクリックします。「サーバーの概要」ページが表示されます。

3. 表の「名前」列にあるサーバーの名前(ハイパーリンクとして表示されています)をクリックします。選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

4. 「サービス」サブタブをクリックします。

5. ページの「デフォルト・ストア」セクションで、そのデータ・ファイルが格納されるデフォルト永続ストアのあるフォルダのパスを入力します。パスのディレクトリ構造は次のとおりです。

ASERVER_HOME/soa_cluster_name/tlogs

6. 「保存」をクリックします。

注意:

トランザクション・リカバリ・サービスの移行を有効にするには、クラスタにある他のサーバーが使用できる永続記憶域ソリューションの場所を指定します。WLS_SOA1とWLS_SOA2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。

10.2.15 OracleファイルとFTPアダプタの高可用性化

OracleファイルとFTPアダプタを使用すると、BPELプロセスやOracle MediatorでFTP(ファイル転送プロトコル)を使用して、ローカルとリモートのファイル・システムにあるファイルの読取りと書込みができます。これらのアダプタは、インバウンドとアウトバウンドの両方の操作に対し、Oracle BPEL Process ManagerとOracle Mediatorサービス・エンジンを使用してアクティブ/アクティブ・トポロジの高可用性をサポートします。Oracle File AdapterとOracle FTP Adapterがアウトバウンド操作に対する高可用性を備えるようにするには、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のアウトバウンド操作での高可用性に関する項で説明されているデータベースのmutexロック操作を使用します。データベースのmutexロック操作を使用すると、複数の参照から同じディレクトリへの書込みが発生しても、これらのアダプタでは相互の上書きを防止できます。

注意:

この項で説明する操作は、これらのアダプタがアプリケーションで必要になる場合にのみ実行する必要があります。

注意:

ファイル・アダプタは、インバウンド・ディレクトリからファイルを取得して処理し、出力ディレクトリにファイルを出力します。ファイル・アダプタでの処理はトランザクション方式ではないので、ファイルは2回処理できます。この結果として、Oracle RACバックエンドまたはSOA管理対象サーバーでフェイルオーバーが発生したときに、重複するファイルが得られる可能性があります。

10.2.15.1 データベースのmutexロック操作の使用

データベース表をコーディネータとして使用することで、アウトバウンドのOracleファイルやFTPアダプタのサービスに高可用性を実現します。そのためには次の手順を実行します。

注意:

FTPアダプタの手順および構成オプションは、フィルタ・アダプタのオプションと完全に同じです。FTP HAの構成に使用する接続ファクトリは、FTPアダプタ・デプロイメントの送信接続プールの下に表示されるeis/Ftp/HAFtpAdapterです。

注意:

データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトの値を大きくする必要があります。

1. データベース表の作成
データベース・スキーマはsoainfraの一部として事前に作成済なので、この手順を実行する必要はありません。

2. Oracleファイル・アダプタのデプロイメント・ディスクリプタの変更
eis/HAFileAdapterに対応する接続インスタンスについて、Oracle WebLogic ServerコンソールからOracleファイル・アダプタのデプロイメント・ディスクリプタを変更します。

1. Oracle WebLogic Serverコンソールにログインします。このコンソールにアクセスするには、http://servername:portnumber/consoleにアクセスします。

2. 「ドメイン構造」の左ペインで「デプロイメント」をクリックします。

3. 右ペインの「デプロイメントの概要」で「FileAdapter」をクリックします。

4. 「構成」タブをクリックします。

5. 「アウトバウンド接続プール」タブをクリックして「javax.resource.cci.ConnectionFactory」を開き、構成済の接続ファクトリを表示します。

6. 「eis/HAFileAdapter」をクリックします。高可用性に対応する接続ファクトリの「アウトバウンド接続のプロパティ」が表示されます。

7. 図10-3に示すように、接続ファクトリのプロパティが表示されます。

図10-3 Oracle WebLogic Serverコンソール - 「javax.resource.cci.Connectionfactoryの設定」ページ

「ロックして編集」をクリックします。これにより、プロパティ値の列が編集可能になります(「プロパティ値」列で任意の行をクリックしてその値を変更できます)。

OracleファイルとFTPアダプタの接続ファクトリの新しいパラメータは次のとおりです。

表10-7 OracleファイルとFTPのアダプタ

パラメータ

説明

controlDir

制御ファイルを格納するディレクトリ構造に設定します。1つのクラスタの中で複数のWebLogic Serverインスタンスを実行する場合は、この値を共有場所に設定する必要があります。この共有記憶域のディレクトリは次のような構造にします。

ASERVER_HOME/cluster_name/fadapter

inboundDataSource

値をjdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。以前に作成されたスキーマは次のディレクトリにあります。

ORACLE_HOME/rcu/integration/soainfra/sql/createschema_soainfra_oracle.sql

事前作成スキーマを別の場所で作成する場合は、このスクリプトを使用します。別のスキーマを選択する場合は、それに応じてinboundDataSourceプロパティを設定する必要があります。

outboundDataSource

値をjdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。以前に作成されたスキーマは次のディレクトリにあります。

ORACLE_HOME/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sql

事前作成スキーマを別の場所で作成する場合は、このスクリプトを使用します。その場合は、outboundDataSourceプロパティを設定する必要があります。

outboundDataSourceLocal

値をjdbc/SOALocalTxDataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。

outboundLockTypeForWrite

Oracle Databaseを使用している場合は、この値をoracleに設定します。デフォルトでは、OracleファイルとFTPアダプタはインメモリーmutexを使用してアウトバウンドの書込み操作をロックします。書込み操作を同期化するには、次の値のいずれかを選択する必要があります。

- memory: OracleファイルとFTPアダプタはインメモリーmutexを使用してファイル・システムへのアクセスを同期化します。

- oracle: アダプタは、Oracle Databaseシーケンスを使用します。

- db: アダプタは事前作成されたデータベース表(FILEADAPTER_MUTEX)をロック・メカニズムとして使用します。このオプションは、Oracle Databaseスキーマ以外のスキーマを使用している場合にのみ使用します。

- user-defined: アダプタはユーザー定義のmutexを使用します。ユーザー定義のmutexを構成するには、mutexインタフェースoracle.tip.adapter.file.Mutexを実装し、新しいバインド・プロパティoracle.tip.adapter.file.mutexを構成して、その値にアウトバウンド参照のmutexの完全修飾クラス名を指定します。

8. これらのプロパティを更新した後、「保存」をクリックします。「デプロイメント・プランの保存」ページが表示されます。

9. デプロイメント・プランの共有記憶域場所を入力します。そのディレクトリ構造は次のとおりです。

ASERVER_HOME/cluster_name/dd/Plan.xml

10. 「保存してアクティブ化」をクリックします。

11. 次の例のように、接続ファクトリが使用されるようにBPELプロセスまたはMediatorシナリオを構成します。

<adapter-config name="FlatStructureOut" adapter="File Adapter" xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/HAFileAdapter" adapterRef=""/>
<endpoint-interaction portType="Write_ptt" operation="Write">
<interaction-spec className="oracle.tip.adapter.file.outbound.FileInteractionSpec">
<property../>
<property../>
</interaction-spec>
</endpoint-interaction>
</adapter-config>

注意:

location属性は、接続ファクトリのeis/HAFileAdapterに設定されています。

10.2.16 Oracle JMSアダプタの高可用性化

Oracle JMSアダプタがクラスタ内の複数のサーバーと通信する場合、アダプタの通信ファクトリのプロパティFactoryPropertiesに使用可能なサーバーがリストされている必要があります。サーバーがリストされない場合、ランダムな1サーバーとの接続が確立されます。そのサーバーが停止しても、追加のメッセージは処理されません。

アダプタのJCA接続ファクトリを確認する手順は次のとおりです。

1. 次のURLを使用して、Oracle WebLogic Server管理コンソールにログインします。
http://servername:portnumber/console

2. 「ドメイン構造」の左ペインで「デプロイメント」をクリックします。

3. 右ペインの「デプロイメントのサマリー」でJMSAdapterをクリックします。

4. 「構成」タブをクリックします。

5. 「アウトバウンド接続プール」タブをクリックしてoracle.tip.adapter.jms.IJmsConnectionFactoryを開き、構成済の接続ファクトリを表示します。

6. 使用中の特定のインスタンス(例: eis/wls/Queue)をクリックします。接続ファクトリの「アウトバウンド接続のプロパティ」が開きます。

7. 「ロックして編集」をクリックします。

8. FactoryPropertiesフィールドで(「プロパティ」値の該当するセルをクリックして)、次を入力します。

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;
java.naming.provider.url=t3://soahostvhn1:8001,soahost2vhn1:8001;java.naming.se
curity.principal=weblogic;java.naming.security.credentials=mypassword

9. これらのプロパティを更新した後、「保存」をクリックします。「デプロイメント・プランの保存」ページが表示されます。

10. デプロイメント・プランの共有記憶域場所を入力します。そのディレクトリ構造は次のとおりです。

ASERVER_HOME/cluster_name/dp/Plan.xml

11. 「保存してアクティブ化」をクリックします。

コンソールでデプロイメントを更新します。

1. 「デプロイメント」をクリックしてJMSアダプタを選択します。

2. 「ロックして編集」をクリックし、「更新」をクリックします。

3. 新規デプロイメント・プランの変更(デプロイメント・プランはこのオプションで指定)を含め、このアプリケーションの「更新」を選択し、共有記憶域の場所に保存されたデプロイメント・プランを選択すると、クラスタ内のすべてのサーバーは、このプランにアクセス可能になります。

4. 「終了」をクリックします。

5. 変更をアクティブ化します。

10.2.17 Oracleデータベース・アダプタのスケーリング

ロックのスキップ機能の導入により、これまでの最善の方法であった、各ポーリング・ノードでLogicalDeletePollingStrategyまたはDeletePollingStrategyと一意のMarkReservedValueを使用し、MaxTransactionSizeを設定する方法は使用できなくなりました。以前にこのアプローチを使用していた場合は、MarkReservedValueを(db.jcaで)削除するか、または(ウィザードの「論理削除」ページで)消去するだけです。それによってロックが自動的にスキップされるようになります。

予約された値に対してロックのスキップを使用することには、次のような利点があります。

- ロックをスキップすると、クラスタにおいて、また負荷がかかっている状態で、スケーリングが向上します。

- (更新/予約→コミットを行ってから新しいトランザクションで選択するのとは反対に)すべての作業が1つのトランザクションで行われるため、高可用性環境でリカバリ不能な状況に直面するリスクが最小に抑えられます。

- 一意のMarkReservedValueを指定する必要がありません。以前は、そのようにするためには、R${weblogic.Name-2}-${IP-2}-${instance}のように、複雑な変数を構成することが必要でした。

論理削除ポーリングを使用していて、MarkReservedValueを設定している場合は、ロックのスキップは使用されません。

以前は、複数のOracle BPEL Process ManagerノードまたはOracle Mediatorノードにデプロイする複数のOracleデータベース・アダプタ・プロセス・インスタンスにおける最善の手法は、基本的に、ポーリング・ノードごとに一意のMarkReservedValueを設定し、さらにMaxTransactionSizeを設定して、LogicalDeletePollingStrategyまたはDeletePollingStrategyを使用することでした。

詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のスケーラビリティとポーリング計画に関する項を参照してください。

10.2.18 高可用性を実現するためのB2B構成の更新

ファイル、FTPまたは電子メールのトランスポートを高可用性環境で設定するには、b2b.HAInstanceName unique_instance_nameを使用して、各インスタンスの一意の名前を指定します。値にServerNameを使用すると、Oracle B2Bは、HAInstanceNameとしてWebLogic Server名を取得します。

一意の名前を指定する手順は次のとおりです。

1. 第8.4.1項「SOAHOST1での管理サーバー用boot.propertiesの作成」で指定したユーザー名とパスワードを使用してOracle Enterprise Manager Fusion Middleware Controlにログインします。

2. 左側のナビゲーション・ツリーで「Farm_<domain_name>」→「SOA」を展開し、「soa-infra<server_name>」を右クリックし、「SOA管理」→「B2Bサーバー・プロパティ」を選択します。

3. 右側の「詳細B2B構成プロパティ」をクリックします。

4. b2b MBeanをクリックします。

5. 「操作」タブをクリックします。

6. 右側のリストの「addProperty」をクリックします。

7. 「キー」フィールドに「b2b.HAInstanceName」を入力します。

8. 値フィールドに「#ServerName#」を入力します。
この値は2つのサーバーのうち1つにのみ入力します。

9. 「起動」をクリックします。

10.3 オプション2: Oracle BPMを追加するためのSOAドメインの拡張

この手順では、第9章「SOAコンポーネントを使用するためのドメインの拡張」で作成したドメインを、Oracle BPMを扱うことができるように拡張します。

Oracle BPMを追加するためのSOAドメイン拡張の前提条件

現在のドメインを拡張する前に、既存のデプロイメントが次の前提条件を満たしていることを確認します。

- インストールのバックアップ - 既存のFusion Middlewareホームとドメインをバックアップしていない場合は、今すぐバックアップすることをお薦めします。
既存のFusion Middlewareホームおよびドメインをバックアップする手順は次のとおりです。

tar -cvpf fmwhomeback.tar MW_HOME
tar -cvpf domainhomeback.tar ASERVER_HOME

これらのコマンドにより、Oracle WebLogic ServerとOracle Fusion Middlewareの両方のインストール・ファイルのバックアップ、およびドメイン構成が作成されます。

- 前の章でインストールしたWL_HOMEおよびSOA ORACLE_HOME (バイナリ)が共有記憶域にあり、SOAHOST1およびSOAHOST2からアクセスできること(WebLogic構成ウィザードの手順を実行してドメインを拡張する前にこのようになっている必要があります)。

- ノード・マネージャ、管理サーバー、SOAサーバーおよびWSMサーバーが存在し、前の章の説明のように、SOAシステムを実行するように構成されていること。サーバー移行、トランザクション・ログ、Coherenceなど、SOAシステムのすべての構成手順はすでに実行されているので、BPMで使用されます。BPMは、既存の構成のスーパーセットとして追加されます。

この項には次のトピックが含まれます:

- 第10.3.1項「SOAHOST1での構成ウィザードを使用したBPMを追加するためのSOAドメインの拡張」

- 第10.3.2項「SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播」

- 第10.3.3項「BPM Suiteコンポーネントの起動」

- 第10.3.4項「WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成」

- 第10.3.5項「Oracle HTTP Serverを介したアクセスの検証」

10.3.1 SOAHOST1での構成ウィザードを使用したBPMを追加するためのSOAドメインの拡張

SOAホーム・ディレクトリで構成ウィザードを実行して、管理サーバーとOracle Web Services Managerを持つドメインを拡張し、SOAおよびBPMのコンポーネントをサポートするようにします。

1. ディレクトリを構成ウィザードの場所に変更します。これはSOAホーム・ディレクトリ内にあります。ドメインの拡張は、管理サーバーが存在するノードから実行します。

cd ORACLE_COMMON_HOME/common/bin

2. Oracle Fusion Middleware構成ウィザードを開始します。

./config.sh

3. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

4. WebLogicドメイン・ディレクトリ画面で、WebLogicドメイン・ディレクトリORACLE_BASE/admin/domain_name/aserver/domain_nameを選択し、「次へ」をクリックします。

5. 「拡張ソースの選択」画面で、次の手順を実行します。

- 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。次の製品を選択します。

- 次の製品を選択します。

- Oracle BPM Suite - 11.1.1.0 [soa]

6. 「JDBCコンポーネント・スキーマの構成」画面に入力されている値(既存のSOAシステムで作成されたスキーマ)を受け入れて、「次へ」をクリックします。
Oracle BPMでは、既存のsoa-infraシステムと同じデータ・ソースが使用されます。

7. オプションの構成の画面で、次の項目を選択します。

- JMS分散宛先

- デプロイメントとサービス

「次へ」をクリックします。

8. 「JMS分散宛先タイプの選択」画面で、BPMJMSModuleのドロップダウン・リストから「UDD」を選択します。既存のモジュールはそのままにします。

9. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- WSM-PMはWSM-PM_Clusterにのみターゲット設定します。

- usermessagingserverおよびusermessagingdriver-emailは、SOA_Clusterにのみターゲット設定します。(usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです。)

- oracle.sdp.*、oracle.bpm.*およびoracle.soa.*ライブラリは、SOA_Clusterにのみターゲット設定します。

- oracle.rules.*ライブラリは、SOA_Clusterおよび管理サーバーにターゲット設定します。

「次へ」をクリックします。

アプリケーションとリソースのターゲット設定の詳細は、付録B「アプリケーションとリソースのサーバーへのターゲット設定」を参照してください。

10. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、mds-owsmデータソースをWSM-PM_ClusterおよびAdminServerにターゲット設定し、「次へ」をクリックします。

11. 「JMSファイル・ストアの構成」画面で、第4.3項「異なるディレクトリの推奨場所」でお薦めしているように、JMSストアに指定した共有ディレクトリの場所を入力します。例:

ASERVER_HOME/soa_cluster_name/jms

すべてのストアに対してDirect-writeポリシーを選択します。

「次へ」をクリックします。

12. 「構成のサマリ」画面で、「拡張」をクリックします。

13. 「ドメインの作成中」画面で、「完了」をクリックします。
この構成を有効にするには、管理サーバーを再起動する必要があります。管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

10.3.2 SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播

Oracle BPM Suiteでは、WebLogic Serverの起動スクリプトに多少の更新が必要です。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。

注意:

解凍前にサーバー移行を構成すると(BPMが含まれるようにドメインを拡張すると)、wlsifconfigスクリプトは上書きされるため、-overwriteオプションが提供するコピーからリストアする必要があります。

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播するには:

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのバックアップ・コピーを作成します。

2. SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ASERVER_HOME
-template=soadomaintemplateExtSOABPM.jar
-template_name=soa_domain_templateExtSOABPM

3. SOAHOST1でunpackコマンドを実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

./unpack.sh -domain=MSERVER_HOME
-overwrite_domain=true -template=soadomaintemplateExtSOABPM.jar
-app_dir=MSERVER_HOME/applications

注意:

unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

4. テンプレートをSOAHOST2にコピーします。

cd ORACLE_COMMON_HOME/common/bin

scp soadomaintemplateExtSOABPM.jar oracle@SOAHOST2:/ORACLE_HOME/common/bin

5. unpackコマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME/DOMAIN_NAME -overwrite_domain=true
-template=soadomaintemplateExtSOABPM.jar -app_dir=MSERVER_HOME/applications

注意:

このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。

10.3.3 BPM Suiteコンポーネントの起動

構成変更および起動スクリプトを有効にするには、BPMが追加されたWLS_SOAnサーバーを再起動する必要があります。BPMでは既存のSOAシステムが拡張されているので、管理サーバーおよびそれぞれのノード・マネージャはSOAHOST1およびSOAHOST2で稼働しています。

追加されたBPMコンポーネントを起動するには:

1. WLS_SOA1管理対象サーバーを再起動します。

1. 次の場所にあるOracle WebLogic Server管理コンソールにログインします。
http://ADMINVHN:7001/console

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。
「サーバーの概要」ページが表示されます。

3. 「制御」タブをクリックします。

4. 表の「サーバー」列から「WLS_SOA1」を選択します。

5. 「停止」をクリックします。停止が完了するのを待ちます(WebLogic Serverコンソールのページを更新して、ステータスが「停止」になったことを確認します)。

6. 「起動」をクリックします。

2. WLS_SOA2に対して手順aからfを繰り返します。

10.3.4 WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成

WLS_SOAn管理対象サーバーが属するSOA_ClusterにOracle HTTP Serverからルーティングできるようにするには、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。

Oracle HTTP ServerでSOA_Clusterへのルーティングを有効化する手順は次のとおりです。

1. WEBHOST1およびWEBHOST2上で、次のディレクトリにあるsoa.vh.confファイルにディレクティブを追加します。

ORACLE_INSTANCE/config/OHS/component_name/moduleconf

<VirtualHost>タグ内に、次のディレクティブを追加します。

# BPM
<Location /bpm/composer>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# BPM
<Location /bpm/workspace>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

soa_vh.confファイルは、例10-1のように表示されます。

2. WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

WEBHOST1> ORACLE_INSTANCE/bin/opmnctl restartproc ias-component=ohs1
WEBHOST2> ORACLE_INSTANCE/bin/opmnctl restartproc ias-component=ohs2

10.3.5 Oracle HTTP Serverを介したアクセスの検証

SOA_Clusterのクラスタ・アドレスは前の章で設定済なので、Oracle HTTP ServerがBPMコンテキストURLをWebLogicサーバーにルーティングするよう構成してからでないと、BPMシステムは検証できません。URLを検証して、HTTP ServerからBPM Suiteコンポーネントへのルーティングとフェイルオーバーが適切に機能することを確認します。

ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。

URLを検証する手順は次のとおりです。

1. WLS_SOA2が稼動している状態で、Oracle WebLogic Server管理コンソールを使用してWLS_SOA1を停止します。

2. WebHost1:7777/bpm/composerおよびWebHost1:7777/bpm/workspaceにアクセスして、BPMプロジェクト・コンポーザが正常に機能していることを確認します。

3. Oracle WebLogic Server管理コンソールでWLS_SOA1を起動します。

4. Oracle WebLogic Server管理コンソールでWLS_SOA2を停止します。

5. WebHost1:7777/bpm/composerおよびWebHost1:7777/bpm/workspaceにアクセスして、BPMワークスペースが正常に機能していることを確認します。

これらのURLは、ロード・バランサ・アドレスを使用して確認することもできます。

- http://soa.mycompany.com:80/bpm/composer

- http://soa.mycompany.com:80/bpm/workspace

10.4 Oracle BPM構成のバックアップ

拡張したドメインが正常に動作していることを確認した後、そのドメイン構成をバックアップします。このバックアップは、この後の手順でエラーが発生した場合にすぐにリストアできるようにすることが目的です。構成をローカル・ディスクにバックアップします。エンタープライズ・デプロイメントが完了すれば、このバックアップは破棄してかまいません。エンタープライズ・デプロイメントが完了すれば、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。情報のリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。

ドメイン構成をバックアップする手順は次のとおりです。

1. Web層をバックアップする手順は次のとおりです。

1. opmnctlを使用してインスタンスを停止します。

ORACLE_INSTANCE/bin/opmnctl stopall

2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

3. 次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance.tar ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

ORACLE_INSTANCE/bin/opmnctl startall

2. データベースをバックアップします。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。

3. 管理サーバーのドメイン・ディレクトリをバックアップしてドメイン構成を保存します。構成ファイルは次のディレクトリにあります。

ASERVER_HOME

管理サーバーをバックアップするには、SOAHOST1で次のコマンドを実行します。

tar -cvpf edgdomainback.tar ASERVER_HOME

注意:

ORACLE_HOMEのバックアップは、B2B設定の一部であるXEngine構成が変更されたときに実行する必要があります。これらのファイルは、次のディレクトリにあります。

ORACLE_HOME/soa/thirdparty/edifecs/XEngine

ORACLE_HOMEをバックアップする手順は次のとおりです。

tar -cvpf fmwhomeback.tar MW_HOME

11 Oracle Service Busを追加するためのSOAドメインの拡張

この章では、Oracle Service Busを追加するためのドメイン拡張の手順を説明します。

この章の項目は次のとおりです。

- 第11.1項「SOAドメインへのOracle Service Busの追加の概要」

- 第11.2項「SOAHOST1でのVIP5およびSOAHOST2でのVIP6の有効化」

- 第11.3項「SOAHOST1での構成ウィザードを使用したOracle Service Busを追加するためのSOAドメインの拡張」

- 第11.4項「WLS_OSBn管理対象サーバーに対するホスト名検証の無効化」

- 第11.5項「Oracle Service Busの結果キャッシュのOracle Coherenceの構成」

- 第11.6項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」

- 第11.7項「SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播」

- 第11.8項「Oracle Service Busサーバーの起動」

- 第11.9項「WLS_OSB管理対象サーバーの検証」

- 第11.10項「WLS_OSBn管理対象サーバーについてのOracle HTTP Serverの構成」

- 第11.11項「OSB_Clusterに対するフロントエンドHTTPのホストおよびポートの設定」

- 第11.12項「Oracle HTTP Serverを使用したアクセスの検証」

- 第11.13項「Oracle DB、ファイルおよびFTPのアダプタの高可用性化」

- 第11.14項「WLS_OSBサーバーのサーバー移行の構成」

- 第11.15項「Oracle Service Bus構成のバックアップ」

11.1 SOAドメインへのOracle Service Busの追加の概要

この項では、SOAドメインへのOracle Service Busの追加について概説します。表11-1は、Oracle Service Busを使用するためのSOAドメイン拡張の大まかな手順と説明を示しています。

表11-1 Oracle Service Busを追加するためのSOAドメインの拡張手順

手順

説明

詳細

SOAHOST1でのVIP5およびSOAHOST2でのVIP6の有効化

2つのSOAマシン上でこれらの各ホスト名の仮想IPマッピングを有効化します。

第11.2項「SOAHOST1でのVIP5およびSOAHOST2でのVIP6の有効化」

ドメイン拡張のための構成ウィザードの実行

Oracle Service Busコンポーネントを追加するためにSOAドメイン拡張します

第11.3項「SOAHOST1での構成ウィザードを使用したOracle Service Busを追加するためのSOAドメインの拡張」

WLS_OSBn管理対象サーバーに対するホスト名検証の無効化

管理サーバー、管理対象サーバーおよびノード・マネージャの間のホスト名を検証するための適切な証明書を設定していない場合、ホスト名検証を無効化します。

第11.4項「WLS_OSBn管理対象サーバーに対するホスト名検証の無効化」

Oracle Service Busの結果キャッシュのOracle Coherenceの構成

Oracle Service Busの結果キャッシュでユニキャスト通信を使用します。

第11.5項「Oracle Service Busの結果キャッシュのOracle Coherenceの構成」

トランザクション・リカバリのためのデフォルトの永続ストアの構成

クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセスできる場所にトランザクション・ログを格納します。

第11.6項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」

SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播

Oracle Service Busでは、WebLogic Serverの起動スクリプトに多少の更新が必要です。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。

第11.7項「SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播」

Oracle Service Busサーバーの起動

Oracle Service Busサーバーは既存のドメインを拡張します。そのため、管理サーバーおよびそれぞれのノード・マネージャはSOAHOST1およびSOAHOST2で稼働しています。

第11.8項「Oracle Service Busサーバーの起動」

WLS_OSB管理対象サーバーの検証

管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認し、URLにアクセスしてサーバーのステータスを確認します。

第11.9項「WLS_OSB管理対象サーバーの検証」

WLS_OSBn管理対象サーバーについてのOracle HTTP Serverの構成

Oracle Service BusコンソールおよびOracle Service BusサービスにOracle HTTP Serverからルーティングできるようにするため、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。

第11.10項「WLS_OSBn管理対象サーバーについてのOracle HTTP Serverの構成」

OSB_Clusterに対するフロントエンドHTTPのホストおよびポートの設定

Oracle WebLogic Serverクラスタに対してフロントエンドHTTPのホストとポートを設定します。

第11.11項「OSB_Clusterに対するフロントエンドHTTPのホストおよびポートの設定」

Oracle HTTP Serverを介したアクセスの検証

サーバーのステータスが「実行中」であることを確認します。

第11.12項「Oracle HTTP Serverを使用したアクセスの検証」

OracleファイルとFTPアダプタの高可用性化

OracleファイルとFTPアダプタのアウトバウンド操作に対する高可用性を、データベースのmutexロック操作を使用して実現します。

第11.13項「Oracle DB、ファイルおよびFTPのアダプタの高可用性化」

WLS_OSBサーバーのサーバー移行の構成

Oracle Service Busシステムの高可用性アーキテクチャでは、一部のシングルトン・サービスを障害から保護するためにサーバー移行を利用します。

第11.14項「WLS_OSBサーバーのサーバー移行の構成」

11.1.1 Oracle Service Busを追加するためのSOAドメインの拡張の前提条件

現在のドメインを拡張する前に、既存のデプロイメントが次の前提条件を満たしていることを確認します。

- インストールのバックアップ - 既存のFusion Middlewareホームとドメインをバックアップしていない場合は、今すぐバックアップすることをお薦めします。
既存のFusion Middlewareホームおよびドメインをバックアップするには、次のコマンドをSOAHOST1で実行します。

tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw
tar -cvpf domainhomeback.tar ORACLE_BASE/admin/domain_name/aserver/domain_name

これらのコマンドにより、Oracle WebLogic ServerとOracle Fusion Middlewareの両方のインストール・ファイルのバックアップ、およびドメイン構成が作成されます。

- WL_HOMEとMW_HOME (バイナリ)が共有記憶域にインストールされており、SOAHOST1とSOAHOST2からアクセスできます。

- 前の章の説明のとおり、SOAシステムを実行するために、ノード・マネージャ、管理サーバー、SOAサーバーおよびWSMサーバーがすでに構成されています。サーバー移行、トランザクション・ログ、一貫性など、SOAシステムのその他のすべての構成手順が完了しています。

11.2 SOAHOST1でのVIP5およびSOAHOST2でのVIP6の有効化

SOAドメインは、Oracle Service Bus管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのSOAマシンでそれぞれのホスト名の仮想IPマッピングを有効にして(SOAHOST1上のVIP5およびSOAHOST2上のVIP6)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバー、ホスト解決のいずれかで)正しく解決します。

仮想IPを有効にするには、第3.5項「管理サーバーの仮想IPアドレスの有効化」で説明している手順に従ってください。これらの仮想IPおよびVHNは、Oracle Service Busサーバーのサーバー移行を有効にするために必要です。Oracle Service Busクラスタで高可用性を実現するために、サーバー移行を構成する必要があります。Oracle Service Busサーバーのサーバー移行の構成の詳細は、第9章「サーバー移行」を参照してください。

11.3 SOAHOST1での構成ウィザードを使用したOracle Service Busを追加するためのSOAドメインの拡張

この手順では、第9項「SOAコンポーネントを使用するためのドメインの拡張」で作成したドメインを、Oracle Service Busを扱うことができるように拡張します。Oracle Service Busを追加して管理サーバーとWSM-PMクラスタのみを含むドメインを拡張する場合の手順は、この項で説明する手順とほぼ同じになりますが、画面に表示される一部のオプション、ライブラリ、コンポーネントは実際に表示されるものと異なる場合があります。

Oracle Service Busを使用するためのドメイン拡張手順は次のとおりです。

1. ディレクトリを構成ウィザードの場所に変更します。これはOracle Service Busディレクトリ内にあります。(すべてのデータベース・インスタンスを稼働しておく必要があります。)

cd ORACLE_COMMON_HOME/common/bin

2. 構成ウィザードを起動します。

./config.sh

3. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

4. 「WebLogicドメイン・ディレクトリ」画面で、WebLogicドメイン・ディレクトリを選択します。

ORACLE_BASE/admin/domain_name/aserver/domain_name

「次へ」をクリックします。

5. 「拡張ソースの選択」画面で、「次の追加製品をサポートするために、自動的にドメインを拡張する」を選択して、次の製品を選択します(Oracle SOAおよびOracle WSM Policy Managerで必要となるコンポーネントはすでに選択されてグレー表示になっています)。

- Oracle Service Bus OWSM Extension - 11.1.1.6 [osb]

- Oracle Service Bus - 11.1.1.0 [osb]

- WebLogic Advance Web Services JAX-RPC Extension

6. 「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。

- OSB JMSレポート・プロバイダ・スキーマを選択します。

- 「コンポーネント・スキーマのOracle RAC構成」については、「GridLinkへ変換」を選択します。

「次へ」をクリックします。「GridLink RACコンポーネント・スキーマの構成」画面が表示されます。

7. 「GridLink RACコンポーネント・スキーマの構成」画面で、ドメイン内にすでに存在するデータ・ソースに対する値を受け入れ、「次へ」をクリックします。

8. 「JDBCコンポーネント・スキーマのテスト」画面で、Oracle Service Bus JMSレポート・データ・ソースが正常に検証されたことを確認し、「次へ」をクリックします。

9. 「オプションの構成を選択」画面で、次を選択します。

- JMS分散宛先

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

- JMSファイル・ストア

「次へ」をクリックします。

10. 「JMS分散宛先タイプの選択」画面で、すでに存在するJMSシステム・リソースはそのままにしておき、WseeJMSMOduleおよびJmsResourcesにはドロップダウン・リストからUDDを選択します。
「次へ」をクリックします。

11. 「管理対象サーバーの構成」画面で、Oracle Service Busで必要な管理対象サーバーを追加します。

1. 自動的に作成されたサーバーを選択し、「名前の変更」をクリックして、名前をWLS_OSB1に変更します。

2. 「追加」をクリックし他の新規サーバーを追加して、サーバー名としてWLS_OSB2と入力します。

3. WLS_OSB1およびWLS_OSB2サーバーに、表11-2内の属性を指定します。

最終的に、管理対象サーバーのリストは表11-2と一致する必要があります。

「次へ」をクリックします。

- 表11-2 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_SOA1(*)

SOAHOST1VHN1

8001

なし

いいえ

WLS_SOA2(*)

SOAHOST2VHN1

8001

なし

いいえ

WLS_WSM1

SOAHOST1

7010

なし

いいえ

WLS_WSM2

SOAHOST2

7010

なし

いいえ

WLS_OSB1

SOAHOST1VHN2

8011

なし

いいえ

WLS_OSB2

SOAHOST2VHN2

8011

なし

いいえ

12. 「クラスタの構成」画面で、Oracle Service Busクラスタを追加します(既存のクラスタはそのままにしておきます)。

表11-3 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

SOA_Cluster(*)

ユニキャスト

なし

なし

SOAHOST1VHN1:8001、SOAHOST2VHN1:8001

WSM-PM_Cluster

ユニキャスト

なし

なし

空白

OSB_Cluster

ユニキャスト

なし

なし

SOAHOST1VHN2:8011、SOAHOST2VHN2:8011

(*) - SOAドメインを拡張する場合

「次へ」をクリックします。

注意:

直接バインディングを介してリクエスト/レスポンスが非同期でやり取りされるようにするため、SOAコンポジットでは、JNDIプロバイダURLを提供して、呼び出されたサービスが、コールバックするBeanを検索できるようにする必要があります。

soa-infraの構成プロパティは指定されていないがWebLogic Serverクラスタ・アドレスが指定されている場合は、JNDIプロバイダURLのクラスタ・アドレスが使用されます。このクラスタ・アドレスには、クラスタ化されたサーバーのIPアドレスにマップする単一のDNS名を指定することも、サーバーip:portのカンマ区切りリストを指定することもできます。また、ユーザーが明示的に設定していれば、soa-infraの構成プロパティJndiProviderURL/SecureJndiProviderURLを同じ目的に使用することもできます。

13. 「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。

- SOA_Cluster - SOAドメインを拡張する場合

- WLS_SOA1

- WLS_SOA2

- WSM-PM_Cluster

- WLS_WSM1

- WLS_WSM2

- OSB_Cluster

- WLS_OSB1

- WLS_OSB2

「次へ」をクリックします。

14. 次のエントリが表示されることを確認します。

表11-4 マシン

名前

ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINHOST

localhost

他のフィールドはすべてデフォルト値のままにします。

「次へ」をクリックします。

15. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- ADMINHOST:

- AdminServer

- SOAHOST1

- WLS_SOA1 (SOAドメインを拡張する場合)

- WLS_WSM1

- WLS_OSB1

- SOAHOST2:

- WLS_SOA2 (SOAドメインを拡張する場合)

- WLS_WSM2

- WLS_OSB2

「次へ」をクリックします。

16. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- usermessagingserverおよびusermessagingdriver-emailは、SOA_Clusterにのみターゲット設定します。(usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです。)

- oracle.sdp.*およびoracle.soa.*ライブラリは、SOA_Clusterにのみターゲット設定します。

- oracle.rules.*ライブラリは、AdminServerおよびSOA_Clusterにのみターゲット設定します。

- wsm-pmアプリケーションは、WSM-PM_Clusterにのみターゲット設定します。

- すべてのトランスポート・プロバイダのデプロイメントを、OSB_ClusterおよびAdminServerの両方にターゲット設定します。

「次へ」をクリックします。

アプリケーションとリソースのターゲット設定の詳細は、付録B「アプリケーションとリソースのサーバーへのターゲット設定」を参照してください。

17. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次の設定をします。

- mds-owsmをWSM-PM_ClusterおよびAdminServerに対してのみターゲット設定します。

- mds-soaをSOA_Clusterに対してのみターゲット設定します。

「次へ」をクリックします。

18. 「JMSファイル・ストアの構成」画面で、第4.3項「異なるディレクトリの推奨場所」でお薦めしているように、JMSストアに指定した共有ディレクトリの場所を入力します。例:

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

すべてのストアに対してDirect-writeポリシーを選択します。

「次へ」をクリックします。

19. 「構成のサマリ」画面で、「拡張」をクリックします。

20. 「ドメインの拡張」画面で、「完了」をクリックします。

21. この構成を有効にするには、管理サーバーを再起動します。

11.4 WLS_OSBn管理対象サーバーに対するホスト名検証の無効化

このガイドで説明するエンタープライズ・デプロイメントでは、Oracle SOA Suiteを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。WLS_OSB1およびWLS_OSB2管理対象サーバーのホスト名検証を無効化して、様々なWebLogic Serverインスタンスを管理するときにエラーが出ないようにします。詳細は、第8.4.8項「ホスト名検証の無効化」を参照してください。

エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第13.3項「SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。

11.5 Oracle Service Busの結果キャッシュのOracle Coherenceの構成

デフォルトで、結果のキャッシュではマルチキャスト通信が使用されます。Oracle Service Busの結果キャッシュでは、ユニキャスト通信を使用することをお薦めします。また、異なる製品で使用するCoherenceクラスタのポート範囲を分離することをお薦めします。Oracle Service Busの結果キャッシュのCoherenceクラスタに対するポートは、SOAに対して使用されるCoherenceクラスタと異なっている必要があります。

Oracle Service Busの結果キャッシュのCoherenceインフラストラクチャに対してユニキャストを有効にするには、次の手順を実行します。

1. Oracle WebLogic Server管理コンソールにログインします。「チェンジ・センター」で、「 ロックして編集 」をクリックします。

2. 「ドメイン構造」ウィンドウで、「 環境 」ノードを開きます。

3. 「サーバー」をクリックします。

4. 表の「 名前 」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの「設定」ページが表示されます。

5. 「Server Start」タブをクリックします。

6. WLS_OSB1の「引数」フィールドに、次の内容を1行で入力します(改行は入れません)。

-DOSB.coherence.localhost=soahost1vhn2 -DOSB.coherence.localport=7890
-DOSB.coherence.wka1=soahost1vhn2 -DOSB.coherence.wka1.port=7890
-DOSB.coherence.wka2=soahost2vhn2 -DOSB.coherence.wka2.port=7890

WLS_OSB2には、次の1行を入力します(改行は入れません)。

-DOSB.coherence.localhost=soahost2vhn2 -DOSB.coherence.localport=7890
-DOSB.coherence.wka1=soahost1vhn2 -DOSB.coherence.wka1.port=7890
-DOSB.coherence.wka2=soahost2vhn2 -DOSB.coherence.wka2.port=7890

注意:

異なる -D パラメータの間には、空白の行を入れないでください。テキストは、前述の場所からコピーして管理コンソールの引数テキスト・フィールドに貼り付けないでください。貼り付けると、Java引数にHTMLタグが挿入される可能性があります。このテキストには、前述の例に含まれているテキスト文字以外の文字を入れないでください。

7. 変更を保存してアクティブ化します。これらの変更を有効にするには、Oracle Service Busサーバー再起動する必要があります。

注意:

Oracle Service Busの結果キャッシュに使用するCoherenceクラスタは、前述のとおりポート7890を使用して構成されます。このポートは、次の起動パラメータで別のポート(8089など)を指定することで変更できます。

-Dtangosol.coherence.wkan.port
-Dtangosol.coherence.localport

Coherenceクラスタの詳細は、『Oracle Coherence開発者ガイド』を参照してください。

8. これらの変数が管理対象サーバーに正しく渡されていることを、サーバーの出力ログで確認します。
Oracle Coherenceフレームワークに問題があると、結果のキャッシュが機能しなくなる可能性があります。

11.6 トランザクション・リカバリのためのデフォルトの永続ストアの構成

各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。WebLogic Serverでは、システム・クラッシュやネットワーク障害からのリカバリ時にこのトランザクション・ログを使用します。クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセスできる場所にトランザクション・ログを格納します。

注意:

お薦めする場所は、デュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)です。

デフォルトの永続ストアの場所を設定する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」ノードをクリックします。
「サーバーの概要」ページが表示されます。

3. 表の「名前」列にあるサーバーの名前(ハイパーリンクとして表示されています)をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

4. 「サービス」タブをクリックします。

5. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
パスのディレクトリ構造は次のとおりです。

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

6. WLS_OSB1サーバーとWLS_OSB2サーバーの両方で、手順2から5を実行します。

7. 「保存」、「変更のアクティブ化」をクリックします。

注意:

トランザクション・リカバリ・サービスの移行を有効にするには、クラスタにある他のサーバーが使用できる永続記憶域ソリューションの場所を指定します。WLS_OSB1とWLS_OSB2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。

11.7 SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播

Oracle Service Busでは、WebLogic Serverの起動スクリプトに多少の更新が必要です。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。

注意:

解凍前にサーバー移行を構成すると(OSBが含まれるようにドメインを拡張すると)、wlsifconfigスクリプトは上書きされるため、-overwriteオプションが提供するコピーからリストアする必要があります。

前提条件

管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのバックアップ・コピーを作成します。

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播するには:

1. SOAHOST1で pack コマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/
domain_name/aserver/domain_name -template=soadomaintemplateExtOSB.jar
-template_name=soa_domain_templateExtOSB

2. SOAHOST1でunpackコマンドを実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
-overwrite_domain=true -template=soadomaintemplateExtOSB.jar
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

注意:

unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

3. テンプレートをSOAHOST2にコピーするには、次のコマンドをSOAHOST1で実行します。

cd ORACLE_COMMON_HOME/common/bin

scp soadomaintemplateExtOSB.jar oracle@SOAHOST2:/ ORACLE_COMMON_HOME/common/bin

4. unpackコマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name/ -overwrite_domain=true
-template=soadomaintemplateExtOSB.jar -app_dir=ORACLE_BASE/admin/
domain_name/mserver/applications

注意:

このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。

11.8 Oracle Service Busサーバーの起動

Oracle Service Busでは既存のドメインが拡張されているので、管理サーバーおよびそれぞれのノード・マネージャがSOAHOST1およびSOAHOST2で稼働していると想定します。

追加したWLS_OSBサーバーを起動する手順は次のとおりです。

1. 次の場所にあるOracle WebLogic Server管理コンソールにログインします。

http://ADMINVHN:7001/console

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。
「サーバーの概要」ページが表示されます。

3. 「Control」タブをクリックします。

4. 表の「サーバー」列から「WLS_OSB1」を選択します。

5. 「起動」をクリックします。サーバーが起動するのを待ち、管理コンソールでステータスが「実行中」であることを確認します。

6. WLS_OSB2について手順2から5を繰り返します。

11.9 WLS_OSB管理対象サーバーの検証

Oracle WebLogic Server管理コンソールを使用し、URLにアクセスして、管理対象サーバーWLS_OSBを検証します。

WLS_OSB管理対象サーバーを検証する手順は次のとおりです。

1. 管理コンソールに表示されるサーバーのステータスが「 実行中 」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.14項「エンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。

2. 次のURLにアクセスして、WLS_OSB1のステータスを確認します。

http://SOAHOST1VHN2:8011/sbinspection.wsil

デフォルトのインストールでは、これはHTTPレスポンスです。

図11-1 HTTPレスポンス

3. 次のURLにアクセスします。

http://SOAHOST1VHN2:8011/alsb/ws/_async/AsyncResponseServiceJms?WSDL

デフォルトのインストールでは、これはHTTPレスポンスです。

図11-2 HTTPレスポンス

4. 同等URLにアクセスします。

http://SOAHOST2VHN2:8011/

5. 次のURLにアクセスし、Oracle Service Busコンソールから管理サーバーへのデプロイメントが適切であることを確認します。

http://ADMINHOSTVHN:7001/sbconsole/

Oracle Service Busコンソールがエラーなしで表示されます。

11.10 WLS_OSBn管理対象サーバーについてのOracle HTTP Serverの構成

Oracle Service BusコンソールおよびOracle Service BusサービスにOracle HTTP Serverからルーティングできるようにするため、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定する必要があります。

管理目的で仮想サーバーを使用する場合は、admin_vh.confファイルの仮想サーバーのコンテキストで、/sbconsoleによりルーティングを定義します。同様に、Oracle Service Busの残りのURLをosb_vh.confファイルに追加します。

/osb/project-name/folder-name/proxy-service-nameなどの共通名を使用して、HTTPプロキシ・サービスのコンテキスト・パスを開始し、Oracle HTTP Serverのすべてのプロキシ・サービスに対するルーティングを促進します。

パラメータを設定する手順は次のとおりです。

1. WEBHOST1およびWEBHOST2で、次のディレクトリにあるosb_vh.confファイルにディレクティブを追加します。

ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf

第7.6項 「仮想ホストの定義」の説明に従ってosb_vh.confファイルを作成しておく必要があります。

<VirtualHost>タグ内に、次のディレクティブを追加します。

<Location /sbinspection.wsil >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /sbresource >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /osb >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /alsb >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

osb_vh.confファイルは、例11-1のように表示されます。

2. 次のエントリをadmin_vh.confファイルの<VirtualHost>タグ内に追加します。

<Location /sbconsole >
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

admin_vh.confファイルは、例11-2のように表示されます。

3. WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2

例11-1 osb_vh.confファイル

<VirtualHost *:7777>
ServerName https://osb.mycompany.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

<Location /sbinspection.wsil >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /sbresource >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /osb >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /alsb >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
</VirtualHost>

例11-2 admin_vh.confファイル

# The admin URLs should only be accessible via the admin virtual host

<VirtualHost *:7777>
ServerName admin.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# Admin Server and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /em>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /sbconsole >
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
</VirtualHost>

11.11 OSB_Clusterに対するフロントエンドHTTPのホストおよびポートの設定

WebLogic Server管理コンソールを使用して、Oracle WebLogic Serverクラスタに対してフロントエンドHTTPのホストとポートを設定します。

フロントエンドのホストおよびポートを設定する手順は次のとおりです。

1. WebLogic Server管理コンソールの「チェンジ・センター」セクションの「ロックして編集」をクリックします。

2. 左側のペインで、「環境」→「クラスタ」を選択します。

3. 「OSB_Cluster」を選択します。

4. 「HTTP」を選択します。

5. 次の値を設定します。

- フロントエンド・ホスト: osb.mycompany.com

- フロントエンドHTTPポート: 80

- フロントエンドHTTPSポート: 443

注意:

このアドレスが正しく、使用可能である(ロード・バランシング・ルーターが稼働している)ことを確認してください。アドレスのhttp://やホスト名の末尾/など、値が誤っていると、仮想IPを使用してもSOAシステムにアクセスできません。

「保存」をクリックします。

6. 変更をアクティブにするには、管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。

11.12 Oracle HTTP Serverを使用したアクセスの検証

OSB_Clusterのクラスタ・アドレスをすでに設定しているため、Oracle Service BusコンテキストURLをWebLogic ServersにルーティングするようにOracle HTTP Serverを構成しておくだけで、Oracle Service BusのURLを検証できます。URLを検証して、HTTP ServerからOracle Service Busコンポーネントへのルーティングとフェイルオーバーが適切に機能することを確認します。

ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。

URLを検証する手順は次のとおりです。

1. WLS_OSB1が稼動している状態で、Oracle WebLogic Server管理コンソールを使用してWLS_OSB2を停止します。

2. WebHost1:7777/sbinspection.wsilにアクセスし、HTTPレスポンスが第11.9項「WLS_OSB管理対象サーバーの検証」のとおりであることを確認します。

3. Oracle WebLogic Server管理コンソールでWLS_OSB2を起動します。

4. Oracle WebLogic Server管理コンソールでWLS_OSB1を停止します。

5. WebHost1:7777/sbinspection.wsilにアクセスし、HTTPレスポンスが第11.9項「WLS_OSB管理対象サーバーの検証」のとおりであることを確認します。

注意:

OSB_ClusterにフロントエンドURLが設定されているため、URLへのリクエストはLBRへの再ルーティングになりますが、どのようなケースでも、Oracle HTTP Server内のマウント・ポイントおよびフェイルオーバーの検証には十分です。

6. ロード・バランサのアドレスを使用して、このURLを検証します。

http://osb.mycompany.com:80/sbinspection.wsil

11.13 Oracle DB、ファイルおよびFTPのアダプタの高可用性化

Oracle SOA SuiteとOracle Service Busは、同じデータベース、ファイルおよびFTP JCAアダプタを使用します。SOAでOracle Repository Creation Utilityを使用するときに、これらのアダプタに必要なデータベース・スキーマを作成します。アダプタに必要な構成は、第9.8.1項「OracleファイルとFTPアダプタの高可用性化」に記載されています。DBアダプタの構成は、WebLogic Serverのリソース・レベルでは必要ありません。SOAドメインの拡張としてOracle Service Busを構成する場合は、アダプタに対する構成はすでに行われているため構成に加える必要はありません。

Oracle Service Busを、WSM-PMおよび管理サーバーのドメインへの拡張としてデプロイする場合は、次の手順を実行します。

- RCUを実行し、Oracle Service Busデータベースに必要なアダプタ・スキーマをシードします(RCUで「SOAインフラストラクチャ」、「SOAおよびBAMインフラストラクチャ」を選択)。

- 第9.8.1項「OracleファイルとFTPのアダプタの高可用性化」の手順を実行します。

11.14 WLS_OSBサーバーのサーバー移行の構成

Oracle Service Busシステムの高可用性アーキテクチャでは、一部のシングルトン・サービスを障害から保護するためにサーバー移行を利用します。サーバー全体の移行の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

WLS_OSB1管理対象サーバーは、障害発生時にSOAHOST2で再起動するように構成され、WLS_OSB2管理対象サーバーは、障害発生時にSOAHOST1で再起動するように構成されます。このような構成では、WLS_OSB1サーバーおよびWLS_OSB2サーバーは、WLSサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。

表11-5は、WLS_OSBサーバーのサーバー移行を構成するための大まかな手順を示しています。

表11-5 WLS_OSBサーバーのサーバー移行の構成の手順

手順

説明

詳細

サーバー移行リース・テーブルのユーザーおよび表領域の設定

サーバー移行リース・テーブルのユーザーおよび表領域を設定します。

SOAの表領域がすでに設定されている場合、この手順は不要です。

第11.14.1項「サーバー移行リース・テーブルのユーザーと表領域の設定」

ノード・マネージャのプロパティ・ファイルの編集

サーバーが稼働している2つのノード上でノード・マネージャのプロパティ・ファイルを編集します。

第11.14.2項「ノード・マネージャのプロパティ・ファイルの編集」

wlsifconfig.shスクリプトの環境およびスーパーユーザー権限の設定

wlsifconfig.shスクリプトの環境およびスーパーユーザー権限を設定します。

第11.14.3項「wlsifconfig.shスクリプトの環境権限とスーパーユーザー権限の設定」

サーバー移行ターゲットの構成

クラスタの移行ターゲットを構成し、DataSourceForAutomaticMigrationプロパティをtrueに設定します。

第11.14.4項「サーバー移行ターゲットの構成」

サーバー移行の検証

サーバーの移行が適切に行われていることを確認します。

第11.14.5項「サーバー移行の検証」

11.14.1 サーバー移行leasing表のユーザーと表領域の設定

SQL*Plusを使用して、サーバー移行表のユーザーおよび表領域を設定します。

ユーザーと表領域を作成する手順は次のとおりです。

1. leasingという表領域を作成します。たとえば、sysdbaユーザーとしてSQL*Plusにログオンして次のコマンドを実行します。

SQL> create tablespace leasing
logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
size 32m autoextend on next 32m maxsize 2048m extent management local;

2. 次のように、leasingという名前のユーザーを作成し、leasing表領域に割り当てます。

SQL> create user leasing identified by password;
SQL> grant create table to leasing;
SQL> grant create session to leasing;
SQL> alter user leasing default tablespace leasing;
SQL> alter user leasing quota unlimited on LEASING;

3. 次のように、leasing.ddlスクリプトを使用してリース・テーブルを作成します。

1. 次のディレクトリにあるleasing.ddlファイルを、データベース・ノードにコピーします。

WL_HOME/server/db/oracle/920

2. データベースにleasingユーザーとして接続します。

3. 次のように、leasing.ddlスクリプトをSQL*Plusで実行します。

SQL> @copy_location/leasing.ddl;

11.14.2 ノード・マネージャのプロパティ・ファイルの編集

サーバーが稼働している2つのノード上でノード・マネージャのプロパティ・ファイルを編集します。nodemanager.propertiesファイルは次のディレクトリにあります。

WL_HOME/common/nodemanager

次のプロパティを追加してサーバー移行が正常に動作するようにします。

- Interface

Interface=eth0

このプロパティは浮動IP (eth0など)のインタフェース名を指定します。

注意:

eth0:1やeth0:2のようなサブ・インタフェースは指定しないでください。このインタフェースは、:0も:1も指定しないで使用します。ノード・マネージャのスクリプトは、:Xに対応した各種のIPを横断して、どれを追加または削除するかを判定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

- NetMask

NetMask=255.255.255.0

このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。

- UseMACBroadcast

UseMACBroadcast=true

このプロパティはARPパケットを送信する際にノードのMACアドレスを使用するかどうかを指定します。つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。

これらのプロパティが適用されていることをノード・マネージャの出力(ノード・マネージャが起動したシェル)で確認します。それ以外の場合、移行中に問題が発生する可能性があります。出力は次のようになります。

...
StateCheckInterval=500
Interface=eth0 (Linux) or Interface="Local Area Connection" (Windows)
NetMask=255.255.255.0
UseMACBroadcast=true
...

11.14.3 wlsifconfig.shスクリプトの環境権限とスーパーユーザー権限の設定

wlsifconfig.shスクリプトの環境およびスーパーユーザー権限を設定します。

環境およびスーパーユーザー権限を設定する手順は次のとおりです。

1. 表11-6に示すファイルをPATH環境変数で指定していることを確認します。

表11-6 PATH環境変数に必要なファイル

ファイル

ディレクトリの場所

wlsifconfig.sh

ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domain

WL_HOME/common/nodemanager

2. パスワードによる制限を設けずにsudo権限をWebLogicユーザー(oracle)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。
セキュリティ上の理由から、sudoは、wlsifconfig.shスクリプトの実行に必要なコマンド・セットに限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境およびスーパーユーザー権限の設定などです。

Windowsでは、このスクリプトの名前はwlsifconfig.cmdであり、管理者権限で実行できます。

注意:

この手順に適するsudo権限とシステム権限については、システム管理者に問い合せてください。

3. WebLogicユーザー(oracle)がこのスクリプトを実行できることを確認します。sudo実行権限をoracleおよびifconfigとarpingに付与するエントリを記述した/etc/sudoersの例を次に示します。
パスワードによる制限を設けずにsudo権限をWebLogicユーザー('oracle')に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

11.14.4 サーバー移行ターゲットの構成

DataSourceForAutomaticMigrationプロパティをtrueに設定することで、クラスタの移行を構成します。

クラスタ内の移行ターゲットを構成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」を開き、「クラスタ」を選択します。
「クラスタの概要」ページが表示されます。

3. 表の「名前」列で、移行を構成するクラスタ(OSB_Cluster)をクリックします。

4. 「移行」タブをクリックします。

5. 「チェンジ・センター」で、「ロックして編集」をクリックします。

6. 「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。この場合は、「SOAHOST1」と「SOAHOST2」を選択します。

7. 自動移行に使用するデータ・ソースを選択します。この場合は、リース・データソースを選択し、「保存」をクリックします。

8. 「変更のアクティブ化」をクリックします。

9. WLS_OSB1およびWLS_OSB2について、サーバー移行の候補となるマシンを設定します。
WLS_OSB1についてのみ、サーバー移行の候補となるマシンを設定します。WLS_OSB2では、サーバー移行を使用しません。再設定が必要です。OSBサーバーが同一なため、OSB1およびOSB2の両方に対して構成する必要があります。BAM1とBAM2は同一ではないため、BAMではこれを注意してきました。

1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。

2. 移行を構成するサーバーを選択します。

3. 「移行」タブをクリックします。

4. 「移行の構成」セクションの「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。WLS_OSB1には「SOAHOST2」を選択します。WLS_OSB2には「SOAHOST1」を選択します。

5. 「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。

6. 「変更のアクティブ化」をクリックします。

7. 管理サーバーとWLS_OSB1サーバーを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

アプリケーションとリソースのターゲット設定の詳細は、付録B「アプリケーションとリソースのサーバーへのターゲット設定」を参照してください。

11.14.5 サーバー移行の検証

サーバーの移行が適切に行われていることを確認する手順は次のとおりです。

ノード1からテストする手順は次のとおりです。

1. WLS_OSB1管理対象サーバーを強制停止します。

kill -9 pid

pidは、その管理対象サーバーのプロセスID (PID)を指定します。次のコマンドを実行すると、ノードのPIDを識別できます。

ps -ef | grep WLS_OSB1

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了できます。例:

taskkill /f /pid pid

pidは、管理対象サーバーのプロセスIDを表します。

WLS_OSB1管理対象サーバーのプロセスIDを確認する手順は次のとおりです。

MW_HOME\jrockit_160_20_D1.0.1-2124\bin\jps -l -v

2. ノード・マネージャのコンソールを確認します。WLS_OSB1の浮動IPが無効になっていることを示すメッセージが表示されています。

3. ノード・マネージャがWLS_OSB1の2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。

ノード2からテストする手順は次のとおりです。

1. ローカルのノード・マネージャ・コンソールを確認します。ノード1でのWLS_OSB1の再起動が前回試行されてから30秒間経過した後に、WLS_OSB1の浮動IPが表示され、サーバーをこのノードで再起動することを示すメッセージがノード2のノード・マネージャにより表示されます。

2. 同じIPのsbinspection.wsil urlconsoleにアクセスします。

WebLogic Server管理コンソールから移行を検証する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 左のコンソールで「ドメイン」をクリックします。

3. 「監視」タブをクリックし、「移行」タブをクリックします。
「移行の状態」の表に、移行の状態に関する情報が表示されます。

図11-3 管理コンソールの「移行の状態」画面

注意:

サーバーの移行後、そのサーバーを元のノードにフェイルバックするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

11.15 Oracle Service Bus構成のバックアップ

拡張したドメインが正常に動作していることを確認した後、そのドメイン構成をバックアップします。このバックアップは、この後の手順でエラーが発生した場合にすぐにリストアできるようにすることが目的です。構成をローカル・ディスクにバックアップします。エンタープライズ・デプロイメントが完了すれば、このバックアップは破棄してかまいません。エンタープライズ・デプロイメントが完了すれば、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。情報のリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。

ドメイン構成をバックアップする手順は次のとおりです。

1. Web層をバックアップする手順は次のとおりです。

1. opmnctlを使用してインスタンスを停止します。

ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

3. 次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance.tar ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

ORACLE_BASE/admin/instance_name/bin/opmnctl startall

2. データベースをバックアップします。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。

3. 管理サーバーのドメイン・ディレクトリをバックアップしてドメイン構成を保存します。構成ファイルは次のディレクトリにあります。

ORACLE_BASE/admin/domain_name

管理サーバーをバックアップする手順は次のとおりです。

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

12 BAMを追加するためのドメインの拡張

この章では、Oracle Business Activity Monitoring (BAM)を追加するためのドメイン拡張の手順を説明します。

この章の項目は次のとおりです。

- 第12.1項「ドメインへのBAMの追加の概要」

- 第12.3項「BAMHOST1でのVIP4の有効化」

- 第12.4項「構成ウィザードを使用したドメインの拡張」

- 第12.5項「トランザクション・リカバリ用デフォルト永続ストアの構成」

- 第12.6項「WLS_BAM2からのBAMサーバー・システムのターゲット設定の解除」

- 第12.7項「管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播」

- 第12.8項「WLS_BAMn管理対象サーバーに対するホスト名検証の無効化」

- 第12.9項「BAMHOST1およびBAMHOST2でのノード・マネージャの起動」

- 第12.10項「BAMシステムの起動」

- 第12.11項「GridLinkデータ・ソースの検証」

- 第12.12項「BAMHOST1でBAMサーバーを使用するためのBAM Webアプリケーションの構成」

- 第12.13項「WLS_BAMn管理対象サーバーについてのOracle HTTP Serverの構成」

- 第12.14項「Oracle HTTP Serverを介したアクセスの検証」

- 第12.15項「WLS_BAM1サーバーのサーバー移行の構成」

- 第12.16項「BAMクラスタ内のBAMコンポーネントへの構成変更の適用」

- 第12.17項「BAM構成のバックアップ」

12.1 ドメインへのBAMの追加の概要

BAMシステムは、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成された、共有記憶域上のWL_HOMEおよびORACLE_HOMEを使用してインストールされます。BAMHOST1およびBAMHOST2は、MW_HOMEをマウントして、既存のWLSおよびSOAのインストールを再利用します。packユーティリティおよびunpackユーティリティを使用して、この2つの新しいノードでWLS_BAM1サーバーおよびWLS_BAM2サーバーのドメイン構成をブートストラップします。この結果、各ノードにソフトウェアをインストールする必要がなくなります。BAMシステムが正常に機能するには、SOAHOST1およびSOAHOST2にOracle FMWをインストールするときに必要としたシステム構成と同一の構成をBAMHOST1およびBAMHOST2で保持しておく必要があります。このシステム構成がないと、バイナリの実行で予期しない動作が発生することがあります。

12.2 BAMを追加するためのドメイン拡張の前提条件

この項の手順を実行する前に、次の前提条件を確認してください。

既存インストールのバックアップ

既存のFusion Middlewareホームとドメインをバックアップしていない場合は、今すぐバックアップします。

既存のFusion Middlewareホームおよびドメインをバックアップする手順は次のとおりです。

tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw
tar -cvpf domainhomeback.tar ORACLE_BASE/admin/domain_name/aserver/domain_name

これらのコマンドにより、Oracle WebLogic ServerとOracle Fusion Middlewareの両方のインストール・ファイルのバックアップ、およびドメイン構成が作成されます。

BAMHOSTSのインベントリへの既存のOracleホームのアタッチ

新しいノード上に、既存のミドルウェア・ホーム(SOAインストールとドメイン・ディレクトリが存在する)をマウントします。ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認してください。

共有記憶域内のORACLE_HOMEをローカルのOracleインベントリにアタッチするには、BAMHOSTで次のコマンドを実行します。

cd ORACLE_COMMON_HOME/oui/bin/attachHome.sh
./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_version

ミドルウェア・ホーム・リストを更新するには、$HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合は、このファイルを編集)、MW_HOMEをこのファイルに追加します。

12.3 BAMHOST1でのVIP4の有効化

BAMシステムでは、BAMサーバー・コンポーネントをホストする管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。この仮想ホスト名とそれに対応する仮想IPは、BAMサーバー・コンポーネントでサーバー移行を有効にするときに必要となります。BAMHOST1で仮想IP (VIP4)のマッピングBAMHOST1VHN1を有効にして、トポロジ(DNSサーバーとホスト解決のいずれか)で使用されるネットワーク・システムでBAMHOST1VHN1ホスト名を正しく解決します。

仮想IPを有効にするには、第3.5項「管理サーバーの仮想IPアドレスの有効化」を参照してください。

BAMアダプタを使用したOracle BAM Serverへのアクセスについて

BAMアダプタ(rmi)を使用しOracle BAM Serverにアクセスする場合、接続にはBAMサーバー(BAMHOST1VNH1)の仮想ホスト名を使用する必要があります。SOAPリクエストはHTTPを介するため、アダプタを使用する場合はロード・バランサ・アドレスを使用します。

12.4 構成ウィザードを使用したドメインの拡張

この手順では、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを、BAMを扱うことができるように拡張します。この項の手順は、SOAのデプロイメントと同じデータベース・サービス(soaedg.mycompany.com)をBAMのデプロイメントでも使用することを前提としています。ただし、BAM専用の別のデータベース・サービスを使用することもできます。

1. ディレクトリを構成ウィザードの場所に変更します。これはSOAホーム・ディレクトリ内にあります。

cd ORACLE_COMMON_HOME/common/bin

2. 構成ウィザードを起動します。

./config.sh

3. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

4. 「WebLogicドメイン・ディレクトリ」画面で、次のWebLogicドメイン・ディレクトリを選択します。

ORACLE_BASE/admin/domain_name/aserver/domain_name

「次へ」をクリックします。

5. 「拡張ソースの選択」画面で、次の手順を実行します。

- 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

- 次の製品を選択します。

- Oracle Business Activity Monitoring 11.1.1.0

「次へ」をクリックします。

6. 「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。

- 「BAM Schema」を選択します。

- 「コンポーネント・スキーマのOracle RAC構成」については、「GridLinkへ変換」を選択します。

「次へ」をクリックします。

7. 「GridLink RACコンポーネント・スキーマの構成」画面が表示されます(図12-1)。

図12-1 「GridLink RACコンポーネント・スキーマの構成」画面

この画面で、次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: OracleのGridLinkConnections用ドライバ (Thin) バージョン: 10以上を選択します。

- サービス名: データベースのサービス名を、小文字で入力します。例:
soaedg.mycompany.com

- ユーザー名: 対応するコンポーネントのデータベース・スキーマ・オーナーの名前を入力します。

- パスワード: データベース・スキーマ・オーナーのパスワードを入力します。

- 「FANの有効化」を選択します。

- 「SSLの有効化」が選択解除されていることを確認します(暗号化するONS通知にsslが選択されている場合は、適切なウォレットとウォレット・パスワードを指定します)。

- サービス・リスナー: 使用するRACデータベースのためのSCANアドレスとポートを入力します。このアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せれば識別できます。

SQL>show parameter remote_listener;

NAME              TYPE                VALUE
-------------------------------------------------------------
remote_listener   string    db-scan.mycompany.com:1521

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。次に例を示します。

custdbhost1-vip.mycompany.com (port 1521)

および

custdbhost2-vip.mycompany.com (1521)

Oracle Database 10gでは、Oracle RACデータベースへの接続にマルチ・データ・ソースを使用します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- ONSホスト: Oracle RACデータベースのSCANアドレスおよびデータベースから報告されたONSリモート・ポートを入力します。

[orcl@db-scan1 ~]$ srvctl config nodeapps -s

ONS exists: Local port 6100, remote port 6200, EM port 2016

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベースのONSサービスのホスト名とポートを使用します。次に例を示します。

custdbhost1.mycompany.com (port 6200)

および

custdbhost2.mycompany.com (6200)

8. 「JDBCデータ・ソースのテスト」画面で、各接続のテストが自動的に行われます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。

9. 「オプションの構成を選択」画面で、次を選択します。

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

- JMSファイル・ストア

- JMS分散宛先
「次へ」をクリックします。

10. 「JMS分散宛先タイプの選択」画面で、すべてのFusion MiddlewareコンポーネントのJMSモジュールのドロップダウン・リストから「UDD」を選択します。

注意:

Fusion Middlewareコンポーネントでは、WDDの使用はサポートされていません。

11. 「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。
bam_server1というサーバーが自動的に作成されます。このサーバーの名前をWLS_BAM1に変更し、WLS_BAM2という新しいサーバーを追加します。表12-1に示す属性をこれらのサーバーに指定します。この画面に表示されている他のサーバーは、このまま変更しません。

表12-1 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_BAM1

BAMHOST1VHN1

9001

なし

いいえ

WLS_BAM2

BAMHOST2

9001

なし

いいえ

「次へ」をクリックします。

12. 「クラスタの構成」画面で、表12-2に示す次のクラスタを追加します。この画面に表示されている他のクラスタは、このまま変更しません。

表12-2 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

BAM_Cluster

ユニキャスト

なし

なし

空白

「次へ」をクリックします。

13. 「サーバーのクラスタへの割当」画面で、次の項目を追加します。この画面に表示されている他の割当ては、このまま変更しません。

- BAM_Cluster

- WLS_BAM1

- WLS_BAM2

「次へ」をクリックします。

14. 「マシンの構成」画面で、次の手順を実行します。

- デフォルトで表示される「LocalMachine」を削除します。

- 「Unixマシン」タブをクリックします。マシンBAMHOST1およびBAMHOST2を追加して、次のように入力します。

表12-3 マシン

名前

ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

BAMHOST1

BAMHOST1

BAMHOST2

BAMHOST2

他のフィールドはすべてデフォルト値のままにします。

「次へ」をクリックします。

15. 「サーバーのマシンへの割当」画面で、次の項目を追加します。

- WLS_BAM1をBAMHOST1に割り当てます。

- WLS_BAM2をBAMHOST2に割り当てます。

「次へ」をクリックします。

16. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- usermessagingserverおよびusermessagingdriver-emailは、SOA_ClusterおよびBAM_Clusterにのみターゲット設定する必要があります。(usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです。)

- WSM-PMはWSM-PM_Clusterにのみターゲット設定する必要があります。

- 「DMSアプリケーション」は、BAM_Cluster、SOA_Cluster、WSM-PM_Clusterおよび「管理サーバー」にターゲット設定する必要があります。

- oracle.sdp.*ライブラリは、SOA_ClusterおよびBAM_Clusterにのみターゲット設定します。oracle.soa.*ライブラリは、SOA_Clusterにのみターゲット設定します。

- oracle.rules.*ライブラリは、SOA_Cluster、BAM_Clusterおよび管理サーバーにターゲット設定します。

- oracle.bam*は、BAM_Clusterにのみターゲット設定する必要があります。

「次へ」をクリックします。

17. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- mds-owsmをWSM-PM_ClusterおよびAdminServerの両方にターゲット設定します。

- mds-soaをSOA_ClusterおよびAdminServerの両方にターゲット設定します。

- OraSDPMDatasourceをSOA_ClusterおよびBAM_Clusterの両方にターゲット設定します。
「次へ」をクリックします。

アプリケーションとリソースのターゲット設定の詳細は、付録B「アプリケーションとリソースのサーバーへのターゲット設定」を参照してください。

18. 「JMSファイル・ストアの構成」画面で、第4.3項「異なるディレクトリの推奨場所」でお薦めしているように、JMSストアに指定した共有ディレクトリの場所を入力します。例:

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

19. 「構成のサマリ」画面で、「拡張」をクリックします。

20. 管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順で再起動します。

12.5 トランザクション・リカバリ用デフォルト永続ストアの構成

各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。WebLogic Serverでは、システム・クラッシュやネットワーク障害からのリカバリ時にこのトランザクション・ログを使用します。クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーからアクセスできる場所にトランザクション・ログを格納します。

注意:

お薦めする場所は、デュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)です。

WLS_BAM1のデフォルト永続ストアの場所を設定する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」ノードをクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列で「WLS_BAM1」(これはハイパーリンクとして表示されています)をクリックします。WLS_BAM1サーバーの「設定」ページが表示され、デフォルトで「構成」タブが選択状態になります。

5. 「サービス」サブタブをクリックします。

6. ページの「デフォルト・ストア」セクションで、そのデータ・ファイルが格納されるデフォルト永続ストアのあるフォルダのパスを入力します。パスのディレクトリ構造は次のとおりです。

ORACLE_BASE/admin/domain_name/bam_cluster_name/tlogs

7. 「保存」をクリックします。

8. 「変更のアクティブ化」をクリックします。

注意:

トランザクション・リカバリ・サービスの移行を有効にするには、クラスタにある他のサーバーが使用できる永続記憶域ソリューションの場所を指定します。BAMHOST1とBAMHOST2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。

12.6 WLS_BAM2からのBAMサーバー・システムのターゲット設定の解除

BAMのBAMサーバー・コンポーネントはシングルトンなので、そのコンポーネントをサーバー移行用に構成する前に、いずれかのWLS_BAMサーバーのターゲット設定を解除する必要があります。

次の手順では、BAMサーバーのランタイムをWLS_BAM2から削除します。

WLS_BAM2からBAM Serverアーティファクトのターゲット指定を解除する手順は次のとおりです。

1. http://ADMINVHN:7001/consoleのOracle WebLogic管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」→「サーバー」を選択します。「サーバーの概要」ページが表示されます。

3. 表の「名前」列で「WLS_BAM2」を選択します。WLS_BAM2の「設定」ページが表示されます。

4. 「デプロイメント」タブをクリックします。

5. 表の「名前」列でoracle-bamアプリケーションを選択します。oracle-bamアプリケーションの「設定」ページが表示されます。

6. 「ターゲット」タブをクリックします。

7. 「ロックして編集」をクリックします。

8. 表12-4に従って各モジュールのターゲットを変更します。これらのコンポーネントをすべて変更する必要があり、ターゲット指定を誤ると、BAMシステムが起動しなくなります。

表12-4 oracle-bamコンポーネントのターゲット・タイプ

コンポーネント

タイプ

ターゲット

oracle-bam(11.1.1)

エンタープライズ・アプリケーション

BAM_Cluster

/oracle/bam

WEBAPP

WLS_BAM1

oracle-bam-adc-ejb.jar

EJB

WLS_BAM1

oracle-bam-ems-ejb.jar

EJB

WLS_BAM1

oracle-bam-eventengine-ejb.jar

EJB

WLS_BAM1

oracle-bam-reportcache-ejb.jar

EJB

WLS_BAM1

OracleBAM

WEBAPP

BAM_Cluster

OracleBAMWS

WEBAPP

BAM_Cluster

oracle-bam-statuslistener-ejb.jar

EJB

WLS_BAM1

sdpmessagingclient-ejb.jar

EJB

WLS_BAM1

9. 「保存」をクリックして、「変更のアクティブ化」をクリックします。
アプリケーションとリソースのターゲット設定の詳細は、付録B「アプリケーションとリソースのサーバーへのターゲット設定」を参照してください。

12.7 管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播

pack/unpackユーティリティを使用して、BAMHOST1およびBAMHOST2にドメイン構成を伝播します。

注意:

解凍前にサーバー移行を構成すると(BAMが含まれるようにドメインを拡張すると)、wlsifconfigスクリプトは上書きされるため、-overwriteオプションが提供するコピーからリストアする必要があります。

新しいドメイン構成を伝播する手順は次のとおりです。

1. BAMHOST1に、SOAHOST2と同様のディレクトリおよび共有記憶域構成(第3章「エンタープライズ・デプロイメント用のネットワークの準備」の説明のとおり)があることを確認します。BAMHOST1とBAMHOST2が、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したMW_HOMEディレクトリをマウントしている必要があります。

2. SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

1. 次のコマンドを実行します。

cd ORACLE_COMMON_HOME/common/bin

注意:

このディレクトリは第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したMW_HOMEへのマウント・ポイントとして使用できます。

2. 次のようにpackコマンドを実行します。

./pack.sh -managed=true -domain=ORACLE_BASE/admin/
domain_name/aserver/domain_name -template=soadomaintemplateExtBAM.jar
-template_name=soa_domain_templateExtBAM

3. 次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをBAMHOST1にコピーします。

scp soadomaintemplateExtBAM.jar
oracle@BAMHOST1:/ORACLE_COMMON_HOME/common/bin

4. 次のように、BAMHOST1でunpackコマンドを実行して、管理対象サーバーのドメイン・ディレクトリにテンプレートを解凍します。

BAMHOST1> cd ORACLE_COMMON_HOME/common/bin
BAMHOST1> ./unpack.sh -domain= ORACLE_BASE/admin/
domain_name/mserver/domain_name -template=soadomaintemplateExtBAM.jar
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

5. BAMHOST2に対してcopyコマンドとunpackコマンドを実行します。

注意:

このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。

12.8 WLS_BAMn管理対象サーバーに対するホスト名検証の無効化

このガイドで説明するエンタープライズ・デプロイメントでは、Oracle SOA Suiteを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。WLS_BAM1およびWLS_BAM2管理対象サーバーのホスト名検証を無効化して、様々なWebLogic Serverインスタンスを管理するときにエラーが出ないようにします。詳細は、第8.4.8項「ホスト名検証の無効化」を参照してください。

エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第13.3項「SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。

12.9 BAMHOST1およびBAMHOST2でのノード・マネージャの起動

setNMProps.shスクリプトを使用してノード・マネージャを起動します。

BAMHOST1およびBAMHOST2でノード・マネージャを起動する手順は次のとおりです。

1. ノード・マネージャを起動する前に、各サーバーのORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。

BAMHOSTn> cd ORACLE_COMMON_HOME/common/bin
BAMHOSTn> ./setNMProps.sh

注意:

クラスのロード失敗やその他の問題を回避するため、StartScriptEnabledプロパティを使用します。StartScriptEnabledの詳細は、第16.14.5項「SOAサーバーの再起動に失敗したためにポリシー移行が未完になる」を参照してください。

注意:

第3章「エンタープライズ・デプロイメント用のネットワークの準備」の共有記憶域構成で示しているように、BAMサーバーがローカル記憶域または共有記憶域でSOAとMW_HOMEを共有している場合には、setNMProps.shを再度実行する必要はありません。この場合、ノード・マネージャはすでに起動スクリプトを使用するように構成されています。

2. 次のコマンドを実行し、BAMHOST1でノード・マネージャを起動します。

BAMHOST1> cd WL_HOME/server/bin
BAMHOST1> ./startNodeManager.sh

次のコマンドを実行し、BAMHOST2でノード・マネージャを起動します。

BAMHOST2> cd WL_HOME/server/bin
BAMHOST2> ./startNodeManager.sh

12.10 BAMシステムの起動

Oracle WebLogic Server管理コンソールを使用して、管理対象サーバーWLS_BAM1を起動します。

ここで示す手順は、SOAHOST2でWS-MまたはSOAの管理対象サーバーについて事前にホスト名の検証が行われており、さらに、SOAHOST2でノード・マネージャがすでに実行されていることを前提としています。

BAMHOST1上の管理対象サーバーWLS_BAM1を起動する手順は次のとおりです。

1. WLS_BAM1管理対象サーバーを起動します。

1. http://ADMINVHN:7001/consoleのOracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。

3. 「制御」タブをクリックします。

4. 表の「サーバー」列の「WLS_BAM1」を選択します。

5. 「起動」をクリックします。

2. http://BAMHOST1VHN1:9001/OracleBAMにアクセスしてWLS_BAM1のステータスを確認します。

管理対象サーバーの起動に失敗すると次のメッセージが表示されます。

Listener refused the connection with the following error:
ORA-12519, TNS:no appropriate service handler found
The Connection descriptor used by the client was <db_connect_string>

この場合は、データベースのPROCESSES初期化パラメータが十分に高い値に設定されていることを確認してください。詳細は、第5.2.3項「初期化パラメータについて」を参照してください。このエラーが発生する可能性があるのは、1台のサーバーを起動した後で別のサーバーを起動した場合です。

1. WLS_BAM2管理対象サーバーを起動します。

1. http://ADMINVHN:7001/consoleのOracle WebLogic管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。

3. 「制御」タブをクリックします。

4. 表の「サーバー」列の「WLS_BAM2」を選択します。

5. 「起動」をクリックします。

2. http://BAMHOST2:9001/OracleBAMにアクセスしてWLS_BAM2のステータスを確認します。

12.11 GridLinkデータ・ソースの検証

サーバーが開始したら、GridLinkデーター・ソースが正しく構成され、ONS設定が正しいことを確認します。作成されたすべてのGridLinkデータ・ソースに対して、この手順を実行します。

GridLinkデータ・ソースの構成を検証する手順は次のとおりです。

1. Oracle WebLogic管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

3. 新しいデータ・ソースの内の1つをクリックします。

4. 「監視」タブをクリックし、いずれかのサーバーを選択します。

5. 「統計」タブをクリックし、いずれかのサーバーを選択します。

6. 「ONS」タブをクリックし、「テスト」タブをクリックします。

7. サーバーを選択して、「ONSのテスト」をクリックします。
テストが両方とも成功すれば、正しく構成されています。ONSのテストが失敗した場合は、RACデータベース・ノードでONSサービスが実行されていることを確認します。

orcl@db-scan1 ~]$ srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node db-scan1
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node db-scan2
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node db-scan2

[orcl@db-scan1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

[orcl@db-scan1 ~]$ srvctl status nodeapps | grep ONS
ONS is enabled
ONS daemon is running on node: db-scan1
ONS daemon is running on node: db-scan2

データ・ソースを使用するすべてのWebLogicサーバーからONSテストを実行します。

12.12 BAMHOST1でBAMサーバーを使用するためのBAM Webアプリケーションの構成

BAMHOST1でBAM Serverを使用するためのOracleBamWeb(WLS_BAM1)アプリケーションおよびOracleBamWeb(WLS_BAM2)アプリケーションを構成する手順は次のとおりです。

1. http://ADMINVHN:7001/emのOracle Enterprise Manager Fusion Middleware Controlにアクセスします。

2. ナビゲーション・ツリーの「BAM」を開きます。

3. 「OracleBamWeb(WLS_BAM1)」を右クリックします。

4. コンテキスト・メニューから「BAM Webプロパティ」を選択します。「BAM Webプロパティ」ページが表示されます。

5. 次のプロパティを定義します。

- アプリケーションURLにhttps://soa.mycompany.com:443と入力します。

- サーバー名にBAMHOST1VHN1と入力します。第3.4項「IPおよび仮想IPについて」の表3-2も参照してください。

- 「適用」をクリックします。

- Mbeanブラウザを使用し、サーバーのリスニング・ポートを変更します。

- Oracle Enterprise Manager Fusion Middleware Controlにログインします。

- 左側のナビゲーション・ツリーのドメイン名を展開します。

- 左側のナビゲーション・ツリーのBAM項目を展開します。

- 左側のナビゲーション・ツリーのOracleBamServerを強調表示します。

- 右上のBAMServerドロップダウン・メニューから「システムMBeanブラウザ」を選択します。

- 右側で「oracle.bam.web」→「サーバー」→「アプリケーション」→「構成」→「BAMWebConfig」に移動します。

- 「ServerPort」フィールドの「デフォルト」値を「9001」に置き換えます。

6. ナビゲーション・ツリーで「OracleBamWeb(WLS_BAM2)」を選択し、手順3から5を繰り返します。

12.13 WLS_BAMn管理対象サーバーについてのOracle HTTP Serverの構成

WLS_BAMn管理対象サーバーが属するBAM_ClusterにOracle HTTP Serverからルーティングをできるようにするには、次のようにWebLogicClusterパラメータをこのクラスタにあるノードのリストに設定する必要があります。

Oracle HTTP ServerでSOA_Clusterへのルーティングを有効化する手順は次のとおりです。

1. WEBHOST1とWEBHOST2上で、次のディレクトリにあるsoa_vh.confファイルにディレクティブを追加します。

ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf

第7.6項「仮想ホストの定義」の指示に従って、soa_vh.confファイルを作成している必要があります。

次のディレクティブをsoa_vh.confファイルの<VirtualHost>タグ内に追加します。

# BAM Web Application
<Location /OracleBAM >
SetHandler weblogic-handler
WebLogicCluster BAMHOST1VHN1:9001,BAMHOST2:9001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /OracleBAMWS >
SetHandler weblogic-handler
WebLogicCluster BAMHOST1VHN1:9001,BAMHOST2:9001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

soa_vh.confファイルは、例12-1のように表示されます。

2. WEBHOST1およびWEBHOST2の両方で、次のようにOracle HTTP Serverを再起動します。

WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1
WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2

例12-1 soa_vh.confファイル

<VirtualHost *:7777>
ServerName https://soa.mycompany.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

<Location /soa-infra>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Worklist
<Location /integration>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# B2B
<Location /b2bconsole>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Default to-do taskflow
<Location /workflow/DefaultToDoTaskFlow/>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Workflow
<Location /workflow>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA composer application
<Location /soa/composer>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# BAM Web Application
<Location /OracleBAM >
SetHandler weblogic-handler
WebLogicCluster BAMHOST1VHN1:9001,BAMHOST2:9001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /OracleBAMWS >
SetHandler weblogic-handler
WebLogicCluster BAMHOST1VHN1:9001,BAMHOST2:9001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
</VirtualHost>

WebLogicClusterパラメータで指定したサーバーは、起動時のプラグインに対してのみ重要な役割を持ちます。このノードのリストには、実行しているクラスタ・メンバーを1つ以上記述しておく必要があります。記述しておかないと、このプラグインで他のクラスタ・メンバーを検出できません。Oracle HTTP Serverの起動時には、リストに記述したクラスタ・メンバーを実行している必要があります。Oracle WebLogic Serverとこのプラグインの連携により、クラスタに発生した新規のクラスタ・メンバー、失敗したクラスタ・メンバーおよびリカバリしたクラスタ・メンバーを反映してサーバーのリストが自動的に更新されます。

次に例を示します。

- 例1: 2つのノードで構成したクラスタに3番目のメンバーを追加する場合、そのメンバーを追加するために構成を更新する必要はありません。3番目のメンバーは、実行時に自動的に検出されます。

- 例2: クラスタは3つのノードで構成されていても、構成に記述されているノードはそのうちの2つのみであるとします。Oracle HTTP Serverを起動するときにこの2つのノードが両方とも停止していると、プラグインはクラスタを検出できません。Oracle HTTP Serverを起動するときは、リストに記述したノードを1つ以上実行している必要があります。
クラスタのメンバーをすべてリストに記述した場合は、Oracle HTTP Serverの起動時にそのうちの1つ以上を実行しておくことで、クラスタに確実に到達できます。

WebLogic Serverプラグインの構成の詳細は、『Oracle WebLogic ServerにおけるWebサーバー・プラグインの使用』ガイドを参照してください。

12.14 Oracle HTTP Serverを介したアクセスの検証

URLを検証して、HTTP ServerからBAM_Clusterへのルーティングとフェイルオーバーが適切に機能することを確認します。

URLを検証する手順は次のとおりです。

1. WLS_BAM2が稼動している状態で、Oracle WebLogic Server管理コンソールを使用してWLS_BAM1を停止します。

2. WebHost1:7777/OracleBAMにアクセスして正常に機能していることを確認しますBAMサーバーが起動していないため、この時点ではレポートやデータを取得できません。

3. Oracle WebLogic Server管理コンソールでWLS_BAM1を起動します。

4. Oracle WebLogic Server管理コンソールでWLS_BAM2を停止します。

5. WebHost1:7777/OracleBAMにアクセスして正常に機能していることを確認します

12.15 WLS_BAM1サーバーのサーバー移行の構成

BAMの高可用性アーキテクチャでは、サーバーの移行を使用してBAMサーバーのシングルトン・サービスを障害から保護します。障害が発生した場合にBAMHOST2で再起動できるようにWLS_BAM1管理対象サーバーを構成します。この構成では、WebLogic Serverの移行によってフェイルオーバーの対象となる特定の浮動IPをWLS_BAM1でリスニングします。WLS_BAM1管理対象サーバーのサーバー移行を構成する手順は次のとおりです。

- ステップ1: サーバー移行リース・テーブルのユーザーおよび表領域の設定

- ステップ2: 管理コンソールによるリース用のGridlinkデータ・ソースの作成

- ステップ3: ノード・マネージャのプロパティ・ファイルの編集

- ステップ4: wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する

- ステップ5: BAMHOSTnノードのノード・マネージャと管理サーバーのホスト名検証の有効化

- ステップ6: サーバー移行ターゲットの構成

- ステップ7: サーバー移行のテスト

注意:

SOAに対してサーバーの移行を構成済であれば、それと同じデータ・ソースとデータベース・スキーマをBAMステムで使用できます。この場合、ステップ1から4は不要ですが、対応するサーバー移行/リース・データソースをBAMクラスタにターゲット設定する必要があります。

12.15.1 サーバー移行リース・テーブルのユーザーおよび表領域の設定

ユーザーと表領域を作成する手順は次のとおりです。

1. leasingという表領域を作成します。たとえば、sysdbaユーザーとしてSQL*Plusにログオンして次のコマンドを実行します。

SQL> create tablespace leasing
logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
size 32m autoextend on next 32m maxsize 2048m extent management local;

2. 次のように、leasingという名前のユーザーを作成し、leasing表領域に割り当てます。

SQL> create user leasing identified by password;
SQL> grant create table to leasing;
SQL> grant create session to leasing;
SQL> alter user leasing default tablespace leasing;
SQL> alter user leasing quota unlimited on LEASING;

3. 次のように、leasing.ddlスクリプトを使用してリース・テーブルを作成します。

1. WL_HOME/server/db/oracle/920ディレクトリにあるleasing.ddlファイルを、使用するデータベース・ノードにコピーします。

2. データベースにleasingユーザーとして接続します。

3. 次のように、leasing.ddlスクリプトをSQL*Plusで実行します。

SQL> @copy_location/leasing.ddl;

12.15.2 管理コンソールによるリース用のGridlinkデータ・ソースの作成

第14.3項「管理コンソールによるリース用のGridLinkデータ・ソースの作成」の手順に従って、Oracle WebLogic Server管理コンソールを使用して、リース・テーブルに使用するGridLinkデータ・ソースを作成します。

12.15.3 ノード・マネージャのプロパティ・ファイルの編集

サーバーが稼働している2つのノード上でノード・マネージャのプロパティ・ファイルを編集します。nodemanager.propertiesファイルは次のディレクトリにあります。

WL_HOME/common/nodemanager

次のプロパティを追加してサーバー移行が正常に動作するようにします。

- Interface

Interface=eth0

このプロパティは浮動IP (eth0など)のインタフェース名を指定します。

注意:

eth0:1やeth0:2のようなサブ・インタフェースは指定しないでください。このインタフェースは、:0も:1も指定しないで使用します。ノード・マネージャのスクリプトは、:Xに対応した各種のIPを横断して、どれを追加または削除するかを判定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

- NetMask

NetMask=255.255.255.0

このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。

- UseMACBroadcast

UseMACBroadcast=true

このプロパティはARPパケットを送信する際にノードのMACアドレスを使用するかどうかを指定します。つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。

これらのプロパティが適用されていることをノード・マネージャの出力(ノード・マネージャが起動したシェル)で確認します。それ以外の場合、移行中に問題が発生する可能性があります。出力は次のようになります。

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

注意:

サーバーのプロパティ(起動プロパティ)が設定されており、ノード・マネージャがサーバーをリモートで起動できる場合には、次の手順は必要ありません。

1. nodemanager.propertiesファイルのStartScriptEnabledプロパティをtrueに設定していない場合はtrueに設定します。これは、ノード・マネージャが管理対象サーバーを起動するために必要です。

2. WL_HOME/server/bin/ディレクトリにあるstartNodeManager.shスクリプトを実行し、ノード1とノード2でノード・マネージャを起動します。

注意:

共有記憶域のインストールからノード・マネージャを実行している場合、同じnodemanager.propertiesファイルを使用する複数のノードが起動します。ただし、NetMaskプロパティやInterfaceプロパティにはノードごとに異なる値が必要です。この場合、環境変数を使用してノードごとに個別のパラメータを指定します。たとえば、SOAHOSTnで異なるインタフェース(eth3)を使用するには、SOAHOSTn> export JAVA_OPTIONS=-DInterface=eth3としてInterface環境変数を使用します。この環境変数をシェルに設定した後、ノード・マネージャを起動します。

12.15.4 wlsifconfig.shスクリプトの環境権限とスーパーユーザー権限の設定

wlsifconfig.shスクリプトの環境およびスーパーユーザー権限を設定します。

表12-5に示すファイルをPATH環境変数で指定していることを確認します。

表12-5 PATH環境変数に必要なファイル

ファイル

ディレクトリの場所

wlsifconfig.sh

ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domain

WL_HOME/common/nodemanager

パスワードによる制限を設けずにsudo権限をWebLogicユーザー(oracle)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

セキュリティ上の理由から、sudoの付与はwlsifconfig.shスクリプトの実行に必要なコマンドの一部に限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する手順は次のとおりです。

注意:

この手順に適するsudo権限とシステム権限については、システム管理者に問い合せてください。

WebLogicユーザー(oracle)がこのスクリプトを実行できることを確認します。sudo実行権限をoracleおよびifconfigとarpingに付与するエントリを記述した/etc/sudoersの例を次に示します。

パスワードによる制限を設けずにsudo権限をWebLogicユーザー('oracle')に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

12.15.5 BAMHOSTnノードのノード・マネージャと管理サーバーのホスト名検証の有効化

BAMHOSTnノードのノード・マネージャと管理サーバー間でのホスト名検証証明書を有効化します。ホスト名検証証明書を有効化するには、第13.3項「SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。

12.15.6 サーバー移行ターゲットの構成

クラスタの移行ターゲットを構成するには、DataSourceForAutomaticMigrationプロパティをtrueに設定します。

クラスタ内の移行ターゲットを構成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」を開き、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。

3. 表の「名前」列で、移行を構成するクラスタ(BAM_Cluster)をクリックします。

4. 「移行」タブをクリックします。

5. 「ロックして編集」をクリックします。

6. 「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。この場合は、「BAMHOST1」と「BAMHOST2」を選択します。

7. 自動移行に使用するデータソースを選択します。この場合は、leasingデータ・ソースを選択します。

8. 「保存」および「変更のアクティブ化」をクリックします。

9. WLS_BAM1についてのみ、サーバー移行の候補となるマシンを設定します。WLS_BAM2はサーバー移行を使用しません。

1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。

2. 移行を構成するサーバーを選択します。

3. 「移行」タブをクリックします。

4. 「移行の構成」セクションの「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。WLS_BAM1についてBAMHOST2を選択します。

5. 「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。

6. 「変更のアクティブ化」をクリックします。

7. 管理サーバーとWLS_BAM1サーバーを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

ヒント:

「サーバーの概要」ページの「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動すると、サーバーを実行しているマシンを確認できます。このサーバーが自動的に移行すると、構成と異なる内容になります。

12.15.7 サーバー移行のテスト

サーバーの移行が適切に行われていることを確認する手順は次のとおりです。

ノード1からテストする手順は次のとおりです。

1. WLS_BAM1管理対象サーバーを停止します。

BAMHOST1> kill -9 pid

pidは、その管理対象サーバーのプロセスID (PID)を指定します。次のコマンドを実行すると、ノードのPIDを識別できます。

BAMHOST1> ps -ef | grep WLS_BAM1

2. ノード・マネージャのコンソールを確認します。WLS_BAM1の浮動IPが無効になったことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_BAM1の2回目の再起動を試行するまで待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。

ノード2からテストする手順は次のとおりです。

1. ローカルのノード・マネージャ・コンソールを確認します。ノード1でのWLS_BAM1の再起動が前回試行されてから30秒間経過した後に、WLS_BAM1の浮動IPが表示され、サーバーをこのノードで再起動することを示すメッセージがノード2のノード・マネージャにより表示されます。

2. BAMHOST1VHN1とsoa.mycompany.com/OracleBAMを使用してOracle BAMコンソールにアクセスします。

管理コンソールから移行を検証する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 左のコンソールで「ドメイン」をクリックします。

3. 「監視」タブをクリックし、「移行」タブをクリックします。
「移行の状態」の表に、移行の状態に関する情報が表示されます。

12.16 BAMクラスタ内のBAMコンポーネントへの構成変更の適用

Oracle BAMをクラスタ環境で使用している場合、あるノードをOracle Enterprise Managerで変更したときには、その変更をすべてのノードに適用する必要があります。また、BAMエンタープライズ・デプロイメント・トポロジでBAMサーバーに構成変更を行う場合には、次の作業も検討してください。

サーバーの移行機能を使用するため、BAMサーバーは別のノードのドメイン・ディレクトリに移動します。BAMサーバー構成は、フェイルオーバー・ノード内であらかじめ作成しておく必要があります。このBAMサーバー構成ファイルは、次のディレクトリにあります。

DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/oracle_bam-11.1.1/config

フェイルオーバーに備えてファイルを作成するには、強制的にサーバー移行を実行してファイルをソース・ノードからコピーしてください。たとえば、BAMの場合の手順は次のとおりです。

1. WLS_BAM1のドライバをBAMHOST1内で構成します。

2. BAMHOST2へのWLS_BAM1のフェイルオーバーを強制的に実行します。フェイルオーバー・ノード内のBAMサーバーのディレクトリ構造を確認してください。

DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/oracle_bam-11.1.1/config

12.17 BAM構成のバックアップ

拡張したドメインが正常に動作していることを確認した後、そのドメイン構成をバックアップします。このバックアップは、この後の手順でエラーが発生した場合にすぐにリストアできるようにすることが目的です。構成をローカル・ディスクにバックアップします。エンタープライズ・デプロイメントが完了すれば、このバックアップは破棄してかまいません。エンタープライズ・デプロイメントが完了すれば、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。情報のリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。

ドメイン構成をバックアップする手順は次のとおりです。

1. Web層をバックアップする手順は次のとおりです。

1. opmnctlを使用してインスタンスを停止します。

ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

3. 次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance.tar ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

ORACLE_BASE/admin/instance_name/bin/opmnctl startall

2. データベースをバックアップします。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。

3. 管理サーバーのドメイン・ディレクトリをバックアップしてドメイン構成を保存します。構成ファイルは次のディレクトリにあります。

ORACLE_BASE/ admin/domain_name

管理サーバーをバックアップする手順は次のとおりです。

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

13 エンタープライズ・デプロイメント用のノード・マネージャの設定

この章では、エンタープライズ・デプロイメントの推奨事項に従ってノード・マネージャを構成する方法を説明します。

この章の項目は次のとおりです。

- 第13.1項「ノード・マネージャの概要」

- 第13.2項「ノード・マネージャのログの場所の変更」

- 第13.3項「SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」

- 第13.4項「SOAHOST1でのノード・マネージャの起動」

- 第13.5項「SOAHOST2でのノード・マネージャに対するホスト名検証証明書の有効化」

- 第13.6項「SOAHOST2でのノード・マネージャの起動」

- 第13.7項「カスタム・キーストアを使用するためのWebLogic Serverの構成」

13.1 ノード・マネージャの概要

ノード・マネージャを使用すると、管理サーバーおよび各管理対象サーバーの起動と停止が可能です。

オラクル社では、ノード・マネージャと管理サーバー間の通信にホスト名を使用した検証を使用することをお薦めしています。このホスト名検証には、管理サーバーと通信するそれぞれのアドレスに証明書を使用する必要があります。この章では、ホスト名検証に使用する証明書をSOAHOST1およびSOAHOST2に構成する手順を説明します。BAMエンタープライズ・デプロイメント・トポロジのBAMHOST1およびBAMHOST2にも同様の手順が必要となります。その手順ではBAMに応じたホスト名の変更が必要ですが、一連の手順や構文はまったく同じです。

13.2 ノード・マネージャのログの場所の変更

また、Oracle Fusion Middlewareデプロイメントのノード・マネージャのログは、デフォルト(ノード・マネージャが存在するMW_Homeの中)以外の場所に置くことをお薦めします。

ノード・マネージャのログの場所を変更するには、次のディレクトリにあるnodemanager.propertiesファイルを編集します。

MW_HOME/wlserver_10.3/common/nodemanager

このファイルは、MW_HOMEディレクトリでなく、デプロイメントのadminディレクトリ内に置くことをお薦めします。

nodemanager.propertiesに次の行を追加します。

LogFile=ORACLE_BASE/admin/nodemanager.log

ノード・マネージャを再起動して、変更を有効にします。

13.3 SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化

ホスト名検証はノード・マネージャと管理サーバー間の通信を可能にするものです。この検証では、管理サーバーと通信するそれぞれのアドレスに証明書を使用する必要があります。

この項には次のトピックが含まれます:

- ステップ1: utils.CertGenユーティリティを使用した自己署名証明書の生成

- ステップ2: utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成

- ステップ3: keytoolユーティリティを使用した信頼キーストアの作成

- ステップ4: カスタム・キーストアを使用するためのノード・マネージャの構成

- ステップ5: 共通または共有記憶域インストールの使用

13.3.1 utils.CertGenユーティリティを使用した自己署名証明書の生成

この項では、SOAHOST1.mycompany.comに自己署名証明書を作成する手順を説明します。これらの証明書はネットワーク名/別名を使用して作成します。

キーストアおよび信頼キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。様々な目的(HTTPを起動するためのSSL設定など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。この場合、SOAHOST2では、SOAHOST1の証明書用に作成されたcertディレクトリを使用します。

自己署名証明書のかわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。

パスワードについて

このガイドで使用するパスワードはあくまでも一例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字を含むパスワードを使用します。

自己署名証明書を作成する手順は次のとおりです。

1. WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して環境を設定します。
Bourneシェルで、次のコマンドを実行します。

. setWLSEnv.sh

CLASSPATH環境変数が設定されていることを確認します。

echo $CLASSPATH

2. 証明書用のユーザー定義ディレクトリを作成します。

mkdir certs

3. ディレクトリをユーザー定義ディレクトリに変更します。

cd certs

4. ユーザー定義ディレクトリからutils.CertGenツールを実行して、HOST. mycompany.comおよびVIP. mycompany.comの両方に対する証明書を作成します。
構文:

java utils.CertGen key_passphrase cert_file_name key_file_name [export | domestic] [hostname]

例:

java utils.CertGen password SOAHOST1.mycompany.com_cert SOAHOST1.mycompany.com_key domestic SOAHOST1.mycompany.com

java utils.CertGen password ADMINVHN.mycompany.com_cert ADMINVHN.mycompany.com_key domestic ADMINVHN.mycompany.com

13.3.2 utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成

この項では、SOAHOST1.mycompany.comでアイデンティティ・キーストアを作成する方法について説明します。

前の項で説明されている手順では、アイデンティティ・キーストアを作成してそれを共有記憶域に配置しました。この項では、SOAHOST2用の新しい鍵をそのストアに追加します。SOAHOST2とSOAHOST2VHN1の両方の証明書と秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

1. utils.ImportPrivateKeyユーティリティを使用してappIdentityKeyStoreという新しいアイデンティティ・キーストアを作成します。
このキーストアは、証明書と同じディレクトリに作成します。

ASERVER_HOME/certs

注意:

アイデンティティ・ストアは、utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をインポートすることで作成されます(存在していない場合)

2. SOAHOST1とVIPHOST1の両方の証明書と秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。
構文:

java utils.ImportPrivateKey keystore_file keystore_password certificate_alias_to_use private_key_passphrase certificate_file private_key_file keystore_type

例:

java utils.ImportPrivateKey appIdentityKeyStore.jks password
appIdentity1 password
ASERVER_HOME/certs/SOAHOST1.mycompany.com_cert.pem
ASERVER_HOME/certs/SOAHOST1.mycompany.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks password
appIdentity2 password
ASERVER_HOME/certs/SOAHOST1VHN1.mycompany.com_cert.pem
ASERVER_HOME/certs/SOAHOST1VHN1.mycompany.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks password
appIdentity3 password
ASERVER_HOME/certs/ADMINVHN.mycompany.com_cert.pem
ASERVER_HOME/certs/ADMINVHN.mycompany.com_key.pem

13.3.3 keytoolユーティリティを使用した信頼キーストアの作成

SOAHOST1.mycompany.comに信頼キーストアを作成する手順は次のとおりです。

1. 新しい信頼キーストアを作成するには、標準のJavaキーストアを使用します。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。標準のJava信頼キーストアは、直接変更しないことをお薦めします。WL_HOME/server/libディレクトリにある標準のJavaキーストアCA証明書を、証明書のあるディレクトリにコピーします。例:

cp WL_HOME/server/lib/cacerts
ASERVER_HOME/certs/appTrustKeyStore.jks

2. 標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは、常に変更することをお薦めします。パスワードを変更するには、keytoolユーティリティを使用します。その構文は次のとおりです。

keytool -storepasswd -new NewPassword -keystore TrustKeyStore -storepass Original_Password

例:

keytool -storepasswd -new password -keystore appTrustKeyStore.jks -storepass changeit

3. utils.CertGenツールで生成された証明書にすべて署名するには、CA証明書CertGenCA.derを使用します。これは、WL_HOME/server/libディレクトリにあります。このCA証明書は、keytoolユーティリティを使用してappTrustKeyStoreにインポートする必要があります。その構文は次のとおりです。

keytool -import -v -noprompt -trustcacerts -alias AliasName
-file CAFileLocation -keystore KeyStoreLocation -storepass KeyStore_Password

例:

keytool -import -v -noprompt -trustcacerts -alias clientCACert -file
WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStore.jks -storepass password

13.3.4 カスタム・キーストアを使用するためのノード・マネージャの構成

カスタム・キーストアを使用するようにノード・マネージャを構成するには、WL_HOME/common/nodemanagerディレクトリにあるnodemanager.propertiesファイルの最後に次の行を追加します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity KeyStore
CustomIdentityKeyStorePassPhrase=Identity KeyStore Passwd
CustomIdentityAlias=Identity Key Store Alias
CustomIdentityPrivateKeyPassPhrase=Private Key used when creating Certificate

ノード・マネージャのリスニング・アドレスのCustomIdentityAliasには必ず正しい値を使用してください。たとえば、SOAHOST1では、第13.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」の手順に従ってappIdentity1を使用します。

(appIdentity1 mapped to the SOAHOST1 listen address).
Example for Node 1:
KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=ASERVER_HOME/certs/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=password
CustomIdentityAlias=appIdentity1
CustomIdentityPrivateKeyPassPhrase=password

第13.4項「SOAHOST1でのノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリが暗号化されます。セキュリティ上の理由から、nodemanager.propertiesファイル内のエントリが暗号化されていない時間を最小に抑える必要があります。ファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化します。

13.3.5 共通または共有記憶域インストールの使用

共通記憶域または共有記憶域のインストールをMW_HOMEに指定している場合、ノード・マネージャは同じ基本構成(nodemanager.properties)を使用してそれぞれのノードから起動します。第13.3.1項「utils.CertGenユーティリティを使用した自己署名証明書の生成」の説明のとおり、新しいノードの証明書を作成しappIdentityKeyStore.jksにインポートする方法で、バイナリを共有するすべてのノードの証明書をappIdentityKeyStore.jksアイデンティティ・ストアに追加します。このストアで証明書が使用できるようになった時点で、各ノード・マネージャはそれぞれのアイデンティティ別名を指定して、正しい証明書を管理サーバーに送信する必要があります。

各ノードでノード・マネージャを起動する前に、該当の環境変数を設定します。

cd WL_HOME/server/bin
export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST1

cd WL_HOME/server/bin
export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOSTn

13.4 SOAHOST1でのノード・マネージャの起動

startNodeManager.shスクリプトを使用してSOAHOST1でノード・マネージャを起動します。

注意:

ノード・マネージャが未構成で、まだ1度も起動していない場合は、第8.4.2項「SOAHOST1でのノード・マネージャの起動」の説明に従ってsetNMProps.shスクリプトを実行してください。このスクリプトを実行後に、SOAおよびBAMに必要な起動スクリプトを使用できるようになります。

SOAHOST1でノード・マネージャを起動する手順は次のとおりです。

SOAHOST1> cd WL_HOME/server/bin
SOAHOST1> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityX
SOAHOST1> ./startNodeManager.sh

注意:

各ホストに明確に割り当てられているカスタムのアイデンティティ別名を指定してください。つまり、...HOST1にはappIdentity1、...HOST2にはappIdentity2を指定します。

13.5 SOAHOST2でのノード・マネージャに対するホスト名検証証明書の有効化

ホスト名検証はノード・マネージャと管理サーバー間の通信を可能にするものです。この検証では、管理サーバーと通信するそれぞれのアドレスに証明書を使用する必要があります。

ノード・マネージャと管理サーバー間のSSL通信を設定するには、次の手順を実行します。

- ステップ1: utils.CertGenユーティリティを使用した自己署名証明書の生成

- ステップ2: utils.ImportPrivateKeyユーティリティを使用したSOAHOST2のアイデンティティのインポート

- ステップ3: keytoolユーティリティを使用した信頼キーストアの作成

- ステップ4: カスタム・キーストアを使用するためのノード・マネージャの構成

13.5.1 utils.CertGenユーティリティを使用した自己署名証明書の生成

この項では、SOAHOST2.mycompany.comに自己署名証明書を作成する手順を説明します。これらの証明書はネットワーク名/別名を使用して作成します。

キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、管理サーバーまたはSOAサーバーが(手動またはサーバー移行により)フェイルオーバーしたときに、ノードが適切な証明書にアクセスできるようにする必要があります。この場合、SOAHOST2では、SOAHOST1の証明書用に作成されたcertディレクトリを使用します。複製されたストアを保持している場合は、証明書用のユーザー定義ディレクトリを作成します。

ネットワーク名/別名を使用して、untils.CertGenユーティリティで自己署名証明書を作成します。

自己署名証明書のかわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。

SOAHOST2.mycompany.comに自己署名証明書を作成する手順は次のとおりです。

1. WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して環境を設定します。
Bourneシェルで、次のコマンドを実行します。

. setWLSEnv.sh

CLASSPATH環境変数が設定されていることを確認します。

echo $CLASSPATH

2. 証明書用のユーザー定義ディレクトリを作成します。

mkdir certs

3. ディレクトリをユーザー定義ディレクトリに変更します。

cd certs

4. ユーザー定義ディレクトリからutils.CertGenツールを実行して、SOAHOST2とSOAHOST2VHN1の両方に対する証明書を作成します。
構文:

java utils.CertGen key_passphrase cert_file_name key_file_name
export | domestic hostname

例:

java utils.CertGen password SOAHOST2_cert SOAHOST2_key
domestic SOAHOST2.mycompany.com

java utils.CertGen password SOAHOST2VHN1_cert SOAHOST2VHN1_key
domestic SOAHOST2VHN1.mycompany.com

13.5.2 utils.ImportPrivateKeyユーティリティを使用したSOAHOST2のアイデンティティのインポート

前の項で説明されている手順では、アイデンティティ・キーストアを作成してそれを共有記憶域に配置しました。この項ではSOAHOST2用の新しい鍵をそのストアに追加します。SOAHOST2とSOAHOST2VHN1の両方の証明書と秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

SOAHOST2.mycompany.comにアイデンティティ・ストアを作成する手順は次のとおりです。

構文:

java utils.ImportPrivateKey keystore_file keystore_password certificate_alias_to_use private_key_passphrase certificate_file private_key_file keystore_type

例:

java utils.ImportPrivateKey appIdentityKeyStore.jks password
appIdentity4 password
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST2_cert.pem
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST2_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks password
appIdentity5 password
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST2VHN1_cert.pem
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST2VHN1_key.pem

13.5.3 カスタム・キーストアを使用するためのノード・マネージャの構成

カスタム・キーストアを使用するようにノード・マネージャを構成する手順は次のとおりです。

1. WL_HOME/common/nodemanagerディレクトリにあるnodemanager.propertiesファイルの最後に次の行を追加します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity KeyStore
CustomIdentityKeyStorePassPhrase=Identity KeyStore Passwd
CustomIdentityAlias=Identity Key Store Alias
CustomIdentityPrivateKeyPassPhrase=Private Key used when creating Certificate

各ノードでCustomIdentityAliasの正しい値を使用してください。たとえば、SOAHOST2ではappIdentity3を使用します。

ノード2の例:

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=ASERVER_HOME/domain_name/certs/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=password
CustomIdentityAlias=appIdentity3
CustomIdentityPrivateKeyPassPhrase=password

注意:

第13.6項「SOAHOST2でのノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリは暗号化されます。

セキュリティ上の理由から、nodemanager.propertiesファイルのエントリが暗号化されていない時間を可能なかぎり短くする必要があります。ファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化してください。

13.6 SOAHOST2でのノード・マネージャの起動

startNodeManager.shスクリプトを使用してSOAHOST2でノード・マネージャを起動するには、第13.4項「SOAHOST1でのノード・マネージャの起動」の手順を実行します。SOAHOST2からコマンドを実行します。

注意:

ノード・マネージャが適切なストアおよび別名を使用していることを、ノード・マネージャの出力で確認します。ノード・マネージャのプロンプトは次のようになります。

CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appIdentityKeyStore.jks
CustomIdentityAlias=appIdentityX

テストの構成変更をサーバーに適用したときにノード・マネージャでSSLエラーが報告されることなく正常に終了する場合、ホスト名検証は機能します。

13.7 カスタム・キーストアを使用するためのWebLogic Serverの構成

Oracle WebLogic Server管理コンソールを使用して、カスタム・キーストアを使用するためにWebLogic Serverを構成します。この手順を、管理サーバー、WLS_WSMnおよびWLS_SOAnサーバーで実行します。

手順6のディレクトリ・パスは例です。キーストアは、aserverディレクトリではなく共有記憶域に配置することをお薦めします。証明書用のディレクトリとは別のディレクトリに配置する方がより適切です。

アイデンティティ・キーストアおよび信頼キーストアを構成する手順は次のとおりです。

1. 管理コンソールにログインして「ロックして編集」をクリックします。

2. 左ペインで「環境」を開き、「サーバー」を選択します。

3. アイデンティティ・キーストアおよび信頼キーストアを構成するサーバーの名前をクリックします。

4. 「構成」を選択して、「キーストア」を選択します。

5. 「キーストア」フィールドで、「変更」をクリックし、秘密鍵/デジタル証明書のペアおよび信頼できるCA証明書の格納および管理に使用するための「カスタムIDとカスタム信頼」方法を選択して、「保存」をクリックします。

6. 「ID」セクションで、アイデンティティ・キーストアの属性を定義します。

1. カスタムIDキーストア: アイデンティティ・キーストアの完全修飾パスを入力します。

ASERVER_HOME/certs/appIdentityKeyStore.jks

2. カスタムIDキーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

3. カスタムIDキーストアのパスフレーズ: 第13.3.2項「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で指定したパスワードKeystore_Passwordを入力します。
この属性はオプションの場合も必須の場合もあります。どちらになるかはキーストアのタイプによって決まります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

7. 「信頼」セクションで、信頼キーストアのプロパティを定義します。

1. カスタム信頼キーストア: 信頼キーストアの完全修飾パスを入力します。

ASERVER_HOME/certs/appIdentityKeyStore.jks

2. カスタム信頼キーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

3. カスタム信頼キーストアのパスフレーズ: 第13.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワードNew_Password。
前の手順で説明したとおり、この属性はオプションの場合も必須の場合もあり、どちらになるかはキーストアのタイプによって決まります。

8. 「保存」をクリックします。

9. これらの変更を有効にするために、管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックします。

10. 「ロックして編集」をクリックします。

11. 「構成」をクリックし、「SSL」をクリックします。

12. 「秘密鍵の別名」フィールドで、管理対象サーバーがリスニングを実行するホスト名に使用した別名を入力します。
「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、第13.3.2項「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」で作成したキーストアのパスワードを入力します。

13. 「保存」をクリックします。

14. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

15. 変更を適用したサーバーを再起動します。

16. ホスト名検証を有効化して、ノード・マネージャ、管理サーバーおよび管理対象サーバー間の通信が正しいことを検証します。

1. 各サーバーの管理コンソールで、「構成」、「SSL」、「詳細」、「ホスト名の検証」、「BEAホスト名の検証」を選択します。

2. 管理コンソールを使用してサーバーを再起動します。

14 エンタープライズ・デプロイメント用のサーバー移行の構成

この章では、エンタープライズ・デプロイメント用にサーバー移行を構成する手順を説明します。

この章の項目は次のとおりです。

- 第14.1項「エンタープライズ・デプロイメント用のサーバー移行の概要」

- 第14.2項「サーバー移行leasing表のユーザーと表領域の設定」

- 第14.3項「管理コンソールによるリース用のGridLinkデータ・ソースの作成」

- 第14.4項「ノード・マネージャのプロパティ・ファイルの編集」

- 第14.5項「wlsifconfig.shスクリプトの環境権限とスーパーユーザー権限の設定」

- 第14.6項「サーバー移行ターゲットの構成」

- 第14.7項「サーバー移行のテスト」

14.1 エンタープライズ・デプロイメント用のサーバー移行の概要

管理対象サーバーWLS_SOA1およびWLS_SOA2のサーバー移行を構成します。サーバー移行が構成されていると、障害が発生したときに、WLS_SOA1管理対象サーバーがSOAHOST2で再起動し、WLS_SOA2管理対象サーバーがSOAHOST1で再起動します。WLS_SOA1およびWLS_SOA2サーバーは、Oracle WebLogic Serverによってフェイルオーバーされる特定の浮動IPをリスニングします。

次の項の手順を実行し、管理対象サーバーのサーバー移行を構成します。

14.2 サーバー移行リース・テーブルのユーザーおよび表領域の設定

create tablespace leasingコマンドを使用して、サーバー移行リース・テーブルのユーザーおよび表領域を設定します。

サーバー移行リース・テーブルのユーザーと表領域を設定する手順は次のとおりです。

1. Leasingという表領域を作成します。たとえば、sysdbaユーザーとしてSQL*Plusにログオンし、次のコマンドを実行します。

SQL> create tablespace Leasing
logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
size 32m autoextend on next 32m maxsize 2048m extent management local;

2. Leasingというユーザー名を作成し、リース表領域に割り当てます。

SQL> create user Leasing identified by password;

SQL> grant create table to Leasing;

SQL> grant create session to Leasing;

SQL> alter user Leasing default tablespace Leasing;

SQL> alter user Leasing quota unlimited on LEASING;

3. leasing.ddlスクリプトを使用してリース・テーブルを作成します。

1. 次のいずれかのディレクトリにあるleasing.ddlファイルを、データベース・ノードにコピーします。

WL_HOME/server/db/oracle/817
WL_HOME/server/db/oracle/920

2. Leasingユーザーとしてデータベースに接続します。

3. leasing.ddlスクリプトをSQL*Plusで実行します。

SQL> @copy_location/leasing.ddl;

14.3 管理コンソールによるリース用のGridLinkデータ・ソースの作成

Oracle WebLogic Server管理コンソールでリース・テーブルのGridLinkデータ・ソースを作成します。

GridLinkデータ・ソースを作成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」の「ロックして編集」をまだ選択していない場合は選択して、「次へ」をクリックします。

3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

4. データ・ソースの概要ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次の内容を入力します。

- 「名前」フィールドにデータ・ソースの論理名を入力します。例: Leasing

- JNDIの名前を入力します。例: jdbc/leasing

- データベース・ドライバには、Oracle Driver (Thin) for GridLink Connections Versions: 11以上を選択します。

- 「次へ」をクリックします。

5. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」を選択解除して「次へ」をクリックします。

6. 「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。

7. 次の接続プロパティを入力します。

- サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。例:

soaedg.mycompany.com

- ホスト名とポート: 使用中のRACデータベースのSCANアドレスとポートを入力します。このアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せれば識別できます。

SQL>show parameter remote_listener;

NAME                 TYPE        VALUE

--------------------------------------------------

remote_listener     string      db-scan.mycompany.com

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。次に例を示します。

custdbhost1-vip.mycompany.com (port 1521)

および

custdbhost2-vip.mycompany.com (1521)

Oracle Database 10gでは、Oracle RACデータベースへの接続にマルチ・データ・ソースを使用します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- ポート - データベース・サーバーが接続リクエストをリスニングするポートを入力します。

- データベース・ユーザー名: Leasingと入力します。

- パスワード: たとえば、welcome1などを入力します。

- パスワードの確認: もう一度パスワードを入力し、「次へ」をクリックします。

8. 「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。接続が成功したときに表示される通知の一例を示します。

Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=db-scan.mycompany.com)
(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=ps5soaedg.mycompany.com))) succeeded.

「次へ」をクリックします。

9. 「ONSクライアント構成」ページで、次の手順を実行します。

- 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

- ここにも、データベースから報告されたRACデータベースのSCANアドレスおよびONSリモート・ポートを次のように入力し、「追加」をクリックします。

[orcl@db-scan1 ~]$ srvctl config nodeapps -s

ONS exists: Local port 6100, remote port 6200, EM port 2016

- 「次へ」をクリックします。

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベースのONSサービスのホスト名とポートを使用します。次に例を示します。

custdbhost1.mycompany.com (port 6200)

および

custdbhost2.mycompany.com (6200)

10. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。
接続が成功したときに表示される通知の一例を示します。

Connection test for db-scan.mycompany.com:6200 succeeded.

「次へ」をクリックします。

11. 「ターゲットの選択」ページでSOA_Clusterをターゲットとして選択し、「クラスタのすべてのサーバー」を選択します。

12. 「終了」をクリックします。

13. 「変更のアクティブ化」をクリックします。

14.4 ノード・マネージャのプロパティ・ファイルの編集

サーバーが稼働している2つのノード上でノード・マネージャのプロパティ・ファイルを編集します。nodemanager.propertiesファイルは次のディレクトリにあります。

WL_HOME/common/nodemanager

次のプロパティを追加してサーバー移行が正常に動作するようにします。

- Interface

Interface=eth0

このプロパティは浮動IP (eth0など)のインタフェース名を指定します。

注意:

eth0:1やeth0:2のようなサブ・インタフェースは指定しないでください。このインタフェースは、:0も:1も指定しないで使用します。ノード・マネージャのスクリプトは、:Xに対応した各種のIPを横断して、どれを追加または削除するかを判定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

- NetMask

NetMask=255.255.255.0

このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。

- UseMACBroadcast

UseMACBroadcast=true

このプロパティはARPパケットを送信する際にノードのMACアドレスを使用するかどうかを指定します。つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。

これらのプロパティが適用されていることをノード・マネージャの出力(ノード・マネージャが起動したシェル)で確認します。それ以外の場合、移行中に問題が発生する可能性があります。出力は次のようになります。

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

注意:

サーバーのプロパティ(起動プロパティ)が設定されており、ノード・マネージャがサーバーをリモートで起動できる場合には、次の手順は必要ありません。

1. nodemanager.propertiesファイルのStartScriptEnabledプロパティをtrueに設定していない場合はtrueに設定します。これは、ノード・マネージャが管理対象サーバーを起動するために必要です。

2. WL_HOME/server/bin/ディレクトリにあるstartNodeManager.shスクリプトを実行し、ノード1とノード2でノード・マネージャを起動します。

注意:

共有記憶域のインストールからノード・マネージャを実行している場合、同じnodemanager.propertiesファイルを使用する複数のノードが起動します。ただし、NetMaskプロパティやInterfaceプロパティにはノードごとに異なる値が必要です。この場合、環境変数を使用してノードごとに個別のパラメータを指定します。たとえば、SOAHOSTnで異なるインタフェース(eth3)を使用するには、SOAHOSTn> export JAVA_OPTIONS=-DInterface=eth3としてInterface環境変数を使用します。この環境変数をシェルに設定した後、ノード・マネージャを起動します。

14.5 wlsifconfig.shスクリプトの環境およびスーパー・ユーザー権限の設定

wlsifconfig.shスクリプトの環境およびスーパーユーザー権限を設定します。

表14-1に示すファイルをPATH環境変数で指定していることを確認します。

表14-1 PATH環境変数に必要なファイル

ファイル

ディレクトリの場所

wlsifconfig.sh

ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domain

WL_HOME/common/nodemanager

パスワードによる制限を設けずにsudo権限をWebLogicユーザー(oracle)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

セキュリティ上の理由から、sudoの付与はwlsifconfig.shスクリプトの実行に必要なコマンドの一部に限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する手順は次のとおりです。

注意:

この手順に適するsudo権限とシステム権限については、システム管理者に問い合せてください。

WebLogicユーザー(oracle)がこのスクリプトを実行できることを確認します。sudo実行権限をoracleおよびifconfigとarpingに付与するエントリを記述した/etc/sudoersの例を次に示します。

パスワードによる制限を設けずにsudo権限をWebLogicユーザー('oracle')に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

14.6 サーバー移行ターゲットの構成

サーバー移行ターゲットを構成します。クラスタ移行を構成することにより、DataSourceForAutomaticMigrationプロパティがtrueに設定されます。

クラスタ内の移行を構成する手順は次のとおりです。

1. http://<host>:<adminPort>/consoleのOracle WebLogic Server管理コンソールにログインします。通常、adminPortはデフォルトの7001です。

2. 「ドメイン構造」ウィンドウの「環境」を開き、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。

3. 表の「名前」列で、移行を構成するクラスタ(SOA_Cluster)をクリックします。

4. 「移行」タブをクリックします。

5. 「ロックして編集」をクリックします。

6. 「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。この場合は、「SOAHOST1」と「SOAHOST2」を選択します。

7. 自動移行に使用するデータ・ソースを選択します。この場合は、リース・データソースを選択します。

8. 「保存」をクリックします。

9. 「変更のアクティブ化」をクリックします。

10. サーバー移行の候補となるマシンを設定します。この作業は、次の手順に従ってすべての管理対象サーバーで実行する必要があります。

1. 「ロックして編集」をクリックします。

2. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。

3. 移行を構成するサーバーを選択します。

4. 「移行」タブをクリックします。

5. 「移行の構成」セクションの「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。「WLS_SOA1」に対しては「SOAHOST2」を選択します。「WLS_SOA2」に対しては「SOAHOST1」を選択します。

6. 「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。

アプリケーションとリソースのターゲット設定の詳細は、付録B「アプリケーションとリソースのサーバーへのターゲット設定」を参照してください。

7. 「変更のアクティブ化」をクリックします。

8. 管理サーバーと、サーバー移行が構成されているサーバーを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

ヒント:

「サーバーの概要」ページの「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動すると、サーバーを実行しているマシンを確認できます。このサーバーが自動的に移行すると、構成と異なる内容になります。

14.7 サーバー移行のテスト

サーバーの移行が適切に行われていることを確認する手順は次のとおりです。

ノード1からテストする手順は次のとおりです。

1. WLS_SOA1管理対象サーバーを停止します。

kill -9 pid

PIDには管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノードのPIDを識別できます。

ps -ef | grep WLS_SOA1

2. ノード・マネージャのコンソールを確認します。WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_SOA1の2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。

ノード2からテストする手順は次のとおりです。

1. ローカルのノード・マネージャ・コンソールを確認します。ノード1でのWLS_SOA1の再起動が前回試行されてから30秒間経過した後に、WLS_SOA1の浮動IPが表示され、サーバーをこのノードで再起動することを示すメッセージがノード2のノード・マネージャにより表示されます。

2. 同じIPでsoa-infraコンソールにアクセスします。

管理コンソールでの確認

管理コンソールを使用して移行を検証することも可能です。

1. 管理コンソールにログインします。

2. 左のコンソールで「ドメイン」をクリックします。

3. 「監視」タブをクリックし、「移行」サブタブをクリックします。
「移行の状態」の表に、移行の状態に関する情報が表示されます。

図14-1 管理コンソールの「移行の状態」画面

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

15 エンタープライズ・デプロイメントとOracle Identity Managementの統合

この章では、Oracle SOA SuiteをOracle Identity Managementと統合する方法について説明します。ここでは、次の項目について説明します。

- 第15.1項「Oracle Identity Managementとの統合の概要」

- 第15.2項「資格証明ストアの構成」

- 第15.3項「ポリシー・ストアの構成」

- 第15.4項「資格証明およびポリシーの再関連付け」

- 第15.5項「Oracle Access Manager 10gの統合」

- 第15.6項「Oracle Access Manager 11gの統合」

- 第15.7項「Identity Management構成のバックアップ」

15.1 Oracle Identity Managementとの統合の概要

Oracle Fusion Middlewareエンタープライズ・デプロイメントをOracle Identity Manager 10gまたは11gと統合できます。次の項では、資格証明ストアとポリシー・ストアの最初の構成方法とそれらの資格証明ストアおよびポリシー・ストアの再関連付けの方法を説明し、Oracle Identity Manager 10gまたは11gと統合します。

表15-1は、Oracle Identity Manager 10gをOracle SOAエンタープライズ・デプロイメントに統合するための大まかな手順を示しています。

表15-2は、Oracle Identity Manager 11gをOracle SOAエンタープライズ・デプロイメントに統合するための大まかな手順を示しています。

注意:

Oracle Identity Managementとの統合時には、Oracle Identity Managementサーバーで現在使用されているトランスポート・モードを使用します。たとえば、オープン、簡易、証明書などです。

表15-1 Oracle Identity Manager 10gとの統合手順

手順

説明

詳細

資格証明ストアの構成

Oracle Fusion Middleware SOA Suiteエンタープライズ・デプロイメント・トポロジの資格証明ストアとしてOracle Internet Directory LDAPを構成します。

第15.2項「資格証明ストアの構成」

ポリシー・ストアの構成

Oracle Fusion Middleware SOA Suiteエンタープライズ・デプロイメント・トポロジのポリシー・ストアとしてOracle Internet Directory LDAPを構成します。

第15.3項「ポリシー・ストアの構成」

OAM構成ツールの使用

OAM構成ツール(oamcfg)は、一連のスクリプトを起動して必要なポリシーを設定します。

第15.5.3項「OAM構成ツールの使用」

WebGateのインストールと構成

各WEBHOSTnマシンにWebGateをインストールし、Web層を保護します。

第15.5.4項「Webゲートのインストールと構成」

Oracle BAMのSOA_EDG_AGでのCacheControlヘッダーの変更

SOA_EDG_AGアクセス・ゲートでCacheControlヘッダーの設定を変更します。

第15.5.5項「Oracle BAMのSOA_EDG_AGでのCacheControlヘッダーの変更」

WebGateのIP検証の構成

アクセス・システム・コンソールを使用して、WebGateのIP検証を構成します。

第15.5.6項「WebゲートのIP検証の構成」

WebLogic認証プロバイダの設定

構成ファイルのバックアップ、OAM IDアサータの設定およびプロバイダの順序設定によって、WebLogic認証プロバイダを設定します。

第15.5.7項「WebLogic認証プロバイダの設定」

表15-2 Oracle Identity Manager 11gとの統合手順

手順

説明

詳細

資格証明ストアの構成

Oracle Fusion Middleware SOA Suiteエンタープライズ・デプロイメント・トポロジの資格証明ストアとしてOracle Internet Directory LDAPを構成します。

第15.2項「資格証明ストアの構成」

ポリシー・ストアの構成

Oracle Fusion Middleware SOA Suiteエンタープライズ・デプロイメント・トポロジのポリシー・ストアとしてOracle Internet Directory LDAPを構成します。

第15.3項「ポリシー・ストアの構成」

WebGateのインストール

HTTPサーバーがすでにインストールされている各WEBHOSTマシンにWebGateをインストールします。

第15.6.3項「WebGateのインストール」

WebGateエージェントの登録

RREGツールを使用したWebGateエージェントの登録

第15.6.4項「WebGateエージェントの登録」

soa-infraのBAMWorkflowAdminアプリケーション・ロールのロール・メンバーの設定

ユーザーweblogicを持たないアイデンティティ・ストアにドメインを関連付ける場合は、アプリケーション・ロールBAMWorkflowAdminに別の有効なユーザーを割り当てる必要があります。

第15.6.5項「soa-infraのBPMWorkflowAdminアプリケーション・ロールのロール・メンバーの設定」

WebLogic認証プロバイダの設定

構成ファイルのバックアップ、OAM IDアサータの設定およびプロバイダの順序設定によって、WebLogic認証プロバイダを設定します。

第15.6.6項「WebLogicオーセンティケータのセットアップ」

15.2 資格証明ストアの構成

Oracle Fusion Middlewareでは、WebLogicドメインで異なるタイプの資格証明ストアおよびポリシー・ストアを使用できます。ドメインでは、XMLファイルまたは様々なタイプのLDAPプロバイダに基づいてストアを使用できます。ドメインがLDAPストアを使用する場合は、ポリシーと資格証明のデータはすべて、一元化されたストアで保持および保守されます。ただし、XMLポリシー・ストアを使用している場合、管理対象サーバーへの変更は、同じドメイン・ホームを使用していなければ管理サーバーには伝播されません。Oracle Fusion Middleware SOA Suiteエンタープライズ・デプロイメント・トポロジでは、管理サーバーと管理対象サーバーで異なるドメイン・ホームを使用するので、整合性および一貫性を保持するために、ポリシー・ストアおよび資格証明ストアとしてLDAPストアを使用する必要があります。デフォルトでは、Oracle WebLogic Serverドメインはポリシー・ストアにXMLファイルを使用します。次の各項では、資格証明およびポリシーのデフォルトのストアをOracle Internet Directory LDAPに変更するために必要な手順について説明します。

注意:

ポリシー・ストアと資格証明ストアのバックエンド・リポジトリは、同じ種類のLDAPサーバーを使用する必要があります。この一貫性を保持するために、一方のストアを再関連付けるともう一方も再関連付けることになります。つまり、資格証明ストアとポリシー・ストアの両方の再関連付けは、Enterprise Manager Fusion Middleware ControlまたはWLSTコマンドreassociateSecurityStoreを使用して、1つの単位として実行されます。詳細は、第15.4項「資格証明およびポリシーの再関連付け」を参照してください。

資格証明ストアは、セキュリティ・データ(資格証明)のリポジトリです。資格証明には、ユーザー名とパスワードの組合せ、チケットまたは公開鍵証明書を保持できます。資格証明は、プリンシパルをサブジェクトに移入する際の認証時、さらにはサブジェクトが実行できるアクションを決定する際の認可時に使用されます。この項では、Oracle Fusion Middleware SOA Suiteエンタープライズ・デプロイメント・トポロジの資格証明ストアとしてOracle Internet Directory LDAPを構成する手順について説明します。資格証明ストアの構成の詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』の資格証明ストアの構成に関する章を参照してください。

次の各項では、資格証明ストアの構成について説明します。

- 第15.2.1項「LDAP認証プロバイダの作成」

- 第15.2.2項「WebLogic管理者のLDAPへの移行」

- 第15.2.3項「ドメインの資格証明ストアの再関連付け」

15.2.1 LDAP認証プロバイダの作成

この項では、WebLogic Server管理コンソールを使用して、LDAP認証プロバイダを作成する方法について説明します。

前提条件

LDAP認証プロバイダを作成する前に、関連構成ファイルをバックアップする必要があります。

ORACLE_BASE/admin/domain_name/aserver/domain_name/config/config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/jps-config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/system-jazn-data.xml

次のディレクトリにある、管理サーバーのboot.propertiesファイルをバックアップします。

ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/security

LDAPを使用するように資格証明ストアを構成する手順は次のとおりです。

1. WebLogic Serverコンソールにログインします。

2. 左のナビゲーション・バーにある「セキュリティ・レルム」リンクをクリックします。

3. myrealmデフォルト・レルム・エントリをクリックして構成します。

4. このレルムにある「プロバイダ」タブを開きます。

5. このレルム用に構成したDefaultAuthenticatorプロバイダがあることを確認します。

6. 「ロックして編集」をクリックします。

7. 「新規」ボタンをクリックし、新しいプロバイダを追加します。

8. Oracle Internet Directoryを使用する場合はOIDAuthenticator、Oracle Virtual Directoryを使用する場合はOVDAuthenticatorのように、プロバイダの名前を入力します。

9. 認証プロバイダのリストから、OracleInternetDirectoryAuthenticator (Oracle Internet Directoryが使用される場合)、またはOracleVirtualDirectoryAuthenticator (Oracle Virtual Directoryが使用される場合)のいずれかのタイプを選択し、「OK」をクリックします。

10. 「プロバイダ」画面で、新しく作成した認証プロバイダをクリックします。

11. 「制御フラグ」を「SUFFICIENT」に設定します。このフラグは、この認証プロバイダによって正常に認証されたユーザーは、その認証を受け入れたうえで、他の認証プロバイダを呼び出さないようにすることを示しています。認証に失敗した場合、そのユーザーは、チェーンにある次の順番の認証プロバイダに引き継がれます。移行のすべての認証プロバイダの制御フラグも「SUFFICIENT」に設定されていることを確認してください。特に「DefaultAuthenticator」を確認し、その制御フラグを「SUFFICIENT」に設定します。

12. 「保存」をクリックしてこの設定を保存します。

13. 「プロバイダ固有」タブを開き、LDAPサーバーの詳細情報を入力します。

14. 次の表に示すように、使用しているLDAPサーバーに固有の詳細情報を入力します。

パラメータ

値

値の説明

ホスト

例: oid.mycompany.com

LDAPサーバーのサーバーID。

ポート

例: 636

LDAPサーバーのポート番号。

プリンシパル

例: cn=orcladmin

LDAPサーバーへの接続に使用されるLDAPユーザーのDN。

資格証明

なし

LDAPサーバーへの接続に使用されるパスワード。

SSL有効

チェック済

LDAPサーバーに接続するときにSSLプロトコルを使用するかどうかを指定します。

ユーザー・ベースDN

例: cn=users,dc=us,dc=mycompany,dc=com

ユーザーが開始時に使用するDNを指定します。

グループ・ベースDN

例: cn=groups,dc=us,dc=mycompany,dc=com

グループ・ノードを指すDNを指定します。

取得したユーザー名をプリンシパルとして使用する

チェック済

オンにする必要があります。

「保存」をクリックします。

15. 「変更のアクティブ化」をクリックして、変更を伝播します。

認証プロバイダの並替え

OID/OVD認証プロバイダおよびデフォルト認証プロバイダを並べ替えて、それぞれの認証プロバイダの制御フラグが次のように設定されていることを確認します。

認証プロバイダの順序を設定する手順は次のとおりです。

1. WebLogicコンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 「SecurityRealms」→デフォルト・レルム名→「Providers」に移動します。

4. OID/OVD認証プロバイダおよびデフォルト認証プロバイダの制御フラグが次のように設定されていることを確認し、これらの認証プロバイダを並べ替えます。

- OID LDAP認証プロバイダ(またはOVD LDAP認証プロバイダ): SUFFICIENT

- デフォルト認証プロバイダ: SUFFICIENT

5. 「OK」をクリックします。

6. 「変更のアクティブ化」をクリックして、変更を伝播します。

7. 管理サーバーとすべての管理対象サーバーを再起動します。

15.2.2 WebLogic管理者のLDAPへの移行

この項では、Oracle Fusion Middleware SOA Suiteエンタープライズ・デプロイメントWebLogicドメインを管理するための、新しい管理ユーザーおよびグループのプロビジョニングの詳細について説明します。この項で説明するタスクは次のとおりです。

- 第15.2.2.1項「LDAPディレクトリへの管理ユーザーおよび管理グループのプロビジョニング」

- 第15.2.2.2項「管理ロールの管理グループへの割当て」

- 第15.2.2.3項「boot.propertiesファイルの更新およびシステムの再起動」

15.2.2.1 LDAPディレクトリへの管理ユーザーおよび管理グループのプロビジョニング

この項の冒頭で述べたように、複数のWebLogicドメインのユーザーおよびグループは、中央のLDAPユーザー・ストアにプロビジョニングできます。そのような場合、あるWebLogic管理ユーザーがエンタープライズ内のすべてのドメインにアクセスできてしまうことにもなります。これはお薦めしません。WebLogic管理ユーザーがすべてのドメインにアクセスできるような状況にならないようにするために、プロビジョニングされるユーザーおよびグループには、ディレクトリ・ツリー内で一意の識別名を付与しておく必要があります。このガイドで説明するSOAエンタープライズ・デプロイメントのWebLogicドメインでは、管理ユーザーおよびグループは、次のDNでプロビジョニングされます。

- 管理ユーザーDN:

cn=weblogic_soa,cn=Users,dc=us,dc=mycompany,dc=com

- 管理グループDN:

cn=SOA Administrators,cn=Groups,dc=us,dc=mycompany,dc=com

管理ユーザーおよび管理グループをOracle Internet Directoryにプロビジョニングする手順は次のとおりです。

1. 次に示す内容を指定してadmin_user.ldifという名前のldifファイルを作成し、保存します。

dn: cn=weblogic_soa, cn=Users, dc=us, dc=mycompany, dc=com
orclsamaccountname: weblogic_soa
givenname: weblogic_soa
sn: weblogic_soa
userpassword: <password>
mail: weblogic_soa
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: orcluser
objectclass: orcluserV2
uid: weblogic_soa
cn: weblogic_soa
description: Admin User for the SOA Domain

2. ORACLE_HOME/binディレクトリにあるldapaddコマンドを実行して、Oracle Internet Directoryにユーザーをプロビジョニングします。

注意:

ここで使用するORACLE_HOMEは、Oracle Internet Directoryが存在するアイデンティティ管理インストールのORACLE_HOMEです。ldapaddコマンドが成功するには、ORACLE_HOME環境変数を設定する必要があります。

たとえば、次のように指定します(この例では読みやすくするためにコマンドを2行にわたり記載していますが、実際にはコマンドは1行で入力してください)。

OIDHOST1> ORACLE_HOME/bin/ldapadd -h oid.mycompany.com -p 389 -D
cn="orcladmin" -w <password> -c -v -f admin_user.ldif

3. 次に示す内容を指定してadmin_group.ldifという名前のldifファイルを作成し、保存します。

dn: cn=SOA Administrators, cn=Groups, dc=us, dc=mycompany, dc=com
displayname: SOA Administrators
objectclass: top
objectclass: groupOfUniqueNames
objectclass: orclGroup
uniquemember: cn=weblogic_soa,cn=users,dc=us,dc=mycompany,dc=com
cn: SOA Administrators
description: Administrators Group for the SOA Domain

4. ORACLE_HOME/bin/ディレクトリにあるldapaddコマンドを実行して、Oracle Internet Directoryにグループをプロビジョニングします(この例では読みやすくするためにコマンドを2行にわたり記載していますが、実際にはコマンドは1行で入力してください)。

OIDHOST1> ORACLE_HOME/bin/ldapadd -h oid.mycompany.com -p 389 -D
cn="orcladmin" -w <password> -c -v -f admin_group.ldif

15.2.2.2 管理ロールの管理グループへの割当て

Oracle Internet Directoryにユーザーおよびグループを追加したら、WebLogicドメインのセキュリティ・レルム内で、グループに管理ロールを割り当てる必要があります。これにより、そのグループに属するすべてのユーザーをそのドメインの管理者にできます。

管理ロールを管理グループに割り当てる手順は次のとおりです。

1. WebLogic Server管理コンソールにログインします。

2. コンソールの左ペインで「セキュリティ・レルム」をクリックします。

3. 「セキュリティ・レルムのサマリー」ページで、「レルム」表の下の「myrealm」をクリックします。

4. 「myrealm」の「設定」ページで、「ロールとポリシー」タブをクリックします。

5. 「レルム・ロール」ページの表「ロール」の「グローバル・ロール」エントリを開きます。すると、「ロール」のエントリが表示されます。「ロール」リンクをクリックして、「グローバル・ロール」ページを表示します。

6. 「グローバル・ロール」ページで、「管理」ロールをクリックして「グローバル・ロールの編集」ページを開きます。

1. 「グローバル・ロールの編集」ページの表「ロール条件」の「条件の追加」ボタンをクリックします。

2. 「述部の選択」ページで、述部のドロップダウン・リストから「グループ」を選択し、「次へ」をクリックします。

3. 「引数の編集」ページのグループ引数フィールドでSOA管理者を指定し、「追加」をクリックします。

7. 「終了」をクリックして、「グローバル・ロールの編集」ページに戻ります。

8. これで、「ロール条件」表にSOA管理者グループのエントリが表示されるようになりました。

9. 「保存」をクリックすると、SOA管理者グループに管理ロールを追加する処理が終了します。

10. Webブラウザを使用してWebLogic Server管理コンソールを開き、変更が正しく行われたことを確認します。ログインにはweblogic_soaユーザーの資格証明を使用します。

注意:

それぞれのSOAアプリケーションには、管理および監視用に事前定義された独自のロールおよびグループがあります。デフォルトでは、「管理者」グループでその作業を実行できます。ただし、「管理者」グループは広範になりすぎることもあります。たとえば、B2B管理者をSOAが稼働するWebLogic Serverドメインの管理者にしたくない場合があります。そのため、「SOA管理者」のような、より具体的なグループを作成することもできます。様々なアプリケーションで、SOA管理者グループによって様々なシステムを管理できるようにするには、必要なロールをSOA管理者グループに追加する必要があります。たとえば、B2Bの管理の場合はSOA管理者グループにB2BAdminロールを追加し、ワークリスト・アプリケーションの管理の場合はSOAAdminロールを追加します。それぞれのケースで必要なロールについては、各コンポーネントの固有のロールを参照してください。

15.2.2.3 boot.propertiesファイルの更新およびシステムの再起動

管理サーバーのboot.propertiesファイルは、Oracle Internet Directoryで作成されたWebLogic管理ユーザーで更新する必要があります。次の手順に従って、boot.propertiesファイルを更新します。

1. SOAHOST1で、次のディレクトリに移動します。

cd ORACLE_BASE/admin/domainName/aserver/domainName/servers/
AdminServer/security

2. 既存のboot.propertiesファイルの名前を変更します。

mv boot.properties boot.properties.backup

3. テキスト・エディタを使用して、securityディレクトリの下にboot.propertiesというファイルを作成します。次のエントリをこのファイルに入力します。

username=weblogic_soa
password=password

4. ファイルを保存します。

5. 次のコマンドを使用して、管理サーバーを停止します。

wls:/nm/domain_name>nmKill("AdminServer")

6. 管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順で起動します。

15.2.3 ドメインの資格証明ストアの再関連付け

構成が済んだら、資格証明ストアとポリシー・ストアを再度関連付けます。Enterprise Manager Fusion Middleware ControlまたはWLSTコマンドreassociateSecurityStoreを使用して、資格証明ストアとポリシー・ストアを再度関連付けます。詳細な手順は、第15.4項「資格証明およびポリシーの再関連付け」を参照してください。

15.3 ポリシー・ストアの構成

ドメインのポリシー・ストアは、システムおよびアプリケーション固有のポリシーのリポジトリです。あるドメインには、そのドメインにデプロイされたすべてのアプリケーションで使用できるポリシーがすべて格納されたストアが1つあります。この項では、Oracle Fusion Middleware SOA Suiteエンタープライズ・デプロイメント・トポロジのポリシー・ストアとして、Oracle Internet Directory LDAPを構成する手順について説明します。この手順は、2つの部分で構成されています。

- サーバー・ディレクトリでのノードの設定

- ドメイン・ポリシー・ストアの再関連付け

ポリシー・ストアの構成の詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』のOPSS認可およびポリシー・ストアに関する章を参照してください。

15.3.1 サーバー・ディレクトリでのノードの設定

ポリシー・ストアとして使用されるLDAPサーバー・ディレクトリ(Oracle Internet Directory)に正しくアクセスできるようにするには、サーバー・ディレクトリにノードを設定する必要があります。この手順はOracle Internet Directory管理者が実行する必要があります。

Oracle Internet Directoryサーバーに適切なノードを作成する手順は次のとおりです。

1. 次のDNエントリおよびCNエントリを指定して、LDIFファイル(この例ではjpstestnode.ldifと想定)を作成します。

dn: cn=jpsroot_soa
cn: jpsroot_soa
objectclass: top
objectclass: OrclContainer

(前述の文字列jpsroot_soaで示された)ルート・ノードの識別名は、他の識別名と区別できるようにする必要があります。1つのルート・ノードは、複数のWebLogicドメインで共有できます。サブツリーに対する読取りアクセス権および書込みアクセス権がOracle Internet Directory管理者に付与されていれば、このノードを最上位レベルに作成する必要はありません。

2. 次の例に示すように、コマンドldapaddを使用して、Oracle Internet Directoryサーバーにこのデータをインポートします(この例では読みやすくするためにコマンドを2行にわたり記載していますが、実際にはコマンドは1行で入力してください)。

OIDHOST1> ORACLE_HOME/bin/ldapadd -h ldap_host -p ldap_port -D
cn=orcladmin -w password -c -v -f jpstestnode.ldif

3. 次の例に示すように、コマンドldapsearchを使用して、ノードが正しく挿入されていることを確認します(この例では読みやすくするためにコマンドを2行にわたり記載していますが、実際にはコマンドは1行で入力してください)。

OIDHOST1> ORACLE_HOME/bin/ldapsearch -h ldap_host -p ldap_port -D
cn=orcladmin -w password -b "cn=jpsroot_soa" objectclass="orclContainer"

4. Oracle internet DirectoryをLDAPベースのポリシー・ストアとして使用している場合は、INFRADBHOSTsでユーティリティoidstats.sqlを実行して、データベースのパフォーマンスを最適化するためのデータベースの統計を生成します。

ORACLE_HOME/bin/sqlplus

ユーザー名にODSを入力します。ODSユーザーの資格証明を入力するよう求められます。SQL*Plus内では次のコマンドを入力して、統計情報を収集します。

SQLPLUS> @ORACLE_HOME/ldap/admin/oidstats.sql

oidstats.sqlユーティリティは、初期プロビジョニング後に1回だけ実行する必要があります。このユーティリティの詳細は、『Oracle Fusion Middleware Oracle Identity Managementユーザー・リファレンス』を参照してください。

15.3.2 ドメイン・ポリシー・ストアの再関連付け

ファイルまたはLDAPベースのリポジトリから、LDAPベースのリポジトリにポリシー・データを移行して、ポリシー・ストアを再度関連付けます。再関連付けでは、格納データの整合性を維持しながらリポジトリが変更されます。ソース・ポリシー・ストアの各ポリシーに対して再関連付けを行うと、ターゲットのLDAPディレクトリが検索され、一致が見つかると、一致したポリシーが必要に応じて更新されます。何も見つからない場合は、ポリシーがそのまま移行されます。

ドメイン・ポリシー・ストアをインスタンス化したら、ファイルベースまたはLDAPベースのポリシー・ストアを、同じデータを格納するLDAPベースのポリシー・ストアにいつでも再関連付けできます。これをサポートするには、必要に応じてLDAPポリシー・ストアを使用するようにドメインを構成する必要があります。

15.4 資格証明およびポリシーの再関連付け

この項では、WLST reassociateSecurityStoreコマンドによる、ポリシー・ストアと資格証明ストアのOracle Internet Directoryへの再関連付け手順を説明します。

ポリシー・ストアおよび資格証明ストアの再関連付け手順は次のとおりです。

1. SOAHOST1からwlstシェルを起動します。

cd ORACLE_COMMONHOME/common/bin
./wlst.sh

2. 次のようにwlst connectコマンドを使用して、WebLogic管理サーバーに接続します。
構文:

connect('AdminUser','AdminUserPassword','t3://hostname:port')

例:

connect("weblogic","password","t3://ADMINVHN:7001")

3. 次のようにreassociateSecurityStoreコマンドを実行します。
構文:

reassociateSecurityStore(domain="domainName",admin="cn=orcladmin",
password="orclPassword",ldapurl="ldap://LDAPHOST:LDAPPORT",servertype="OID",
jpsroot="cn=jpsroot_soa")

例:

wls:/SOAEDGDomain/serverConfig>reassociateSecurityStore(domain="soaedg_domain",
admin="cn=orcladmin",password="password",ldapurl="ldap://oid.mycompany.com:389",servertype="OID",jpsroot="cn=jpsroot_soa")

このコマンドの出力は次のようになります。

{servertype=OID,jpsroot_soa=cn=jpsroot_soa_idm_idmhost1,admin=cn=orcladmin,
domain=IDMDomain,ldapurl=ldap://oid.mycompany.com:389,password=password}
Location changed to domainRuntime tree. This is a read-only tree with
DomainMBean as the root.

For more help, use help(domainRuntime)

Starting Policy Store reassociation.
LDAP server and  ServiceConfigurator setup done.

Schema is seeded into LDAP server
Data is migrated to LDAP server
Service in LDAP server after migration has been tested to be available
Update of jps configuration is done
Policy Store reassociation done.
Starting credential Store reassociation
LDAP server and  ServiceConfigurator setup done.
Schema is seeded into LDAP server
Data is migrated to LDAP server
Service in LDAP server after migration has been tested to be available
Update of jps configuration is done
Credential Store reassociation done
Jps Configuration has been changed. Please restart the server.

4. コマンドが正しく実行されたら、管理サーバーを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

注意:

資格証明およびポリシーの変更を有効にするには、ドメインのサーバーを再起動する必要があります。

Oracle Internet Directoryの属性のカタログ化

検索フィルタで使用するOracle Internet Directoryの属性に索引を付けます。索引付けは、パフォーマンス向上のためのオプションの手順です。このOracle Internet Directory内の属性への索引付けが済んでいない場合は、catalogツールを使用して索引付けます。

たとえば、orclerolescope属性に索引付けを行う場合は、次のようにします。

catalog connect="orcl" add=true attribute="orclrolescope" verbose="true"

ファイルに複数の属性名を記載してバッチとして処理すると、複数の属性名に索引を付けることができます。

orclrolescope
orclassignedroles
orclApplicationCommonName
orclAppFullName
orclCSFAlias
orclCSFKey
orclCSFName
orclCSFDBUrl
orclCSFDBPort
orclCSFCredentialType
orclCSFExpiryTime
modifytimestamp
createtimestamp
orcljpsassignee

OID属性の索引付けの詳細は、『Oracle Fusion Middleware Oracle Identity Managementユーザー・リファレンス』のタスクおよびカタログの例に関する項を参照してください。

15.5 Oracle Access Manager 10g統合

この項では、Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジのシングル・サインオン・ソリューションとしてOracle Access Manager 10gを設定する方法について説明します。

この項には次のトピックが含まれます:

- 第15.5.1項「Oracle Access Managerの統合の概要」

- 第15.5.2項「Oracle Access Managerの前提条件」

- 第15.5.3項「OAM構成ツールの使用」

- 第15.5.4項「Webゲートのインストールと構成」

- 第15.5.5項「Oracle BAMのSOA_EDG_AGでのCacheControlヘッダーの変更」

- 第15.5.6項「WebゲートのIP検証の構成」

- 第15.5.7項「WebLogic認証プロバイダの設定」

15.5.1 Oracle Access Manager統合の概要

Oracle Fusion Middleware 11g リリース1に推奨されるシングル・サインオン・ソリューションはOracle Access Manager (OAM)です。OAMインストールのインストールおよび構成の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。この章では、既存のOAM 11gインストールおよびその基礎となるディレクトリ・サービスでSOAインストールを構成する手順を説明します。Oracle Internet Directory (OID)またはOracle Virtual Directory (OVD)のいずれか、あるいはこの両方のディレクトリ・サービスの使用をお薦めします。

注意:

このガイドで説明するSOAエンタープライズ・デプロイメント・トポロジでは、シングル・サインオン構成を使用します。ここでは、SOAシステムとシングル・サインオン・システムの両方が、同一のネットワーク・ドメイン(mycompany.com)内に存在しています。複数ドメイン構成の場合は、『Oracle Access Managerアクセス管理ガイド』の第7章「シングル・サインオンの構成」に記載されている、必要な構成手順を参照してください。

SOAコンポジット・アプリケーションおよびOracle Access Managerのログアウトのガイドライン

Oracle Access Managerのログアウト・ガイドラインに準拠するSOAコンポジット・アプリケーション(特に/adfAuthentication?logout=true&end_url=<someURI>によってログアウトを起動するコンポジット)をOracle Access Manager 10g環境に統合するとき、WebGateがend_urlを処理するための追加の設定が必要です。この構成を追加しない場合、ログアウトしても、Oracle Access Manager 10gのWebゲートでend_urlが処理されないので、終了URLへのリダイレクトが行われません。

構成手順の詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。

15.5.2 Oracle Access Managerの前提条件

Oracle Access Manager (OAM)の設定では、Access Managerおよびポリシー・マネージャを保護するポリシーを完備した、OAMインストールが存在することを前提としています。OAMインストールのインストールおよび構成の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。この設定には、スタンドアロンのOracle Virtual Directory (OVD)構成またはその一部としてのOracle Internet Directory (OID)などのディレクトリ・サービスがあります。この章では、SOAをインストールした環境をOIDまたはOVDを使用して構成する際に必要な手順を説明します。

さらに、OAMのインストール環境にはWebGateで構成した専用のWebサーバーが必要です。またこの項では、OAM Webサーバーを委任認証サーバーとして使用する手順についても説明します。

15.5.3 OAM構成ツールの使用

OAM構成ツール(oamcfg)は、一連のスクリプトを起動して必要なポリシーを設定します。そのためには、入力情報として様々なパラメータが必要となります。具体的には次の項目が作成されます。

1. OAMのフォーム認証スキーム

2. WebLogic Serverでの認証を可能にするポリシー

3. Web層にあるOracle HTTP Server WebGateで構成済アプリケーションを保護できるようにOAMで指定するWebGateエントリ

4. 選択したシナリオに応じたホスト識別子(指定しない場合は、デフォルトのホスト識別子が使用されます) アプリケーション固有のURLを保護するポリシーと保護しないポリシー

この項の項目は次のとおりです。

- 第15.5.3.1項「OAM構成ツールの実行の前提条件」

- 第15.5.3.2項「OAM構成ツールの実行」

- 第15.5.3.3項「ポリシー・ドメインおよびアクセス・ゲートを正常に作成したことの確認」

- 第15.5.3.4項「ホスト識別子の更新」

- 第15.5.3.5項「WebGateプロファイルの更新」

- 第15.5.3.6項「アクセス・サーバーの追加」

- 第15.5.3.7項「委任フォーム認証の構成」

15.5.3.1 OAM構成ツールの実行の前提条件

OAM構成ツールを実行する前に次の前提条件を確認します。

- パスワード: セキュアなパスワードを作成します。このパスワードは、この後に作成するWebGateインストールのパスワードとして使用します。

- LDAPホスト: 高可用性やエンタープライズ・デプロイメントの構成の場合は、ディレクトリ・サーバーのホスト名またはロード・バランサのアドレスを用意します。

- LDAPポート: ディレクトリ・サーバーのポートを用意します。

- LDAP USER DN: LDAP管理ユーザーのDNを用意します。これは「cn=orcladmin」などの値です。

- LDAPパスワード: LDAP管理ユーザーのパスワードを用意します。

- oam_aa_host: Oracle Access Managerのホスト名を用意します。

- oam_aa_port: Oracle Access Managerのポートを用意します。

15.5.3.2 OAM構成ツールの実行

OAM構成ツールは次の場所にあります。

ORACLE_COMMON_HOME/modules/oracle.oamprovider_11.1.1

ORACLE_COMMON_HOMEは構成ツールを実行するマシンによって異なります。このツールは、必要なインストール・ファイルがあればすべてのマシンから実行できます。この項で説明する手順では、SOAHOST1からツールを実行します。

OAM構成ツールは、保護されているリソースやパブリック・リソースをOAMシステムに登録する手段を提供します。OAMシステムに追加される、保護されているリソースのリストは次のとおりです。

/integration/worklistapp
/integration/worklistapp/.../*
/workflow/sdpmessagingsca-ui-worklist
/workflow/sdpmessagingsca-ui-worklist/.../*
/b2bconsole
/b2bconsole/.../*
/sdpmessaging/userprefs-ui
/sdpmessaging/userprefs-ui/.../*
/DefaultToDoTaskFlow
/DefaultToDoTaskFlow/.../*
/em
/em/.../*
/console
/console/.../*
/soa/composer
/soa/composer/.../
/OracleBAM (For BAM systems only)
/OracleBAM/.../* (For BAM systems only)
/BAM/composer (For BAM systems only)
/BAM/composer/.../* (For BAM systems only)
/BAM/workspace
/BAM/workspace/.../*
/soa-infra
/soa-infra/deployer
/soa-infra/events/edn-db-log
/soa-infra/cluster/info
/inspection.wsil/
/sbconsole/
/sbconsole/.../*

パブリック・リソースのリストは次のとおりです。

/soa-infra/services/.../*
/soa-infra/directWSDL
/soa-infra/directWSDL/.../*
/OracleBAMWS
/OracleBAMWS/.../*
/ucs/messaging/webservice
/ucs/messaging/webservice/.../*
/sbinspection.wsil /sbinpection.wsil/.../*
/osb
/osb/.../*
/sbresource
/sbresource/.../*
/b2b/services/ws/
/b2b/services/ws/.../*

「/.../*」は、urlコンテキストの下のすべてのリソースを表します。

OAM構成ツールを実行する手順は次のとおりです。

1. OAM 10gへの登録のため、次のコマンドを使用して1行のコマンド行でOAM構成ツールを実行します。

MW_HOME/jrockit_160_<version>/bin/java -jar oamcfgtool.jar mode=CREATE
app_domain="SOA_EDG"
protected_uris="$URI_LIST"
app_agent_password=<Password_to_be_provisioned_for_App_Agent>
ldap_host=OID.MYCOMPANY.COM
ldap_port=389
ldap_userdn="cn=orcladmin"
ldap_userpassword=<Password_of_LDAP_Admin_User>
oam_aaa_host=OAMHOST1
oam_aaa_port=OAMPORT1

2. 保護するURIのリストを含めるよう、$URI_LIST変数を次のように定義します。

###########################
#Product Name: SOA
###########################

########################
protected_uris
########################

/integration/worklistapp
/workflow/sdpmessagingsca-ui-worklist
/b2bconsole
/sdpmessaging/userprefs-ui
/DefaultToDoTaskFlow
/em
/console
/soa/composer
/soa-infra
/soa-infra/deployer
/soa-infra/events/edn-db-log
/soa-infra/cluster/info
/inspection.wsil
#(For BAM systems only)
/OracleBAM
# For BAM systems only)
/BAM/composer
/BAM/workspace
/sbconsole
/sbconsole/.../*

3. 保護対象またはパブリックとして設定しないURIのリストを含めるよう、$PUBLIC_URI_LIST変数を次のように定義します。

###########################
public_uris
###########################

/soa-infra/services
/soa-infra/directWSDL
/OracleBAMWS
/ucs/messaging/webservice
/sbinspection.wsil
/osb
/b2b/services/ws/
/sbresource

注意:

OAM 10gでは、URL接頭辞に含まれるすべてのリソースは、ポリシーを介してより個別性の高いルールが適用されている場合を除いて、ポリシー・ドメインのデフォルト・ルールによって保護されます。特別な保護パターンを使用する必要がある場合は、10g版の『Oracle Access Managerアクセス管理ガイド』を参照して、使用可能な他のパターンを確認してください。

4. コマンドが正常に実行されたかどうかを確認するには、次の出力を確認します。

Processed input parameters
Initialized Global Configuration
Successfully completed the Create operation
Operation Summary:
Policy Domain: SOA_EDG
Host Identifier: SOA_EDG
Access Gate ID: SOA_EDG_AG

注意:

BAMを後でインストールする場合または別のURLの保護が必要になった場合は、同じapp_domainを使用し、保護するURLをすべて指定して(新しいURLのみではなく)、再度OAM構成ツールを実行します。

15.5.3.3 ポリシー・ドメインおよびアクセス・ゲートを正常に作成したことの確認

ポリシー・ドメインとAccessGateの作成を検証する手順は2つの部分で構成されます。

ポリシー・ドメインを検証する手順は次のとおりです。

1. 次のURLを使用してOracle Access Managerにログオンします。

http://OAMADMINHOST:port/access/oblix/

2. 「ポリシー・マネージャ」をクリックします。

3. 左側のパネルで「ポリシー・ドメイン」リンクをクリックします。
すべてのポリシー・ドメインのリストが表示されます。先ほど作成したドメインがここに表示されます。その接尾辞は_PD(たとえば、SOA_EDG_PD)となります。3番目の列「URL接頭辞」には、このドメインの作成時に指定したURIが表示されます。

4. 先ほど作成したポリシー・ドメインのリンクをクリックします。
このリンクから、このドメインの「一般」エリアに移動できます。

5. 「リソース」タブをクリックします。
指定したURIが表示されます。他のタブをクリックし、他の設定を表示することもできます。

AccessGate構成を検証する手順は次のとおりです。

1. 右上にある「アクセス・システム・コンソール」リンクをクリックします。
これはトグルのように機能し、クリックすると「ポリシー・マネージャ」リンクに切り替わります。

2. 「アクセス・システム構成」タブをクリックします。

3. 左のパネルにある「アクセス・ゲート構成」リンクをクリックします。

4. 検索条件にSOA_EDGと入力し(または第15.5.3.2項「OAM構成ツールの実行」でapp_domain名として使用した他のサブストリングなどを入力)、「実行」をクリックします。

5. 作成したドメインのアクセス・ゲートが表示されたら(アクセス・ゲートの接尾辞は_AGなので、たとえばSOA_EDG_AGなど)、それをクリックすると作成したばかりのアクセス・ゲートの詳細が表示されます。

15.5.3.4 ホスト識別子の更新

OAM構成ツールは、app_domainパラメータの値を使用してポリシー・ドメインのホスト識別子を作成します。構成が正常に機能するためには、ホストに対するすべてのホスト名バリエーションを反映してホスト識別子を更新する必要があります。OAM構成ツールで作成したホスト識別子を更新する手順は次のとおりです。

1. Webブラウザで次のURLを指定し、アクセス・システム・コンソールに移動します。

http://hostname:port/access/oblix

hostnameにはWebPass Oracle HTTP Serverインスタンスを実行しているWebPassのホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. ユーザー名とパスワードの入力を求められたら、管理者としてログインします。「OK」をクリックします。

3. 「アクセス・システム(Access System)」メイン・ページで、「アクセス・システム・コンソール」リンクをクリックします。

4. 「アクセス・システム・コンソール」ページで、「アクセス・システム構成」タブをクリックします。

5. 「アクセス・システム構成」ページで、左下にある「ホスト識別子」をクリックします。

6. 「すべてのホスト識別子をリスト」ページで、OAM構成ツールで作成したホスト識別子をクリックします。たとえば、SOA_EDGを選択します。

7. 「ホスト識別子詳細」ページで「変更」をクリックします。

8. アクセス・システム構成で使用される「優先HTTPホスト」値を追加します。次に、SSOおよびWebGateを使用する、考えられるホスト名のバリエーションをすべて示します。

- webhost1.mydomain.com:7777

- webhost2.mydomain.com:7777

- soahost1vhn1.mycompany.com:8001

- soahost2vhn1.mycompany.com:8001

- soahost1vhn1.mycompany.com:8010

- soahost2vhn1.mycompany.com:8010

- bamhost1.mycompany.com:9001

- bamhost2.mycompany.com:9001

- admin.mycompany.com:80

- adminvhn.mycompany.com:7001

- soahost1vhn1:8001

- soahost2vhn1:8001

- soahost1vhn1:8010

- soahost2vhn1:8010

- adminvhn:7001

- soahost1vhn2:8011

- soahost2vhn2:8011

9. 「キャッシュの更新」の横にあるチェック・ボックスを選択し、「保存」をクリックします。
次のメッセージ・ボックスが表示されます。「現時点でキャッシュを更新すると、システム内のすべてのキャッシュがフラッシュされます。よろしいですか。」

「OK」をクリックして、構成変更の保存を終了します。

10. 「ホスト識別子詳細」ページで変更内容を確認します。

15.5.3.5 WebGateプロファイルの更新

OAM構成ツールでは、app_domainパラメータの値で作成したWebGateプロファイルのPreferred_HTTP_Hostおよびホスト名属性に値が移入されます。正しく機能する構成とするには、この2つの属性の両方を適切な値で更新する必要があります。OAM CFGツールで作成したWebGateプロファイルを更新する手順は次のとおりです。

1. Webブラウザで次のURLを指定し、アクセス・システム・コンソールに移動します。

http://hostname:port/access/oblix

hostnameにはWebPass Oracle HTTP Serverインスタンスを実行しているWebPassのホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. 「アクセス・システム(Access System)」メイン・ページで、「アクセス・システム・コンソール」リンクをクリックし、管理者としてログインします。

3. 「アクセス・システム・コンソール」メイン・ページで、「アクセス・システム構成」をクリックし、左ペインで「アクセス・ゲート構成」リンクをクリックし、アクセス・ゲート検索ページを表示します。

4. 適切な検索条件を入力して、「実行」をクリックし、アクセス・ゲートのリストを表示します。

5. OAM構成ツールで作成したアクセス・ゲートを選択します。たとえば、SOA_EDG_AGを選択します。

6. 「アクセス・ゲート詳細」ページで、「変更」を選択し、「アクセス・ゲートの変更」ページを表示します。

7. 「アクセス・ゲートの変更」ページで、次のように更新します。

- ホスト名: WebGateを実行しているコンピュータの名前にホスト名を更新します(webhost1.mycompany.comなど)。

- 優先HTTPホスト: Preferred_HTTP_Hostを、前述の項で指定したホスト名バリエーションの1つに更新します(admin.mycompany.com:80など)。

- プライマリHTTP Cookieドメイン: ホスト識別子のドメイン接尾辞にプライマリHTTP Cookieドメインを更新します(mycompany.comなど)。

8. 「保存」をクリックします。「これらの変更をコミットしますか。」という内容のメッセージ・ボックスが表示されます。

9. 「OK」をクリックして、構成の更新を終了します。

10. 「アクセス・ゲートの詳細」ページに表示される値を確認し、正常に更新されたことを確認します。

15.5.3.6 アクセス・サーバーの追加

WebGateにアクセス・サーバーを割り当てる手順は次のとおりです。

1. 管理者としてアクセス・システム・コンソールにログインします。

2. 必要に応じて、「アクセス・ゲート」ページの「詳細」に移動します。アクセス・システム・コンソールから、「アクセス・システム構成」を選択して「アクセス・ゲート構成を選択し、WebGateのリンク(SOA_EDG_AG)を選択します。

3. 「アクセス・ゲート」ページの「詳細」で、「アクセス・サーバーをリスト」をクリックします。

4. ページが開き、このWebGateに現在構成されているプライマリ・アクセス・サーバーまたはセカンダリ・アクセス・サーバーが表示されます。
「追加」をクリックします。

5. 「新規アクセス・サーバーの追加」ページで、「サーバーの選択」リストから「アクセス・サーバー」を選択して、「プライマリ・サーバー」を指定し、WebGateの2つの接続を定義します。
「追加」ボタンをクリックすると、関連付けが完了します。

6. ページが開き、アクセス・サーバーとWebGateが関連付けられていることが示されます。リンクをクリックすると概要が表示されます。後で使用する場合に備えてこのページを印刷しておきます。

7. ステップ3から6を繰り返して、さらに多くのアクセス・サーバーをWebGateに関連付けます。

15.5.3.7 委任フォーム認証の構成

OAMインストールとともにインストールしたWebGateにリダイレクトするようにフォーム認証を構成する手順は次のとおりです。

1. 「アクセス・システム・コンソール」を開きます。

2. 「アクセス・システム構成」画面で、左側のバーから「認証管理」を選択します。

3. 「OraDefaultFormAuthNScheme」を選択します。

4. 「変更」をクリックします。

5. 「チャレンジ・リダイレクト」フィールドで、IDMインストールのホストとポートを入力します(http://sso.mycompany.comなど)。

IDMインストールにすでにWebGateがインストールされている必要があります。詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

15.5.4 WebGateのインストールと構成

各WEBHOSTnマシンにWebGateをインストールし、Web層を保護します。

WebGateをインストールし構成する手順は次のとおりです。

1. 次のコマンドを使用して、WebGateインストーラ(取得場所の詳細は、第2.3項「インストールするソフトウェア・コンポーネントの特定」を参照)を起動します。

./Oracle_Access_Manager10_1_4_3_0_linux_OHS11g_WebGate –gui

「ようこそ」画面が表示されます。「次へ」をクリックします。

2. 「顧客情報」画面(図15-1)で、Webサーバーを実行しているユーザー名とユーザー・グループを入力します。「次へ」をクリックして続行します。

図15-1 「顧客情報」画面

3. インストール先画面(図15-2)で、WebGateをインストールするディレクトリを指定します。「次へ」をクリックして続行します。

図15-2 インストール先画面

4. インストールの概要の画面で「次へ」をクリックします。

5. WebGate構成画面(図15-3)の説明に従って、WebGateに必要なGCCランタイム・ライブラリをダウンロードし、「参照」を使用して、このGCCランタイム・ライブラリのローカル・コンピュータ上の場所を指定します。「次へ」をクリックして続行します。

図15-3 ランタイム・ライブラリ画面

6. この段階で、インストーラにより必要なアーティファクトが作成されます。作成が完了したら、「次へ」をクリックして続行します。

7. 「トランスポート・セキュリティ・モード」画面(図15-4)で、「オープン・モード: 暗号化なし」を選択し、「次へ」をクリックして続行します。

図15-4 トランスポート・セキュリティ・モード画面

8. WebGate構成画面で、使用するアクセス・サーバーの詳細を入力します。入力する情報は次のとおりです。

- WebGate ID: OAM構成ツールを実行したときの指定のID

- WebGateのパスワード

- アクセス・サーバーID: OAMアクセス・サーバー構成から報告されたID

- アクセス・サーバーのホスト名: OAMアクセス・サーバー構成から報告された名前

- アクセス・サーバーのポート番号: OAMアクセス・サーバー構成から報告された番号

注意:

アクセス・サーバーのID、ホスト名およびポートは、すべて入力が必須の項目です。

これらの詳細は、Oracle Access Manager管理者から取得できます。「次へ」をクリックして続行します。

図15-5 アクセス・サーバー構成画面

9. 「Webサーバーの構成」画面で「はい」をクリックすると、自動的にWebサーバーが更新されます。「次へ」をクリックして続行します。

10. 次の「Webサーバーの構成画面で、httpd.confファイルが格納されているディレクトリのフルパスを指定します。このファイルは、次のディレクトリに格納されています。

ORACLE_BASE/admin/OHS_Instance/config/OHS/OHS_ComponentName

例:

ORACLE_BASE/admin/ohs_instance2/config/OHS/ohs2/httpd.conf

「次へ」をクリックして続行します。

11. 表示された「Webサーバーの構成」ページに、Webサーバー構成がWebGate向けに変更されたことを示すメッセージが示されます。「はい」をクリックして確認します。

12. Webサーバーをいったん停止してから再起動し、構成の更新を有効にします。「次へ」をクリックして続行します。

13. 表示された「Webサーバーの構成」画面に、次のメッセージが示されます: 「WebサーバーをSSLモードで設定する場合、SSL関連パラメータを使用してhttpd.confファイルを構成する必要があります。SSL構成を手動で調整するには、表示される指示に従ってください。」。「次へ」をクリックして続行します。

14. 次の「Webサーバーの構成」画面に、製品設定とWebサーバーの構成の残りの部分に関する情報が記載されているドキュメントの場所を示すメッセージが表示されます。「いいえ」を選択し、「次へ」をクリックして続行します。

15. 最後の「Webサーバーの構成」画面が表示されます。Webサーバーの構成に関する詳細情報を得るには、手動でブラウザを起動し、該当のHTMLドキュメントを開くように指示するメッセージが表示されます。「次へ」をクリックして続行します。

16. 「Oracle COREid Readme」画面が表示されます。画面の情報を確認し、「次へ」をクリックして続行します。
正常にインストールが完了したことを示すメッセージが、インストールの詳細とともに表示されます。

15.5.5 Oracle BAMのSOA_EDG_AGでのCacheControlヘッダーの変更

一部のOracle BAMオブジェクトを実行するには、それがブラウザのキャッシュまたは一時フォルダに存在している必要があります。Oracle Access ManagerをOracle BAMのシングル・サインオンとして使用する場合、WebページのHTTPキャッシュ・ヘッダーは、セキュリティ上の理由から、デフォルトで「no-cache」に設定されています。これにより、Microsoftサポート技術情報(http://support.microsoft.com/kb/316431)に説明があるように、Internet Explorerから一部のオブジェクトにアクセスできず、Oracle BAMのコンソールで別のメニュー項目をクリックしたときに例外が発生することがあります。このようなエラーが発生しないようにするには、SOA_EDG_AGアクセス・ゲートでCacheControlヘッダーの設定を変更します。

CacheControlヘッダーの設定を変更する手順は次のとおりです。

1. 次のURLを使用して、アクセス・システム・コンソールに移動します。

http://hostname:port/access/oblix

hostnameにはWebPass Oracle HTTP Serverインスタンスを実行しているホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. 「アクセス・システム(Access System)」メイン・ページで、「アクセス・システム・コンソール」リンクをクリックし、管理者としてログインします。

3. 「アクセス・システム・コンソール」メイン・ページで、「アクセス・システム構成」をクリックし、左ペインで「アクセス・ゲート構成」リンクをクリックし、アクセス・ゲート検索ページを表示します。

4. 適切な検索条件を入力して、「実行」をクリックし、アクセス・ゲートのリストを表示します。

5. Oracle Access Manager構成ツールで作成したアクセス・ゲートを選択します。

6. ページの一番下にある「変更」をクリックします。

7. 「CachePragmaHeader」フィールドおよび「CacheControlHeader」フィールドで、「no-cache」フィールドを「private」に置き換えます。

8. ページの一番下にある「保存」をクリックします。

15.5.6 WebgateのIP検証の構成

IP検証により、クライアントのIPアドレスが、シングル・サインオン用に生成されてObSSOCookieに格納されたIPアドレスと同じかどうかが判定されます。IPターミネーションを実行するように構成されたロード・バランサ・デバイスを使用しているシステムにおいては、また認証するWebGateのフロントエンドのロード・バランサがエンタープライズ・デプロイメントのフロントエンドのロード・バランサと異なる場合は、IP検証で問題が発生することがあります。

このような場合に検証が行われないようにロード・バランサを構成する手順は次のとおりです。

1. 次のURLを使用して、アクセス・システム・コンソールに移動します。
http://hostname:port/access/oblix

hostnameにはWebPass Oracle HTTP Serverインスタンスを実行しているホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. 「アクセス・システム(Access System)」メイン・ページで、「アクセス・システム・コンソール」リンクをクリックし、管理者としてログインします。

3. 「アクセス・システム・コンソール」メイン・ページで、「アクセス・システム構成」をクリックし、左ペインで「アクセス・ゲート構成」リンクをクリックし、アクセス・ゲート検索ページを表示します。

4. 適切な検索条件を入力して、「実行」をクリックし、アクセス・ゲートのリストを表示します。

5. Oracle Access Manager構成ツールで作成したアクセス・ゲートを選択します。

6. ページの一番下にある「変更」をクリックします。

7. 「IPValidationException」フィールドに、デプロイメントのフロントエンドに位置するロード・バランサのアドレスを入力します。

8. ページの一番下にある「保存」をクリックします。

15.5.7 WebLogic認証プロバイダの設定

この項では、WebLogic認証プロバイダの設定方法を説明します。

前提条件

LDAP認証プロバイダをまだ作成していない場合は、作成してからこの項を読み進めてください。LDAP認証プロバイダを設定するには、第15.2.1項「LDAP認証プロバイダの作成」の手順を実行します。

この項には次のトピックが含まれます:

- 第15.5.7.1項「構成ファイルのバックアップ」

- 第15.5.7.2項「OAM IDアサータの設定」

- 第15.5.7.3項「プロバイダの順序の設定」

15.5.7.1 構成ファイルのバックアップ

まず、次の関連する構成ファイルをバックアップします。

ORACLE_BASE/admin/domain_name/aserver/domain_name/config/config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/jps-config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/system-jazn-data.xml

管理サーバーのboot.propertiesファイルもバックアップします。

15.5.7.2 OAM IDアサータの設定

Weblogicコンソールを使用してOAM IDアサータを設定します。

OAM IDアサータを設定するには:

1. WebLogicコンソールにログインしていない場合は、ログインします。

2. 次の場所に移動します。

SecurityRealms\Default_Realm_Name\Providers

3. 「新規」をクリックし、ドロップダウン・メニューから「OAM Identity Asserter」を選択します。

4. アサータの名前(OAM ID Asserterなど)を入力し、「保存」をクリックします。

5. 新しく追加したアサータをクリックし、OAMアイデンティティ・アサータの構成画面を確認します。

6. 「制御フラグ」を「REQUIRED」に設定して、「保存」をクリックします。

7. 「プロバイダ固有」タブを開き、必要な設定を次のように構成します。

- プライマリ・アクセス・サーバー: OAMサーバーのエンドポイント情報をHOST:PORT形式で指定します。

- アクセス・ゲート名: アクセス・ゲートの名前(SOA_EDG_AGなど)。

- アクセス・ゲートのパスワード: アクセス・ゲートのパスワード(オプション)。

8. 設定を保存します。

15.5.7.3 プロバイダの順序の設定

プロバイダの順序を設定する手順は次のとおりです。

1. WebLogicコンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 「SecurityRealms」→デフォルト・レルム名→「Providers」に移動します。

4. 「並替え」をクリックします。

5. OAMアイデンティティ・アサータ、OID/OVD認証プロバイダおよびデフォルト認証プロバイダの制御フラグが次のように設定されていることを確認し、これらの認証プロバイダを並べ替えます。

- OAMアイデンティティ・アサータ: REQUIRED

- OID LDAP認証プロバイダ(またはOVD LDAP認証プロバイダ): SUFFICIENT

- デフォルト認証プロバイダ: SUFFICIENT

6. 「OK」をクリックします。

7. 「変更のアクティブ化」をクリックして、変更を伝播します。

8. 管理サーバーとすべての管理対象サーバーを再起動します。

15.6 Oracle Access Manager 11g統合

この項では、Oracle SOAエンタープライズ・デプロイメント・トポロジのシングル・サインオン・ソリューションとしてOracle Access Manager 11gを設定する方法について説明します。

この章の項目は次のとおりです。

- 第15.6.1項「Oracle Access Managerの統合の概要」

- 第15.6.2項「Oracle Access Managerの前提条件」

- 第15.6.3項「WebGateのインストール」

- 第15.6.4項「WebGateエージェントの登録」

- 第15.6.5項「soa-infraのBPMWorkflowAdminアプリケーション・ロールのロール・メンバーの設定」

- 第15.6.6項「WebLogicオーセンティケータのセットアップ」

15.6.1 Oracle Access Manager統合の概要

Oracle Fusion Middleware 11g リリース1に推奨されるシングル・サインオン・ソリューションはOracle Access Manager (OAM)です。OAMインストールのインストールおよび構成の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。ここでは、既存のOAM 11gインストールおよびその基礎となるディレクトリ・サービスでSOAインストールを構成する手順を説明します。Oracle Internet Directory (OID)またはOracle Virtual Directory (OVD)のいずれか、あるいはこの両方のディレクトリ・サービスの使用をお薦めします。

注意:

このガイドで説明するSOAトポロジでは、シングル・サインオン構成を使用します。ここでは、SOAシステムとシングル・サインオン・システムの両方が、同一のネットワーク・ドメイン(mycompany.com)内に存在しています。複数ドメイン構成の場合は、『Oracle Access Managerアクセス管理ガイド』の第7章「シングル・サインオンの構成」に記載されている、必要な構成手順を参照してください。

15.6.2 Oracle Access Managerの前提条件

この項の手順を実行する前に、Access Managersおよびポリシー・マネージャを保護するポリシーを備えた既存のOracle Access Manager (OAM)のインストールが必要です。OAMインストールのインストールおよび構成の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。この設定には、スタンドアロンのOracle Virtual Directory (OVD)構成またはその一部としてのOracle Internet Directory (OID)などのディレクトリ・サービスがあります。この章では、SOAをインストールした環境をOIDまたはOVDを使用して構成する際に必要な手順を説明します。

さらに、OAMのインストール環境にはWebGateで構成した専用のWebサーバーが必要です。またこの項では、OAM Webサーバーを委任認証サーバーとして使用する手順についても説明します。

15.6.3 WebGateのインストール

この項では、HTTPサーバーがすでにインストールされている各WEBHOSTマシンにWebGateをインストールする方法を説明します。

15.6.3.1 GCCライブラリのインストールの前提条件

WebGateをインストールする前に、マシンにサード・パーティ製GCCライブラリをダウンロードおよびインストールする必要があります。次のサードパーティWebサイトから該当するGCCライブラリをダウンロードできます。

http://gcc.gnu.org/

32ビットのLinuxの場合、必要なライブラリはバージョン3.3.2のlibgcc_s.so.1およびlibstdc++.so.5です。表15-3は、LinuxおよびSolarisのGCCサード・パーティ製ライブラリのバージョンを示しています。

表15-3 LinuxおよびSolarisのGCCサードパーティ製ライブラリのバージョン

オペレーティング・システム

アーキテクチャ

GCCライブラリ

必要なライブラリ・バージョン

Linux 32ビット

x86

libgcc_s.so.1

libstdc++.so.5

3.3.2

Linux 64ビット

x64

libgcc_s.so.1

libstdc++.so.6

3.4.6

Solaris 64ビット

SPARC

libgcc_s.so.1

libstdc++.so.5

3.3.2

15.6.3.2 WebGateのインストール

この項では、WebGateをインストールする手順を説明します。

Oracle HTTP Server 11g Webgate for Oracle Access Managerのインストーラ・プログラムはwebgate.zipファイルに含まれています。

WebGateをインストールする手順は次のとおりです。

1. webgate.zipファイルのコンテンツを、ディレクトリに解凍します。
デフォルトでは、このディレクトリはwebgateと名前が付けられています。

2. Disk1ディレクトリをwebgateフォルダの下に移動します。

3. MW_HOME環境変数をWeb層のミドルウェア・ホームに設定します。

export MW_HOME=ORACLE_BASE/product/fmw/web

4. 次のコマンドを使用し、インストーラを開始します。

$ ./runInstaller -jreLoc MW_HOME/jdk

注意:

Oracle HTTP Serverをインストールすると、WebTier_Homeディレクトリの下にjdkディレクトリが作成されます。インストーラの開始時には、このJDK内にあるJREディレクトリの絶対パスを入力する必要があります。

インストーラが起動すると、「ようこそ」画面が表示されます。

5. 「ようこそ」画面で「次へ」をクリックします。

6. 「前提条件のチェック」画面で、「次へ」をクリックします。

7. 「インストール場所の指定」画面で、Oracleミドルウェア・ホームとOracleホームの場所を指定します。

- ORACLE_BASE/product/fmw

- Oracle_OAMWebGate1 (デフォルト名のまま)

注意:

MiddleWareホームには、Oracle Web層のOracleホームがあります。このOracleホームのデフォルト名はOracle_OAMWebGate1で、これはミドルウェア・ホームの下に作成されます。

「次へ」をクリックします。

8. GCCライブラリの指定画面で、GCCライブラリを含むディレクトリを指定し、「次へ」をクリックします。

9. 「インストール・サマリー」画面で情報を確認し、「インストール」をクリックしインストールを開始します。

10. 「インストールの進行状況」画面で、ファイルおよびディレクトリに対して正しい権限を設定するために、ORACLE_HOME/oracleRoot.shスクリプトの実行を求められる場合があります。
「次へ」をクリックして続行します。

11. 「インストール完了」画面で、「終了」をクリックしてインストーラを終了します。

15.6.3.3 インストール後の手順

Oracle HTTP Server 11g Webgate for Oracle Access Managerのインストール後、次の手順を完了します。

1. Oracleホーム下のWebgateの次のディレクトリの下に移動します。

$ cd Webgate_Home/webgate/ohs/tools/deployWebGate

2. コマンド行から次のコマンドを実行し、Webgate_HomeディレクトリからWebgateインスタンスの場所へ必要なエージェント・ビットをコピーします。

$ ./deployWebGateInstance.sh -w ORACLE_BASE/admin/webN/config/OHS/ohsN -oh Webgate_Oracle_Home

ここでWebgate_Oracle_Homeは、次の例で示すように、Oracle HTTP Server Webgateをインストールし、WebgateのOracleホームとして作成したディレクトリです。

MW_HOME/Oracle_OAMWebGate1

次のディレクトリはOracle HTTP Serverのインスタンス・ホームです(Nはインストールの連番で、たとえば、WEBHOST1は1、WEBHOST2は2のようになります)。

ORACLE_BASE/admin/webN/config/OHS/ohsN

注意:

Oracle HTTP Serverのインスタンス・ホームはOracle HTTP Serverの構成後に作成されます。

3. 次のコマンドを実行し、LD_LIBRARY_PATH変数にOracle_Home_for_Oracle_HTTP_Server/libが含まれることを確認します。

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:Oracle_Home_for_Oracle_HTTP_Server/lib

4. 現在の作業ディレクトリから1レベル上位のディレクトリに移動します。

$ cd Webgate_Oracle_Home/webgate/ohs/tools/setup/InstallTools

5. コマンド行で次のコマンドを実行し、apache_webgate.templateをWebgate_HomeディレクトリからWebgateのインスタンスの場所(webgate.confに名前が変更されている)にコピーし、httpd.confファイルを更新してwebgate.confの名前を含めるよう1行追加します。

$ ./EditHttpConf -w ORACLE_BASE/admin/webN/config/OHS/ohsN [-oh Webgate_Oracle_Home] [-o output_file]]

注意:

-oh WebGate_Oracle_Homeパラメータおよび-o output_fileパラメータはオプションです。

ここでWebgate_Oracle_Homeは、次の例で示すように、Oracle HTTP Server Webgate for Oracle Access Managerをインストールし、WebgateのOracleホームとして作成したディレクトリです。

MW_HOME/Oracle_OAMWebGate1

Webgate_Instance_Directoryは、Webgateインスタンス・ホームの場所で、次の例のようにOracle HTTP Serverのインスタンス・ホームと同じです。

MW_HOME/Oracle_WT1/instances/instance1/config/OHS/ohs1

output_fileは、ツールが使用する一時出力ファイルであり、次の例に示すとおりです。

Edithttpconf.log

15.6.4 WebGateエージェントの登録

この項では、WebGateエージェントを登録する手順を説明します。

15.6.4.1 RREGツール

RREGツールはOAM 11gのインストールの一部です。見つからない場合は、次の手順を使用して抽出します。

1. Oracle Access Managerのインストールおよび構成後、次の場所に移動します。

IDM_Home/oam/server/rreg/client

2. コマンド行から、次の例のとおり、gunzipを使用してRREG.tar.gzファイルを解凍します。

gunzip RREG.tar.gz

tar -xvf RREG.tar

エージェントを登録するためのツールは次の場所にあります。

RREG_Home/bin/oamreg.sh

RREG_Homeは、RREG.tar.gz/rregの内容の抽出先ディレクトリです。

RREG構成ツールは、保護されているリソースやパブリック・リソースをOAMシステムに登録する手段を提供します。OAMシステムに追加される、保護されているリソースのリストは次のとおりです。

/integration/worklistapp
/integration/worklistapp/.../*
/integration/services
/integration/services/.../*
/workflow/sdpmessagingsca-ui-worklist
/workflow/sdpmessagingsca-ui-worklist/.../*
/b2bconsole
/b2bconsole/.../*
/sdpmessaging/userprefs-ui
/sdpmessaging/userprefs-ui/.../*
/workflow/DefaultToDoTaskFlow
/workflow/DefaultToDoTaskFlow/.../*
/em
/em/.../*
/console
/console/.../*
/soa/composer
/soa/composer/.../*
/OracleBAM (For BAM systems only)
/OracleBAM/.../* (For BAM systems only)
/bpm/composer (For BPM systems only)
/bpm/composer/.../* (For BPM systems only)
/bpm/workspace (For BPM systems only)
/bpm/workspace/.../* (For BPM systems only)
/soa-infra
/soa-infra/deployer
/soa-infra/events/edn-db-log
/soa-infra/cluster/info
/inspection.wsil/
/sbconsole
/sbconsole/.../*

パブリック・リソースのリストは次のとおりです。

/soa-infra/services/.../*
/soa-infra/directWSDL
/soa-infra/directWSDL/.../*
/OracleBAMWS
/OracleBAMWS/.../*
/b2b/services/ws/
/b2b/services/ws/.../*
/wsm-pm
/wsm-pm/.../*

「/.../*」は、urlコンテキストの下のすべてのリソースを表します。

15.6.4.2 OAM11gRequestファイルの更新

RREG_Home/inputディレクトリの中に、OAM11GRequest.xmlという名前のテンプレート・ファイルがあります。このファイルをコピーおよび編集して、SOAインストールのポリシーを作成します。

oamreg.shスクリプトの実行権限を追加します。

chmod u+x /RREG_Home/bin/oamreg.sh

編集後のファイルは次のようになります。

注意:

$$webtierhost$$、$$oamadminserverport$$および$$oamhost$$を、実際のインストールのホスト名に置換します。

<?xml version="1.0" encoding="UTF-8"?>

<!-- Copyright (c) 2009, 2010, Oracle and/or its affiliates. All rights reserved.

NAME: OAM11GRequest_short.xml - Template for OAM 11G Agent Registration request file
(Shorter version - Only mandatory values - Default values will be used for all other fields)
DESCRIPTION: Modify with specific values and pass file as input to the tool.

-->
<OAM11GRegRequest>
<serverAddress>http://$$oamhost$$:$$oamadminserverport$$</serverAddress>
<hostIdentifier>$$webtierhost$$_soa</hostIdentifier>
<agentName>$$webtierhost$$_soa</agentName>
<applicationDomain>$$webtierhost$$_soa</applicationDomain>
<cachePragmaHeader>private</cachePragmaHeader
<cacheControlHeader>private</cacheControlHeader>
<ipValidation>1</ipValidation>
<ValList ListName="ipValidationExceptions">
<ValListMember Value="10.1.1.1"/>
</ValList>
<logOutUrls>
<url></url>
</logOutUrls>
<protectedResourcesList>
<resource>/integration/worklistapp</resource>
<resource>/integration/worklistapp/.../*</resource>
<resource>/workflow/sdpmessagingsca-ui-worklist</resource>
<resource>/workflow/sdpmessagingsca-ui-worklist/.../*</resource>
<resource>/b2bconsole</resource>
<resource>/b2bconsole/.../*</resource>
<resource>/sdpmessaging/userprefs-ui</resource>
<resource>/sdpmessaging/userprefs-ui/.../*</resource>
<resource>/workflow/DefaultToDoTaskFlow</resource>
<resource>/workflow/DefaultToDoTaskFlow/.../*</resource>
<resource>/em</resource>
<resource>/em/.../*</resource>
<resource>/console</resource>
<resource>/console/.../*</resource>
<resource>/sbconsole</resource>
<resource>/sbconsole/.../*</resource> <-- (For OSB systems only) -->
<resource>/soa/composer</resource>
<resource>/soa/composer/.../*</resource>
<resource>/OracleBAM </resource><!-- (For BAM systems only) -->
<resource>/OracleBAM/.../*</resource><!-- (For BAM systems only) -->
<resource>/bpm/composer</resource> <!-- (For BPM systems only) -->
<resource>/bpm/composer/.../*</resource> <!-- (For BPM systems only) -->
<resource>/bpm/workspace</resource><!-- (For BPM systems only) -->
<resource>/bpm/workspace/.../*</resource><!-- (For BPM systems only) -->
<resource>/soa-infra</resource>
<resource>/soa-infra/deployer</resource>
<resource>/soa-infra/deployer/.../*</resource>
<resource>/soa-infra/events/edn-db-log</resource>
<resource>/soa-infra/events/edn-db-log/.../*</resource>
<resource>/soa-infra/cluster/info</resource>
<resource>/soa-infra/cluster/info/.../*</resource>
<resource>/inspection.wsil</resource>
</protectedResourcesList>
<publicResourcesList>
<resource>/integration/services/.../*</resource>
<resource>/integration/services</resource>
<resource>/soa-infra/directWSDL</resource>
<resource>/b2b/services/ws</resource>
<resource>/b2b/services/ws/../* </resource>
<resource>/sbinspection.wsil</resource> <!-- (For OSB systems only) -->
</publicResourcesList>
<excludedResourcesList>
<resource>/wsm-pm</resource>
<resource>/wsm-pm/.../*</resource>
<resource>/soa-infra/services/.../*</resource>
<resource>/OracleBAMWS</resource> <!-- (For BAM systems only) -->
<resource>/OracleBAMWS/.../*</resource><!-- (For BAM systems only) -->
<resource>/ucs/messaging/webservice</resource>
<resource>/ucs/messaging/webservice/.../*</resource>
<resource>/osb</resource> <!-- (For OSB systems only) -->
<resource>/osb/.../*</resource> <!-- (For OSB systems only) -->
<resource>/sbresource</resource> <!-- (For OSB systems only) -->
<resource>/sbresource/.../*</resource> <!-- (For OSB systems only) -->
</excludedResourcesList>
</OAM11GRegRequest>

15.6.4.3 oamregツールの実行

次のコマンドを使用し、oamregツールを実行します。

$ ./RREG_Home/bin/oamreg.sh inband input/SOAOAM11GRequest.xml

実行すると次のように表示されます。

------------------------------------------------
Welcome to OAM Remote Registration Tool!
Parameters passed to the registration tool are:
Mode: inband
Filename: MW_HOME/Oracle_IDM1/oam/server/rreg/input/SOAOAM11gRequest.xml
Enter your agent username:weblogic
Username: weblogic
Enter agent password:
Do you want to enter a Webgate password?(y/n):
y
Enter webgate password:
Enter webgate password again:
Password accepted. Proceeding to register..
Aug 16, 2010 1:22:30 AM oracle.security.am.engines.rreg.client.handlers.request.OAM11GRequestHandler getWebgatePassword
INFO: Passwords matched and accepted.
Do you want to import an URIs file?(y/n):
n
----------------------------------------
Request summary:
OAM11G Agent Name:WEBHOST1_soa
URL String:WEBHOST1_soa
Registering in Mode:inband
Your registration request is being been sent to the Admin server at: http://oamserver.mycompany.com:7001
----------------------------------------
Inband registration process completed successfully! Output artifacts are created in the output folder.

15.6.4.4 アクセス・ファイルのWEBHOSTへのコピー

次の2つのファイルがRREG_Home/output/$$webtierhost$$_soaに生成されます。

- ObAccessClient.xml

- cwallet.sso

これらのファイルを、WEBHOSTマシン上のWebGateインスタンスの場所にコピーします。

scp ObAccessClient.xml oracle@WEBHOSTN:ORACLE_BASE/admin/webN/config/OHS/ohsN/
webgate/config/

scp cwallet.sso oracle@WEBHOSTN:ORACLE_BASE/admin/webN/config/OHS/ohsN/
webgate/config/

scpコマンドの、Nはインストールの連番で、たとえば、WEBHOST1は1、WEBHOST2は2です。

Web層のインスタンスを再起動してWebGateをアクティブ化します。

15.6.5 soa-infraのBPMWorkflowAdminアプリケーション・ロールのロール・メンバーの設定

ユーザーweblogicを持たないアイデンティティ・ストアにドメインを関連付ける場合は、アプリケーション・ロールBAMWorkflowAdminに別の有効なユーザーを割り当てる必要があります。

このロールを有効なユーザーに割り当てる手順は次のとおりです。

1. この場合は、LDAPストアにSOAAdminという名前のユーザーを作成します。このユーザーがロールに割り当てられます。

2. ロールを割り当てます。この作業は、SOAのOracleホームからWLSTを使用して実行できます。
例:

cd ORACLE_HOME/common/bin/
wlst.sh

connect('weblogic','weblogic', 'SOADMINHOST:7001')
revokeAppRole(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin", principalClass="oracle.security.jps.service.policystore.ApplicationRole", principalName="SOAAdmin")
grantAppRole(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin", principalClass="weblogic.security.principal.WLSUserImpl", principalName="SOAAdmin")

15.6.6 WebLogic認証プロバイダの設定

構成ファイルのバックアップ、OAM IDアサータの設定およびプロバイダの順序設定によって、WebLogic認証プロバイダを設定します。

前提条件

WebLogic認証プロバイダを設定する前に、第15.2.1項「LDAP認証プロバイダの作成」の手順に従ってLDAP認証プロバイダを設定しておく必要があります。まだLDAP認証を作成していない場合は、それを作成してからこの項の続きを実行してください。

この項には次のトピックが含まれます:

- 第15.6.6.1項「構成ファイルのバックアップ」

- 第15.6.6.2項「OAM IDアサータの設定」

- 第15.6.6.3項「プロバイダの順序の設定」

15.6.6.1 構成ファイルのバックアップ

まず、次の関連する構成ファイルをバックアップします。

ORACLE_BASE/admin/domain_name/aserver/domain_name/config/config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/jps-config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fwmconfig/system-jazn-data.xml

さらに、管理サーバー用にboot.propertiesファイルをバックアップします。

15.6.6.2 OAM IDアサータの設定

OAM IDアサータを設定するには:

1. WebLogicコンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 「SecurityRealms」→「<デフォルト・レルム名>」→「Providers」に移動します。

4. 「新規」をクリックし、ドロップダウン・メニューから「OAM Identity Asserter」を選択します。

5. アサータの名前(OAM ID Asserterなど)を入力し、「保存」をクリックします。

6. 新しく追加したアサータをクリックし、OAMアイデンティティ・アサータの構成画面を確認します。

7. 「制御フラグ」を「REQUIRED」に設定します。

8. 「選択済み」タイプで「ObSSOCookie」および「OAM_REMOTE_USER」の2つのオプションを選択します。

9. 設定を保存します。

10. 「変更を適用」をクリックします。

最後にWLSTコンソールにadminとしてログインし、次のコマンドを実行します。

cd /ORACLE_HOME/Oracle_SOA1/common/bin./wlst.sh
addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication",logouturi="/oamsso/logout.html")

15.6.6.3 プロバイダの順序の設定

WebLogic管理コンソールを使用してプロバイダの順序を設定します。

プロバイダの順序を設定する手順は次のとおりです。

1. WebLogicコンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「SecurityRealms」→デフォルト・レルム名→「Providers」に移動します。

4. OAMアイデンティティ・アサータ、OID/OVD認証プロバイダおよびデフォルト認証プロバイダの制御フラグが次のように設定されていることを確認し、これらの認証プロバイダを並べ替えます。

- OAMアイデンティティ・アサータ: REQUIRED

- OID LDAP認証プロバイダ(またはOVD LDAP認証プロバイダ): SUFFICIENT

- デフォルト認証プロバイダ: SUFFICIENT

5. 「OK」をクリックします。

6. 「変更のアクティブ化」をクリックして、変更を伝播します。

7. 管理サーバーとすべての管理対象サーバーを再起動します。

15.7 Identity Management構成のバックアップ

拡張したドメインが正常に動作していることを確認した後、そのドメイン構成をバックアップします。このバックアップは、この後の手順でエラーが発生した場合にすぐにリストアできるようにすることが目的です。構成をローカル・ディスクにバックアップします。エンタープライズ・デプロイメントが完了すれば、このバックアップは破棄してかまいません。エンタープライズ・デプロイメントが完了すれば、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。情報のリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。

この時点で構成をバックアップする手順は次のとおりです。

1. Web層をバックアップする手順は次のとおりです。

1. opmnctlを使用してインスタンスを停止します。

ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME

3. 次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

ORACLE_BASE/admin/instance_name/bin/opmnctl startall

2. データベースをバックアップします。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。

3. 管理サーバーのドメイン・ディレクトリをバックアップしてドメイン構成を保存します。構成ファイルは次のディレクトリにあります。

ORACLE_BASE/ admin/domain_name

管理サーバーをバックアップするには、SOAHOST1で次のコマンドを実行します。

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

16 エンタープライズ・デプロイメント用のトポロジの管理

この章では、トポロジの設定後に実行できる操作について説明します。実行できる操作には、トポロジの監視、スケーリング、バックアップなどがあります。

この章の項目は次のとおりです。

- 第16.1項「トポロジの管理の概要」

- 第16.2項「SOAエンタープライズ・デプロイメント・トポロジにコンポジットおよびアーティファクトをデプロイする際のヒント」

- 第16.3項「SOAインフラストラクチャ・データベースでの領域の管理」

- 第16.4項「UMSドライバの構成」

- 第16.5項「トポロジのスケールアップ(管理対象サーバーを既存ノードに追加)」

- 第16.6項「トポロジのスケールアウト(管理対象サーバーを新しいノードに追加)」

- 第16.7項「管理サーバーの手動フェイルオーバーの検証」

- 第16.8項「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」

- 第16.9項「SQLNet接続のタイムアウト防止」

- 第16.10項「失敗したBPELインスタンスとメディエータ・インスタンスのリカバリ」

- 第16.11項「Webサービスに対するDoS攻撃や再帰的ノード攻撃を防ぐための構成」

- 第16.12項「Oracle Business Activity Monitoring (BAM)構成プロパティ」

- 第16.13項「デプロイメント・プランおよびSOAインフラストラクチャ・アプリケーション更新での共有記憶域の使用」

- 第16.14項「エンタープライズ・デプロイメントのトポロジのトラブルシューティング」

16.1 トポロジの管理の概要

SOAエンタープライズ・デプロイメントを構成したら、この章の情報を使用してトポロジを管理します。

SOAアプリケーションは、様々なコンポーネントで構成されるコンポジットとしてデプロイされます。SOAコンポジット・アプリケーションには次が含まれます。

- ルーティングのためのOracle Mediator、オーケストレーションのためのBPELプロセス、オーケストレーションのためのBAMNプロセス(Oracle BAM Suiteがインストールされている場合)、ワークフロー承認のためのヒューマン・タスク、SOAコンポジット・アプリケーションにJavaインタフェースを統合するためのSpring、ビジネス・ルールを使用するためのデシジョン・サービスなどのサービス・コンポーネント。

- 外部のサービス、アプリケーションおよびテクノロジに対してSOAコンポジット・アプリケーションを接続するバインディング・コンポーネント(サービスと参照)

これらのコンポーネントが、1つのSOAコンポジット・アプリケーションに組み込まれています。この章では、SOAコンポジット・アプリケーションのデプロイのヒントを示します。

SOAコンポジット・アプリケーションの監視の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のSOAコンポジット・アプリケーションの監視に関する項を参照してください。

SOAコンポジット・アプリケーションの管理の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のSOAコンポジット・アプリケーションの監視に関する項を参照してください。

スケール・アップやスケール・アウトなどの方法で、トポロジの拡張が必要になることがあります。スケール・アップとスケール・アウトの違いおよびこれらのタスクの実行方法の詳細は、第16.5項「トポロジのスケールアップ(管理対象サーバーを既存ノードに追加)」および第16.6項「トポロジのスケールアウト(管理対象サーバーを新しいノードに追加)」を参照してください。

構成の変更前後にはトポロジをバックアップします。構成変更後の問題発生に対応するためバックアップしておく必要のあるディレクトリとファイルについては、第16.8項「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」で説明します。

この章では、トポロジの構成後に発生する可能性のある既知の問題の解決方法も示します。

16.2 SOAエンタープライズ・デプロイメント・トポロジにコンポジットおよびアーティファクトをデプロイする際のヒント

この項では、SOAエンタープライズ・デプロイメントにコンポジットおよびアーティファクトをデプロイする際のヒントを示します。コンポジットのデプロイ方法の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のSOAコンポジット・アプリケーションのデプロイに関する章を参照してください。

特定のサーバー・アドレスへのコンポジットのデプロイ

SOAコンポジットをSOAエンタープライズ・デプロイメント・トポロジにデプロイする場合、ロード・バランサ・アドレス(soa.mycompany.com)にではなく、特定のサーバーのアドレスにデプロイします。ロード・バランサ・アドレスにデプロイするには、デプロイヤ・ノードから外部のロード・バランサ・アドレスへの直接接続が必要になることがあり、その接続のために、システムのファイアウォールで追加ポートを開く必要が生じる場合があります。

B2Bコンソールを使用したアグリーメントのデプロイおよびメタデータのパージとインポート

B2Bの場合、アグリーメントのデプロイおよびメタデータのパージとインポートは、B2BコンソールのGUIから実行してください。コマンド行ユーティリティは使用しません。コマンド行ユーティリティを使用してこれらの操作を実行すると、B2Bシステムで不整合やエラーが発生することがあります。

FODデプロイメントに関するその他の指示

SOA Fusion Order Demoをデプロイする場合は、FODのREADMEファイルで指定されたデプロイ手順を実行した後、次の追加手順を実行します。

1. earファイルが各ノードにコピーされるように、Webアプリケーションのbuild.xmlファイルのnostageプロパティをfalseに変更します。FOD_dir\CreditCardAuthorization\binおよびFOD_dir\OrderApprovalHumanTask\binのディレクトリにあるbuild.xmlファイルのCreditCardAuthorizationおよびOrderApprvalHumanTaskを編集して次のフィールドを変更します。

<target name="deploy-application">
<wldeploy action="deploy" name="${war.name}"
source="${deploy.ear.source}" library="false"
nostage="false"
user="${wls.user}" password="${wls.password}"
verbose="false" adminurl="${wls.url}"
remote="true" upload="true"
targets="${server.targets}" />
</target>

これを次のように変更します。

<target name="deploy-application">
<wldeploy action="deploy" name="${war.name}"
source="${deploy.ear.source}" library="false"
nostage="true"
user="${wls.user}" password="${wls.password}"
verbose="false" adminurl="${wls.url}"
remote="true" upload="true"
targets="${server.targets}" />
</target>

2. Webアプリケーションのターゲットを変更して、デプロイが個別のサーバーでなくSOAクラスタにターゲット設定されるようにします。FOD_Dir/binディレクトリにあるFODのbuild.propertiesファイルを編集して、次のフィールドを変更します。

# wls target server (for shiphome set to server_soa, for ADRS use AdminServer)
server.targets=SOA_Cluster (the SOA cluster name in your SOA EDG)

3. JMSシード・テンプレートを変更し、通常の宛先でなく共通分散宛先を使用して、JMSアーティファクトがエンタープライズ・デプロイメントJMSモジュールにターゲット設定するようにします。FOD_DIR\bin\templatesディレクトリにあるcreateJMSResources.seedファイルを編集して、次のフィールドを変更します。

# lookup the SOAJMSModule - it's a system resource
jmsSOASystemResource = lookup("SOAJMSModule","JMSSystemResource")

jmsResource = jmsSOASystemResource.getJMSResource()

cfbean = jmsResource.lookupConnectionFactory('DemoSupplierTopicCF')
if cfbean is None:
print "Creating DemoSupplierTopicCF connection factory"
demoConnectionFactory =
jmsResource.createConnectionFactory('DemoSupplierTopicCF')
demoConnectionFactory.setJNDIName('jms/DemoSupplierTopicCF')
demoConnectionFactory.setSubDeploymentName('SOASubDeployment')
.
topicbean = jmsResource.lookupTopic('DemoSupplierTopic')
if topicbean is None:
print "Creating DemoSupplierTopic jms topic"
demoJMSTopic = jmsResource.createTopic("DemoSupplierTopic")
demoJMSTopic.setJNDIName('jms/DemoSupplierTopic')
demoJMSTopic.setSubDeploymentName('SOASubDeployment')

これを次のように変更します。

jmsSOASystemResource = lookup("SOAJMSModule","JMSSystemResource")

jmsResource = jmsSOASystemResource.getJMSResource()

topicbean=jmsResource.lookupTopic('DemoSupplierTopic_UDD')

if topicbean is None:
print "Creating DemoSupplierTopicC jms topic"
#create a udd - so clustering is automatically working and done
demoJMSTopic = jmsResource.createUniformDistributedTopic("DemoSupplierTopic_UDD")

demoJMSTopic.setJNDIName('@jms.topic.jndi@')
#Replace the subdeployment name with the one that appears in the WLS AdminConsole as listed for the SOAJMSModule

demoJMSTopic.setSubDeploymentName()

else: print "Found DemoSupplierTopic_UDD topic – noop"

16.3 SOAインフラストラクチャ・データベースでの領域の管理

すべてのコンポジットがデータベースを頻繁に使用するわけではありませんが、CUBE_INSTANCEおよびMEDIATOR_INSTANCEスキーマにはかなりの量のデータがサービス・エンジンによって生成されます。データベース領域が不足すると、SOAコンポジットが機能しなくなることがあります。

SOAインフラストラクチャ・データベースでスペースを管理する手順は次のとおりです。

- Oracle Enterprise Manager Fusion Middleware Controlコンソール(のダッシュボードなど)でOracle.fabric.common.FabricInvocationExceptionなどの汎用エラーがないか確認します。

- SOAサーバーのログで次のようなエラーを検索します。

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を使用することはお薦めしません。操作でトランザクション・タイム・アウトが高い確率で発生します。リポジトリ作成ユーティリティには、インスタンスのパージ用に提供されているパッケージがあります。例:

DECLARE
FILTER INSTANCE_FILTER := INSTANCE_FILTER();

MAX_INSTANCES NUMBER;
DELETED_INSTANCES NUMBER;
PURGE_PARTITIONED_DATA BOOLEAN := TRUE;
BEGIN
.
FILTER.COMPOSITE_PARTITION_NAME:='default';
FILTER.COMPOSITE_NAME := 'FlatStructure';
FILTER.COMPOSITE_REVISION := '10.0';
FILTER.STATE := fabric. STATE_UNKNOWN;
FILTER.MIN_CREATED_DATE := to_timestamp('2010-09-07','YYYY-MM-DD');
FILTER.MAX_CREATED_DATE := to_timestamp('2010-09-08','YYYY-MM-DD');
MAX_INSTANCES := 1000;
.
DELETED_INSTANCES := FABRIC.DELETE_COMPOSITE_INSTANCES(
FILTER => FILTER,
MAX_INSTANCES => MAX_INSTANCES,
PURGE_PARTITIONED_DATA => PURGE_PARTITIONED_DATA
);

これによって2010-09-07から2010-09-08の間に作成されたFlatStructureコンポジット(バージョン10)の「UNKNOWN」状態の最初の1000インスタンスが削除されます。提供されるSQLパッケージに含まれている可能性のある操作の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のSOAコンポジット・アプリケーションの管理に関する項を参照してください。正しく消去するには、提供されているスクリプトを常に使用します。composite_dn表からのみ行を削除すると、Oracle Fusion Middleware SOAインフラストラクチャが使用するその他の表の参照が解決されなくなる場合があります。

16.4 UMSドライバの構成

UMSドライバの構成情報は、SOAやBAMのクラスタに自動的には伝播されません。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などです。

フェイルオーバーに備え、強制的にサーバー移行を実行しファイルをソース・ノードからコピーする方法でUMSドライバ構成ファイルを作成します。

たとえば、BAM用のファイルを作成する手順は次のとおりです。

1. WLS_BAM1のドライバをBAMHOST1内で構成します。

2. BAMHOST2へのWLS_BAM1のフェイルオーバーを強制的に実行します。フェイルオーバー・ノード内でUMSドライバ構成用の次のディレクトリ構造を確認します。

cd ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/

(「*」はデプロイメント時にランダムに生成されるディレクトリ名、たとえば「3682yq」を表します)。

3. ドライバ構成ファイルをBAMHOST1からBAMHOST2にリモート・コピーします。

BAMHOST1> scp ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml
oracle@BAMHOST2:ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/

4. これらの変更を有効にするため、ドライバを再起動します。
ドライバを再起動する手順は次のとおりです。

1. Oracle WebLogic管理コンソールにログインします。

2. ナビゲーション・ツリーの環境ノードを開きます。

3. 「デプロイメント」をクリックします。

4. ドライバを選択します。

5. 「停止」→「作業完了時」をクリックし、操作を確認します。

6. ドライバの状態が「準備完了」に変化するまで待ちます(必要に応じて、管理コンソール・ページを更新します)。

7. 再度ドライバを選択し、「起動」→「すべてのリクエストを処理」をクリックして操作を確認します。

ドライバのプロパティが保持されていることを、Oracle Enterprise Manager Fusion Middleware Controlで確認します。

16.5 トポロジのスケールアップ(管理対象サーバーを既存ノードに追加)

トポロジをスケールアップするときには、Fusion Middlewareコンポーネントを使用して構成されている管理対象サーバーまたはWSM-PMを含む管理対象サーバーを実行するノードがすでに存在します。このノードには、共有記憶域内にWebLogic ServerホームとOracle Fusion Middleware SOAホームが存在します。このような既存のインストール(WebLogic Serverホーム、Oracle Fusion Middlewareホーム、ドメイン・ディレクトリなど)を使用して、新しい管理対象サーバーをWLS_SOAおよびWLS_WSMという名前で作成します。WLSまたはSOAのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。

サーバー移行を使用してサーバーのスケール・アップを行う場合は、必要となる容量およびリソース割当てについて計画します。例として、次のシナリオについて考えてみます。

- サーバー1がノード1上にあり、このサーバーはノード2上のサーバー2を使用するクラスタ内サーバー移行を使用します。

- スケールアップ操作によって、ノード1のクラスタにサーバー3が追加されます。これもサーバー移行を使用します。

このシナリオでは、ノード1またはノード2のいずれかですべてのサーバー(サーバー1、サーバー2、サーバー3および管理サーバー)が実行される恐れがあります。つまり、サーバー移行を使用するすべてのサーバーが1つのノード上(サーバー移行候補マシンの構成で定義される)で実行される最悪のケースに対応できるように、各ノードを十分なリソースで設計する必要があるということです。

注意:

スケール・アップの手順は、WSM管理対象サーバーにのみ適用されます。

16.5.1 Oracle SOAのスケールアップ手順

SOAトポロジをスケール・アップする手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールを使用し、WLS_SOA1またはWLS_WSM1をクローニングして新しい管理対象サーバーを作成します。クローニング元の管理対象サーバーとして選択できるのは、新しい管理対象サーバーを実行するノード上にすでに存在しているサーバーです。
管理対象サーバーのクローンを作成するには:

1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。

2. 「ロックして編集」をクリックして、クローニングする管理対象サーバー(たとえばWLS_SOA1)を選択します。

3. 「クローンの作成」をクリックします。

4. 新しい管理対象サーバーの名前をWLS_SOAnにします。nは、新しい管理対象サーバーの識別番号です。ここでは、WLS_SOA1が実行されていたノード1に新しいサーバーを追加します。

以降の手順は、新しいサーバーをSOAHOST1に追加します。このホストではすでにWLS_SOA1が実行されています。

2. リスニング・アドレスには、この新しい管理対象サーバーで使用するホスト名またはIPを指定します。推奨されているとおりにサーバー移行を使用する場合、サーバーを別のノードに移動できるように仮想IP(浮動IPとも呼ばれる)を指定します。仮想IPは、すでに実行されている管理対象サーバーで使用されているものとは別のものである必要があります。

3. WLS_WSMサーバーの場合は、第8.6項「Oracle WSMでのJava Object Cacheの構成」で説明されているように、Java Object Cacheの構成ユーティリティをもう一度実行して、JOC分散キャッシュにこの新しいサーバーを追加します。同じノード内にある複数のWLS_WSMサーバーが同一の検出ポートを使用できます。第8.6項で説明されている手順をWLS_WSMサーバーごとに繰り返して、サーバー・リストを更新します。

4. SOA用およびUMS用のJMSサーバーを、新しい管理対象サーバー上に作成します。

注意:

WLS_WSM管理対象サーバーまたはBAM Webアプリケーション・システムをスケール・アップする場合は、新しい管理対象サーバー上でSOAおよびUMSのJMSサーバーを作成する必要はありません。この手順は、WLS_SOA管理対象サーバーをスケール・アップする場合にのみ必要です。

SOAおよびUMS用のJMSサーバーを作成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述します)、SOAJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms

2. SOA用の新しいJMSサーバーを作成し、SOAJMSServer_Nなどの名前を付けます。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

3. 新しいUMS JMSサーバー用の新しい永続ストアを作成し(UMS JMSサーバーの作成方法は後述します)、UMSJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms

注意:

新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

4. UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

5. UMSJMSSystemResourceのターゲットとしてSOA_Clusterを指定します(拡張操作のときに変更された可能性があるため)。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(クローニングで作成されたWLS_SOAnも含む)が選択されていることを確認してください。

6. SOAおよびUMSのSubDeploymentターゲットを更新して、先ほど作成したJMSサーバーを含めます。
そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA用: SOAJMSModuleおよびUMS用: UMSSYtemResource)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。

注意:

このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXXまたはUMSJMSServerXXXXXXのフォームのランダムな名前で、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。

このサブデプロイメントをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを追加し、SOAの場合はSOAJMSServer_Nを追加します)。

5. 新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順については、第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。

注意:

変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。

Dtangosol.coherence.localhost=SOAHOST1VHNn

6. 管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic

「保存してアクティブ化」をクリックします。

7. 新しいサーバー用の永続ストアを構成します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているように、他のノードから参照可能な場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。

8. 新しい管理対象サーバー用のホスト名検証を無効にします。WLS_SOAN管理対象サーバーを起動および検証する前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にすることができます。
新しいサーバーのクローニング元となっているサーバーでホスト名検証がすでに無効になっている場合は、これらの手順は不要です(ホスト名検証の設定はクローニング後のサーバーに伝播されます)。ホスト名検証を無効にする手順は次のとおりです。

1. Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。

4. 表の「名前」列の「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

9. 新しい管理対象サーバー用のサーバー移行を構成します。Oracle WebLogic Server管理コンソールを使用してサーバー移行を構成する手順は次のとおりです。

注意:

これはスケールアップ操作であるため、ノードにノード・マネージャが存在していること、およびサーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済であることが必要です。新しいSOA管理対象サーバー用の浮動IPも、すでに存在している必要があります。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

2. 表の「名前」列で、移行を構成するサーバーの名前(ハイパーリンクとして表示される)をクリックします。選択したサーバーの「設定」ページが表示されます。

3. 「移行」サブタブをクリックします。

4. 「移行の構成」セクションで、移行に参加するサーバーを「使用可能」ウィンドウから選択して右向き矢印をクリックします。ノード上に存在するサーバーと同じ移行ターゲットを選択してください。
たとえば、SOAHOST1(すでにWLS_SOA1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。SOAHOST2(すでにWLS_SOA2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。

注意:

移行時に複数の管理対象サーバーを同時に実行するには、十分な空きリソースを確保しておく必要があります。

5. 「サーバーの自動移行を有効化」オプションを選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。

6. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

10. 次のように、新しいサーバーを含むようクラスタ・アドレスを更新します。

1. 管理コンソールで、「環境」、「クラスタ」の順に選択します。

2. 「SOA_Cluster」サーバーをクリックします。
SOA_Clusterの設定画面が表示されます。

3. 「ロックして編集」をクリックします。

4. 「クラスタ・アドレス」フィールドに新しいサーバーのアドレスとポートを入力します。例: SOAHOST1VHN1:8011,SOAHOST2VHN1:8011,SOAHOST1VHN1:8001

5. 変更を保存してアクティブ化します。

11. この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。

1. 次のコマンドを使用して、WLS_SOAn管理対象サーバーを停止します。

kill -9 pid

ノードのPID (プロセスID)は次のコマンドで特定できます。

ps -ef | grep WLS_SOAn

2. ノード・マネージャ・コンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。

16.5.2 Oracle BAMのスケールアップ手順

SOAトポロジをスケール・アップする手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールを使用し、WLS_SOA1のクローンを作成して新しい管理対象サーバーにします。クローニング元の管理対象サーバーとして選択できるのは、新しい管理対象サーバーを実行するノード上にすでに存在しているサーバーです。
管理対象サーバーのクローンを作成するには:

1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。

2. 「ロックして編集」をクリックして、クローニングする管理対象サーバー(たとえばWLS_SOA1)を選択します。

3. 「クローンの作成」をクリックします。

4. 新しい管理対象サーバーの名前をWLS_SOAnにします。nは、新しい管理対象サーバーの識別番号です。ここでは、WLS_SOA1が実行されていたノード1に新しいサーバーを追加します。

以降の手順は、新しいサーバーをSOAHOST1に追加します。このホストではすでにWLS_SOA1が実行されています。

2. リスニング・アドレスには、この新しい管理対象サーバーで使用するホスト名またはIPを指定します。推奨されているとおりにサーバー移行を使用する場合、サーバーを別のノードに移動できるように仮想IP(浮動IPとも呼ばれる)を指定します。仮想IPは、すでに実行されている管理対象サーバーで使用されているものとは別のものである必要があります。

3. SOA用およびUMS用のJMSサーバーを、新しい管理対象サーバー上に作成します。
SOA、UMSおよびBAM用のJMSサーバーを作成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述します)、SOAJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms

2. SOA用の新しいJMSサーバーを作成し、SOAJMSServer_Nなどの名前を付けます。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

3. 新しいUMS JMSサーバー用の新しい永続ストアを作成し(UMS JMSサーバーの作成方法は後述します)、UMSJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms

注意:

新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

4. UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

5. 新しいBAMJMSServerの新しい永続ストアを作成します(たとえば、BAMJMSFileStore_N)。このストアのパスを指定します。第4.3項「各種ディレクトリの推奨場所について」で推奨されているとおり、ディレクトリは共有記憶域上にある必要があります。例:

ORACLE_BASE/admin/domain_name/cluster_name/jms

注意:

SOAJMSFileStore_Nを新しいBAM JMSサーバーのストアとして割り当てることも可能です。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

6. BAMの新しいJMSサーバーを作成します(たとえば、BAMJMSServer_N)。このJMSServerにはBAMJMSFileStore_Nを使用します。BAMJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

7. UMSJMSSystemResourceのターゲットとしてSOA_Clusterを指定します(拡張操作のときに変更された可能性があるため)。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(クローニングで作成されたWLS_SOAnも含む)が選択されていることを確認してください。

8. SOA、UMSおよびBAM JMSモジュールのSubDeploymentターゲットを更新して、先ほど作成したJMSサーバーを含めます。
そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA: SOAJMSModule用、BAM: BAMJMSMOdule用およびUMS: UMSSYtemResource用)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。

注意:

このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXX、UMSJMSServerXXXXXXまたはBAMJMSServerXXXXXXの形式によるランダムな名前であり、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。

このサブデプロイメントをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを追加し、SOAの場合はSOAJMSServer_Nを追加します)。「保存してアクティブ化」をクリックします。

4. 新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順については、第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。

注意:

変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。

Dtangosol.coherence.localhost=SOAHOST1VHNn

5. 管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic1

「保存してアクティブ化」をクリックします。

6. 新しいサーバー用の永続ストアを構成します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているように、他のノードから参照可能な場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。

7. 新しい管理対象サーバー用のホスト名検証を無効にします。WLS_SOAN管理対象サーバーを起動および検証する前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にすることができます。
新しいサーバーのクローニング元となっているサーバーでホスト名検証がすでに無効になっている場合は、これらの手順は不要です(ホスト名検証の設定はクローニング後のサーバーに伝播されます)。ホスト名検証を無効にする手順は次のとおりです。

1. Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。

4. 表の「名前」列の「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

8. 新しい管理対象サーバー用のサーバー移行を構成します。Oracle WebLogic Server管理コンソールを使用してサーバー移行を構成する手順は次のとおりです。

注意:

これはスケールアップ操作であるため、ノードにノード・マネージャが存在していること、およびサーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済であることが必要です。新しいSOA管理対象サーバー用の浮動IPも、すでに存在している必要があります。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

2. 表の「名前」列で、移行を構成するサーバーの名前(ハイパーリンクとして表示される)をクリックします。選択したサーバーの「設定」ページが表示されます。

3. 「移行」サブタブをクリックします。

4. 「移行の構成」セクションで、移行に参加するサーバーを「使用可能」ウィンドウから選択して右向き矢印をクリックします。ノード上に存在するサーバーと同じ移行ターゲットを選択してください。
たとえば、SOAHOST1(すでにWLS_SOA1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。SOAHOST2(すでにWLS_SOA2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。

注意:

移行時に複数の管理対象サーバーを同時に実行するには、十分な空きリソースを確保しておく必要があります。

5. 「サーバーの自動移行を有効化」オプションを選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。

6. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

9. 次のように、新しいサーバーを含むようクラスタ・アドレスを更新します。

1. 管理コンソールで、「環境」、「クラスタ」の順に選択します。

2. 「SOA_Cluster」サーバーをクリックします。
SOA_Clusterの設定画面が表示されます。

3. 「ロックして編集」をクリックします。

4. 「クラスタ・アドレス」フィールドに新しいサーバーのアドレスとポートを入力します。例:

SOAHOST1VHN1:8011,SOAHOST2VHN1:8011,SOAHOST1VHN1 :8001

5. 変更を保存してアクティブ化します。

10. この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。

1. 管理対象サーバーのPIDで次のコマンドを使用して、WLS_SOAn管理対象サーバーを停止します。

kill -9 pid

ノードのPIDは次のコマンドで特定できます。

ps -ef | grep WLS_SOAn

2. ノード・マネージャ・コンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。

16.5.3 Oracle BAMのスケールアップ手順

BAMサーバーはアクティブ/パッシブ・モードで動作するため、BAMサーバーの管理対象サーバーをスケーリングできません。しかし、BAM Webアプリケーション・サーバーのスケーリングは可能です。

BAM Webアプリケーション・サーバーのスケーリング方法は2つあります。

- BAM Webアプリケーション・サーバーのみを実行している管理対象サーバーをクローニングします。

- BAMサーバーとBAM Webアプリケーション・サーバーの両方を実行している管理対象サーバーをクローニングし、第12.6項「WLS_BAM2からのBAMサーバー・システムのターゲット設定の解除」の説明のとおり、ターゲット設定からBAMサーバー・システムを外します。

BAM Webアプリケーション・サーバーをスケールアップするには、第16.5.1項「Oracle SOAのスケールアップ手順」の「手順5 新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します」以外の手順を実行します。

16.5.4 Oracle Service Busのスケールアップ手順

1つ以上の管理対象サーバーをすでに実行しているノードに新しい管理対象サーバーを追加することで、Oracle Service Busサーバーをスケールアップできます。

前提条件

Oracle Service Busサーバーをスケールアップする前に、次の前提条件を確認してください。

- クラスタで、Oracle Service Busコンポーネントを使用して構成されている管理対象サーバーを実行しています。

- ノードには、既存の管理対象サーバーのミドルウェア・ホーム、Oracleホーム(SOAとOracle Service Bus)およびドメイン・ディレクトリが含まれています。

- クローンのソースとなる管理対象サーバーが、新しい管理対象サーバーを実行するノードにすでに存在しています。

新しいWLS_OSBサーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用できます。SOAまたはOracle Service Busのバイナリを新しい場所にインストールしたり、packやunpackを実行したりする必要はありません。

Oracle Service Busサーバーをスケールアップする手順は次のとおりです。

1. 管理コンソールを使用し、WLS_OSBnのクローンを新しい管理対象サーバーにします。

1. 「環境」→「サーバー」を選択します。

2. クローンを作成する管理対象サーバー(WLS_OSB1など)を選択します。

3. 「クローン」を選択します。
新しい管理対象サーバーにWLS_OSBnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。

以降の手順は、新しいサーバーをSOAHOST1に追加します。すでにWLS_OSB1が実行されています。

2. リスニング・アドレスに対して、この新しい管理対象サーバーに使用する仮想ホスト名を割り当てます。
このサーバーに対して推奨されているサーバー移行の使用を計画している場合は、この仮想ホスト名により別のノードに移動できます。この仮想ホスト名は、Oracle Service Bus/SOAドメイン(同じドメインまたは別のドメイン)によって使用されているノードで実行されている他の管理対象サーバーで使用されているものとは異なっている必要があります。

管理対象サーバーのリスニング・アドレスを設定する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

4. 「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。

5. 表の「名前」列で、更新するリスニング・アドレスを持つ管理対象サーバーを選択します。
その管理対象サーバーの「設定」ページが表示されます。

6. 「リスニング・アドレス」を「SOAHOST1VHNn」に設定し、「保存」をクリックします。
管理対象サーバーを再起動して変更を有効にします。

3. 次のように、新しいサーバーを含むようクラスタ・アドレスを更新します。

1. 管理コンソールで、「環境」、「クラスタ」の順に選択します。

2. 「OSB_Cluster」サーバーをクリックします。
OSB_Clusterの「設定」画面が表示されます。

3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

4. 新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。例:

SOAHOST1VHN2:8011,SOAHOST2VHN2:8011,SOAHOST1VHNn:8011

4. Oracle Service BusにJMSリクエスト/レスポンス機能を使用するビジネス・サービスが1つ以上構成されている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールから次の手順を実行します。

1. 「チェンジ・センター」で、「作成」をクリックしてセッションを作成します。

2. プロジェクト・エクスプローラで、JMSリクエスト/レスポンスを使用するビジネス・サービスを検索し、選択します。
このタイプのビジネス・サービスは、「サービスのタイプ」としてメッセージング・サービスが表示されます。

3. 「詳細の表示」ページの下部にある「編集」をクリックします。

4. エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。

5. ビジネス・サービスの編集 - サマリー・ページで「保存」をクリックします。

6. JMSリクエスト/レスポンスを使用する他のビジネス・サービスについて、それぞれ前の手順を繰り返します。

7. 「チェンジ・センター」で、「アクティブ化」をクリックしてセッションを作成します。

8. 管理対象サーバーを再起動します。

9. 管理サーバーを再起動します。
これで、ビジネス・サービスは、拡張されたドメインで操作できるように構成されています。

注意:

JMS MessageID相関スキームを使用するビジネス・サービスの場合、接続ファクトリ設定を編集して、管理対象サーバーをキューにマッピングする表にエントリを追加します。キューとトピック宛先の構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のJMSサーバーのターゲット指定に関する項を参照してください。

5. Oracle Service Busにクラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスが1つ以上構成されている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールから次の手順を実行します。

1. 「チェンジ・センター」で、「作成」をクリックしてセッションを作成します。

2. プロジェクト・エクスプローラで、クラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスを検索し、選択します。

3. 「詳細の表示」ページの下部にある「編集」をクリックします。

4. エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。

5. 「プロキシ・サービスの編集 - サマリー」ページで「保存」をクリックします。

6. クラスタ・アドレスを含むJMSエンドポイントを使用する他のプロキシ・サービスについて、それぞれ前の手順を繰り返します。

7. 「チェンジ・センター」で、「アクティブ化」をクリックします。

8. 管理対象サーバーを再起動します。
これで、プロキシ・サービスは、拡張されたドメインで操作できるように構成されています。

6. 新しいサーバーのOracle Service Busの結果キャッシュのCoherence構成を更新する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

4. 「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。

5. 表の「名前」列で、サーバーの名前(ハイパーリンク)をクリックします。
選択したサーバーの「設定」ページが表示されます。

6. 「サーバーの起動」タブをクリックします。
WLS_OSBnについて(改行を入れずに1行で)次のように入力します。

-DOSB.coherence.localhost=SOAHOST1vhnn -DOSB.coherence.localport=7890
-DOSB.coherence.wka1=SOAHOST1vhn2 -DOSB.coherence.wka1.port=7890
-DOSB.coherence.wka2=SOAHOST2vhn2 -DOSB.coherence.wka1.port=7890

注意:

この構成では、WLS_OSBnの起動時に、サーバーWLS_OSB1とWLS_OSB2が実行している必要があります(このガイドの残りの手順で使用しているように仮想ホスト名SOAHOST1VHNおよびSOAHOST2VHNをリスニング)。これによりWLS_OSBnは、WLS_OSB1またはWLS_OSB2のどちらかによって起動されたCoherenceクラスタに、指定されたWKAアドレスを使用して参加します。また、3つのサーバーすべてを再起動する場合、WLS_OSB1とWLS_OSB2が起動されてからWLS_OSBnが起動されることを確認します。これによりWLS_OSBnは、WLS_OSB1またはWLS_OSB2のどちらかによって起動されたクラスタに参加します。サーバーの起動順序が重要でない場合は、WLS_OSB1とWLS_OSB2のWKAとしてWLS_OSBnのホストとポートを追加し、さらにWLS_OSBnのWKAとしてWLS_OSBnを追加します。

7. 変更を保存してアクティブ化します。
Oracle Service Busサーバーを再起動して、変更内容を反映します。

7. 管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic1

「保存してアクティブ化」をクリックします。

8. 新しい管理対象サーバーにOracle Service Busのレポート作成/内部宛先のJMSサーバーと永続ストアを作成します。

1. Oracle WebLogic Server管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、OSB_rep_JMSFileStore_Nなどの名前を付けます。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶領域のディレクトリである必要があります。例:

ORACLE_BASE/admin/DOMAIN_NAME/cluster_name/jms/

ストアを新しいクローン済サーバー(WLS_OSBn)にターゲット設定します。

2. Oracle Service Busの新しいJMSサーバーを作成します(たとえば、OSB_rep_JMSServer_N)。このJMSサーバーに対して、OSB_rep_JMSFileStore_Nを使用します。OSB_rep_JMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_OSBn)にターゲット指定します。

3. 新たに作成されたOSB JMSサーバーが含まれるように、"jmsResources" Oracle Service Bus JMSモジュールのSubDeploymentターゲットを更新します。
「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。

「jmsResources」をクリックします(表の「名前」列内のハイパーリンク)。jmsResourcesの「設定」ページが表示されます。

「サブデプロイメント」タブをクリックします。jmsresourcesのサブデプロイメント・モジュールが表示されます。

注意:

宛先のこのサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OSB1とWLS_OSB2)のJMS構成から生成されたwlsbJMSServerXXXXXXという形式のランダム名です。

サブデプロイメント「wlsbJMSServerXXXXXX」をクリックし、新しいOSB_rep_JMSServer_nサーバーが含まれるようにターゲットを更新します。

9. 新しい管理対象サーバーにOSB JAX-RPCのJMSサーバー、永続ストアおよび宛先を作成します。

注意:

WebLogic JAX-RPC Webサービスの高度な拡張機能では、通常の(非分散)宛先を使用して、ローカルに処理するサービス・リクエストがローカル・メンバーにのみエンキューされることを保証します。

1. Oracle WebLogic Server管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、Wsee_rpc_JMSFileStore_Nなどの名前を付けます。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶域上のディレクトリである必要があります。

2. OSB JAX-RPCの新しいJMSサーバーを作成します(たとえば、OSB_rpc_JMSServer_N)。このJMSサーバーに対して、Wsee_rpc_JMSFileStore_Nを使用します。OSB_rpc_JMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_OSBn)にターゲット指定します。

3. 「サービス」ノード、「メッセージング」ノードを開き、WseeJMSModule OSB JMSモジュールを宛先および新しく作成したOSB JMSサーバーで更新します。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「WseeJmsModule」をクリックします(表の「名前」列内のハイパーリンク)。WseeJmsModuleの「設定」ページが表示されます。ステップdからvを実行して、この手順を完了します。

4. 「チェンジ・センター」で、「ロックして編集」をクリックし、「新規」をクリックします。

5. 「DefaultCallbackQueue-WseeJmsServer_auto_n」を選択し、「次へ」をクリックします。

6. 「新しいサブデプロイメントの作成」をクリックします。

7. デフォルトの名前を受け入れて「OK」をクリックします。

8. ターゲットとして「OSB_rpc_JMSServer_n」を選択し、「終了」をクリックします。

9. 宛先のローカルJNDI名を更新します。
「チェンジ・センター」で、「ロックして編集」をクリックします。

「WseeJmsModuleの設定」ページで、「DefaultCallbackQueue-WseeJmsServer_auto_n」宛先をクリックします。

「一般構成」タブで、「詳細」をクリックします。

ローカルJNDI名をweblogic.wsee.DefaultCallbackQueueに更新します。

10. DefaultQueue-WseeJmsServer_auto_nキューに対して、JNDI名としてweblogic.wsee.DefaultQueue-WseeJmsServer_auto_nを、ローカルJNDI名としてweblogic.wsee.DefaultQueueを使用して、ステップdからhを繰り返します。

10. 新しいSAFエージェントを作成し、そのターゲットを新しく追加した管理対象サーバーに設定します。

1. Oracle WebLogic Server管理コンソールで、「サービス」、「メッセージング」、「ストア・アンド・フォワード・エージェント」を展開します。

2. 新しいSAFエージェントReliableWseeSAFAgent_auto_Nを追加します。

3. 永続ストアWsee_rpc_JMSFileStore_N (OSB JAX-RPC用に作成された永続ストア)を選択します。

4. SAFエージェントのターゲットを新しい管理対象サーバーに設定し、変更をアクティブにします。

11. 新しいサーバーのTX永続ストアを、他のノードから参照可能な場所に構成します。

1. 管理コンソールから、「Server_name」を選択し、「サービス」タブを選択します。

2. 「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。

12. 新しい管理対象サーバー用のホスト名検証を無効にします。WLS_OSBn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておきます。Oracle WebLogic管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローンの元となったソース・サーバーでホスト名検証がすでに無効化されている場合、これらの手順は不要です(ホスト名検証の設定はクローニングされたサーバーに伝播されているため)。
ホスト名検証を無効化するには:

1. Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。

3. 表の「名前」列で「WLS_OSBn」を選択します。
サーバーの「設定」ページが表示されます。

4. 「SSL」タブ、「詳細」を順にクリックします。

5. 「ホスト名の検証」を「なし」に設定し、「保存」をクリックします。

13. 新しいノードでノード・マネージャがまだ起動されていない場合はそれを起動します。ノード・マネージャを起動するには、次のように、すでに存在しているノードの共有記憶域にあるインストールを使用します。

SOAHOSTN> WL_HOME/server/bin/startNodeManager

14. 管理コンソールから、新しい管理対象サーバーを起動してテストします。

1. クラスタ内の既存の管理対象サーバーを停止します。

2. 新たに作成した管理対象サーバーWLS_OSBnが起動していることを確認します。

3. 次のURLを使用して、新しく作成した管理対象サーバー上のアプリケーションにアクセスします。

http://vip:port/sbinspection.wsil

15. 新しい管理対象サーバーに対してサーバー移行を構成します。

注意:

これはスケール・アップ操作であるため、ノード・マネージャと、サーバー移行に対して構成された環境が、あらかじめノードに用意されている必要があります。新しいOracle Service Bus管理対象サーバー用の浮動IPがすでに存在している必要があります。

サーバー移行を構成する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 左側のペインで「環境」を開き、「サーバー」を選択します。

3. 移行を構成する新しい管理対象サーバーの名前を選択します。

4. 「移行」タブをクリックします。

5. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可するマシンを選択して、右向き矢印をクリックします。

6. ノードの既存のサーバーと同じ移行ターゲットを選択します。
たとえば、SOAHOST1(すでにWLS_OSB1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。SOAHOST2(すでにWLS_OSB2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。

移行時に管理対象サーバーを同時に実行できるように、適切なリソースが使用可能になっていることを確認してください。

7. 「サーバーの自動移行を有効化」オプションを選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。

8. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

16. この新規サーバーを追加したノードから、新規サーバーのサーバー移行をテストします。

1. 管理対象サーバーのPID (プロセスID)で次のコマンドを実行して、WLS_OSBn管理対象サーバーを停止します。

kill -9 pid

ノードのPIDは次のコマンドで特定できます。

ps -ef | grep WLS_OSBn

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了できます。例:

taskkill /f /pid pid

pidは、管理対象サーバーのプロセスIDを表します。

WLS_OSBn管理対象サーバーのプロセスIDを確認するには、次のコマンドを実行します。

MW_HOME\jrockit_160_20_D1.0.1-2124\bin\jps -l -v

2. ノード・マネージャのコンソールに、WLS_OSBnの浮動IPが無効になったことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_OSBnの2回目の再起動を試行するのを待ちます。
ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャでサーバーを再起動したら、再び停止します。
サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。

注意:

サーバーの移行後、そのサーバーを元のノードにフェイルバックするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

16.6 トポロジのスケールアウト(管理対象サーバーを新しいノードに追加)

トポロジをスケールアウトするには、SOAまたはWSM-PMを構成した新しい管理対象サーバーを新しいノードに追加します。

この項の手順を実行する前に、次の要件が満たされていることを確認してください。

前提条件

- SOAまたはWSM-PMを構成した管理対象サーバーが、トポロジ内の既存のノードで実行されている必要があります。

- 新しいノードが、WebLogic ServerとSOAの既存のホーム・ディレクトリにアクセスできること(新しい管理対象サーバーWLS_SOAまたはWLS_WSMを作成するには、共有記憶域内の既存のインストールを使用します。WebLogic ServerやSOAのバイナリを新しい場所にインストールする必要はありませんが、新しいノードでpackとunpackを実行してドメイン構成をブートストラップする必要はあります。)

- ORACLE_HOMEまたはWL_HOMEが別のノード上の複数のサーバーで共有されている場合、パッチのインストールと適用の一貫性を維持するために、これらのノードにあるOracleインベントリおよびミドルウェア・ホーム・リストを常に最新にしておきます。ノード内のoraInventoryを更新し、これに共有記憶域のインストールをアタッチするには、次の場所でattachHome.shスクリプトを使用します。

ORACLE_HOME/oui/bin/

ミドルウェア・ホーム・リストを更新してWL_HOMEを追加または削除するには、次のディレクトリにあるbeahomelistファイルを編集します。

MW_HOME/bea

注意:

スケール・アウトの手順は、WSM管理対象サーバーにのみ適用されます。

16.6.1 Oracle SOAのスケールアウト手順

トポロジをスケール・アウトするには:

1. 新しいノード上に、既存のミドルウェア・ホーム(SOAインストールとドメイン・ディレクトリが存在する)をマウントします。ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認してください。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリにアタッチするには、次のコマンドを実行します。

SOAHOSTn>cd ORACLE_COMMON_HOME/oui/bin/attachHome.sh
SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>

ミドルウェア・ホーム・リストを更新するには、beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合は、このファイルを編集します)、MW_HOMEをこのファイルに追加します。beahomelistファイルは、次のディレクトリにあります。

MW_HOME/bea

3. Oracle WebLogic管理コンソールにログインします。

4. 新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。

5. マシンのノード・マネージャのアドレスを更新し、スケールアウトに使用しているノードのIPをマッピングします。

6. Oracle WebLogic Server管理コンソールを使用し、WLS_SOA1またはWLS_WSM1をクローニングして新しい管理対象サーバーを作成します。この管理対象サーバーには、WLS_SOAnまたはWLS_WSMnという名前を付けます(nは番号です)。これを、作成した新しいマシンに割り当てます。

注意:

この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。

7. 新しい管理対象サーバーのリスニング・アドレスとして使用するホスト名またはIPを指定します。
このサーバーでサーバー移行を実行する場合(推奨)は、ここでサーバーの仮想IP(浮動IPとも呼ばれる)を指定します。この仮想IPは、既存の管理対象サーバーとは別のものを使用してください。

8. WLS_WSMサーバーの場合は、第8.6項「Oracle WSMでのJava Object Cacheの構成」で説明されているように、Java Object Cacheの構成ユーティリティをもう一度実行して、JOC分散キャッシュにこの新しいサーバーを追加します。

9. SOA用およびUMS用のJMSサーバーを、新しい管理対象サーバー上に作成します。

注意:

WSM_WSM管理対象サーバーまたはBAM Webアプリケーション・システムをスケール・アップする場合は、新しい管理対象サーバー上でSOAおよびUMSのJMSサーバーを作成する必要はありません。この手順は、WLS_SOA管理対象サーバーをスケール・アップする場合にのみ必要です。

SOA用およびUMS用のJMSサーバーを作成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述します)、SOAJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms/

2. SOA用の新しいJMSサーバーを作成し、SOAJMSServer_Nなどの名前を付けます。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

3. 新しいUMSJMSServer用の新しい永続ストアを作成し、UMSJMSFileStore_Nなどの名前を付けます。永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」でJMS永続ストアのディレクトリとして推奨されているパスを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms

注意:

新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

4. UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

5. SOA、UMSおよびBPM JMSモジュール用のSubDeploymentターゲットを更新し、新しく作成したJMSサーバーを含めます(該当する場合)。この操作を実行するには、「サービス」ノードを開き、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA: SOAJMSModule用、BPM: BPMJMSModule用およびUMS: UMSSYtemResource用)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。

注意:

このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXX、UMSJMSServerXXXXXXまたはBPMJMSServerXXXXXXの形式によるランダムな名前であり、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。

このサブデプロイメントをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを追加し、SOAの場合はSOAJMSServer_Nを追加します)。「保存してアクティブ化」をクリックします。

6. UMSJMSSystemResourceのターゲットとしてSOA_Clusterを指定します(拡張操作のときに変更された可能性があるため)。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(クローニングで作成されたWLS_SOAnも含む)が選択されていることを確認してください。

7. SOAおよびUMS JMSモジュール(適用可能な場合)のサブデプロイメント・ターゲットを更新し、作成したJMSサーバーを追加します。
そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA用: SOAJMSModuleおよびUMS用: UMSSYtemResource)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。

注意:

このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXXまたはUMSJMSServerXXXXXXのフォームのランダムな名前で、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。

このサブデプロイメントをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを追加し、SOAの場合はSOAJMSServer_Nを追加します)。

10. 次のように、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name
-template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale

SOAHOST1で次のコマンドを実行し、テンプレート・ファイルをSOAHOSTnにコピーします。

scp soadomaintemplateScale.jar oracle@SOAHOSTN:/ ORACLE_COMMON_HOME/common/bin

次のように、SOAHOSTnでunpackコマンドを実行して、管理対象サーバーのドメイン・ディレクトリにテンプレートを解凍します。

SOAHOSTN> cd ORACLE_COMMON_HOME/common/bin

SOAHOSTN> ./unpack.sh -domain=ORACLE_BASE/admin/domain_name
/mserver/domain_name/
-template=soadomaintemplateScale.jar
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

注意:

このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。

11. 新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順については、第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。

注意:

変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。

Dtangosol.coherence.localhost=SOAHOST1VHNn

12. 管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic1

「保存してアクティブ化」をクリックします。

13. 新しいサーバー用の永続ストアを構成します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているように、他のノードから参照可能な場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。

14. 新しい管理対象サーバー用のホスト名検証を無効にします。WLS_SOAn管理対象サーバーを起動および検証する前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にすることができます。
新しいサーバーのクローニング元となっているサーバーでホスト名検証がすでに無効になっている場合は、これらの手順は不要です(ホスト名検証の設定はクローニング後のサーバーに伝播されます)。ホスト名検証を無効にする手順は次のとおりです。

1. Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。

4. 表の「名前」列の「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

15. 新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、既存のノードの共有記憶域内にあるインストールを使用してから、次のように新しいノードのホスト名をパラメータとして渡します。

SOAHOSTN> WL_HOME/server/bin/startNodeManager

16. Oracle WebLogic Server管理コンソールで、新しい管理対象サーバーを起動してテストします。

1. 新たに作成した管理対象サーバー、WLS_SOAnが実行されていることを確認します。

2. 次のURLを使用して、ロード・バランサ上のアプリケーションにアクセスします。

https://soa.mycompany.com/soa-infra

アプリケーションが機能している必要があります。

注意:

トポロジ内のHTTP Serverは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。クラスタ内のすべてのサーバーをOracle HTTP Serverのsoa_vh.confファイルのWebLogicClusterディレクティブに追加する必要はありません。ただし、クラスタ内の新しいサーバーへのルーティングは、WebLogicClusterディレクティブにリストされているサーバーが最低1つは起動している場合のみ実行されます。

17. 新しい管理対象サーバー用のサーバー移行を構成します。

注意:

この新しいノードでは既存の共有記憶域インストールが使用されるため、このノードにはノード・マネージャが存在しています。また、サーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済です。新しいSOA管理対象サーバー用の浮動IPも、新しいノードにすでに存在します。

Oracle WebLogic Server管理コンソールにログインし、サーバー移行を構成します。

サーバー移行を構成する手順は次のとおりです。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。

2. 表の「名前」列で、移行を構成するサーバー(ハイパーリンクとして表示される)を選択します。そのサーバーの「設定」ページが表示されます。

3. 「移行」タブをクリックします。

4. 「移行の構成」セクションの「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。

注意:

マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。

5. 「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。

6. 「保存」をクリックします。

7. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

18. 次のように、新しいサーバーを含むようクラスタ・アドレスを更新します。

1. 管理コンソールで、「環境」、「クラスタ」の順に選択します。

2. 「SOA_Cluster」サーバーをクリックします。
SOA_Clusterの設定画面が表示されます。

3. 「ロックして編集」をクリックします。

4. 「クラスタ・アドレス」フィールドに新しいサーバーのアドレスとポートを入力します。たとえば、SOAHOST1VHN1:8011,SOAHOST2VHN1:8011,SOAHOSTNVHN1:8001と入力します。

5. 変更を保存してアクティブ化します。

19. この新規サーバーを追加したノードから、新規サーバーのサーバー移行をテストします。

1. WLS_SOAn管理対象サーバーに対して次のコマンドを実行して、このサーバーをすぐに停止します。

kill -9 pid

ノードのPID (プロセスID)は次のコマンドで特定できます。

ps -ef | grep WLS_SOAn

2. ノード・マネージャのコンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。

16.6.2 BAMトポロジのスケール・アウト

トポロジをスケール・アウトするには:

1. 新しいノード上に、既存のミドルウェア・ホーム(SOAインストールとドメイン・ディレクトリが存在する)をマウントします。ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認してください。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリにアタッチするには、次のコマンドを実行します。

SOAHOSTn>cd ORACLE_COMMON_HOME/oui/bin/attachHome.sh
SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>

ミドルウェア・ホーム・リストを更新するには、beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合は、このファイルを編集します)、MW_HOMEをこのファイルに追加します。beahomelistファイルは、次のディレクトリにあります。

MW_HOME/bea

3. Oracle WebLogic管理コンソールにログインします。

4. 新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。

5. マシンのノード・マネージャのアドレスを更新し、スケールアウトに使用しているノードのIPをマッピングします。

6. Oracle WebLogic Server管理コンソールを使用し、WLS_SOA1のクローンを作成して新しい管理対象サーバーにします。このサーバーにWLS_SOAnという名前を付けます(nは番号です)。これを、作成した新しいマシンに割り当てます。

注意:

この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。

7. 新しい管理対象サーバーのリスニング・アドレスとして使用するホスト名またはIPを指定します。
このサーバーでサーバー移行を実行する場合(推奨)は、ここでサーバーの仮想IP(浮動IPとも呼ばれる)を指定します。この仮想IPは、既存の管理対象サーバーとは別のものを使用してください。

8. SOA、BAM(適用可能な場合)およびUMS用のJMSサーバーを、新しい管理対象サーバー上に作成します。
SOA用およびUMS用のJMSサーバーを作成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述します)、SOAJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms/

2. SOA用の新しいJMSサーバーを作成し、SOAJMSServer_Nなどの名前を付けます。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

3. 新しいUMSJMSServer用の新しい永続ストアを作成し、UMSJMSFileStore_Nなどの名前を付けます。永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」でJMS永続ストアのディレクトリとして推奨されているパスを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms

注意:

新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

4. UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

5. 新しいBAMJMSServerの新しい永続ストアを作成します(たとえば、BAMJMSFileStore_N)。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶域上のディレクトリである必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms

注意:

SOAJMSFileStore_Nを新しいBAM JMSサーバーのストアとして割り当てることも可能です。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

6. BAMの新しいJMSサーバーを作成します(たとえば、BAMJMSServer_N)。このJMSServerにはBAMJMSFileStore_Nを使用します。BAMJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

7. SOA JMSモジュールのサブデプロイメント・ターゲットを更新し、作成したSOA JMSサーバーを追加します。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列にハイパーリンクとして表示)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。SOAJMSSubDMサブデプロイメントが表示されます。

注意:

このサブデプロイメント・モジュールは、最初の2つのサーバー(WLS_SOA1およびWLS_SOA2)のJMS構成を共通分散宛先(UDD)スクリプト(soa-createUDD.py)によって更新した結果作成されたものです。このスクリプトは、エンタープライズ・デプロイメント・トポロジの初期設定に必要です。

このサブデプロイメントをクリックします。SOA用の新しいJMSサーバーSOAJMSServer_Nを、このサブデプロイメントに追加します。「保存」をクリックします。

8. UMSJMSSystemResourceのターゲットとしてSOA_Clusterを指定します(拡張操作のときに変更された可能性があるため)。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(クローニングで作成されたWLS_SOAnも含む)が選択されていることを確認してください。

9. SOA、UMSおよびBAM JMSモジュール(適用可能な場合)のサブデプロイメント・ターゲットを更新し、作成したJMSサーバーを追加します。
そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA: SOAJMSModule用、BAM: BAMJMSMOdule用およびUMS: UMSSYtemResource用)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。

注意:

このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXX、UMSJMSServerXXXXXXまたはBAMJMSServerXXXXXXの形式によるランダムな名前であり、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。

このサブデプロイメントをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを追加し、SOAの場合はSOAJMSServer_Nを追加します)。

9. 次のように、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name
-template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale

SOAHOST1で次のコマンドを実行し、テンプレート・ファイルをSOAHOSTnにコピーします。

scp soadomaintemplateScale.jar oracle@SOAHOSTN:/ ORACLE_COMMON_HOME/common/bin

次のように、SOAHOSTnでunpackコマンドを実行して、管理対象サーバーのドメイン・ディレクトリにテンプレートを解凍します。

SOAHOSTN> cd ORACLE_COMMON_HOME/common/bin

SOAHOSTN> ./unpack.sh -domain=ORACLE_BASE/admin/domain_name
/mserver/domain_name/
-template=soadomaintemplateScale.jar
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

注意:

このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。

10. 新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順については、第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。

注意:

変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。

Dtangosol.coherence.localhost=SOAHOST1VHNn

11. 管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic1

「保存してアクティブ化」をクリックします。

12. 新しいサーバー用の永続ストアを構成します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているように、他のノードから参照可能な場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。

13. 新しい管理対象サーバー用のホスト名検証を無効にします。WLS_SOAn管理対象サーバーを起動および検証する前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にすることができます。
新しいサーバーのクローニング元となっているサーバーでホスト名検証がすでに無効になっている場合は、これらの手順は不要です(ホスト名検証の設定はクローニング後のサーバーに伝播されます)。ホスト名検証を無効にする手順は次のとおりです。

1. Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。

4. 表の「名前」列の「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

14. 新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、既存のノードの共有記憶域内にあるインストールを使用してから、次のように新しいノードのホスト名をパラメータとして渡します。

SOAHOSTN> WL_HOME/server/bin/startNodeManager

15. Oracle WebLogic Server管理コンソールで、新しい管理対象サーバーを起動してテストします。

1. 新たに作成した管理対象サーバー、WLS_SOAnが実行されていることを確認します。

2. 次のURLを使用して、ロード・バランサ上のアプリケーションにアクセスします。

https://soa.mycompany.com/soa-infra

アプリケーションが機能している必要があります。

注意:

トポロジ内のHTTP Serverは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。クラスタ内のすべてのサーバーをOracle HTTP Serverのsoa_vh.confファイルのWebLogicClusterディレクティブに追加する必要はありません。ただし、クラスタ内の新しいサーバーへのルーティングは、WebLogicClusterディレクティブにリストされているサーバーが最低1つは起動している場合のみ実行されます。

16. 新しい管理対象サーバー用のサーバー移行を構成します。

注意:

この新しいノードでは既存の共有記憶域インストールが使用されるため、このノードにはノード・マネージャが存在しています。また、サーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済です。新しいSOA管理対象サーバー用の浮動IPも、新しいノードにすでに存在します。

Oracle WebLogic Server管理コンソールにログインし、サーバー移行を構成します。

サーバー移行を構成する手順は次のとおりです。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。

2. 表の「名前」列で、移行を構成するサーバー(ハイパーリンクとして表示される)を選択します。そのサーバーの「設定」ページが表示されます。

3. 「移行」タブをクリックします。

4. 「移行の構成」セクションの「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。

注意:

マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。

5. 「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。

6. 「保存」をクリックします。

7. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

17. 次のように、新しいサーバーを含むようクラスタ・アドレスを更新します。

1. 管理コンソールで、「環境」、「クラスタ」の順に選択します。

2. 「SOA_Cluster」サーバーをクリックします。
SOA_Clusterの設定画面が表示されます。

3. 「ロックして編集」をクリックします。

4. 「クラスタ・アドレス」フィールドに新しいサーバーのアドレスとポートを入力します。例:

SOAHOST1VHN1:8011,SOAHOST2VHN1:8011,SOAHOSTNVHN1:8001

5. 変更を保存してアクティブ化します。

18. この新規サーバーを追加したノードから、新規サーバーのサーバー移行をテストします。

1. WLS_SOAn管理対象サーバーに対して次のコマンドを実行して、このサーバーをすぐに停止します。

kill -9 pid

ノードのPID (プロセスID)は次のコマンドで特定できます。

ps -ef | grep WLS_SOAn

2. ノード・マネージャのコンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。

16.6.3 Oracle BAMのスケールアウト手順

BAMサーバーはアクティブ/パッシブ・モードで動作するため、BAMサーバーの管理対象サーバーをスケーリングできません。しかし、BAM Webアプリケーション・サーバーのスケーリングは可能です。

BAM Webアプリケーション・サーバーのスケーリング方法は2つあります。

- BAM Webアプリケーション・サーバーのみを実行している管理対象サーバーをクローニングします。

- BAMサーバーとBAM Webアプリケーション・サーバーの両方を実行している管理対象サーバーをクローニングし、第12.6項「WLS_BAM2からのBAMサーバー・システムのターゲット設定の解除」の説明のとおり、ターゲット設定からBAMサーバー・システムを外します。

BAM Webアプリケーション・サーバーをスケールアウトするには、第16.6.1項「Oracle SOAのスケールアウト手順」の「手順11 新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します」以外の手順を実行します。

16.6.4 Oracle Service Busのスケールアウト手順

トポロジのスケール・アウトでは、Oracle Service Busで構成された新しい管理対象サーバーを新しいノードに追加します。

前提条件

Oracle Service Busトポロジをスケール・アウトする前に、次の前提条件を満たしていることを確認します。

- Oracle Service Busで構成された管理対象サーバーを実行しているノードがトポロジ内に存在しています。

- 新しいノードは、WebLogic ServerとOracle Service Busインストールの既存のホーム・ディレクトリに必要に応じてアクセスできます。新しいWLS_OSB管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用してください。この場合、WebLogic ServerまたはOracle Service Busバイナリを新しい場所すべてにインストールする必要はありませんが、同じドメインの他のサーバーを含んでいるマシン(SOAサーバー)にOracle Service Busサーバーをスケールアウトする場合を除いて、packおよびunpackコマンドを実行して、新しいノードでドメイン構成をブートストラップする必要があります。

- 共有記憶域に既存のインストールがない場合は、WebLogic Server、SOAおよびOracle Service Busを新しいノードにインストールします。

- ORACLE_HOMEまたはWL_HOMEが別のノード上の複数のサーバーで共有されている場合、パッチのインストールと適用の一貫性を維持するために、これらのノードにあるOracleインベントリおよびミドルウェア・ホーム・リストを常に最新にしておきます。ノード内のoraInventoryを更新し、これに共有記憶域のインストールをアタッチするには、次のディレクトリにあるattachHome.shファイルを使用します。

ORACLE_HOME/oui/bin/

ミドルウェア・ホーム・リストを更新してWL_HOMEを追加または削除するには、次のディレクトリにあるbeahomelistファイルを編集します。

MW_HOME/bea

トポロジをスケール・アウトするには:

1. 新しいノードで、既存のミドルウェア・ホームをマウントします。これにはOracle Service BusとSOA (ホームを共有している場合)のインストールおよびドメイン・ディレクトリが含まれている必要があります。新しいノードが、ドメイン内の他のノードと同様に、このディレクトリにアクセスできることを確認します。

2. 次のコマンドを使用して、共有記憶域内のORACLE_HOMEをローカルのOracleインベントリにアタッチします。

SOAHOSTn>cd ORACLE_BASE/product/fmw/soa/
SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>

ミドルウェア・ホーム・リストを更新するには、次のディレクトリにbeahomelistファイルを作成します(別のWebLogicインストールがノード内に存在する場合は、このファイルを編集します)。

MW_HOME/bea/

ORACLE_BASE/product/fmwをリストに追加します。

3. Oracle WebLogic管理コンソールにログインします。

4. 新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。

5. マシンのノード・マネージャのアドレスを更新し、スケールアウトに使用しているノードのIPをマッピングします。

6. Oracle WebLogic Server管理コンソールを使用し、WLS_OSB1のクローンを作成して新しい管理対象サーバーにします。これにWLS_OSBnという名前を付けます(nは新しいマシンに割り当てる番号です)。

注意:

これらの手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加します。

7. リスニング・アドレスに対して、この新しい管理対象サーバーに使用する仮想ホスト名を割り当てます。このサーバーに対して推奨されているサーバー移行の使用を計画している場合は、この仮想ホスト名により別のノードに移動できます。この仮想ホスト名は、OSB/SOAドメイン(同じドメインまたは別のドメイン)によって使用されているノードで実行されている他の管理対象サーバーで使用されているものとは異なっている必要があります。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。

5. 表の「名前」列で、リスニング・アドレスを更新する管理対象サーバーを選択します。
その管理対象サーバーの「設定」ページが表示されます。

6. 「リスニング・アドレス」を「SOAHOSTnVHN1」に設定し、「保存」をクリックします。

7. 変更を保存してアクティブ化します。

8. 管理対象サーバーを再起動します。

8. 次のように、新しいサーバーを含むようクラスタ・アドレスを更新します。

1. 管理コンソールで「環境」、「クラスタ」を順に選択します。

2. 「OSB_Cluster」サーバーをクリックします。
OSB_Clusterの「設定」画面が表示されます。

3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

4. 新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。例:

SOAHOST1VHN1:8011,SOAHOST2VHN1:8011,SOAHOSTNVHN1:8011

9. 新しい管理対象サーバーにOracle Service Busのレポート作成/内部宛先のJMSサーバーと永続ストアを作成します。

1. Oracle WebLogic Server管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、OSB_rep_JMSFileStore_Nなどの名前を付けます。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶域上のディレクトリである必要があります。

注意:

このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。

ORACLE_BASE/admin/domain_name/cluster_name/jms/OSB_rep_JMSFileStore _N

2. Oracle Service Busの新しいJMSサーバーを作成します(たとえば、OSB_rep_JMSServer_N)。このJMSサーバーに対して、OSB_rep_JMSFileStore_Nを使用します。OSB_rep_JMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_OSBn)にターゲット指定します。

3. 新たに作成されたOracle Service Bus JMSサーバーが含まれるように、jmsresources Oracle Service Bus JMSモジュールのSubDeploymentターゲットを更新します。
「サービス」ノードを開いてから、「メッセージング」ノードを開きます。

Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。

「jmsresources」をクリックします(表の「名前」列内のハイパーリンク)。jmsResourcesの「設定」ページが表示されます。

「サブデプロイメント」タブを開きます。jmsresourcesのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュールの名前は、wlsbJMSServerXXXXXXのフォームのランダムな名前で、最初の2つのサーバー(WLS_OSB1とWLS_OSB2)に対する構成ウィザードのJMS構成から生成されます。

サブデプロイメント「wlsbJMSServerXXXXXX」をクリックし、新しいOSB_rep_JMSServer_Nサーバーが含まれるようにターゲットを更新します。

10. 新しい管理対象サーバーにOSB JAX-RPCのJMSサーバー、永続ストアおよび宛先を作成します。

注意:

WebLogic JAX-RPC Webサービスの高度な拡張機能では、通常の(非分散)宛先を使用して、ローカルに処理するサービス・リクエストがローカル・メンバーにのみエンキューされることを保証します。

1. Oracle WebLogic Server管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、Wsee_rpc_JMSFileStore_Nなどの名前を付けます。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶域上のディレクトリである必要があります。

注意:

このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。

ORACLE_BASE/admin/DOMAIN_NAME/cluster_name/jms/Wsee_rpc_JMSFileStore_N

2. Oracle Service Bus JAX-RPCの新しいJMSサーバーを作成します(たとえば、OSB_rpc_JMSServer_N)。このJMSサーバーに対して、Wsee_rpc_JMSFileStore_Nを使用します。OSB_rpc_JMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_OSBn)にターゲット指定します。

3. WseeJMSModule Oracle Service Bus JMSモジュールを、宛先および新しく作成したOracle Service Bus JMSサーバーで更新します。
「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。

「WseeJmsModule」をクリックします(表の「名前」列内のハイパーリンク)。WseeJmsModuleの「設定」ページが表示されます。

ステップdからjを実行して、この手順を完了します。

4. 「チェンジ・センター」で、「ロックして編集」をクリックし、「新規」をクリックします。

5. 「キュー」を選択し、「次へ」をクリックします。

6. キューの名前としてDefaultCallbackQueue-WseeJmsServer_auto_nと入力します。

7. JNDI名として「weblogic.wsee.DefaultCallbackQueue-WseeJmsServer_auto_n」と入力し、「次へ」をクリックします。

8. 「新しいサブデプロイメントの作成」をクリックします。

9. デフォルトの名前を受け入れて「OK」をクリックします。

10. ターゲットとして「OSB_rpc_JMSServer_n」を選択し、「終了」をクリックします。

11. 変更をアクティブ化します。

12. 宛先のローカルJNDI名を更新します。
「チェンジ・センター」で、「ロックして編集」をクリックします。

WseeJmsModuleの「設定」ページで、「DefaultCallbackQueue-WseeJmsServer_auto_n」宛先をクリックします。

「一般構成」タブで、「詳細」をクリックします。

ローカルJNDI名をweblogic.wsee.DefaultCallbackQueueに更新します。

11. 新しいSAFエージェントを作成し、そのターゲットを新しく追加した管理対象サーバーに設定します。
Oracle WebLogic Server管理コンソールで、「サービス」→「メッセージング」→「ストア・アンド・フォワード・エージェント」を展開して、新しいSAFエージェント「ReliableWseeSAFAgent_auto_N」を追加します。

永続ストアWsee_rpc_JMSFileStore_N (Oracle Service Bus JAX-RPC用に作成された永続ストア)を選択します。SAFエージェントのターゲットを新しい管理対象サーバーに設定し、変更をアクティブにします。

12. Oracle Service BusにJMSリクエスト/レスポンス機能を使用するビジネス・サービスが1つ以上構成されている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールから次の手順を実行します。

1. 「チェンジ・センター」で、「作成」をクリックしてセッションを作成します。

2. プロジェクト・エクスプローラで、JMSリクエスト/レスポンスを使用するビジネス・サービスを検索し、選択します。
このタイプのビジネス・サービスは、「サービスのタイプ」としてメッセージング・サービスが表示されます。

3. 「詳細の表示」ページの下部にある「編集」をクリックします。

4. エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。

5. 「ビジネス・サービスの編集 - サマリー」ページで「保存」をクリックします。

6. JMSリクエスト/レスポンスを使用する他のビジネス・サービスについて、それぞれ前の手順を繰り返します。

7. 「チェンジ・センター」で、「アクティブ化」をクリックします。

8. 管理対象サーバーを再起動します。

9. 管理サーバーを再起動します。
これで、ビジネス・サービスは、拡張されたドメインで操作できるように構成されています。

注意:

JMS MessageID相関スキームを使用するビジネス・サービスの場合、接続ファクトリ設定を編集して、管理対象サーバーをキューにマッピングする表にエントリを追加します。キューとトピック宛先の構成方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のJMSサーバーのターゲット指定に関する項を参照してください。

13. Oracle Service Busにクラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスが1つ以上構成されている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールから次の手順を実行します。

1. 「チェンジ・センター」で、「作成」をクリックしてセッションを作成します。

2. プロジェクト・エクスプローラで、クラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスを検索し、選択します。

3. 「詳細の表示」ページの下部にある「編集」をクリックします。

4. エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。

5. 「プロキシ・サービスの編集 - サマリー」ページで「保存」をクリックします。

6. クラスタ・アドレスを含むJMSエンドポイントを使用する他のプロキシ・サービスについて、それぞれ前の手順を繰り返します。

7. 「チェンジ・センター」で、「アクティブ化」をクリックします。

8. 管理対象サーバーを再起動します。

これで、プロキシ・サービスは、拡張されたドメインで操作できるように構成されています。

14. 新しいサーバーのOracle Service Busの結果キャッシュのCoherence構成を更新する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。「チェンジ・センター」で、「ロックして編集」をクリックします。

2. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

3. 「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。

4. 表の「名前」列で、サーバーの名前(ハイパーリンク)をクリックします。
選択したサーバーの「設定」ページが表示されます。

5. 「サーバーの起動」タブをクリックします。

6. 「詳細」をクリックします。

7. WLS_OSBnについて(改行を入れずに1行で)次のように入力します。

-DOSB.coherence.localhost=SOAHOSTnvhn1 -DOSB.coherence.localport=7890
-DOSB.coherence.wka1=SOAHOST1vhn1 -DOSB.coherence.wka1.port=7890
-DOSB.coherence.wka2=SOAHOST2vhn1 -DOSB.coherence.wka1.port=7890

注意:

前述の構成は、WLS_OSBnの起動時に、サーバーWLS_OSB1とWLS_OSB2が実行されてます。これによりWLS_OSBnは、WLS_OSB1またはWLS_OSB2のどちらかによって起動されたCoherenceクラスタに、指定されたWKAアドレスを使用して参加します。また、3つのサーバーすべてを起動する場合、WLS_OSB1とWLS_OSB2が起動されてからWLS_OSBnが起動されることを確認します。これによりWLS_OSBnは、WLS_OSB1またはWLS_OSB2のどちらかによって起動されたクラスタに参加できます。サーバーの起動順序を考慮する必要のない構成の場合は、WLS_OSB1とWLS_OSB2のWKAとしてWLS_OSBnのホストとポートを追加し、さらにWLS_OSBnのWKAとしてWLS_OSBnを追加します。

8. 変更を保存してアクティブ化します
Oracle Service Busサーバーを再起動します。

15. 管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic1

「保存してアクティブ化」をクリックします。

16. 次のように、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=MW_HOME/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale

次のコマンドをSOAHOST1で実行し、作成したテンプレート・ファイルをSOAHOSTnにコピーします。

scp soadomaintemplateScale.jar oracle@SOAHOSTN:/ORACLE_BASE/product/fmw/soa/common/bin

次のように、unpackコマンドをSOAHOSTNで実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

cd ORACLE_BASE/product/fmw/soa/common/bin

./unpack.sh -domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar

注意:

このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。

17. 共有記憶域に関する推奨事項に記載されているように、他のノードから参照可能な場所に新しいサーバーのTX永続ストアを構成します

1. 管理コンソールからサーバー名を選択して、「サービス」タブを選択します。

2. 「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。

18. 新しい管理対象サーバー用のホスト名検証を無効にします。
WLS_OSBn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておきます。Oracle WebLogic管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローンの元となったソース・サーバーでホスト名検証がすでに無効化されている場合、この手順は省略してかまいません(ホスト名検証の設定はクローニングされたサーバーに伝播されているため)。

ホスト名検証を無効化するには:

1. Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。

4. 表の「名前」列で「WLS_OSBn」を選択します。
サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定し、「保存」をクリックします。

19. すでに存在しているノードの共有記憶域にあるインストールを使用して、新しいノード上のノード・マネージャを起動します。新しいノードのホスト名をパラメータとして渡します。

SOAHOSTN> WL_HOME/server/bin/startNodeManager new_node_ip

20. Oracle WebLogic Server管理コンソールから新しい管理対象サーバーを起動して、テストします。

1. クラスタ内の既存の管理対象サーバーをすべて停止します。

2. 新たに作成した管理対象サーバーWLS_OSBnが実行されていることを確認します。新たに作成した管理対象サーバー上のアプリケーションにアクセスします。

http://vip:port/sbinspection.wsil

アプリケーションが機能している必要があります。

21. 新しい管理対象サーバー用のサーバー移行を構成します。

注意:

この新しいノードでは既存の共有記憶域インストールを使用しているため、ノードではすでに、ノード・マネージャおよびネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限などの、サーバー移行用に構成された環境が使用されています。新しいOracle Service Bus管理対象サーバー用の浮動IPも、新しいノードにすでに存在します。

サーバー移行を構成する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 左側のペインで「環境」を開き、「サーバー」を選択します。

3. 移行を構成する対象となるサーバー(ハイパーリンクとして表示)を表の「名前」列から選択します。
このサーバーの「設定」ページが表示されます。

4. 「移行」タブをクリックします。

5. 「移行の構成」セクションの「使用可能」フィールドで、移行先にするマシンを選択して、右向き矢印をクリックします。
たとえば、SOAHOST1(すでにWLS_OSB1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。SOAHOST2(すでにWLS_OSB2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。

注意:

マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。

6. 「サーバーの自動移行を有効化」オプションを選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。

7. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

22. この新規サーバーを追加したノードから、新規サーバーのサーバー移行をテストします。

1. 管理対象サーバーのPID (プロセスID)で次のコマンドを実行して、WLS_OSBn管理対象サーバーをすぐに停止します。

kill -9 pid

ノードのPIDは次のコマンドで特定できます。

ps -ef | grep WLS_OSBn

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了できます。例:

taskkill /f /pid pid

pidは、管理対象サーバーのプロセスIDを表します。

WLS_OSBn管理対象サーバーのプロセスIDは次のコマンドで特定できます。

MW_HOME\jrockit_160_20_D1.0.1-2124\bin\jps -l -v

2. ノード・マネージャ・コンソールに、WLS_OSBnの浮動IPが無効になったことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_OSBnの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャでサーバーを再起動したら、再び停止します。
サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。

注意:

サーバーが移行された後に、それを元のノードまたはマシンにフェイルバックさせるには、Oracle WebLogic管理コンソールから管理対象サーバーを停止して、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。

16.7 管理サーバーの手動フェイルオーバーの検証

ノードで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。次に、SOAHOST1およびSOAHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証する方法を示します。

前提条件:

- 管理サーバーを、任意のアドレスではなくADMINVHN上でリスニングするように構成します。第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」の手順14を参照してください。

- これらの手順では、2つのノードがそれぞれ別々のドメイン・ディレクトリを使用していることおよびこれらのディレクトリがローカル記憶域または別のボリュームにある共有記憶域に配置されていることを想定しています。

- 管理サーバーはSOAHOST1からSOAHOST2にフェイルオーバーし、これら2つのノードには次のIPが割り当てられています。

- SOAHOST1: 100.200.140.165

- SOAHOST2: 100.200.140.205

- ADMINVHN : 100.200.140.206。これは管理サーバーを実行している場所の仮想IPであり、ethX:Yに割り当てられており、SOAHOST1とSOAHOST2からアクセスできます。

- SOAHOST1での管理サーバーの実行場所であるドメイン・ディレクトリは共有記憶域にあり、SOAHOST2からもマウントされています。

- 第6章「エンタープライズ・デプロイメント用のソフトウェアのインストール」の説明のとおり、Oracle WebLogic ServerおよびOracle Fusion MiddlewareコンポーネントはSOAHOST2にインストールされています(つまり、SOAHOST1に存在するORACLE_HOMEおよびMW_HOMEのパスをSOAHOST2でも使用できます)。

この項には次のトピックが含まれます:

- 第16.7.1項「別ノードへの管理サーバーのフェイルオーバー」

- 第16.7.2項「Oracle HTTP Serverを介したSOAHOST2へのアクセスの検証」

- 第16.7.3項「SOAHOST1への管理サーバーのフェイルバック」

16.7.1 別ノードへの管理サーバーのフェイルオーバー

次の手順は、管理サーバーを別のノード(SOAHOST2)にフェイルオーバーしたうえで、同じWebLogic Serverマシン(これは物理マシンではなく論理マシンです)を引き続きその管理サーバーで使用する方法を示しています。

管理サーバーを別ノードにフェイルオーバーする手順は次のとおりです。

1. 管理サーバーを停止します。

2. IPを第2ノードに移行します。

1. SOAHOST1上で次のコマンドをroot権限で実行します(X:YはADMINVHNで現在使用しているインタフェース)。

/sbin/ifconfig ethX:Y down

2. 次のコマンドをSOAHOST2上で実行します。

/sbin/ifconfig <interface:index> IP_Address netmask <netmask>

例:

/sbin/ifconfig eth0:1 10.0.0.1 netmask 255.255.255.0

注意:

使用するネットマスクとインタフェースは、SOAHOST2で使用可能なネットワーク構成と一致している必要があります。

3. 次の例のようにarpingを使用してルーティング表を更新します。

/sbin/arping -q -U -c 3 -I eth0 10.0.0.1

4. SOAHOST2上の管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用して起動します。

5. 次の方法でSOAHOST2上の管理サーバーにアクセスできることをテストします。

1. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。

http://ADMINVHN:7001/console

2. 次のURLを使用してOracle Enterprise Managerにアクセスおよびコンポーネントのステータスを確認できることを確認します。

http://ADMINVHN:7001/em

注意:

管理サーバーでは、フェイルオーバーにノード・マネージャを使用しません。手動でフェイルオーバーした後、サーバーの管理コンソールの「現在のマシン」フィールドに表示されるマシン名は、フェイルオーバー・マシン「SOAHOST2」でなく、「SOAHOST1」になります。ノード・マネージャでは管理サーバーを監視しないので、「現在のマシン」フィールドに表示されるマシン名は関係ないため、無視してかまいません。

16.7.2 Oracle HTTP Serverを介したSOAHOST2へのアクセスの検証

第8.7.5項「Oracle HTTP Serverを介したアクセスの検証」と同じ手順を実行します。この目的は、SOAHOST2で実行している管理サーバーにもアクセスできることを確認することです。

16.7.3 SOAHOST1への管理サーバーのフェイルバック

この手順では、管理サーバーをフェイルバックできることを確認します。フェイルバックとは、SOAHOST2で実行している管理サーバーを停止し、ADMINVHNをSOAHOST1ノードに戻して、SOAHOST1で再び管理サーバーを実行することです。

ADMINVHNをSOAHOST1に戻す手順は次のとおりです。

1. 管理サーバーが起動されていないことを確認します。

2. 次のコマンドをSOAHOST2上で実行します。

/sbin/ifconfig ethZ:N down

3. 次のコマンドをSOAHOST1上で実行します。

/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0

注意:

使用するネットマスクとインタフェースは、SOAHOST1で使用可能なネットワーク構成と一致している必要があります。

4. arpingを使用してルーティング表を更新します。次のコマンドをSOAHOST1から実行します。

/sbin/arping -q -U -c 3 -I ethZ 100.200.140.206

5. 第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用して、SOAHOST1上の管理サーバーを再度起動します。

cd ORACLE_BASE/admin/domain_name/aserver/domain_name/bin
./startWebLogic.sh

6. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることをテストします。

http://ADMINVHN:7001/console

7. 次のURLを使用してOracle Enterprise Managerにアクセスおよびコンポーネントのステータスを確認できることを確認します。

http://ADMINVHN:7001/em

16.8 SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行

環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。情報のリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。

表16-1は、11gのSOAエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。

表16-1 11gのSOAエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト

タイプ

ホスト

場所

層

ORACLEホーム(DB)

CUSTDBHOST1およびCUSTDBHOST

ユーザー定義

データ層

MWホーム(OHS)

WEBHOST1およびWEBHOST2

ORACLE_HOME/fmw

Web層

MWホーム(SOAホームも含む)

SOAHOST1およびSOAHOST2

MW_HOME

SOAホームはMW_HOMEのサブディレクトリになります

ORACLE_HOME

アプリケーション層

インストール関連ファイル

OraInventory

MW_HOME/bea/beahomelist, oraInst.loc, oratab

なし

表16-2は、11gのSOAエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。

表16-2 11gのSOAエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクト

タイプ

ホスト

場所

層

ドメイン・ホーム

SOAHOST1およびSOAHOST2

ORACLE_BASE/admin/domain_name/ mserver/domain_name

アプリケーション層

アプリケーション・アーティファクト(EARおよびWARファイル)

SOAHOST1およびSOAHOST2

アプリケーション・アーティファクトの場所を調べるには、管理コンソールですべてのデプロイメントを表示する

アプリケーション層

OHSインスタンス・ホーム

WEBHOST1およびWEBHOST2

ORACLE_BASE/admin/instance_name

Web層

Oracle RACデータベース

CUSTDBHOST1およびCUSTDBHOST2

ユーザー定義

データ層

注意:

ORACLE_HOMEのバックアップは、B2B設定の一部であるXEngine構成が変更されたときに実行する必要があります。これらのファイルは、次のディレクトリにあります。

ORACLE_HOME/soa/thirdparty/edifecs/XEngine

ORACLE_HOMEをバックアップするには、次のコマンドを使用します。

tar -cvpf fmwhomeback.tar MW_HOME

16.9 SQLNet接続のタイムアウト防止

エンタープライズ・デプロイメントの本番デプロイメントでは、かなりの部分にファイアウォールが使用されています。データベース接続はファイアウォールを介して行われるため、データベース接続がタイムアウトしないようにファイアウォールを構成することをお薦めします。Oracle Real Application Clusters (RAC)の場合、データベース接続はOracle RACの仮想IPとデータベース・リスナー・ポートに対して行われます。このような接続がタイムアウトしないように、ファイアウォールが構成されている必要があります。このような構成が不可能である場合は、次のディレクトリにあるsqlnet.oraファイル内の*SQLNET.EXPIRE_TIME=n*パラメータを設定します。

ORACLE_HOME/network/admin

nは分単位の時間です。この値を、ネットワーク・デバイス(つまりファイアウォール)の既知のタイムアウト値よりも小さくしてください。Oracle RACについては、このパラメータをすべてのOracleホーム・ディレクトリで設定します。

16.10 失敗したBPELインスタンスとメディエータ・インスタンスのリカバリ

この項では、BPELやメディエータなどのサービス・エンジンの失敗したインスタンスの有無を調べてリカバリする方法について説明します。

注意:

この手順でSQL文を実行するときは、データベースにsoainfraスキーマとして接続してください。

- リカバリ可能インスタンスの有無を調べるには、データベース内で次のSQL文を実行します。

// Find recoverable activities
SQL> select * from work_item where state = 1 and execution_type != 1;

// Find recoverable invoke messages
SQL> select * from dlv_message where dlv_type = 1 and state = 0;

// Find recoverable callback messages
SQL> select * from dlv_message where dlv_type = 2 and (state = 0 or state = 1);

- 失敗したBPELインスタンスをリカバリするには:
Enterprise Managerで、「Farm_<domain_name>」を選択し、「SOA」を展開し、「soa-infra (server_soa)」を右クリックして、「サービス・エンジン」→「BPEL」→「リカバリ」を選択します。

- 失敗したメディエータ・コンポジットをリカバリするには:
Enterprise Managerで、「Farm_<domain_name>」を選択し、「SOA」を展開し、「soa-infra (server_soa)」を右クリックして、「サービス・エンジン」→「メディエータ」→「フォルト」を選択します。

- 拒否メッセージの有無を調べるには:

SQL> select * from rejected_message

- インスタンス・トラッキング表のデータを調べるには、次のSQL問合せを実行します。

SQL> select ID, STATE from COMPOSITE_INSTANCE where CREATED_TIME > datetime

datetimeには、問合せを絞り込むための日時を指定します。例:

'04-NOV-09 03.20.52.902000000 PM'

アダプタからのデータは、まずCOMPOSITE_INSTANCE表に入力されます。

アダプタからのデータがアダプタBCに公開されると、STATEが0のエントリ1個がCOMPOSITE_INSTANCE表に挿入されます。そのメッセージの処理が完了すると、STATEは1になります。エラーの場合は、STATE >= 2になります。

16.11 Webサービスに対するDoS攻撃や再帰的ノード攻撃を防ぐための構成

Webサービスに対するDoS攻撃や再帰的ノード攻撃を防ぐための構成は、SCABindingProperties.xmlおよびoracle-webservices.xmlで行います。

SCABindingProperties.xmlの構成

DoS攻撃や再帰的ノード攻撃を防ぐには、エンベロープ・サイズおよびネスト制限を例16-1のようにSCABBindingProperties.xmlで設定します。

例16-1 SCABBindingProperties.xmlでのエンベロープ・サイズとネスト制限の構成

<bindingType type="ws">
<serviceBinding>
<bindingProperty>
<name>request-envelope-max-kilobytes</name>
<type>xs:integer</type>
<defaultValue>-1</defaultValue>
</bindingProperty>
<bindingProperty>
<name>request-envelope-nest-level</name>
<type>xs:integer</type>
<defaultValue>-1</defaultValue>
</bindingProperty>
</serviceBinding>

oracle-webservices.xmlの構成

スタンドアロンのWebサービスについては、エンベロープ・サイズとネスト制限をoracle-webservices.xmlで構成します。例:

<request-envelope-limits kilobytes="4" nest-level="6" />

注意:

エンベロープ・サイズとネスト制限の値が極端に大きい場合や、値がまったく設定されていない場合は、DoS攻撃を受けるおそれがあります。

16.12 Oracle Business Activity Monitoring (BAM)構成プロパティ

BAMによる、Oracle RACフェイルオーバー後の処理中トランザクションの再試行回数を変更するには、MaxDBNodeFailoverRetries設定をデフォルトの5回から別の値に変更します。ただし、UseDBFailoverおよびMaxDBNodeFailoverRetriesの設定はデフォルトのままにしておくことをお薦めします。BAMのOracle RACフェイルオーバー再試行サポートを無効化するには、UseDBFailoverをfalseに設定します。(この設定のデフォルト値はtrueです。)これらの設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のOracle BAM構成プロパティ・リファレンスの項を参照してください。

16.13 デプロイメント・プランおよびSOAインフラストラクチャ・アプリケーション更新での共有記憶域の使用

SOAクラスタ内のSOAインフラストラクチャ・アプリケーションまたはリソース・アダプタを再デプロイするときは、デプロイメント・プランとアプリケーション・ビットに、クラスタ内の全サーバーからアクセスできる必要があります。SOAのアプリケーションおよびリソース・アダプタは、nostageデプロイメント・モードを使用してインストールされます。nostageデプロイメント・モードを選択した場合、管理サーバーはアーカイブ・ファイルをソースの場所からコピーしないため、各サーバーが同じデプロイメント・プランにアクセスできるようにしておく必要があります。デプロイメント・プランおよびアプリケーションに次の場所を使用します。

ORACLE_BASE/admin/domain_name/cluster_name/dp

第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているとおり、このディレクトリはエンタープライズ・デプロイメント・トポロジ内のすべてのノードからアクセスできる場所である必要があります。

16.14 エンタープライズ・デプロイメントのトポロジのトラブルシューティング

この項では、SOAエンタープライズ・デプロイメントで発生する可能性のある問題を示し、その解決方法を提案します。

この項の項目は次のとおりです。

- 第16.14.1項「BAMにアクセスするとHTTPエラー404が発生する」

- 第16.14.2項「soa-infraアプリケーションにロード・バランサ経由でアクセスしたときに「ページが見つかりません」というエラーが発生する」

- 第16.14.3項「Oracle B2Bドキュメント定義の取得時にエラーが発生する」

- 第16.14.4項「デプロイメント・フレームワークの問題が原因でsoa-infraアプリケーションの起動に失敗する(Coherence)」

- 第16.14.5項「SOAサーバーの再起動に失敗したためにポリシー移行が未完になる」

- 第16.14.6項「データベース内の最大プロセス数に達したためにSOA、BAMまたはWMSサーバーの起動に失敗する」

- 第16.14.7項「手動フェイルオーバー後に管理サーバーの起動に失敗する」

- 第16.14.8項「管理コンソールで変更をアクティブ化するときにエラーが発生する」

- 第16.14.9項「サーバー移行後にSOA/BAMサーバーがフェイルオーバーしない」

- 第16.14.10項「サーバー移行後にSOA/BAMサーバーにブラウザからアクセスできない」

- 第16.14.11項「SOAサーバーのアクティブ化後、しばらくの間高い負荷がかかるとサーバーが応答を停止する」

- 第16.14.12項「B2Bコンソールでデプロイ/パージ/インポート操作を実行しているときに例外が発生する」

- 第16.14.13項「OAM構成ツール実行時にURLが削除されない」

- 第16.14.14項「管理コンソールで変更をアクティブ化した後でユーザーがログイン画面にリダイレクトされる」

- 第16.14.15項「OAMに対する変更をアクティブ化した後でユーザーが管理コンソールのホーム・ページにリダイレクトされる」

- 第16.14.16項「構成済のJOCポートがすでに使用中」

- 第16.14.17項「SOAサーバーまたはBAMサーバーの起動に失敗する」

- 第16.14.18項「B2Bデリバリ・チャネル更新のためのJOCの構成」

- 第16.14.19項「同じノードに複数のクラスタがある場合のSOA Coherenceクラスタの不一致」

- 第16.14.20項「サーバー移行時にSudoエラーが発生する」

- 第16.14.21項「トランザクション・タイムアウト・エラー」

- 第16.14.22項「最大サイズ超過エラー・メッセージ」

- 第16.14.23項「同期していないクロックがエラーの原因になる」

16.14.1 BAMにアクセスするとHTTPエラー404が発生する

問題: BAMアプリケーションにアクセスするとHTTP 404エラー「見つかりません」が発生します。BAMスキーマを含むデータベース・インスタンスを起動する前に、BAMサーバーを起動したことが、このエラーの原因である可能性があります。

解決方法: データベースがすでに起動していることを確認してから、BAMインスタンスを停止して再起動します。

16.14.2 soa-infraアプリケーションにロード・バランサ経由でアクセスしたときに「ページが見つかりません」というエラーが発生する

問題: ロード・バランサのアドレスを使用してsoa-infraアプリケーションにアクセスしようとしたときに、404メッセージ「ページが見つかりません」がWebブラウザに表示されます。このエラーは断続的に発生し、WLS管理コンソールではSOAサーバーが「実行中」と表示されます。

解決方法: SOA管理対象サーバーが実行中であるように見えても、そのサーバー内のアプリケーションの状態が「アクティブ」ではなく、「管理」や「準備完了」である場合があります。SOAサーバーが実行中でも、soa-infraアプリケーションが使用不可になることもあります。管理コンソールの「デプロイメント」ページで、soa-infraアプリケーションの状態を調べてください。状態は「アクティブ」になっている必要があります。SOA Serverの出力ログにsoa-infraアプリケーション関連のエラーがないことを確認し、管理コンソールの「デプロイメント」ページでsoa-infraアプリケーションを起動してください。

16.14.3 Oracle B2Bドキュメント定義の取得時にエラーが発生する

問題: ドキュメント定義XSDをOracle B2Bから取得しようとするときにエラーが発生します。B2Bはクラスタ内に存在しており、ロード・バランサ経由でアクセスします。B2Bコンソールには、次のようにレポートされます。

An error occured while loading the document definitions. java.lang.IllegalArgumentException: Cluster address must be set when clustering is enabled.

解決方法: Oracle B2Bが存在するOracle WebLogicクラスタのフロントエンドにあるHTTPホストおよびポートを設定します。SOAクラスタに対してフロントエンド・アドレスを設定します。

1. WebLogic Server管理コンソールの「チェンジ・センター」セクションの「ロックして編集」をクリックします。

2. 左ペインの「ドメイン構造」ウィンドウの「環境」を選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。

3. 「WLS_SOA」クラスタを選択します。

4. 「HTTP」を選択します。

5. 次の値を設定し、「保存」をクリックします。

- フロントエンド・ホスト: soa.mycompany.com

- フロントエンドHTTPSポート: 443

- フロントエンドHTTPポート: 80

6. 変更を有効にするために、管理コンソールの「チェンジ・センター」セクションの「変更のアクティブ化」をクリックします。

7. サーバーを再起動して、クラスタのフロントエンド・ホストの指定を有効化します。

16.14.4 デプロイメント・フレームワークの問題が原因でsoa-infraアプリケーションの起動に失敗する(Coherence)

問題: デプロイメントのCoherence構成に対する変更を適用した後、soa-infraアプリケーションの起動に失敗します。SOAサーバーの出力ログには、次のように報告されます。

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.

解決方法:

1. SOAコンポジットのクラスタ・デプロイメントに対してユニキャストではなくマルチキャストを使用する場合、前述のようなメッセージが表示されることがあります。その原因は、soa-infraアプリケーションの起動時(つまり、SOAが実行される管理対象サーバーの起動時)にマルチキャスト競合が発生したためです。このメッセージは、Oracle Coherenceがランタイム例外をスローしたときに生成されるもので、例外自体の詳細情報も含まれています。このようなメッセージが表示された場合、ネットワークのマルチキャスト構成を確認してください。マルチキャスト・アドレスに対してpingを実行できることを確認します。さらに、ネットワーク内の別の名前のクラスタが同じマルチキャスト・アドレスを使用しているかどうかを調べてください。このようなクラスタがあると、競合が発生してsoa-infraを起動できなくなることがあります。ネットワークでマルチキャストが有効化されていない場合、ユニキャストを使用するようにデプロイメント・フレームワークを変更してください。その方法については、『Oracle Coherence開発者ガイド』を参照してください。

2. ユニキャスト用の既知アドレス・リストをサーバー起動パラメータ内に入力するときは、ノードのローカル・ホストおよびクラスタ化されたサーバー用のアドレスが正しいことを確認してください。エラー・メッセージの例を次に示します。

oracle.integration.platform.blocks.deploy.CompositeDeploymentCoordinatorMessages errorUnableToStartCoherence

このようなエラーがサーバーの出力ログにある場合、正しく解決されていないアドレスがあります。

16.14.5 SOAサーバーの再起動に失敗したためにポリシー移行が未完になる

問題: ノード・マネージャのプロパティをstartScriptEnabled=trueに設定する前にSOAサーバーを管理コンソールから起動しようとすると、失敗します。このプロパティを設定した後、サーバーが起動しません。SOAサーバーの出力ログには、次のように報告されます。

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)
...

解決方法: system-jazn-data.xmlファイル内の<jazn-policy>要素を編集してBAM-services.jarに権限を付与します。

<grant>
<grantee>
<codesource>
<url>file:${oracle.home}/soa/modules/oracle.soa.workflow_11.1.1/BAM-
services.jar</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>java.security.AllPermission</class>
</permission>
</permissions>
</grant>

16.14.6 データベース内の最大プロセス数に達したためにSOA、BAMまたはWMSサーバーの起動に失敗する

問題: SOA、WSMまたはBAMサーバーの起動に失敗します。新しい管理対象サーバー・タイプ用にドメインが拡張されているか(たとえば、BAM用にSOAを拡張)、システムがスケールアップされています(同じタイプのサーバーを追加)です。SOA/BAMまたはWSMサーバーの出力ログに、次のように報告されます。

<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コマンドを発行します。

SQL> SHOW PARAMETER processes

次のコマンドを使用して初期化パラメータを設定します。

SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE

データベースを再起動します。

注意:

パラメータの値を変更する方法は、パラメータが静的か動的かによって異なり、データベースがパラメータ・ファイルとサーバー・パラメータ・ファイルのどちらを使用しているかによっても異なります。パラメータ・ファイル、サーバー・パラメータ・ファイルおよびパラメータ値の変更方法の詳細は、Oracle Database管理者ガイドを参照してください。

16.14.7 手動フェイルオーバー後に管理サーバーの起動に失敗する

問題: 管理サーバーに障害が発生して別のノードへの手動フェイルオーバーを実行した後で、管理サーバーの起動に失敗します。管理サーバーの出力ログには、次のように報告されます。

<Feb 19, 2009 3:43:05 AM PST> <Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: ORACLE_BASE/admin/soadomain/aserver/soadomain/servers/AdminServer/data/ldap/ldapfiles. Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>

解決方法: 次のディレクトリからEmbeddedLDAP.lokファイルを削除します。

ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/data/ldap/ldapfiles/

.

16.14.8 管理コンソールで変更をアクティブ化するときにエラーが発生する

問題: サーバーの起動構成を変更した後で、管理コンソールで変更をアクティブ化しようとすると失敗します。「変更のアクティブ化」をクリックすると、管理コンソールに次のように表示されます。

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

解決方法: 構成を変更しようとしていたサーバーの起動構成の一部であるユーザー名/パスワードの情報を管理コンソールで指定するか、<password-encrypted></password-encrypted>エントリをconfig.xmlファイルから削除してください(管理サーバーの再起動が必要)。

16.14.9 サーバー移行後にSOA/BAMサーバーがフェイルオーバーしない

問題: ローカルのノード・マネージャによる再起動試行回数が最大数に達した後で、フェイルオーバー・ノードのノード・マネージャが再起動を試行しますが、サーバーは起動しません。ノード・マネージャの出力情報には、サーバーがフェイルオーバーしたことが報告されます。ノード・マネージャがSOAサーバーの移行を試行した後でも、このサーバーが使用する仮想IPがフェイルオーバー・ノード内で有効化されていません(フェイルオーバー・ノードでif configを実行しても、どのインタフェースの仮想IPも報告されません)。コマンド「sudo ifconfig $INTERFACE $ADDRESS $NETMASK」を実行しても、そのIPはフェイルオーバー・ノード内で有効化されません。

解決方法: sudo実行時にパスワード入力を要求するような権限と構成を設定しないでください。パスワード入力を要求しなくてもsudoが動作するようにsudoが構成されていることを、システム管理者に確認してください。

16.14.10 サーバー移行後にSOA/BAMサーバーにブラウザからアクセスできない

問題: サーバー移行は正常に実行されますが(SOA/BAMサーバーがフェイルオーバー・ノード内で再起動されます)、<仮想ホスト名>:8001/soa-infra URLにWebブラウザからアクセスできません。元のホストではすでにサーバーが強制終了されており、フェイルオーバー・ノードのノード・マネージャでは、仮想IPが移行済でサーバーが起動していることが報告されます。SOAサーバーが使用する仮想IPに対して、クライアントのノード(ブラウザが使用されているノード)からpingを実行しても応答がありません。

解決方法: nodemanager.propertiesファイルを更新してMACBroadcastを追加するか、次のように手動でarpingを実行してください。

/sbin/arping -b -q -c 3 -A -I $INTERFACE $ADDRESS > $NullDevice 2>&1

$INTERFACEは、仮想IPが有効化されているネットワーク・インタフェース、$ADDRESSは仮想IPアドレスです。

16.14.11 SOAサーバーのアクティブ化後、しばらくの間高い負荷がかかるとサーバーが応答を停止する

問題: WLS_SOAは正常に起動し、しばらくの間機能しますが、Oracleファイル・アダプタまたはOracle FTPアダプタを使用するアプリケーションの実行後に応答しなくなります。サーバーのログ・ファイルには、次のように報告されます。

<Error> <Server> <BEA-002606> <Unable to create
a server socket for listening on channel "Default". The address
X.X.X.X might be incorrect or another process is using port 8001:
@ java.net.SocketException: Too many open files.>

解決方法: コンポジットでOracleファイルおよびFTPアダプタを使用している場合は(これらのアダプタは大量の同時メッセージを処理するように設計されている)、オペレーティング・システムのオープン・ファイル・パラメータの数値を大きくしてください。たとえば、Linuxのオープン・ファイル・パラメータの値を8192に設定するには、ulimit -n 8192コマンドを使用します。この値は、予想されるシステム負荷に基づいて調整する必要があります。

16.14.12 B2Bコンソールでデプロイ/パージ/インポート操作を実行しているときに例外が発生する

問題: 新しいアグリーメントのデプロイメントまたは新しいメタデータのパージ/インポートに失敗し、SWLS_SOAサーバーの出力ログに「[java] MDS-02202: Content of the metadata object」(デプロイメント)、「postTransfer: MDS-00521: error while reading document...」(パージ/インポート)と報告されます。

解決方法: この問題は、操作におけるタイミングとロード・バランシングのメカニズムが原因で発生します。例外が発生する可能性は非常に低いため、操作を再試行すれば概して成功します。クリーンアップなどの追加の手順は必要ありません。

16.14.13 OAM構成ツール実行時にURLが削除されない

問題: OAM構成ツールを使用して、複数のURLをまとめてOracle Access Managerのポリシーに追加しました。しかし、そのURLの1つに誤記がありました。正しいURLを指定してOAM構成ツールをもう一度実行すると、処理は正常に完了しますが、ポリシー・マネージャには誤ったURLが依然として表示されます。

解決方法: 同じapp_domain名を指定してOAM構成ツールを実行したときは、既存ポリシーへの新しいURLの追加のみが行われます。特定のURLを削除するには、OAMのポリシー・マネージャ・コンソールを使用してください。OAMのアクセス管理サイトにログオンして、「ポリシー・ドメイン」をクリックし、作成済のポリシー・ドメイン(SOA_EDG)をクリックし、「リソース」タブで誤ったURLを削除します。

16.14.14 管理コンソールで変更をアクティブ化した後にユーザーがログイン画面にリダイレクトされる

問題: Oracle WebLogic管理コンソールにアクセスするためにOHSおよびロード・バランサを構成した後で、なんらかの変更のアクティブ化を行うと、管理コンソールのログイン画面にリダイレクトされます。

解決方法: この問題は、ユーザーがポート、チャネルおよびセキュリティの設定を変更するときに、管理コンソールがその変更を反映しようとすると発生します。変更内容によっては、管理サーバーのリスニング・アドレスにリダイレクトすることがあります。このリダイレクトにかかわらず、アクティブ化は完了します。再度ログインする必要はありません。次のURLを更新し、管理コンソールのホーム・ページに直接アクセスします。

soa.mycompany.com/console/console.portal

注意:

この項で説明する変更の追跡を無効にしている場合、この問題は発生しません。

16.14.15 OAMに対する変更をアクティブ化した後でユーザーが管理コンソールのホーム・ページにリダイレクトされる

問題: OAMを構成した後でなんらかの変更をアクティブ化すると、管理コンソールのホーム・ページにリダイレクトされるようになります(アクティブ化の実行場所であるコンテキスト・メニューには戻りません)。

解決方法: これは、OAM SSOが構成済のときに発生する現象で、管理サーバーによってリダイレクトが実行された結果です。このリダイレクトにかかわらず、アクティブ化は完了します。必要であれば、ユーザーは手動で目的のコンテキスト・メニューに戻ることができます。

16.14.16 構成されたJOCポートがすでに使用中

問題: Java Object Cacheを使用する管理対象サーバー(OWSMやWebCenter Spaces管理対象サーバーなど)を起動しようとすると失敗します。ログには次のようなエラーが記録されます。

J2EE JOC-058 distributed cache initialization failure
J2EE JOC-043 base exception:
J2EE JOC-803 unexpected EOF during read.

解決方法: JOCが取得しようとしているポートを別のプロセスが使用しています。そのプロセスを停止するか、このクラスタのJOCを再構成して、推奨されるポート範囲内で別のポートを使用するようにします。

16.14.17 SOAサーバーまたはBAMサーバーの起動に失敗する

SOAサーバーまたはBAMサーバーを初めて起動するときに失敗して、config.xmlの解析の失敗が報告されます。

問題: ノード・マネージャを使用して初めてサーバーを起動したときに、起動に失敗します。サーバーの出力ログには、次のようなメッセージが記録されます。

<Critical> <WebLogicServer> <eicfdcn35> <wls_server1> <main> <<WLS Kernel>> <> <> <1263329692528> <BEA-000386> <Server subsystem failed. Reason: weblogic.security.SecurityInitializationException: Authentication denied: Boot identity not valid; The user name and/or password from the boot identity file (boot.properties) is not valid. The boot identity may have been changed since the boot identity file was created. Please edit and update the boot identity file with the proper values of username and password. The first time the updated boot identity file is used to start the server, these new values are encrypted.

管理対象サーバーは、初回はMSI(管理対象サーバー独立)モードで起動しようとします。ただし、サーバーは初回起動時には適切な構成を取得できません。管理対象サーバーは、初回起動時には管理サーバーと通信できるようになっている必要があります。

解決方法: 管理サーバーのリスニング・アドレスと管理対象サーバーのリスニング・アドレスの間で通信が有効になっていることを確認します(管理対象サーバーのノードから管理サーバーのリスニング・アドレスに対してpingを実行し、管理サーバーのリスニング・アドレスおよびポートに対してtelnetを実行します)。通信が有効になったら、ドメインの圧縮と新しいドメインへの解凍を再度行うか、(一方のサーバーが同じドメイン・ディレクトリで正常に実行されている場合は)次のディレクトリを削除してサーバーを再起動します。

OARCLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/data/nodemanager

16.14.18 B2Bデリバリ・チャネル更新のためのJOCの構成

SOAクラスタのデフォルトのMDS変更通知メカニズムでは、デフォルトの30秒間隔で更新が伝播されます。B2Bアグリーメントのデリバリ・チャネルの場合または変更が頻繁に行われる場合など、それよりも早く構成変更を伝播する必要がある場合は、Javaオブジェクト・キャッシュ(JOC)を使用します。次のディレクトリにあるconfigure-joc.pyスクリプトを使用して分散Javaオブジェクト・キャッシュを構成します。

MW_HOME/oracle_common/bin

このPythonスクリプトを使用して管理対象サーバーにJOCを構成すると、B2Bデリバリ・チャネルに加えられた変更がすぐに通知されます。スクリプトはWLSTオンライン・モードで実行されます。管理サーバーが稼働している必要があります。

Oracle製品にJOCポートを構成する場合は、9988から9998のポートを使用します。

注意:

WLSTコマンドまたはconfigure-joc.pyスクリプトを使用してJavaオブジェクト・キャッシュを構成した後で、構成を有効にするために、影響を受ける管理対象サーバーをすべて再起動します。

Oracle SOA Suiteサーバーの分散Javaオブジェクト・キャッシュを構成する手順は次のとおりです。

1. 次のディレクトリの、コマンド行Oracle WebLogic Scripting Toolのwlst.shを使用して、管理サーバーに接続します。

MW_HOME/oracle_common/common/bin

wlst.shを使用して接続する手順は次のとおりです。

$ connect()

プロンプトが表示されたら、Oracle WebLogic管理サーバーのユーザー名とパスワードを入力します。

2. WLSTを使用して管理サーバーに接続したら、execfileコマンドを使用してスクリプトを起動します。例:

wls:/mydomain/serverConfig>execfile('MW_HOME/oracle_common/bin/configure-joc.py')

3. 特定のクラスタのすべての管理対象サーバー用のJOCを構成します。
クラスタ名を指定するかどうかを尋ねるスクリプト・プロンプトが表示されたらyを入力します。プロンプトに従ってクラスタ名および検出ポートを指定します。これによって、指定したクラスタの管理対象サーバーがすべて検出され、JOCが構成されます。検出ポートは、そのクラスタのJOC構成全体で共通になります。

For Oracle Web Services Manager: Do you want to specify a cluster name (y/n) <y>
Enter Cluster Name : SOA_Cluster
Enter Discover Port : 9992

高可用性環境のためのconfigure-joc.pyの例を次に示します。

execfile('MW_HOME/oracle_common/bin/configure-joc.py')
.
Enter Hostnames (eg host1,host2) : SOAHOST1VHN1,SOAHOST2VHN1
.
Do you want to specify a cluster name (y/n) <y>y
.
Enter Cluster Name : SOA_Cluster
.
Enter Discover Port : 9992
.
Enter Distribute Mode (true|false) <true> : true
.
Do you want to exclude any server(s) from JOC configuration (y/n) <n> n

このスクリプトは、次のJOC構成にも使用できます。

- 指定された管理対象サーバーすべてのJOCを構成します。
クラスタ名を指定するかどうかを尋ねるプロンプトが表示されたらnを入力し、プロンプトが表示されたら管理対象サーバーと検出ポートを指定します。例:

Do you want to specify a cluster name (y/n) <y>n
Enter Managed Server and Discover Port (WLS_WSM1:9998, WLS_WSM1:9998) : WLS_WSM1:9992,WLS_WSM2:9992

- 一部の管理対象サーバーでJOC構成を除外します。
このスクリプトにより、JOC構成「DistributeMode」を「false」に設定する管理対象サーバーのリストを指定できます。JOC構成から除外するサーバーがあるかどうかを尋ねるプロンプトが表示されたら'y'を入力し、プロンプトが表示されたら除外する管理対象サーバー名を入力します。例:

Do you want to exclude any server(s) from JOC configuration (y/n) <n>y
Exclude Managed Server List (eg Server1,Server2) : WLS_WSM1,WLS_WSM3

- すべての管理対象サーバーに対して分散モードを無効にします。
このスクリプトでは、指定されたクラスタのすべての管理対象サーバーに対する分散を無効にできます。スクリプトにより分散モードに対するプロンプトが表示されたら、「false」を指定します。デフォルトでは、分散モードは「true」に設定されています。

- B2BサーバーのVHNをリスニング・アドレスとして使用するようjavacahce.xmlファイルを編集します。
問題のサーバーのjavacache.xmlファイルを編集します。このファイルは、次のディレクトリに格納されています。

DOMAIN_HOME/aserver/soaedg_domain/config/fmwconfig/servers/server_name

次のようにlisten-addressフィールドを追加します。

...
<packet-distributor enable-router="false" startable="true" dedicated-coordinator="false">
<listener-address host="SOAHOST1VHN1" port="9992" />
<listener-address host="SOAHOST1VHN1" port="9992" />
<distributor-location host=" SOAHOST1VHN1" port="9992" ssl="true"/>
</packet-distributor>
...

CacheWatcherユーティリティを使用し、JOCの構成を確認します。『Oracle Fusion Middleware高可用性ガイド』を参照してください。

『Oracle Fusion Middleware高可用性ガイド』で説明しているように、Oracle WebLogic管理コンソールで「HAパワー・ツール」タブを使用してJavaオブジェクト・キャッシュ(JOC)を構成できます。

16.14.19 同じノードに複数のクラスタがある場合のSOA Coherenceクラスタの不一致

問題: 同じノードに複数のSOAクラスタが存在する場合にsoa-infraの起動に失敗します。サーバーの.outファイルに次のようなメッセージが表示されます。

<Error> <Coherence> <BEA-000000> <Oracle Coherence GE 3.6.0.4 <Error> (thread=Cluster, member=1): This senior Member(…) appears to have been disconnected from another senior Member…stopping cluster service.>

解決方法: Coherenceメンバーは再起動したときに、localport設定で構成されたポートへのバインドを試みます。このポートが使用できない場合は、ポート番号を2つずつ増やしてそのポートへの接続を試みます。複数のSOAクラスタがCoherence用に同じ範囲のポートを使用していると、メンバーが異なるWKAのクラスタに参加する可能性があり、この不一致によりsoa-infraアプリケーションが起動しなくなることがあります。この問題を解決するには、いくつかの方法があります。

- クラスタ・ポートを2ずつ増やす方法ではなく、各クラスタにポート範囲を設定します。たとえば、クラスタ1は8000から8090、クラスタ2は8091から8180のように設定します。これは、このガイドの表3-4で推奨しているモデルが暗黙的に示すもので、各Coherenceクラスタにはそれぞれ別の範囲を使用する必要があります。

- 自動調整を無効化し、メンバーに構成されているlocalhostアドレスを使用するように設定します。これは、システム・プロパティ"tangosol.coherence.localport.adjust"で設定します(例: -Dtangosol.coherence.localport.adjust=false)。

- 各クラスタに一意のクラスタ名を構成します。これは、システム・プロパティtangosol.coherence.clusterを使用して行います。例:

-Dtangosol.coherence.cluster=SOA_Cluster1

これらのオプションの詳細は、次のURLにあるCoherenceクラスタの構成に関するドキュメントを参照してください。

http://download.oracle.com/docs/cd/E24290_01/coh.371/e22837/cluster_setup.htm

16.14.20 サーバー移行時にSudoエラーが発生する

問題: サーバー移行のためwlsifconfigを実行すると、次の警告が表示されます。

sudo: sorry, you must have a tty to run sudo

解決方法: WebLogicユーザー('oracle')がバックグラウンドでsudoを実行できません。この問題を解決するには、次の行を/etc/sudoersに追加します。

Defaults:oracle !requiretty

詳細は、第14.5項「wlsifconfig.shスクリプトの環境およびスーパーユーザー権限の設定」を参照してください。

16.14.21 トランザクション・タイムアウト・エラー

問題: 次のトランザクション・タイムアウト・エラーがログに表示されます。

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トランザクション・タイムアウトより小さく、DataSource XAトランザクション・タイムアウトが(データベースの) distributed_lock_timeoutより小さいことを確認します。

ボックス構成が行われていない場合、SOAデータソースでは、XAタイムアウトがいかなる値にも設定されません。WebLogic Server管理コンソールで、「XAトランザクション・タイムアウトの設定」構成パラメータが選択解除されています。この場合、データソースでは、30に設定されているドメイン・レベルのJTAタイムアウトを使用します。また、データベースに対するdistributed_lock_timeoutのデフォルト値は60です。結果として、トランザクションがこのような値より短い耐用期間を持つことが予想されるシステムでは、SOAの構成が正常に機能します。特定の操作にかかると予想されるトランザクション時間に応じて、これらの値を調整してください。

16.14.22 最大サイズ超過エラー・メッセージ

問題: 複雑なルールを編集してSOAクラスタに保存すると、レプリケーション・メッセージの最大サイズを超えたことをレポートするエラー・メッセージが、サーバーの出力ファイルに表示されることがあります。例:

<rws3211539-v2.company.com> <WLS_SOA1> <ExecuteThread: '2' for queue:
'weblogic.socket.Muxer'> <<WLS Kernel>> <> <> <1326464549135> <BEA-000403>
<IOException occurred on socket:
Socket[addr=/10.10.10.10,port=48290,localport=8001]
weblogic.socket.MaxMessageSizeExceededException: Incoming message of size:
'10000080' bytes exceeds the configured maximum of: '10000000' bytes for
protocol: 't3'.
weblogic.socket.MaxMessageSizeExceededException: Incoming message of size:
'10000080' bytes exceeds the configured maximum of: '10000000' bytes for
protocol: 't3'

解決方法: このエラーは、HTTPセッションで配置されクラスタに複製された、シリアル化されたルールのサイズが大きいために発生します。使用するルールのサイズに応じて、最大メッセージ・サイズを増やしてください。

最大メッセージ・サイズを増やす手順は次のとおりです。

1. WebLogic管理コンソールにログインします。

2. 「サーバー」、「Server_name」、「プロトコル」、「全般」の順に選択します。

3. 必要に応じて「最大メッセージ・サイズ」フィールドを変更します。

16.14.23 同期していないクロックがエラーの原因になる

問題: サーバー移行用に構成され、リースにOracle RACデータベースを使用しているサーバーが、自身をシャットダウンし、次のようなメッセージが表示されます。

<Error> <Cluster> <BEA-000150> <Server failed to get a connection to the
database in the past 60 seconds for lease renewal. Server will shut itself
down.>
<Critical> <Health> <BEA-310006> <Critical Subsystem ServerMigration has
failed. Setting server state to FAILED. Reason: ServerXXX failed to renew
lease in the database>
<Critical> <WebLogicServer> <BEA-000385><Server health failed. Reason:
health of critical service 'ServerMigration'failed>
<Notice> <WebLogicServer> <BEA-000365> <Server state changed to FAILED>

このようなメッセージが表示されるにもかかわらず、リース用のデータ・ソースは正常に動作し、接続テストも正常に実行されます。

解決方法: 様々なRAC DBインスタンスのクロックが同期していることを確認します。

A Oracle RACでのマルチ・データ・ソースの使用

新しいOracle RACアプリケーションの開発には、GridLinkデータ・ソースを使用することをお薦めします。しかし、GridLinkデータ・ソースをサポートしていない従来のアプリケーションおよびデータベースを使用している場合は、この付録の詳細を参照してください。

この付録の内容は次のとおりです。

- 第A.1項「マルチ・データ・ソースとOracle RAC」

- 第A.2項「EDGトポロジ用のマルチ・データ・ソースを構成する標準手順」

A.1 マルチ・データ・ソースとOracle RAC

マルチ・データ・ソースは、接続要求を満たすために使用するデータ・ソースの順序付きリストを提供します。通常、この種類のマルチ・データ・ソースに対する接続要求は、すべてリストの先頭にあるデータ・ソースによって処理されます。データベースの接続テストが失敗し、接続の置換ができない場合またはデータ・ソースが一時停止している場合、接続はリストの次のデータ・ソースから順に試みられます。

Oracle RACを使用したマルチ・データ・ソースの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のOracle RACを使用したマルチ・データ・ソースの使用に関する項を参照してください。

A.2 EDGトポロジ用のマルチ・データ・ソースを構成する標準手順

ドメインを構成する場合は、データ・ソースを構成します。たとえば、エンタープライズ・デプロイメント参照トポロジに最初の管理ドメインを構成する場合、構成ウィザードを使用してドメインの特性およびデータ・ソースを定義します。

このエンタープライズ・デプロイメント・ガイドに記載されているトポロジの構成手順では、Oracle RACを使用してGridLinkデータ・ソースを定義する固有の手順も説明しています。GridLinkデータ・ソースのかわりにマルチ・データ・ソースを使用する場合は、GridLink用の説明を次のように置き換えてください。

1. 「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。

1. 適切なスキーマを選択します。

2. 「コンポーネント・スキーマのRAC構成」については、「RACマルチ・データ・ソースへ変換」を選択します。

3. リポジトリ作成ユーティリティを実行した際、次のデータ・ソースがスキーマの接頭辞とともに表示されることを確認してください。

4. 「次へ」をクリックします。

2. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面が表示されます(図A-1)。

図A-1 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面

この画面で、次の手順を実行します。

1. 次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: 「Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11」を選択します。

- サービス名: データベースのサービス名を入力します。

- ユーザー名: スキーマの完全なユーザー名(接頭辞を含む)を入力します。

- パスワード: スキーマへのアクセスに使用するパスワードを入力します。

2. ホスト名、インスタンス名およびポートを入力します。

3. 「追加」をクリックします。

4. この手順をOracle RACインスタンスごとに実行します。

5. 「次へ」をクリックします。

3. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。

B アプリケーションとリソースのサーバーへのターゲット設定

この付録には、Oracle SOAエンタープライズ・デプロイメント用のアプリケーション、ライブラリ、起動クラス、停止クラス、JMSシステム・リソース、WLDFシステム・リソースおよび自己チューニング・リソース・ターゲットが示されています。

この付録では次の項について説明します。

- 第B.1項「Oracle SOA Suiteのアプリケーション・ターゲット」

- 第B.2項「Oracle SOAエンタープライズ・デプロイメント・ライブラリのターゲット」

- 第B.3項「Oracle SOAエンタープライズ・デプロイメント起動クラスのターゲット」

- 第B.4項「Oracle SOAエンタープライズ・デプロイメント停止クラスのターゲット」

- 第B.5項「Oracle SOAエンタープライズ・デプロイメントJMSシステム・リソースのターゲット」

- 第B.6項「Oracle SOAエンタープライズ・デプロイメントJDBCシステム・リソースのターゲット」

- 第B.7項「Oracle SOAエンタープライズ・デプロイメントWLDFシステム・リソースのターゲット」

- 第B.8項「Oracle SOAエンタープライズ・デプロイメント自己チューニング・リソースのターゲット」

B.1 Oracle SOA Suiteのアプリケーション・ターゲット

表B-1は、Oracle SOAエンタープライズ・デプロイメント・アプリケーションのターゲットを示しています。

表B-1 SOAアプリケーション・ターゲット

アプリケーション

ターゲット

FMW Welcome Page Application#11.1.0.0.0

AdminServer

DMS Application#11.1.1.1.0

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

wsil-wls

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

wsm-pm

WSM-PM_Cluster

em

AdminServer

NonJ2EEManagement#11.1.1

BAM_Cluster,AdminServer

FileAdapter

OSB_Cluster,AdminServer,SOA_Cluster

DbAdapter

OSB_Cluster,AdminServer,SOA_Cluster

JmsAdapter

OSB_Cluster,AdminServer,SOA_Cluster

AqAdapter

OSB_Cluster,AdminServer,SOA_Cluster

FtpAdapter

OSB_Cluster,AdminServer,SOA_Cluster

SocketAdapter

OSB_Cluster,AdminServer,SOA_Cluster

MQSeriesAdapter

OSB_Cluster,AdminServer,SOA_Cluster

OracleAppsAdapter

OSB_Cluster,AdminServer,SOA_Cluster

OracleBamAdapter

OSB_Cluster,AdminServer,SOA_Cluster

usermessagingserver

BAM_Cluster,SOA_Cluster

usermessagingdriver-email

BAM_Cluster,SOA_Cluster

usermessagingdriver-xmpp

optional

usermessagingdriver-smpp

optional

usermessagingdriver-voicexml

optional

usermessagingdriver-extension

optional

UMSAdapter

OSB_Cluster,AdminServer,SOA_Cluster

soa-infra

SOA_Cluster

worklistapp

SOA_Cluster

b2bui

SOA_Cluster

DefaultToDoTaskFlow

SOA_Cluster

composer

SOA_Cluster

OracleBPMProcessRolesApp

SOA_Cluster

OracleBPMComposerRolesApp

SOA_Cluster

OracleBPMWorkspace

SOA_Cluster

BPMComposer

SOA_Cluster

SimpleApprovalTaskFlow

SOA_Cluster

composer

SOA_Cluster

OracleBPMProcessRolesApp

SOA_Cluster

OracleBPMComposerRolesApp

SOA_Cluster

OracleBPMWorkspace

SOA_Cluster

BPMComposer

SOA_Cluster

SimpleApprovalTaskFlow

SOA_Cluster

ALSB Cluster Singleton Marker Application

OSB_Cluster

ALSB Domain Singleton Marker Application

OSB_Cluster

ALSB Framework Starter Application

OSB_Cluster,AdminServer

ALSB Coherence Cache Provider

OSB_Cluster

XBus Kernel

OSB_Cluster,AdminServer

ALSB UDDI Manager

AdminServer

ALSB Subscription Listener

OSB_Cluster

JMS Reporting Provider

OSB_Cluster

Message Reporting Purger

OSB_Cluster

Ftp Transport Provider

OSB_Cluster,AdminServer

SFTP Transport Provider

OSB_Cluster,AdminServer

Email Transport Provider

OSB_Cluster,AdminServer

File Transport Provider

OSB_Cluster,AdminServer

MQ Transport Provider

OSB_Cluster,AdminServer

EJB Transport Provider

OSB_Cluster,AdminServer

Tuxedo Transport Provider

OSB_Cluster,AdminServer

ALDSP Transport Provider

OSB_Cluster,AdminServer

SB Transport Provider

OSB_Cluster,AdminServer

WS Transport Provider

OSB_Cluster,AdminServer

WS Transport Async Applcation

OSB_Cluster

FLOW Transport Provider

OSB_Cluster,AdminServer

BPEL 10g Transport Provider

OSB_Cluster,AdminServer

JCA Transport Provider

OSB_Cluster,AdminServer

JEJB Transport Provider

OSB_Cluster,AdminServer

SOA-DIRECT Transport Provider

OSB_Cluster,AdminServer

ALSB Routing

OSB_Cluster,AdminServer

ALSB Transform

OSB_Cluster,AdminServer

ALSB Publish

OSB_Cluster,AdminServer

ALSB Logging

OSB_Cluster,AdminServer

ALSB Resource

OSB_Cluster

ALSB WSIL

OSB_Cluster

ServiceBus_Console

AdminServer

ALSB Test Framework

OSB_Cluster,AdminServer

oracle-bam#11.1.1

BAM_Cluster

ExternalPartnerSupplierEjb

SOA_Cluster

WebServices_WebLogicFusionOrderDemo_CreditCardAuthorization

SOA_Cluster

ps5app

SOA_Cluster

FutureParticipantSimpleTaskForm

SOA_Cluster

AMXEDGTaskForm

SOA_Cluster

VacationRequestTaskFlow

SOA_Cluster

frevvo

SOA_Cluster

OSBイニシャライザ・アプリケーションにおけるOWSMポリシーのサポート

OSB_Cluster,AdminServer

B.2 Oracle SOAエンタープライズ・デプロイメント・ライブラリのターゲット

表B-2は、Oracle SOAエンタープライズ・デプロイメント・ライブラリのターゲットを示しています。

表B-2 Oracle SOAエンタープライズ・デプロイメント・ライブラリのターゲット

ライブラリ

ターゲット

oracle.bi.adf.view.slib#1.0@11.1.1.2.0

OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

oracle.bi.adf.webcenter.slib#1.0@11.1.1.2.0

OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

odl.clickhistory#1.0@11.1.1

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

odl.clickhistory.webapp#1.0@11.1.1

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

oracle.wsm.seedpolicies#11.1.1@11.1.1

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

oracle.jsp.next#11.1.1@11.1.1

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

oracle.dconfig-infra#11@11.1.1.1.0

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

orai18n-adf#11@11.1.1.1.0

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

oracle.adf.dconfigbeans#1.0@11.1.1.2.0

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

oracle.pwdgen#11.1.1@11.1.1.2.0

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

oracle.jrf.system.filter

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

adf.oracle.domain#1.0@11.1.1.2.0

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

adf.oracle.businesseditor#1.0@11.1.1.2.0

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

oracle.adf.management#1.0@11.1.1.2.0

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

adf.oracle.domain.webapp#1.0@11.1.1.2.0

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

jsf#1.2@1.2.9.0

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

UIX#11@11.1.1.1.0

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

ohw-rcf#5@5.0

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

ohw-uix#5@5.0

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

oracle.adf.desktopintegration.model#1.0@11.1.1.2.0

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

oracle.adf.desktopintegration#1.0@11.1.1.2.0

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

oracle.bi.jbips#11.1.1@0.1

OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

oracle.bi.composer#11.1.1@0.1

OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

oracle.bpm.mgmt#11.1.1@11.1.1

SOA_Cluster

emai

AdminServer

oracle.webcenter.skin#11.1.1@11.1.1

AdminServer

oracle.webcenter.composer#11.1.1@11.1.1

AdminServer

emas

AdminServer

emcore

AdminServer

oracle.rules#11.1.1@11.1.1

BAM_Cluster,AdminServer,SOA_Cluster

oracle.sdp.client#11.1.1@11.1.1

BAM_Cluster,SOA_Cluster

oracle.soa.workflow.wc#11.1.1@11.1.1

SOA_Cluster

oracle.soa.worklist.webapp#11.1.1@11.1.1

SOA_Cluster

oracle.soa.rules_editor_dc.webapp#11.1.1@11.1.1

SOA_Cluster

oracle.soa.rules_dict_dc.webapp#11.1.1@11.1.1

BAM_Cluster,SOA_Cluster

oracle.sdp.messaging#11.1.1@11.1.1

SOA_Cluster,BAM_Cluster

oracle.soa.worklist#11.1.1@11.1.1

SOA_Cluster

oracle.soa.rules_editor_dc.webapp#11.1.1@11.1.1

SOA_Cluster

oracle.soa.rules_dict_dc.webapp#11.1.1@11.1.1

SOA_Cluster

oracle.soa.worklist#11.1.1@11.1.1

SOA_Cluster

oracle.soa.bpel#11.1.1@11.1.1

SOA_Cluster

oracle.soa.workflow#11.1.1@11.1.1

SOA_Cluster

oracle.soa.mediator#11.1.1@11.1.1

SOA_Cluster

oracle.soa.composer.webapp#11.1.1@11.1.1

SOA_Cluster

oracle.soa.ext#11.1.1@11.1.1

SOA_Cluster

oracle.bpm.client#11.1.1@11.1.1

SOA_Cluster

oracle.bpm.runtime#11.1.1@11.1.1

SOA_Cluster

oracle.bpm.projectlib#11.1.1@11.1.1

SOA_Cluster

oracle.bpm.webapp.common#11.1.1@11.1.1

SOA_Cluster

oracle.bpm.composerlib#11.1.1@11.1.1

SOA_Cluster

oracle.bpm.workspace#11.1.1@11.1.1

SOA_Cluster

oracle.jrf.coherence#3@11.1.1

OSB_Cluster,AdminServer

coherence-l10n#11.1.1@11.1.1

OSB_Cluster

ftptransport-l10n#2.5@2.5

OSB_Cluster,AdminServer

sftptransport-l10n#3.0@3.0

OSB_Cluster,AdminServer

emailtransport-l10n#2.5@2.5

OSB_Cluster,AdminServer

filetransport-l10n#2.5@2.5

OSB_Cluster,AdminServer

mqtransport-l10n#3.0@3.0

OSB_Cluster,AdminServer

mqconnection-l10n#3.0@3.0

OSB_Cluster,AdminServer

ejbtransport-l10n#2.5@2.5

OSB_Cluster,AdminServer

tuxedotransport-l10n#2.5@2.5

OSB_Cluster,AdminServer

aldsp_transport-l10n#3.0@3.0

OSB_Cluster,AdminServer

wstransport-l10n#2.6@2.6

OSB_Cluster,AdminServer

flow-transport-l10n#3.0@3.0

OSB_Cluster,AdminServer

bpel10gtransport-l10n#3.1@3.1

OSB_Cluster,AdminServer

jcatransport-l10n#3.1@3.1

OSB_Cluster,AdminServer

wsif#11.1.1@11.1.1

OSB_Cluster,AdminServer

JCAFrameworkImpl#11.1.1@11.1.1

OSB_Cluster,AdminServer

jejbtransport-l10n#3.2@3.2

OSB_Cluster,AdminServer

jejbtransport-jar#3.2@3.2

OSB_Cluster,AdminServer

soatransport-l10n#11.1.1.2.0@11.1.1.2.0

OSB_Cluster,AdminServer

stage-utils#2.5@2.5

OSB_Cluster,AdminServer

sbconsole-l10n#2.5@2.5

OSB_Cluster,AdminServer

xbusrouting-l10n#2.5@2.5

OSB_Cluster,AdminServer

xbustransform-l10n#2.5@2.5

OSB_Cluster,AdminServer

xbuspublish-l10n#2.5@2.5

OSB_Cluster,AdminServer

xbuslogging-l10n#2.5@2.5

OSB_Cluster,AdminServer

testfwk-l10n#2.5@2.5

OSB_Cluster,AdminServer

com.bea.wlp.lwpf.console.app#10.3.0@10.3.0

OSB_Cluster,AdminServer

com.bea.wlp.lwpf.console.web#10.3.0@10.3.0

OSB_Cluster,AdminServer

wlp-lookandfeel-web-lib#10.3.0@10.3.0

OSB_Cluster,AdminServer

wlp-light-web-lib#10.3.0@10.3.0

OSB_Cluster,AdminServer

wlp-framework-common-web-lib#10.3.0@10.3.0

OSB_Cluster,AdminServer

wlp-framework-struts-1.2-web-lib#10.3.0@10.3.0

OSB_Cluster,AdminServer

struts-1.2#1.2@1.2.9

OSB_Cluster,AdminServer

beehive-netui-1.0.1-10.0#1.0@1.0.2.2

OSB_Cluster,AdminServer

beehive-netui-resources-1.0.1-10.0#1.0@1.0.2.2

OSB_Cluster,AdminServer

beehive-controls-1.0.1-10.0-war#1.0@1.0.2.2

OSB_Cluster,AdminServer

weblogic-controls-10.0-war#10.0@10.2

OSB_Cluster,AdminServer

wls-commonslogging-bridge-war#1.0@1.1

OSB_Cluster,AdminServer

jstl#1.2@1.2.0.1

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

oracle.bam.library#11.1.1@11.1.1

BAM_Cluster

weblogic-sca#1.1@1.1.0.0

SOA_Cluster

oracle.bi.adf.model.slib#1.0@11.1.1.2.0

SOA_Cluster,BAM_Cluster,AdminServer

B.3 Oracle SOAエンタープライズ・デプロイメント起動クラスのターゲット

表B-3は、Oracle SOAエンタープライズ・デプロイメント起動クラスのターゲットを示しています。

表B-3 Oracle SOAエンタープライズ・デプロイメント起動クラスのターゲット

クラス

ターゲット

JRF起動クラス

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

JPS起動クラス

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

ODL-起動

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

AWTアプリケーション・コンテキスト起動クラス

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

JMXフレームワーク起動クラス

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

Webサービス起動クラス

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

JOC-起動

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

DMS-起動

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

SOAStartupClass

SOA_Cluster

OSB JCAトランスポート・アクティブ化後起動クラス

OSB_Cluster,AdminServer

B.4 Oracle SOAエンタープライズ・デプロイメント停止クラスのターゲット

表B-4は、Oracle SOAエンタープライズ・デプロイメント停止クラスのターゲットを示しています。

表B-4 SOA EDG停止クラスのターゲット

クラス

ターゲット

JOC-停止

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

DMSShutdown

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

B.5 Oracle SOAエンタープライズ・デプロイメントJMSシステム・リソースのターゲット

表B-5は、Oracle SOAエンタープライズ・デプロイメントJMSリソースのターゲットを示しています。

表B-5 JMSシステム・リソースのターゲット

JMSリソース

ターゲット

UMSJMSSystemResource

BAM_Cluster,SOA_Cluster

PS6SOAJMSModule

SOA_Cluster

BPMJMSModule

SOA_Cluster

SOAJMSModule

SOA_Cluster

AGJMSModule

SOA_Cluster

WseeJmsModule

OSB_Cluster

jmsResources

OSB_Cluster

configwiz-jms

OSB_Cluster,BAM_Cluster

BAMJmsSystemResource

BAM_Cluster

B.6 Oracle SOAエンタープライズ・デプロイメントJDBCシステム・リソースのターゲット

表B-6は、Oracle SOAエンタープライズ・デプロイメントJDBCリソースのターゲットを示しています。

表B-6 JDBCシステム・リソースのターゲット

JMSリソース

ターゲット

mds-owsm

WSM-PM_Cluster,AdminServer

OraSDPMDataSource

BAM_Cluster,SOA_Cluster

SOADataSource

SOA_Cluster

EDNDataSource

SOA_Cluster

EDNLocalTxDataSource

SOA_Cluster

SOALocalTxDataSource

SOA_Cluster

mds-soa

AdminServer,SOA_Cluster

wlsbjmsrpDataSource

OSB_Cluster,AdminServer

leasing

OSB_Cluster,BAM_Cluster,SOA_Cluster

BAMDataSource

BAM_Cluster

jdbc/aqSample

SOA_Cluster

AppsAdapterTestDataSource

AdminServer,SOA_Cluster

RC4Connection

SOA_Cluster

oracle.bi.adf.model.slib

AdminServer,SOA_Cluster

B.7 Oracle SOAエンタープライズ・デプロイメントWLDFシステム・リソースのターゲット

表B-7は、Oracle SOAエンタープライズ・デプロイメントWLDFリソースのターゲットを示しています。

表B-7 WLDFシステム・リソースのターゲット

JMSリソース

ターゲット

モジュール-FMWDFW

WSM-PM_Cluster,OSB_Cluster,BAM_Cluster,AdminServer,SOA_Cluster

B.8 Oracle SOAエンタープライズ・デプロイメント自己チューニング・リソースのターゲット

表B-8は、Oracle SOAエンタープライズ・デプロイメント自己チューニング・リソースのターゲットを示しています。

表B-8 自己チューニング・リソースのターゲット

JMSリソース

ターゲット

wm/SOAWorkManager

SOA_Cluster

weblogic.wsee.mdb.DispatchPolicy

OSB_Cluster

索引
A  B  C  D  E  F  G  H  I  K  L  M  N  O  P  R  S  T  U  V  W  X

A

BAMのドメインへの追加, 12.1

BAMのドメインへの追加

BAMを追加するためのドメインの拡張, 12.4

クラスタの追加, 9.3, 10.2.2 管理対象サーバーの追加, 9.3, 10.2.2 管理対象サーバーの既存ノードへの追加, 16.5 管理対象サーバーの新しいノードへの追加, 16.6 管理コンソール

フロントエンドURL, 8.7.4

ホーム・ページへのリダイレクト, 16.14.15, 16.14.16

ログイン画面へのリダイレクト, 16.14.14

サーバー移行の検証, 14.7

管理サーバー, 8.4.1, 8.4.6, 8.7.1

フェイルオーバー, 8.8, 16.7, 16.7.3

ホスト名の検証, 8.4.8, 8.5.3

SSL通信, 13.3, 13.5

起動, 8.4.3

検証, 8.4.5

admin.mycompany.com, 3.2.2 アプリケーション層, 2.1.5 arping, 8.2 アーティファクト, 16.2 ASM、「自動ストレージ管理(ASM)」を参照 サーバーのクラスタへの割当て, 9.3, 10.2.2, 12.4 サーバーのマシンへの割当て, 9.3, 10.2.2, 12.4 認証プロバイダ, 15.5.7, 15.6.6 自動ストレージ管理(ASM), 5.2.1

B

B2Bドキュメント定義, 16.14.3

バックアップ

Oracle Fusion Middlewareのインストール後, 6.3.4

Oracle HTTP Serverの設定後, 6.2.3

バックアップ

構成ファイル, 15.2.1, 15.5.7.1, 15.6.6.1

データベース, 5.6

ドメイン, 9.3

エンタープライズ・デプロイメント, 16.8

インストール, 8.9, 9.10, 10.4, 15.7

BAM、「Oracle Business Activity Monitoring (BAM)」を参照 BAMHOSTノード, 2.1.5, 12.9 boot.properties, 8.4.1 BPEL, 16.10 組込みセキュリティ, 1.3.1 Business Activity Monitoring、「Oracle Business Activity Monitoring (BAM)」を参照

C

コールバックURL, 10.2.13

クラスタ・エージェント, 1.2

クラスタ, 1.2, 8.3

追加, 9.3, 10.2.2

サーバーの割当て, 9.3, 10.2.2

BAM, 12.4

クラスタウェア, 1.2 Coherence、「Oracle Coherence」を参照 コンポジット, 16.2 構成

BAM Webアプリケーション, 12.12

委任フォーム認証, 15.5.3.7

SOAHOST1上のドメイン, 8.3

フロントエンドHTTPホストとポート, 9.6.3, 10.2.13

Oracleファイル/FTPアダプタの高可用性, 9.8.1, 10.2.15

Oracle Coherence, 9.4, 10.2.3, 11.5

Oracle HTTP Server, 7.5, 8.7.1

BAM管理対象サーバーのOracle HTTP Server, 12.13

WLS管理対象サーバーのOracle HTTP Server, 9.6.1

トランザクション・リカバリ用の永続ストア, 10.2.14, 12.5

Oracleデータベース・アダプタのスケーリング, 9.8.2, 9.9, 10.2.17, 10.2.18

Webサービスのセキュリティ, 16.11

共有記憶域, 4.4

サーバー移行のターゲット, 14.6

UMSドライバ, 16.4

カスタム・キーストアの使用, 13.3.4, 13.5.3

WebGate, 15.5.4

構成ウィザード, 8.3, 9.3 構成ウィザード、実行, 10.2.1 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面, 10.2.2, 10.3.1 configure-joc.pyスクリプト, 8.6 構成

ロード・バランサ用のポート, 3.3

ロード・バランサ上の仮想サーバー名, 3.3

接続ファクトリのパラメータ, 9.8.1.1, 10.2.15.1 createCentralInventory.shスクリプト, 6.3.2 Fusion Middlewareホームの作成, 6.3.1 アイデンティティ・キーストアの作成, 13.3.2, 13.5.2 信頼キーストアの作成, 13.3.3 CUSTDBHOSTノード, 2.1.6, 5.2.1 カスタム・キーストア, 13.3.4, 13.5.3

D

データソース, 14.3

データ・ソース, 8.3, 9.3, 10.2.2, 12.4, A.2

データ層, 2.1.6

データベース

バックアップ, 5.6

およびBAM, 16.14.1

CREATE_SERVICE, 5.3

ホストの要件, 5.2.1

初期化パラメータ, 5.2.3

リポジトリのロード, 5.4

mutexロック, 9.8.1.1, 10.2.15.1

プロセス, 16.14.6

サービス, 5.3

設定, 5.2

サポートされているバージョン, 5.2.2

データベース・リスナー・ポート, 2.1.6 トランザクション・リカバリ用のデフォルト永続ストア, 10.2.14, 12.5 委任フォーム認証, 15.5.3.7 WebサービスでのDoS攻撃

防止, 16.11

コンポジットとアーティファクトのデプロイ, 16.2 ディレクトリ構造, 4.3, 4.3.4, 4.3.5 ホスト名検証の無効化, 8.4.8, 8.5.3

WLS_SOA管理対象サーバー用, 9.5.1, 10.2.4, 11.4, 12.8

DMZ, 1.3.1, 2.1.3, 2.1.5 ドメイン

BAMの追加, 12.1

バックアップ, 9.3

SOAHOST1上での作成, 8.3

BAMを追加するための拡張, 12.4

SOAコンポーネント用に拡張, 9, 9.3

ドメイン構成

伝播, 8.5.1, 9.5.3, 9.5.5, 10.2.5, 10.2.7, 10.3.2, 12.7

DOMAINディレクトリ, 4.2 ドメイン・ディレクトリ, 8.4.6

E

SOAHOST1上でのSOAHOST1VHN1の有効化, 8.2

VIP2の有効化, 10.2.1

VIP3の有効化, 10.2.1

エンタープライズ・デプロイメント, 1.1

バックアップとリカバリ, 16.8

トポロジ, 2.1

環境権限, 14.5 現在のドメインの拡張, 10.2.1 ドメインの拡張

SOAコンポーネント, 9, 9.3

BPMを追加するためのドメインの拡張, 10 外部通信, 1.3.1

F

フェイルバック, 1.2

失敗したBPELインスタンス, 16.10

失敗したメディエータ・インスタンス, 16.10

フェイルオーバー, 1.2、16.14.7、16.14.9

管理サーバーのフェイルオーバー, 8.8, 16.7, 16.7.3

ファイアウォール, 3.6

FMW、「Oracle Fusion Middleware (FMW)」を参照

フロントエンドHTTPホストとポート, 9.6.3, 10.2.13

管理コンソールのフロントエンドURL, 8.7.4

G

自己署名証明書の生成, 13.3.1, 13.5.1

グリッド・サーバー, 1.1

H

ハードウェア・クラスタ, 1.2

ハードウェア要件, 2.2

高可用性, 1.3.2, 9.4.1, 10.2.3.1

Oracleファイル/FTPアダプタ, 9.8.1, 10.2.15

ホーム・ページ、リダイレクト, 16.14.15, 16.14.16 ホスト識別子, 15.5.3.4 ホスト名

ネットワーク, 1.2

物理, 1.2

仮想, 1.2

ホスト名の検証, 8.4.8, 8.5.3

WLS_SOA管理対象サーバーに対する--の無効化, 9.5.1, 10.2.4, 11.4, 12.8

HTTPエラー404(「見つかりません」), 16.14.1 HTTPポート, 2.1.3 httpd.conf, 7.6.2 HTTPSポート, 2.1.3

I

IDアサータ, 15.5.7.2, 15.6.6.2

アイデンティティ・キーストア, 13.3.2, 13.5.2

ifconfig, 8.2

未完のポリシー移行, 16.14.5

誤ったURL, 16.14.13

データベースの初期化パラメータ, 5.2.3

インストール

Fusion Middlewareホーム, 6.3.1

Oracle ECM, 6.3.2

Oracle Fusion Middleware, 6.3

Oracle HTTP Server, 6.2

Oracle WebLogic Server, 6.3.1, 6.3.1, 6.3.1

手順, 2.6

Web層の検証, 7.4

WebGate, 15.5.4

インストールするコンポーネント, 2.3

IP, 3.4, 3.4

K

キーストア

カスタム, 13.3.4, 13.5.3

アイデンティティ, 13.3.2, 13.5.2

信頼, 13.3.3

keytoolユーティリティ, 13.3.3

L

LDAP

WebLogic管理者の移動, 15.2.2

leading.ddlスクリプト, 14.2 サーバー移行用のリース・テーブル, 14.2 ロード・バランサ, 2.1.3, 7.6

ポートの構成, 3.3

仮想サーバー名の構成, 3.3

Oracle HTTP Serverを使用した構成, 7.5

必要な機能, 3.3.1

要件, 2.1.4

ディレクトリの場所, 4.3, 4.3.4, 4.3.5 ログイン画面、リダイレクト, 16.14.14

M

管理対象サーバー, 8.3, 8.4.6

追加, 9.3, 10.2.2

既存ノードへの追加, 16.5

新しいノードへの追加, 16.6

BAM, 12.13

Business Activity Monitoring (BAM), 12.4

ホスト名の検証の無効化, 9.5.1, 10.2.4, 11.4, 12.8

ドメイン変更の伝播, 9.5.3

検証, 9.5.4, 9.5.6, 10.2.6, 10.2.9

WLS_SOA, 9.5.6

WLS_WSM, 8.4.1, 8.4.8, 8.4.9, 8.5.3, 8.5.5, 8.7.1

トポロジの管理, 16 手動フェイルオーバー, 16.14.7 管理サーバーの手動フェイルオーバー, 8.8, 16.7 IPとVIPのマッピング, 3.4, 3.4 メディエータ, 16.10 ミドルウェア・ホーム, 1.2 ポリシーの移行, 16.14.5 サーバーの移行、「サーバー移行」も参照, 14 mod_wl_ohs.confファイル, 8.7.1 トポロジの監視, 16.1 マルチデータ・ソース, 14.3 mutexロック, 9.8.1.1, 10.2.15.1 MW_HOME, 4.2

N

仮想サーバーの名前, 3.2

ネットワーク

ファイアウォール, 3.6

IP, 3.4

ポート, 3.6

共有記憶域, 4.3.5

仮想IP (VIP), 3.4

仮想サーバー, 3.2

ネットワーク・ホスト名, 1.2 ノード・マネージャ

プロパティ・ファイル, 14.4

再起動, 9.5.2

設定, 13

SSL通信, 13.3, 13.5

起動, 8.4.2, 8.5.4, 12.9, 13.4, 13.6

カスタム・キーストアの使用, 13.3.4, 13.5.3

nodemanager.properties, 11.14.2, 12.15.3 ノード

サーバーの既存ノードへの追加, 16.5

サーバーの新しいノードへの追加, 16.6

アプリケーション層, 2.1.5

BAMHOST, 2.1.5, 12.9

CUSTDBHOST, 2.1.6, 5.2.1

データ層, 2.1.6

1次, 1.2

2次, 1.2

SOAHOST, 2.1.5, 8.2, 8.3, 8.4.1, 8.4.2, 8.5.4, 9.5.2, 12.6

Web層, 2.1.3

WEBHOST, 2.1.3

O

OAM、「Oracle Access Manager (OAM)」を参照

OAMCFGツール, 16.14.13

情報の収集, 15.5.3.1

概要, 15.5.3

実行, 15.5.3.2

OAPポート, 2.1.5 OID認証プロバイダ, 15.2.1 OIDポート, 2.1.6 Oracle Access Manager, 2.1.3 Oracle Access Manager (OAM)

委任フォーム認証, 15.5.3.7

IDアサータ, 15.5.7.2, 15.6.6.2

OAMCFGツール, 15.5.3

プロバイダの順序, 15.5.7.3

概要, 15.5.1, 15.6.1

前提条件, 15.5.2, 15.6.2

ホスト識別子の更新, 15.5.3.4

WebGateプロファイルの更新, 15.5.3.5

ポリシー・ドメインの検証, 15.5.3.3

WebGate, 15.5.4

WebLogic認証プロバイダ, 15.5.7, 15.6.6

Oracle Access Manager (OAM) 11gの統合

プロバイダの順序, 15.6.6.3

Oracle Access Protocol (OAP), 2.1.3 Oracle BPM, 10 Oracle Business Activity Monitoring (BAM), 16.12

ドメインへの追加, 12.1

Oracle HTTP Serverの構成, 12.13

WLS_BAMサーバーのサーバー移行の構成, 11.14, 12.15

Webアプリケーションの構成, 12.12

エラー404(「見つかりません」), 16.14.1

BAMを追加するためのドメインの拡張, 12.4

ドメイン構成の伝播, 12.7

BAMシステムの起動, 12.10

BAMサーバー・システムのターゲット指定の解除, 12.6

Oracle HTTP Serverを使用したアクセス検証, 10.3.5, 12.14

Oracle Business Activity Monitoring (BAM)

ターゲット, 12.6

Oracle Coherence, 9.4, 10.2.3, 11.5, 16.14.4 Oracleデータベース・アダプタ、スケーリング, 9.8.2, 9.9, 10.2.17, 10.2.18 Oracleファイル/FTPアダプタ, 9.8.1, 10.2.15 Oracle Fusion Middleware (FMW)

バックアップ, 6.3.4

FMWホームの作成, 6.3.1

Oracle WebLogic Serverのインストール, 6.3.1

ソフトウェアのインストール, 6.3

Oracle Fusion Middleware構成ウィザード, 8.3 Oracleホーム, 1.2 Oracle HTTP Server

構成, 8.7.1

構成, 10.2.11

BAM用の構成, 12.13

登録, 8.7.3

アクセスの検証, 8.7.5, 9.6.2, 10.2.12, 10.3.5, 12.14, 16.7.2

検証, 7.6

Oracle HTTP Server (OHS)

バックアップ, 6.2.3

構成, 7.5

インストール, 6.2

ロード・バランサ, 7.5

位置, 6.2.2

ポート, 6.2.1

Oracleインスタンス, 1.2 Oracle SOA Suite

インストール, 6.3.2

Oracle WebLogic Server

Oracle HTTP Serverの登録, 8.7.3

Oracle WebLogic Server (WLS)

インストール, 6.3.1

Oracle WebLogic Server管理コンソール, 14.3 ORACLE_BASE, 4.2 ORACLE_HOME, 4.2 ORACLE_INSTANCE, 4.2 oracleRoot.shスクリプト, 6.2.2

P

packユーティリティ, 12.7

接続ファクトリのパラメータ, 9.8.1.1, 10.2.15.1

パフォーマンス、エンタープライズ・デプロイメント, 1.1

永続ストア

トランザクション・リカバリ, 10.2.14, 12.5

物理ホスト名, 1.2 物理IP, 1.2 ポリシー・ドメイン, 15.5.3.3 ポリシー移行, 16.14.5 ポート

ロード・バランサ向けの構成, 3.3

データベース・リスナー, 2.1.6

フロントエンドHTTP, 9.6.3, 10.2.13

HTTP, 2.1.3

HTTPS, 2.1.3

Oracle HTTP Server, 6.2.1

Oracle Internet Directory (OID), 2.1.6

トポロジでの使用, 3.6

1次ノード, 1.2 データベースのPROCESSESパラメータ, 5.2.3, 16.14.6 ドメイン変更の伝播, 9.5.3 ドメイン構成の伝播, 8.5.1, 9.5.5, 10.2.5, 10.2.7, 10.3.2, 12.7 ノード・マネージャのプロパティ・ファイル, 14.4 OAMのプロバイダの順序, 15.5.7.3, 15.6.6.3

R

RACデータベース, 2.1.6, 8.3, 9.3, 10.2.2, 12.4, A.2

RACフェイルオーバー

BAMの再試行の無効化, 16.12

RACマルチデータ・ソース・コンポーネント・スキーマ, 10.2.2, 10.3.1 失敗したBPELインスタンスとメディエータ・インスタンスのリカバリ, 16.10 エンタープライズ・デプロイメントのリカバリ, 16.8 Webサービスでの再帰的ノード攻撃

防止, 16.11

SOAアプリケーションの再デプロイ, 16.13 ホーム・ページへのリダイレクト, 16.14.15, 16.14.16 ログイン画面へのリダイレクト, 16.14.14 参照トポロジ, 2.1 Oracle HTTP Serverの登録, 8.7.3 リポジトリ作成ユーティリティ(RCU), 5.1, 5.4 要件

データベース・ホスト, 5.2.1

ロード・バランサ, 2.1.4

要件、ハードウェア, 2.2 ノード・マネージャの再起動, 9.5.2

S

Oracleデータベース・アダプタのスケーリング, 9.8.2, 9.9, 10.2.17, 10.2.18

トポロジのスケールアウト, 16.6

トポロジのスケールアップ, 16.5

画面

RACマルチ・データ・ソース・コンポーネント・スキーマの構成, 10.2.2, 10.3.1

スクリプト

configure-joc.py, 8.6

createCentralInventory.sh, 6.3.2

leasing.ddl, 14.2

oracleRoot.sh, 6.2.2

setNMProps.sh, 8.4.2, 8.5.4, 12.9

wlsifconfig.sh, 11.14.3, 12.15.4, 14.5, 14.5

2次ノード, 1.2 セキュリティ, 1.3.1 Webサービスのセキュリティ, 16.11 自己署名証明書, 13.3.1, 13.5.1 サーバー移行, 14

BAMサーバー, 11.14, 12.15

ターゲットの構成, 14.6

マルチデータ・ソースの作成, 14.3

ノード・マネージャのプロパティ・ファイルの編集, 14.4

リース・テーブル, 14.2

マルチデータ・ソース, 14.3

環境とスーパー・ユーザー権限の設定, 14.5

ユーザーと表領域の設定, 14.2

テスト, 14.7

トラブルシューティング, 16.14.9, 16.14.10

管理コンソールからの検証, 14.7

サーバー, 8.3

クラスタへの割当て, 9.3, 10.2.2, 12.4

マシンへの割当て, 9.3, 10.2.2, 12.4

WLS_BAM, 11.14, 12.15

サービス・レベル合意, 1.1 サービス、Webサービスのセキュリティ, 16.11 setNMProps.shスクリプト, 8.4.2, 8.5.4, 12.9 ノード・マネージャの設定, 13 WebLogic認証プロバイダの設定, 15.5.7, 15.6.6 共有記憶域, 1.2, 4.3.5, 16.13

構成, 4.4

SOAアプリケーションの更新, 16.13 SOAHOST

Fusion Middlewareホームの作成, 6.3.1

Oracle SOA Suiteのインストール, 6.3.2

Oracle WebLogic Serverのインストール, 6.3.1

SOAHOSTノード, 2.1.5, 8.2, 8.3, 8.4.1, 8.4.2, 8.5.4, 9.5.2, 12.6 SOAHOST1VHn仮想ホスト, 9.4.1, 10.2.3.1 soa-infraアプリケーション, 16.14.2, 16.14.4 soainternal.mycompany.com, 3.2.4 soa.mycomany.com, 3.2.1 ソフトウェア

Oracle Fusion Middleware, 6.3

Oracle HTTP Server, 6.2

Oracle WebLogic Server, 6.3.1

SSLの高速化, 2.1.4 SSL通信, 13.3, 13.5 管理サーバーの起動, 8.4.3 BAMシステムの起動, 12.10 ノード・マネージャの起動, 8.4.2, 8.5.4, 12.9, 13.4, 13.6 WLS_SOA管理対象サーバーの起動, 9.5.6 WLS_WSM管理対象サーバーの起動, 8.4.9, 8.5.5 記憶域, 4.3.5 スーパー・ユーザー権限, 14.5 サポートされているデータベース・バージョン, 5.2.2 スイッチバック, 1.2 スイッチオーバー, 1.2

T

ターゲット指定されるアプリケーション, 9.3, 10.2.2, 10.3.1

デプロイメントのターゲット設定, 8.3

BAMのターゲット, 12.6

サーバー移行のターゲット, 14.6

サーバー移行のテスト, 14.7

トポロジ, 2.1

アプリケーション層, 2.1.5

データ層, 2.1.6

管理, 16

監視, 16.1

スケールアウト, 16.6

スケールアップ, 16.5

Web層, 2.1.3

トランザクション・リカバリ, 10.2.14, 12.5 トラブルシューティング

管理サーバーでの変更のアクティブ化, 16.14.8

BAMでの404エラー, 16.14.1

Coherence, 16.14.4

デプロイメント・フレームワークの問題, 16.14.4

B2Bドキュメント定義取得時のエラー, 16.14.3

未完のポリシー移行, 16.14.5

誤ったURL, 16.14.13

手動フェイルオーバー, 16.14.7

データベースの最大プロセス数, 16.14.6

ホーム・ページへのリダイレクト, 16.14.15, 16.14.16

ログイン画面へのリダイレクト, 16.14.14

サーバー移行, 16.14.9, 16.14.10

SOAサーバーの応答停止, 16.14.11

soa-infraアプリケーション, 16.14.2, 16.14.4

soa-infraアプリケーションにロード・バランサ経由でアクセスできない, 16.14.2

信頼キーストア, 13.3.3

U

UMSドライバ, 16.4

ユニキャスト通信, 2.1.7, 9.4, 10.2.3

unpackユーティリティ, 8.5.1, 9.5.5, 10.2.5, 10.2.7, 10.3.2, 12.7

BAMサーバー・システムのターゲット指定の解除, 12.6

SOAアプリケーションの更新, 16.13

ホスト識別子の更新, 15.5.3.4

WebGateプロファイルの更新, 15.5.3.5

URL、コールバック, 10.2.13

utils.CertGenユーティリティ, 13.3.1, 13.5.1

utils.ImportPrivateKeyユーティリティ, 13.3.2, 13.5.2

V

検証

Oracle HTTP Serverを使用したアクセス, 8.7.5, 9.6.2, 10.2.12, 16.7.2

Oracle HTTP Serverを使用したアクセス(BAM), 10.3.5, 12.14

管理サーバー, 8.4.5

Oracle HTTP Server, 7.6

サーバー移行, 14.7

Web層のインストール, 7.4

WLS_SOA管理対象サーバー, 9.5.6, 10.2.6

WLS_SOA2管理対象サーバー, 9.5.4, 10.2.9

WLS_WSM管理対象サーバー, 8.4.9, 8.5.5, 10.2.6

ホスト名の検証, 8.4.8, 8.5.3 VIP, 3.4, 3.4

SOAHOST1上でのSOAHOST1VHN1の有効化, 8.2

仮想ホスト名, 1.2 仮想IP, 1.2, 1.2 仮想IPアドレス

WebLogic管理サーバーの関連付け, 3.5

仮想IP (VIP), 3.4, 3.4 仮想サーバー名, 3.2 仮想サーバー, 2.1.4

admin.mycompany.com, 3.2.2

soainternal.mycompany.com, 3.2.4

soa.mycompany.com, 3.2.1

httpd.confの<VirtualHost>エントリ, 7.6.2

W

BAMのWebアプリケーション, 12.12

Webサービス

保護, 16.11

Webサービス, 16.11 Web層, 2.1.3

インストールの検証, 7.4

WebGate, 2.1.3, 15.5.4 WebGateプロファイル, 15.5.3.5 WEBHOST

ロード・バランサとOHSの構成 7.5

Web層の構成, 7.3

Oracle HTTP Serverのインストール, 6.2.2

WEBHOSTノード, 2.1.3 WebLogic管理サーバー

仮想IPアドレスとの関連付け, 3.5

WebLogic管理者、LDAPへの移動, 15.2.2 WebLogic認証プロバイダ, 15.5.7, 15.6.6 WebLogic構成ウィザード, 8.3 WebLogic Serverホーム, 1.2 WL_HOME, 4.2 WLS_BAM

移行, 12.15

WLS_BAMサーバー, 11.14, 12.15 WLS_SOA管理対象サーバー

ホスト名の検証の無効化, 9.5.1, 10.2.4, 11.4, 12.8

WLS_WSM, 8.4.1, 8.7.1, 8.7.1

ホスト名検証の無効化, 8.4.8, 8.5.3

起動, 8.4.9、8.5.5

検証, 8.4.9, 8.5.5

wlsifconfig.shスクリプト, 11.14.3, 12.15.4, 14.5, 14.5

X

XEngine, 9.5.5.1, 10.2.8

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。