Oracle® Fusion Middleware

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

12c (12.2.1.1)

E77231-01(原本部品番号:E73511-01)

2016年6月

エンタープライズ・デプロイメントで、Oracle Fusion Middlewareコンポーネントをインストールおよび構成する方法について説明します。

Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド, 12c (12.2.1.1)

E77231-01

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

原本著者: Fermin Castro (MAAエンジニア)、Peter LaQuerre (ライター)、HT Ma (品質保証)

原本協力者: Satheesh Amilineni、Sudhakar Betha、John Featherly、Mark Foster、Derek Kam、Rodger King、Stefan Koser、Ashwani Raj、Michael Rhys、Joe Paul、Maria Salzberger、Muthukumar Subramaniam、Mukesh Tailor、Chakravarthy Tenneti、Bonnie Vaughan、Shane Vermette

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

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

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

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)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

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の登録商標です。

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

目次

タイトルと著作権情報

はじめに

- 対象読者

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

- 表記規則

第I部 エンタープライズ・デプロイメントの理解

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

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

- 1.2 エンタープライズ・デプロイメント・ガイドを使用するケース

2 標準的なエンタープライズ・デプロイメントの理解

- 2.1 標準的なエンタープライズ・デプロイメントのダイアグラム

- 2.2 標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムの理解

- 2.2.1 標準的なエンタープライズ・デプロイメントのファイアウォールとゾーンの理解

- 2.2.2 標準的なエンタープライズ・デプロイメント・トポロジの各要素の理解

- 2.2.3 ハードウェア・ロード・バランサを介したリクエストの受信

- 2.2.3.1 ハードウェア・ロード・バランサ(LBR)の目的

- 2.2.3.1.1 インターネットからWeb層内のWebサーバー・インスタンスへのHTTPリクエスト

- 2.2.3.1.2 Oracle SOA Suite for Healthcare IntegrationのMLLPリクエスト

- 2.2.3.1.3 Oracle MFT IntegrationのSFTPリクエスト

- 2.2.3.1.4 アプリケーション層のコンポーネント間特有の内部専用通信

- 2.2.3.2 標準的なロード・バランサの仮想サーバー名のサマリー

- 2.2.3.3 外部仮想サーバー名に対するHTTPSリクエストとHTTPリクエストの対比

- 2.2.4 Web層の理解

- 2.2.4.1 リクエストのルーティングにWeb層を使用する利点

- 2.2.4.2 Web層の使用にかわる方法

- 2.2.4.3 Web層でのOracle HTTP Serverの構成

- 2.2.4.4 Mod_WL_OHSについて

- 2.2.5 アプリケーション層の理解

- 2.2.5.1 管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成

- 2.2.5.2 アプリケーション層でのOracle Web Services Managerの使用

- 2.2.5.3 アプリケーション層におけるクラスタとホストの構成のベスト・プラクティスとバリエーション

- 2.2.5.4 標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について

- 2.2.5.5 アプリケーション層内での通信のためのユニキャストの使用について

- 2.2.5.6 OPSSおよび認証ストアと認可ストアへのリクエストの理解

- 2.2.5.7 標準的なエンタープライズ・デプロイメントでのCoherenceクラスタについて

- 2.2.6 データ層について

3 Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジの理解

- 3.1 プライマリおよび独自構築のエンタープライズ・デプロイメント・トポロジの理解

- 3.2 プライマリOracle SOA Suiteエンタープライズ・トポロジのダイアグラム

- 3.2.1 Oracle SOA SuiteおよびOracle Service Busのトポロジのダイアグラム

- 3.2.2 Oracle SOA SuiteおよびOracle Business Activity Monitoringのトポロジのダイアグラム

- 3.3 プライマリOracle SOA Suiteトポロジ・ダイアグラムの理解

- 3.3.1 Oracle Service Busのトポロジ・オプションの理解

- 3.3.2 Oracle SOA Suiteのロード・バランサ仮想サーバー名のサマリー

- 3.3.3 SOAコンポジット・リクエストのルーティングの理解

- 3.3.3.1 soainternal仮想サーバー名の詳細

- 3.3.3.2 SOAコンポジット・アプリケーション用のWebサービスの最適化について

- 3.3.3.3 Oracle HTTP Serverを介したSOAコンポジット・アプリケーションへのアクセスについて

- 3.3.3.4 ロード・バランサを介したOracle SOA Suiteコンポジット・アプリケーションへのアクセスについて

- 3.3.4 SOAアプリケーション層の管理対象サーバーとクラスタのサマリー

- 3.4 プライマリOracle SOA Suiteエンタープライズ・トポロジの実装のフロー・チャートとロードマップ

- 3.4.1 プライマリOracle SOA Suiteエンタープライズ・トポロジをインストールおよび構成する手順のフロー・チャート

- 3.4.2 エンタープライズ・デプロイメントの計画と準備のためのロードマップ表

- 3.4.3 Oracle SOA SuiteおよびOracle Service Busエンタープライズ・トポロジの構成のためのロードマップ表

- 3.4.4 Oracle SOA SuiteおよびOracle Business Activity Monitoringエンタープライズ・トポロジの構成のためのロードマップ表

- 3.5 独自のOracle SOA Suiteエンタープライズ・トポロジの構築

- 3.5.1 独自構築のエンタープライズ・トポロジのフロー・チャート

- 3.5.2 サポートされている独自構築トポロジの説明

- 3.6 カスタム・エンタープライズ・トポロジのインストールと構成について

- 3.7 Oracle SOA Suiteエンタープライズ・トポロジでの自動サービス移行の使用について

第II部 エンタープライズ・デプロイメントの準備

4 エンタープライズ・デプロイメント・ワークブックの使用

- 4.1 エンタープライズ・デプロイメント・ワークブックの概要

- 4.2 ワークブックの標準的なユース・ケース

- 4.3 Oracle SOA Suiteエンタープライズ・デプロイメント・ワークブックの使用

- 4.3.1 Oracle SOA Suiteエンタープライズ・デプロイメント・ワークブックの入手方法

- 4.3.2 Oracle SOA Suiteエンタープライズ・デプロイメント・ワークブックの内容の理解

- 4.3.2.1 スタート・タブの使用

- 4.3.2.2 ハードウェア - ホスト・コンピュータ・タブの使用

- 4.3.2.3 ネットワーク - 仮想ホストとポート・タブの使用

- 4.3.2.4 ストレージ - ディレクトリ変数タブの使用

- 4.3.2.5 「データベース - 接続の詳細」タブの使用

- 4.4 エンタープライズ・デプロイメント・ワークブックの使用対象者

5 エンタープライズ・デプロイメント用のリソースの取得

- 5.1 エンタープライズ・デプロイメント・トポロジ用のハードウェアおよびソフトウェアの要件

- 5.1.1 ハードウェア・ロード・バランサの要件

- 5.1.2 ホスト・コンピュータのハードウェア要件

- 5.1.2.1 エンタープライズ・デプロイメントのホスト・コンピュータに関する一般的な考慮事項

- 5.1.2.2 Oracle Fusion Middlewareシステム要件の確認

- 5.1.2.3 エンタープライズ・デプロイメントに必要な標準的なメモリー、ファイル・ディスクリプタおよびプロセス数

- 5.1.2.4 エンタープライズ・デプロイメントの標準的なディスク領域要件

- 5.1.3 エンタープライズ・デプロイメント・トポロジのオペレーティング・システム要件

- 5.2 エンタープライズ・デプロイメント用の必須IPアドレスの予約

- 5.2.1 仮想IP (VIP)アドレスとは

- 5.2.2 仮想ホスト名と仮想IPアドレスを使用する理由

- 5.2.3 エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス

- 5.3 エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得

6 エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備

- 6.1 ハードウェア・ロード・バランサでの仮想ホストの構成

- 6.1.1 ハードウェア・ロード・バランサ構成の概要

- 6.1.2 ハードウェア・ロード・バランサの構成の一般的な手順

- 6.1.3 エンタープライズ・デプロイメントに必要な仮想サーバーのサマリー

- 6.1.4 admin.example.comに関する追加手順

- 6.1.5 soa.example.comに関する追加手順

- 6.1.6 soainternal.example.comに関する追加手順

- 6.1.7 osb.example.comに関する追加手順

- 6.1.8 soahealthcare.example.comに関する追加手順

- 6.1.9 mft.example.comに関する追加手順

- 6.2 エンタープライズ・デプロイメントのファイアウォールとポートの構成

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

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

- 7.2 エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項

- 7.3 エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解

- 7.4 このガイドで使用するファイル・システムとディレクトリ変数

- 7.5 エンタープライズ・デプロイメントのディレクトリの作成とマウントについて

- 7.6 エンタープライズ・デプロイメントの共有記憶域ボリュームの概要

8 エンタープライズ・デプロイメント用のホスト・コンピュータの準備

- 8.1 各ホストの最小ハードウェア要件の検証

- 8.2 Linuxオペレーティング・システムの要件の検証

- 8.2.1 Linuxのカーネル・パラメータの設定

- 8.2.2 UNIXシステムでのオープン・ファイル制限とプロセス数の設定

- 8.2.2.1 現在開いているファイル数の表示

- 8.2.2.2 オペレーティング・システムのオープン・ファイルおよびプロセス制限の設定

- 8.2.3 DNSまたはホスト・ファイルでのIPアドレスとホスト名の確認

- 8.3 オペレーティング・システムのユーザーおよびグループの構成

- 8.4 Unicodeサポートの有効化

- 8.5 各ホストへの必要な共有ファイル・システムのマウント

- 8.6 各ホストでの必要な仮想IPアドレスの有効化

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

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

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

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

- 9.2.2 その他のデータベース・ソフトウェア要件

- 9.2.3 エンタープライズ・デプロイメントのPROCESSESデータベース初期化パラメータの設定

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

- 9.4 Oracleデータベースでのラージ・オブジェクト(LOB)に対するSecureFilesの使用

- 9.5 データベース・バックアップ戦略について

- 9.6 Oracle SOA Suiteへのデータベース増分管理戦略の導入

第III部 エンタープライズ・デプロイメントの構成

10 エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成

- 10.1 インフラストラクチャ・ドメインの作成時に使用する変数

- 10.2 初期インフラストラクチャ・ドメインの理解

- 10.2.1 インフラストラクチャ・ディストリビューションについて

- 10.2.2 ドメインの特徴

- 10.3 エンタープライズ・デプロイメントの準備におけるOracle Fusion Middleware Infrastructureのインストール

- 10.3.1 サポートされているJDKのインストール

- 10.3.1.1 JDKソフトウェアの検索とダウンロード

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

- 10.3.2 SOAHOST1でのInfrastructureインストーラの起動

- 10.3.3 Infrastructureインストール画面のナビゲート

- 10.3.4 他のホスト・コンピュータへのOracle Fusion Middleware Infrastructureのインストール

- 10.3.5 ディレクトリ構造のチェック

- 10.4 データベース・スキーマの作成

- 10.4.1 動作保証されたデータベースのインストールおよび構成

- 10.4.2 リポジトリ作成ユーティリティ(RCU)の起動

- 10.4.3 RCU画面からスキーマ作成へのナビゲート

- 10.5 Infrastructureドメインの構成

- 10.5.1 構成ウィザードの起動

- 10.5.2 Infrastructureドメインを構成するための構成ウィザード画面のナビゲート

- 10.6 エンタープライズ・デプロイメントに対するホストごとのノード・マネージャの構成

- 10.6.1 ホストごとのノード・マネージャ構成の作成

- 10.6.2 boot.propertiesファイルの作成

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

- 10.6.4 ノード・マネージャ資格証明およびタイプの構成

- 10.7 ドメイン・ディレクトリの構成とMFTHOST1上のサーバーの起動

- 10.7.1 ノード・マネージャを使用した管理サーバーの起動

- 10.7.2 管理サーバーの検証

- 10.7.3 Derbyデータベースの無効化

- 10.7.4 SOAHOST1での管理対象サーバーの個別ドメイン・ディレクトリの作成

- 10.7.5 SOAHOST1でのWLS_WSM1管理対象サーバーの起動と検証

- 10.8 ドメインの伝播とMFTHOST2上のサーバーの起動

- 10.8.1 MFTHOST2でのドメイン構成の解凍

- 10.8.2SOAHOST2でのドメインの解凍

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

- 10.8.4 SOAHOST2でのWLS_WSM2管理対象サーバーの起動と検証

- 10.9 uploadおよびstageディレクトリの絶対パスへの変更

- 10.10 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング

- 10.10.1 サポートされている認証プロバイダについて

- 10.10.2 エンタープライズ・デプロイメント・ユーザーおよびグループについて

- 10.10.2.1各ドメインで一意の管理ユーザーの使用について

- 10.10.2.2 ドメイン・コネクタ・ユーザーについて

- 10.10.2.3 集中LDAPディレクトリへのユーザーの追加について

- 10.10.2.4 Oracle SOA Suiteの製品固有のロールとグループについて

- 10.10.2.5 このガイドで使用するサンプル・ユーザーとサンプル・ロール

- 10.10.3 新しい認証プロバイダの作成とユーザーおよびグループのプロビジョニングの前提条件

- 10.10.4 LDAPディレクトリでのドメイン・コネクタ・ユーザーのプロビジョニング

- 10.10.5 新しい認証プロバイダの作成

- 10.10.6 エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング

- 10.10.7 管理グループへの新しい管理ユーザーの追加

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

- 10.11 Administratorsグループへのwsm-pmロールの追加

11 エンタープライズ・デプロイメント用のOracle HTTP Serverの構成

- 11.1 Oracle HTTP Serverの構成時に使用される変数

- 11.2 Oracle HTTP Serverドメインについて

- 11.3 WEBHOST1へのOracle HTTP Serverのインストール

- 11.3.1 WEBHOST1でのインストーラの起動

- 11.3.2 Oracle HTTP Serverのインストール画面のナビゲート

- 11.3.3 Oracle HTTP Serverインストールの確認

- 11.4 WEBHOST1でのOracle HTTP Serverドメインの作成

- 11.4.1 WEBHOST1での構成ウィザードの起動

- 11.4.2 Oracle HTTP Serverドメインの構成ウィザード画面のナビゲート

- 11.5 WEBHOST2でのOracle HTTP Serverドメインのインストールおよび構成

- 11.6 WEBHOST1およびWEBHOST2でのノード・マネージャおよびOracle HTTP Serverインスタンスの起動

- 11.6.1 WEBHOST1およびWEBHOST2でのノード・マネージャの起動

- 11.6.2 Oracle HTTP Serverインスタンスの起動

- 11.7 リクエストをアプリケーション層にルーティングするようにOracle HTTP Serverを構成

- 11.7.1 エンタープライズ・デプロイメント用のOracle HTTP Server構成について

- 11.7.1.1Oracle HTTP Server仮想ホストの目的

- 11.7.1.2 <VirtualHost>ディレクティブのWebLogicClusterパラメータについて

- 11.7.1.3 Oracle HTTP Server構成ファイルの推奨構造

- 11.7.2 仮想ホスト構成ファイルを追加するためのhttpd.confファイルの変更

- 11.7.3 仮想ホスト構成ファイルの作成

- 11.7.4 ロード・バランサでの仮想サーバー構成の検証

- 11.7.5 管理サーバーおよびOracle Web Services Managerへのルーティングの構成

- 11.7.6 管理コンソールおよび管理サーバーへのアクセスの確認

12 Oracle Traffic Directorを含めるドメインの拡張

- 12.1 Oracle Traffic Directorについて

- 12.2 エンタープライズ・デプロイメントでOracle Traffic Directorの構成時に使用される変数

- 12.3 エンタープライズ・デプロイメントでのOracle Traffic Directorについて

- 12.4 コロケート・モードでのアプリケーション層ホストへのOracle Traffic Directorのインストール

- 12.4.1 Oracle Traffic Directorインストーラの起動

- 12.4.2 Oracle Traffic Directorのインストール画面のナビゲート(コロケート)

- 12.4.3 アプリケーション層ホストのインストールの確認

- 12.5 スタンドアロン・モードでのWeb層ホストへのOracle Traffic Directorのインストール

- 12.5.1 Oracle Traffic Directorインストーラの起動

- 12.5.2 Oracle Traffic Directorのインストール画面のナビゲート(スタンドアロン)

- 12.5.3 Web層ホストのインストールの確認

- 12.6 Oracle Traffic Directorシステム・コンポーネントを含めるドメインの拡張

- 12.6.1 <otd_apptier_hostname>での構成ウィザードの起動

- 12.6.2 ドメインを拡張するために構成ウィザード画面へ移動

- 12.6.2.1 ドメイン・タイプとドメインの場所の選択

- 12.6.2.2 Oracle Traffic Directorの構成テンプレートの選択

- 12.6.2.3 拡張構成オプションの選択

- 12.6.2.4 Oracle Traffic Directorのシステム・コンポーネントの追加

- 12.6.2.5 Oracle Traffic DirectorのWebLogic Serverマシンの作成

- 12.6.2.6 構成の指定内容の確認とドメインの構成

- 12.6.2.7 ドメイン・ホームと管理サーバーURLの記録

- 12.7 ドメインの伝播とWeb層ホスト上のノード・マネージャの起動

- 12.7.1 アプリケーション層でのドメインの圧縮

- 12.7.2 Web層ホストでのドメイン構成の解凍

- 12.7.3 Web層ホストでのノード・マネージャの構成および起動

- 12.8 Oracle Traffic Director構成の作成

- 12.9 Oracle Traffic Directoryデフォルト・インスタンスの起動

- 12.10 エンタープライズ・デプロイメント用のOracle Traffic Director仮想サーバーの定義

- 12.10.1 必要なオリジン・サーバー・プールの作成

- 12.10.2 仮想サーバーの作成

- 12.10.3 仮想サーバー・ルートの作成

- 12.10.4 オリジン・サーバーおよび仮想ホストのサマリー

- 12.11 Managed File TransferのTCPプロキシの作成

- 12.12 仮想ホストのフェイルオーバー・グループの作成

- 12.12.1 フェイルオーバー・グループの作成

13 Oracle SOA Suiteを含めるドメインの拡張

- 13.1 Oracle SOA Suiteを含めるドメインの拡張時に使用する変数

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

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

- 13.3.1 SOAHOST1でのOracle SOA Suiteインストーラの起動

- 13.3.2 インストール画面のナビゲート

- 13.3.3 他のホスト・コンピュータへのOracle SOA Suiteのインストール

- 13.3.4 インストールの確認

- 13.3.4.1 インストール・ログ・ファイルの確認

- 13.3.4.2 ディレクトリ構造のチェック

- 13.3.4.3 Oracleホームの内容の表示

- 13.4 Oracle SOA Suiteデータベース・スキーマの作成

- 13.4.1 リポジトリ作成ユーティリティ(RCU)の起動

- 13.4.2 RCU画面からスキーマ作成へのナビゲート

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

- 13.5 Oracle SOA Suiteを含めるエンタープライズ・デプロイメント・ドメインの拡張

- 13.5.1 構成ウィザードの起動

- 13.5.2 Oracle SOA Suiteを含めるドメイン拡張を行うための構成ウィザード画面のナビゲート

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

- 13.7 ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

- 13.7.1SOAHOST1での拡張済ドメインの圧縮

- 13.7.2 SOAHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍

- 13.7.3SOAHOST2でのドメインの解凍

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

- 13.8.1 WLS_SOA1管理対象サーバーの起動

- 13.8.2 AdministratorsグループへのSOAAdminロールの追加

- 13.8.3 SOAインフラストラクチャへのログインによる管理対象サーバーの検証

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

- 13.10 トランザクション・ログの場所と作成の検証

- 13.11 拡張したドメイン用のWeb層の構成

- 13.11.1 拡張したドメイン用のOracle Traffic Directorの構成

- 13.11.2 WLS_SOA管理対象サーバー用のOracle HTTP Serverの構成

- 13.11.3 WebLogicプロキシ・プラグインの構成

- 13.11.4 ロード・バランサを使用したOracle SOA Suite URLの検証

- 13.12 Oracle SOA Suiteの構成後手順

- 13.12.1 Oracle SOA Suite用のOracleアダプタの構成

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

- 13.12.1.1.1 OracleファイルおよびFTPアダプタ構成の理解

- 13.12.1.1.2 管理コンソールでのOracleファイル・アダプタの構成

- 13.12.1.1.3 コンポジット・アプリケーション内でのJCAファイルの編集

- 13.12.1.1.4 Oracle FTPアダプタの構成

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

- 13.12.1.3 Oracle Databaseアダプタの高可用性の有効化

- 13.12.2 SOAサーバーとハードウェア・ロード・バランサ間のSSL通信の有効化

- 13.12.3 SOAクラスタ内の同期/非同期相互作用に関する考慮事項

- 13.13 Oracle SOA Suiteに対する自動サービス移行およびJDBC永続ストアの有効化

14 トポロジへのOracle Service Busの追加

- 14.1 トポロジにOracle Service Busを追加する際に使用する変数

- 14.2 Oracle Serviceの独自のドメインでの構成について

- 14.3 トポロジへのOSBの追加の概要

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

- 14.5 Oracle Service Busソフトウェアのインストール

- 14.5.1 Oracle Service Busインストーラの起動

- 14.5.2 OSBインストール画面のナビゲート

- 14.5.3 他のホスト・コンピュータへのソフトウェアのインストール

- 14.5.4 OSBインストールの検証

- 14.5.4.1 インストール・ログ・ファイルの確認

- 14.5.4.2 ディレクトリ構造のチェック

- 14.5.4.3 Oracleホームの内容の表示

- 14.6 Oracle Service Busを追加するためのSOAまたはInfrastructureドメインの拡張

- 14.6.1 構成ウィザードの起動

- 14.6.2 Oracle Service Busの構成ウィザード画面のナビゲート

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

- 14.8 ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

- 14.8.1 変更を他のドメイン・ディレクトリおよびマシンに伝播するために必要なタスクのサマリー

- 14.8.2 WLS_OSB1管理対象サーバーの起動と検証

- 14.8.2.1 WLS_OSB1管理対象サーバーの起動

- 14.8.2.2 エンタープライズ・デプロイメント管理グループへのMiddlewareAdministratorsロールの追加

- 14.8.2.3 SOAインフラストラクチャへのログインによる管理対象サーバーの検証

- 14.8.3 WLS_OSB2管理対象サーバーの起動と検証

- 14.8.4 トランザクション・ログの場所と作成の検証

- 14.8.5 OSBシングルトン・サービスのターゲット指定が適切であるかどうかの確認

- 14.9 拡張したドメイン用のWeb層の構成

- 14.9.1 拡張したドメイン用のOracle Traffic Directorの構成

- 14.9.2 Oracle Service Bus用のOracle HTTP Serverの構成

- 14.9.3 WebLogicプロキシ・プラグインの構成

- 14.9.4 ロード・バランサを使用したOracle Service Bus URLの検証

- 14.10 Oracle Service Busの構成後タスク

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

- 14.10.2 エンタープライズ・デプロイメント用の個別のOracle Service Busサービスの構成

- 14.10.3 Oracle Service Busサーバーとハードウェア・ロード・バランサ間のSSL通信の有効化

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

- 14.11 Oracle Service Busに対する自動サービス移行およびJDBC永続ストアの有効化

15 Business Process Managementを含めるドメインの拡張

- 15.1 この章で使用される変数

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

- 15.3 エンタープライズ・デプロイメント用のOracle Business Process Managementのインストール

- 15.3.1 インストール・プログラムの起動

- 15.3.2 Oracle BPMのインストール画面のナビゲート

- 15.3.3 インストールの確認

- 15.3.3.1 インストール・ログ・ファイルの確認

- 15.3.3.2 ディレクトリ構造のチェック

- 15.3.3.3 Oracleホームの内容の表示

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

- 15.4.1 構成ウィザードの起動

- 15.4.2 ドメインを拡張するために構成ウィザード画面へ移動

- 15.5 ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

- 15.6 WebフォームのSOA BPMサーバーの更新

- 15.7 Business Process ManagementによるWLS_SOA管理対象サーバーの再起動

- 15.8 Oracle BAM Administrationグループへのエンタープライズ・デプロイメント管理ユーザーの追加

- 15.9 拡張したドメイン用のWeb層の構成

- 15.9.1 拡張したドメイン用のOracle Traffic Directorの構成

- 15.9.2 Oracle Business Process Management用のOracle HTTP Serverの構成

- 15.10 Business Process Managementサーバーとハードウェア・ロード・バランサ間のSSL通信の有効化

- 15.11 ハードウェア・ロード・バランサを使用したBusiness Process Managementへのアクセスの検証

- 15.12 Oracle BPM Cluster用のBPMJMSModuleの構成

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

- 15.14 Oracle Business Process Managementに対する自動サービス移行およびJDBC永続ストアの有効化

16 Oracle Enterprise Schedulerを含めるドメインの拡張

- 16.1 この章で使用される変数

- 16.2 SOAドメインへのOracle Enterprise Schedulerの追加の概要

- 16.3 ESS用のデータベース・スキーマの作成

- 16.3.1 リポジトリ作成ユーティリティ(RCU)の起動

- 16.3.2 エンタープライズ・スケジューラ・スキーマを作成するためのRCU画面のナビゲート

- 16.4 Oracle Enterprise Schedulerを追加するためのSOAドメインの拡張

- 16.4.1 構成ウィザードの起動

- 16.4.2 Oracle Enterprise Schedulerを含めるドメイン拡張を行うための構成ウィザード画面への移動

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

- 16.6 ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

- 16.7 SOA管理者グループへのESSAdminロールの追加

- 16.8 WLS_ESS1管理対象サーバーの起動

- 16.9 WLS_ESS2管理対象サーバーの起動と検証

- 16.10 トランザクション・ログの場所と作成の検証

- 16.11 拡張したドメイン用のWeb層の構成

- 16.11.1 拡張したドメイン用のOracle Traffic Directorの構成

- 16.11.2 WLS_ESS管理対象サーバーに対するOracle HTTP Serverの構成

- 16.11.3 WebLogicプロキシ・プラグインの構成

- 16.12 ハードウェア・ロード・バランサを介したOracle Enterprise Schedulerへのアクセスの検証

- 16.13 Oracle Enterprise Scheduler構成のバックアップ

17 Business Activity Monitoringを含めるドメインの拡張

- 17.1 この章で使用される変数

- 17.2 Oracle BAMをドメインに追加するための前提条件

- 17.2.1 Oracle BAMをドメインに追加するためのインストール要件の理解

- 17.2.2 Oracle BAMのデータベース・スキーマ要件の理解

- 17.2.3 既存のインストールのバックアップ

- 17.3 個別のホスト上でOracle BAMを構成する場合の特別な指示

- 17.3.1 Oracle BAM用の追加ホスト・コンピュータの入手

- 17.3.2 個別のホスト上でOracle BAMを構成するときのインストール要件

- 17.3.2.1 個別のボリュームまたはパーティションを使用するときのインストール要件

- 17.3.2.2 共有Oracleホームを使用するときのインストール要件

- 17.3.3 個別のホスト上でOracle BAMを構成するときの構成ウィザードの手順

- 17.3.4 個別のホスト上でOracle BAMを構成するときのドメイン構成の伝播

- 17.4 Oracle BAMをドメインに追加するためのロードマップ

- 17.5 Oracle Business Activity Monitoringを追加するためのSOAドメインの拡張

- 17.5.1 構成ウィザードの起動

- 17.5.2 Oracle BAMの構成ウィザード画面のナビゲート

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

- 17.7 ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

- 17.8 Oracle BAM管理グループへのエンタープライズ・デプロイメント管理ユーザーの追加

- 17.9 WLS_BAM1管理対象サーバーの起動

- 17.10 WLS_BAM2管理対象サーバーの起動と検証

- 17.11 拡張したドメイン用のWeb層の構成

- 17.11.1 拡張したドメイン用のOracle Traffic Directorの構成

- 17.11.2 WLS_BAM管理対象サーバーに対するOracle HTTP Serverの構成

- 17.11.3 WebLogicプロキシ・プラグインの構成

- 17.12 ハードウェア・ロード・バランサを介したOracle BAMへのアクセスの検証

- 17.13 Oracle BAMサーバーに対する自動サービス移行およびJDBC永続ストアの有効化

- 17.14 Oracle BAM構成のバックアップ

18 Oracle B2Bを含めるドメインの拡張

- 18.1 この章で使用される変数

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

- 18.3 エンタープライズ・デプロイメントのOracle B2Bのインストール

- 18.3.1 SOAHOST1でのOracle B2BおよびHealthcareインストーラの起動

- 18.3.2 Oracle B2Bのインストール画面のナビゲート

- 18.3.3 B2BまたはHealthcareインストールの確認

- 18.3.3.1 インストール・ログ・ファイルの確認

- 18.3.3.2 ディレクトリ構造のチェック

- 18.3.3.3 Oracleホームの内容の表示

- 18.4 構成ウィザードを使用したOracle B2Bのための拡張

- 18.4.1 構成ウィザードの起動

- 18.4.2 Oracle B2Bの構成ウィザード画面のナビゲート

- 18.5 B2B Suiteコンポーネントの起動

- 18.6 トランスポートのためのB2Bインスタンス識別子の更新

- 18.7 拡張したドメイン用のWeb層の構成

- 18.7.1 拡張したドメイン用のOracle Traffic Directorの構成

- 18.7.2 Oracle B2Bに対するOracle HTTP Serverの構成

- 18.8 SOA管理者グループへのB2BAdminロールの追加

- 18.9 ロード・バランサを介したOracle B2Bへのアクセスの検証

- 18.10 構成のバックアップ

- 18.11 Oracle B2Bに対する自動サービス移行およびJDBC永続ストアの有効化

19 Oracle SOA Suite for Healthcare Integrationを含めるドメインの拡張

- 19.1 Oracle Healthcare用にドメインを拡張する際に使用される変数

- 19.2 エンタープライズ・デプロイメントでのOracle SOA Suite for Healthcare Integrationについて

- 19.3 Oracle Healthcareを追加するためのドメイン拡張の前提条件

- 19.4 エンタープライズ・デプロイメントのOracle Healthcareのインストール

- 19.4.1 SOAHOST1でのOracle B2BおよびHealthcareインストーラの起動

- 19.4.2 Oracle Healthcareインストール用のインストール画面のナビゲート

- 19.4.3 B2BまたはHealthcareインストールの確認

- 19.4.3.1 インストール・ログ・ファイルの確認

- 19.4.3.2 ディレクトリ構造のチェック

- 19.4.3.3 Oracleホームの内容の表示

- 19.5 Oracle Healthcareの構成ウィザードの実行

- 19.5.1 構成ウィザードの起動

- 19.5.2 Oracle Healthcareの構成ウィザード画面のナビゲート

- 19.6 Healthcareコンポーネントの起動

- 19.7 B2Bインスタンス識別子およびMLLP高可用性モードの更新

- 19.8 最適なロード・バランシングのための接続ファクトリ・アフィニティの無効化

- 19.9 拡張したドメイン用のWeb層の構成

- 19.9.1 拡張したドメイン用のOracle Traffic Directorの構成

- 19.9.2 Oracle Healthcare用のOracle HTTP Serverの構成

- 19.10 SOA管理者グループへのB2BAdminロールの追加

- 19.11 ロード・バランサを介したOracle Healthcareへのアクセスの検証

- 19.12 構成のバックアップ

- 19.13 Oracle Healthcareに対する自動サービス移行の有効化

20 エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

- 20.1 Oracle Managed File Transferについて

- 20.1.1 エンタープライズ・デプロイメントでのManaged File Transferについて

- 20.1.2 Managed File Transferドメインの特徴

- 20.2 エンタープライズ・デプロイメントでOracle Traffic Directorの構成時に使用される変数

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

- 20.4 Managed File Transferドメインを作成するための前提条件

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

- 20.5.1 MFTHOST1でのManaged File Transferインストーラの起動

- 20.5.2 Managed File Transferをインストールする場合のインストール画面のナビゲート

- 20.5.3 インストールの確認

- 20.5.3.1 インストール・ログ・ファイルの確認

- 20.5.3.2 Managed File Transferのディレクトリ構造のチェック

- 20.6 Managed File Transferデータベース・スキーマの作成

- 20.6.1 リポジトリ作成ユーティリティ(RCU)の起動

- 20.6.2 Managed File Transferスキーマを作成するためのRCU画面のナビゲート

- 20.7 エンタープライズ・デプロイメント用のManaged File Transferドメインの作成

- 20.7.1 構成ウィザードの起動

- 20.7.2 ドメインを作成および構成するための構成ウィザード画面のナビゲート

- 20.7.2.1 ドメイン・タイプとドメイン・ホームの場所の選択

- 20.7.2.2 Templates for Oracle Managed File Transferの構成テンプレートの選択

- 20.7.2.3 エンタープライズ・デプロイメント・ドメインのアプリケーション・ホームの場所の選択

- 20.7.2.4 管理者アカウントの構成

- 20.7.2.5 エンタープライズ・デプロイメントのドメイン・モードとJDKの指定

- 20.7.2.6 エンタープライズ・デプロイメントのデータベース構成タイプの指定

- 20.7.2.7 エンタープライズ・デプロイメントのJDBCコンポーネント・スキーマ情報の指定

- 20.7.2.8 GridLink Oracle RACデータベース接続の詳細情報の指定

- 20.7.2.9 JDBC接続のテスト

- 20.7.2.10 ドメインのキーストアの指定

- 20.7.2.11 エンタープライズ・デプロイメントの拡張構成の選択

- 20.7.2.12 エンタープライズ・デプロイメントでの管理サーバーのリスニング・アドレスの構成

- 20.7.2.13 ノード・マネージャ・タイプ(ホストごと)の構成

- 20.7.2.14 エンタープライズ・デプロイメントでのManaged File Transferの管理対象サーバーの構成

- 20.7.2.15 エンタープライズ・デプロイメントでのManaged File Transferクラスタの構成

- 20.7.2.16 クラスタへのManaged File Transferサーバーの割当て

- 20.7.2.17 エンタープライズ・デプロイメントでのCoherenceクラスタの構成

- 20.7.2.18 Managed File Transfer用のマシンの作成

- 20.7.2.19 エンタープライズ・デプロイメントでのマシンへのサーバーの割当て

- 20.7.2.20 エンタープライズ・デプロイメントでのJMSファイル・ストアの構成

- 20.7.2.21 構成の指定内容の確認とドメインの構成

- 20.7.2.22 ドメイン・ホームと管理サーバーURLの記録

- 20.8 Managed File Transferドメイン用のノード・マネージャの構成

- 20.9 ドメイン・ディレクトリの構成とMFTHOST1上のサーバーの起動

- 20.9.1 ノード・マネージャを使用した管理サーバーの起動

- 20.9.2 管理サーバーの検証

- 20.9.3 Derbyデータベースの無効化

- 20.9.4 MFTHOST1での管理対象サーバーの個別ドメイン・ディレクトリの作成

- 20.9.5 MFTHOST1でのWLS_MFT1管理対象サーバーの起動と検証

- 20.10 ドメインの伝播とMFTHOST2上のサーバーの起動

- 20.10.1 MFTHOST2でのドメイン構成の解凍

- 20.10.2 MFTHOST2でのノード・マネージャの起動

- 20.10.3 MFTHOST2でのWLS_MFT2管理対象サーバーの起動と検証

- 20.11 uploadおよびstageディレクトリの絶対パスへの変更

- 20.12 Managed File TransferのSSH-FTPサービスの構成および有効化

- 20.12.1 SFTPポートの構成

- 20.12.2 必要なSSHキーの生成

- 20.12.3 Managed File Transferの追加のSFTP構成手順

- 20.13 Managed File Transfer用のOracle Traffic Directorの構成

- 20.14 新しいLDAPオーセンティケータの作成とManaged File Transferのユーザーのプロビジョニング

- 20.15 Managed File Transferに対する自動サービス移行およびJDBC永続ストアの有効化

第IV部 エンタープライズ・デプロイメントの共通の構成および管理手順

21 エンタープライズ・デプロイメントの共通の構成および管理タスク

- 21.1 すべてのエンタープライズ・デプロイメントの構成および管理タスク

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

- 21.1.1.1 ホストごとのノード・マネージャを使用している場合の管理サーバーのフェイルオーバー

- 21.1.1.2 Oracle HTTP Serverを介したSOAHOST2上の管理サーバーへのアクセスの検証

- 21.1.1.3 ホストごとのノード・マネージャを使用する場合の管理サーバーのSOAHOST1へのフェイルバック

- 21.1.2 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

- 21.1.2.1 中間層とロード・バランサ間のSSL通信が必要になるとき

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

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

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

- 21.1.2.5 トラスト・ストアへのロード・バランサ証明書のインポート

- 21.1.2.6 Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加

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

- 21.1.2.8 SSLエンドポイントを使用したコンポジットのテスト

- 21.1.3 エンタープライズ・デプロイメントの管理用のロールの構成

- 21.1.3.1 特定の管理ロールを持つ製品のサマリー

- 21.1.3.2 特定の管理グループを持つOracle SOA Suite製品のサマリー

- 21.1.3.3 エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加

- 21.1.3.4 製品固有の管理グループへのエンタープライズ・デプロイメントの管理ユーザーの追加

- 21.1.4 エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用

- 21.1.4.1 TLOGおよびJMSのJDBC永続ストアについて

- 21.1.4.2 JMS永続ストアとTLOGを使用する製品およびコンポーネント

- 21.1.4.3 TLOGおよびJMS永続ストアのパフォーマンスへの影響

- 21.1.4.4 TLOGに対するJDBC永続ストアの構成のロードマップ

- 21.1.4.5 JMSに対するJDBC永続ストアの構成のロードマップ

- 21.1.4.6 TLOG用のユーザーおよび表領域の作成

- 21.1.4.7 JMS用のユーザーおよび表領域の作成

- 21.1.4.8 TLOGおよびJMSストアのGridLinkデータ・ソースの作成

- 21.1.4.9 管理対象サーバーへのTLOG JDBCストアの割当て

- 21.1.4.10 JDBC JMSストアの作成

- 21.1.4.11 JMSサーバーへのJMS JDBCストアの割当て

- 21.1.4.12 JMS JDBCストアに必要な表の作成

- 21.1.5 エンタープライズ・デプロイメントのバックアップとリカバリの実行

- 21.2 Oracle SOA Suiteエンタープライズ・デプロイメントの構成および管理タスク

- 21.2.1 エンタープライズ・デプロイメントへのOracle SOA Suiteコンポジット・アプリケーションのデプロイ

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

- 21.2.3 Oracle SOA Suiteエンタープライズ・デプロイメントでのデータベース増分の管理

22 エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用

- 22.1 エンタープライズ・デプロイメントでのサーバー全体の移行と自動サービス移行について

- 22.1.1 サーバー全体の移行とサービスの移行の違いの理解

- 22.1.2 エンタープライズ・デプロイメントでサーバー全体の移行またはサービスの移行を使用する意味

- 22.1.3 サーバー全体の移行とサービスの移行が必要となる製品およびコンポーネントの理解

- 22.2 リース用のGridLinkデータ・ソースの作成

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

- 22.3.1 ノード・マネージャのプロパティ・ファイルを編集してサーバー全体の移行を有効化

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

- 22.3.2.1 wlsifconfig.shスクリプトのPATH環境変数の設定

- 22.3.2.2 wlsifconfig.shスクリプトに対する権限の付与

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

- 22.3.4 サーバー全体の移行のテスト

- 22.4 エンタープライズ・デプロイメントでの自動サービス移行の構成

- 22.4.1 エンタープライズ・デプロイメント・クラスタに対するリース・メカニズムおよびデータ・ソースの設定

- 22.4.2 クラスタ内の管理対象サーバーの移行設定の変更

- 22.4.3 サービス移行ポリシーの選択について

- 22.4.4 クラスタ内の各管理対象サーバーに対するサービス移行ポリシーの設定

- 22.4.5 管理対象サーバーの再起動および自動サービス移行の検証

- 22.4.6 自動サービス移行後のサービスのフェイルバック

23 エンタープライズ・デプロイメントに対するシングル・サインオンの構成

- 23.1 Oracle HTTP Server Webゲートについて

- 23.2 Oracle HTTP Server Webゲートの構成の一般的な前提条件

- 23.3 OHS 12c Webゲートを構成するためのエンタープライズ・デプロイメントの前提条件

- 23.4 エンタープライズ・デプロイメント用にOracle HTTP Server 12c Webゲートを構成

- 23.5 Oracle Access ManagerへのOracle HTTP Server Webゲートの登録

- 23.5.1 RREGインバンドおよびアウトオブバンド・モードについて

- 23.5.2 OAM11gRequest.xmlファイルでの標準プロパティの更新

- 23.5.3 エンタープライズ・デプロイメント用の保護されたリソース、パブリック・リソースおよび除外されたリソースの更新

- 23.5.4 RREGツールの実行

- 23.5.4.1 RREGツールをインバンド・モードで実行

- 23.5.4.2 RREGツールをアウトオブバンド・モードで実行

- 23.5.5 RREGによって生成されるファイルおよびアーティファクト

- 23.5.6 生成されたアーティファクトのOracle HTTP Server Webゲート・インスタンスの場所へのコピー

- 23.5.7 Oracle HTTP Serverインスタンスの再起動

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

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

- 23.6.2 Oracle Access Manager IDアサーション・プロバイダの設定

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

- 23.7 Oracle Access ManagerでのOracle ADFおよびOPSSセキュリティの構成

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

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

- A.2 エンタープライズ・デプロイメントでマルチ・データ・ソースを構成するための標準的な手順

はじめに

このガイドでは、可用性の高いOracle Fusion Middlewareエンタープライズ・デプロイメントのインストール、構成および管理方法について説明します。詳細は、「エンタープライズ・デプロイメント・ガイドについて」を参照してください。

- 対象読者

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

- 表記規則

対象読者

一般に、このドキュメントは、本番デプロイメント用にOracle Fusion Middlewareソフトウェアをインストールして構成するタスクを割り当てられている、Oracle Fusion Middlewareの管理者を対象としています。

データベース管理者(DBA)やネットワーク管理者など、より専門的な管理者に特定のタスクを割り当てることも可能です(該当する場合)。

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

Oracleのアクセシビリティへの取り組みについては、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)にアクセスしてください。

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を参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

表記規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

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

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

注意:

このガイドでは、Oracle Linuxシステムにおけるエンタープライズ・デプロイメント参照用トポロジの実装を中心に取り上げています。

このトポロジは、動作保証済でサポートされている任意のオペレーティング・システムで実装可能ですが、このガイドの例には、多くの場合、Oracle Linux上でbashシェルを使用して実行する必要があるコマンドと構成手順が示されています。

第I部 エンタープライズ・デプロイメントの理解

ここでは、次の内容について説明します。

- エンタープライズ・デプロイメントの概要
この章ではOracle Fusion Middlewareエンタープライズ・デプロイメントの概念を説明します。

- 標準的なエンタープライズ・デプロイメントの理解
この章では、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントの全般的な特徴について説明します。ここで説明する概念は、どの製品固有のエンタープライズ・デプロイメントにも適用できます。

- Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジの理解
ここでは、Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジについて概説します。これらのトポロジは、「標準的なエンタープライズ・デプロイメントの理解」で説明した概念の具体的な参照用実装です。

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

この章ではOracle Fusion Middlewareエンタープライズ・デプロイメントの概念を説明します。

どのような場合にエンタープライズ・デプロイメント・ガイドを使用するかも示します。

- エンタープライズ・デプロイメント・ガイドについて
エンタープライズ・デプロイメント・ガイドは、選択したOracle Fusion Middleware製品のセキュアかつ高可用性の本番品質デプロイメントをインストール、構成および保守するための包括的でスケーラブルな例を提供します。この結果として作成される環境をエンタープライズ・デプロイメント・トポロジと呼びます。

- エンタープライズ・デプロイメント・ガイドを使用するケース
このガイドでは、Oracle Fusion Middlewareの主な3つのインストールおよび構成オプションのうち1つについて説明します。このガイドを使用すると、選択したOracle Fusion Middleware製品のマルチホスト型でセキュアかつ高可用性の本番トポロジを計画、準備、インストールおよび構成できます。

親トピック: エンタープライズ・デプロイメントの理解

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

エンタープライズ・デプロイメント・ガイドは、選択したOracle Fusion Middleware製品のセキュアかつ高可用性の本番品質デプロイメントをインストール、構成および保守するための包括的でスケーラブルな例を提供します。この結果として作成される環境をエンタープライズ・デプロイメント・トポロジと呼びます。

エンタープライズ・デプロイメント・トポロジは、類似のOracle Fusion Middleware環境を各組織に実装するときに使用できる主な概念やベスト・プラクティスを、例を通じて紹介します。

各エンタープライズ・デプロイメント・ガイドには、参照用トポロジを実装するための詳細な検証済手順が記載されています。また、Oracle Fusion Middlewareエンタープライズ・デプロイメントの概念、参考資料および追加オプションについて説明しているサポート・ドキュメントへのリンクも用意されています。

エンタープライズ・デプロイメント・ガイドに記述されているエンタープライズ・デプロイメント・トポロジは、Oracleをご使用のすべてのお客様の要件を完全に満たすものではありません。場合によっては、トポロジのバリエーションがオラクル社によって文書化されサポートされているどうかに応じて、このガイドで説明されている以外の代替手順も検討できます。

エンタープライズ・デプロイメント・ガイドをデプロイメントの第1選択肢として使用することをお薦めします。バリエーションが必要な場合は、関連するOracleドキュメントを確認するか、Oracleサポートと共同でそれらのバリエーションを検証する必要があります。

1.2 エンタープライズ・デプロイメント・ガイドを使用するケース

このガイドでは、Oracle Fusion Middlewareの主な3つのインストールおよび構成オプションのうち1つについて説明します。このガイドを使用すると、選択したOracle Fusion Middleware製品のマルチホスト型でセキュアかつ高可用性の本番トポロジを計画、準備、インストールおよび構成できます。

または次の方法を使用できます。

- 『SOA SuiteおよびBusiness Process Management SuiteのQuick Start for Developersのインストール』の説明に従って開発環境をインストールする。
開発環境は、Java、Oracle Application Development Framework、およびOracleテクノロジに依存する他のアプリケーションの開発に使用できるソフトウェアとツールを提供します。通常、開発環境は単一のホストにインストールされ、本番環境が持つ機能の多くを必要としません。

- 『Oracle Fusion Middlewareのインストールのプランニング』を確認する。このドキュメントには、すべてのOracle Fusion Middlewareインストールの準備に役立つ追加情報が記載されています。

2 標準的なエンタープライズ・デプロイメントの理解

この章では、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントの全般的な特徴について説明します。ここで説明する概念は、どの製品固有のエンタープライズ・デプロイメントにも適用できます。

この章では、エンタープライズ・デプロイメント・トポロジのダイアグラムについて説明します。

- 標準的なエンタープライズ・デプロイメントのダイアグラム
この項では、Web層、アプリケーション層およびデータ層を含む標準的なエンタープライズ・デプロイメントを示します。

- 標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムの理解
この項では、標準的なエンタープライズ・トポロジ・ダイアグラムについて詳しく説明します。

親トピック: エンタープライズ・デプロイメントの理解

2.1 標準的なエンタープライズ・デプロイメントのダイアグラム

この項では、Web層、アプリケーション層およびデータ層を含む標準的なエンタープライズ・デプロイメントを示します。

すべてのOracle Fusion Middlewareエンタープライズ・デプロイメントは、Oracle Fusion Middleware本番環境のインストールと構成に関するベスト・プラクティスを示すように設計されています。

ベスト・プラクティス・アプローチは、複数層デプロイメントと、異なるソフトウェア層間の標準的通信の基本概念で始まります。

図2-1に、Web層、アプリケーション層およびデータ層を含む標準的なエンタープライズ・デプロイメントを示します。すべてのエンタープライズ・デプロイメントは、これらの基本原則に基づいています。

標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントで通信に使用される各層と標準プロトコルの説明は、「標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムの理解」を参照してください。

図2-1 標準的なエンタープライズ・デプロイメント・トポロジのダイアグラム

2.2 標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムの理解

この項では、標準的なエンタープライズ・トポロジ・ダイアグラムについて詳しく説明します。

- 標準的なエンタープライズ・デプロイメントのファイアウォールとゾーンの理解

- 標準的なエンタープライズ・デプロイメント・トポロジの各要素の理解

- ハードウェア・ロード・バランサを介したリクエストの受信

- Web層の理解

- アプリケーション層の理解

- データ層について

2.2.1 標準的なエンタープライズ・デプロイメントのファイアウォールとゾーンの理解

トポロジは、ファイアウォールによって隔てられている、次のようないくつかのセキュリティ・ゾーンに分かれています。

- Web層(またはDMZ)。これは、ハードウェア・ロード・バランサおよびユーザーから初期リクエストを受信するWebサーバーに使用されます(この場合、Oracle HTTP Serverインスタンス)。このゾーンには、ロード・バランサ上で定義されている単一の仮想サーバー名を介してのみアクセスできます。

- アプリケーション層。これはビジネスおよびアプリケーション・ロジックが配置されている場所です。

- データ層。これには、インターネットからアクセスできず、このトポロジ内で可用性の高いデータベース・インスタンス用に予約されています。

ファイアウォールは、特定の通信ポートを介した場合にのみデータ転送が許可されるように構成されています。これらのポート(または、場合によってはファイアウォール内の開いているポートを必要とするプロトコル)は、ダイアグラム内の各ファイアウォール・ライン上に示しています。

例:

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

- アプリケーション層を保護するファイアウォール上では、HTTPポートとMBeanプロキシ・ポートが開いています。
外部HTTPアクセスが必要なアプリケーションは、プロキシとしてOracle HTTP Serverインスタンスを使用できます。このポートはアウトバウンド通信専用であり、Oracle HTTP Serverのプロキシ機能を有効にする必要があります。

- データ層を保護しているファイアウォールでは、データベース・リスナー・ポート(通常は1521)が開かれている必要があります。
また、認可プロバイダとLDAPベースのアイデンティティ・ストア間の通信用に、LDAPポート(通常は389と636)も開いている必要があります。

アプリケーション層がOracle RACデータベース・ワークロードとイベントに関する通知を受信できるように、ONSポート(通常は6200)も必要です。これらのイベントは、Oracle RACデータベース・インスタンスの可用性とワークロードに応じて、Oracle WebLogic Server接続プールが迅速に調整(接続の作成または破棄)するために使用されます。

特定のOracle Fusion Middlewareエンタープライズ・デプロイメント・トポロジにおいて開いておく必要があるポートの全リストは、実装するトポロジについて説明している章を参照するか、実装するトポロジのエンタープライズ・デプロイメント・ワークブックを参照してください。詳細は、「エンタープライズ・デプロイメント・ワークブックの使用」を参照してください。

2.2.2 標準的なエンタープライズ・デプロイメント・トポロジの各要素の理解

エンタープライズ・デプロイメント・トポロジは、大まかに次の要素で構成されます。

- ハードウェア・ロード・バランサ。インターネットからのリクエストをWeb層内のWebサーバーにルーティングします。また、社内ネットワーク内で内部呼出しを実行する内部クライアントや他のコンポーネントからのリクエストもルーティングします。

- Web層。ハードウェア・ロード・バランサとWebサーバー・インスタンスをホストする2つ以上の物理コンピュータで構成されています(高可用性のため)。
Webサーバー・インスタンスは、ユーザーを認証し(外部アイデンティティ・ストアおよびシングル・サインオン・サーバーを使用)、HTTPリクエストを、アプリケーション層内で実行されているOracle Fusion Middleware製品とコンポーネントにルーティングするように構成されています。

また、Webサーバー・インスタンスは、アプリケーション・ロジックの提供を必要としない静的Webコンテンツをホストします。このようなコンテンツをWeb層に配置することで、アプリケーション・サーバーのオーバーヘッドが低減され、不要なネットワーク・アクティビティが排除されます。

- アプリケーション層。Oracle WebLogic Server管理対象サーバーのクラスタとドメイン用の管理サーバーをホストする2つ以上の物理コンピュータで構成されています。管理対象サーバーは、エンタープライズ・デプロイメントでの製品の選択に応じて、Oracle SOA Suite、Oracle Service Bus、Oracle WebCenter Content、Oracle WebCenter Portalなどの様々なOracle Fusion Middleware製品を実行するように構成されています。

- データ層。Oracle RACデータベースをホストする2つ以上の物理ホストで構成されています。

2.2.3 ハードウェア・ロード・バランサを介したリクエストの受信

次の各項で、エンタープライズ・デプロイメントでのハードウェア・ロード・バランサとそのロールについて説明します。

- ハードウェア・ロード・バランサ(LBR)の目的

- 標準的なロード・バランサの仮想サーバー名のサマリー

- 外部仮想サーバー名に対するHTTPSリクエストとHTTPリクエストの対比

2.2.3.1 ハードウェア・ロード・バランサ(LBR)の目的

次の項では、エンタープライズ・デプロイメントでハードウェア・ロード・バランサによって処理されるリクエストのタイプについて説明します。

- インターネットからWeb層内のWebサーバー・インスタンスへのHTTPリクエスト

- Oracle SOA Suite for Healthcare IntegrationのMLLPリクエスト

- Oracle MFT IntegrationのSFTPリクエスト

- アプリケーション層のコンポーネント間特有の内部専用通信

2.2.3.1.1 インターネットからWeb層内のWebサーバー・インスタンスへのHTTPリクエスト

ハードウェア・ロード・バランサは、1つの仮想ホスト名へのリクエストを受信して各リクエストをロード・バランシング・アルゴリズムに基づいてWebサーバー・インスタンスの1つにルーティングすることで、Web層でのロードをバランシングします。このようにして、ロード・バランサは、特定のWebサーバーがHTTPリクエストによってオーバーロードにならないようにします。

ハードウェア・ロード・バランサの特定の仮想ホスト名の用途の詳細は、「標準的なロード・バランサの仮想サーバー名のサマリー」を参照してください。

参照用トポロジでは、HTTPリクエストのみがハードウェア・ロード・バランサからWeb層にルーティングされることに注意してください。Secure Socket Layer (SSL)リクエストはロード・バランサで終了され、HTTPリクエストのみがOracle HTTP Serverインスタンスに転送されます。このガイドでは、ロード・バランサとOracle HTTP Serverインスタンス間およびWeb層とアプリケーション層間のSSL構成について説明していません。

ロード・バランサは、Webサーバーの1つが停止した場合に残りの稼働中のWebサーバーにリクエストがルーティングされるようにすることで、高可用性を実現します。

また、標準的な高可用性構成では、メインのロード・バランシング装置で障害が発生した場合にホット・スタンバイ・デバイスがすぐにサービスを再開できるように、複数のハードウェア・ロード・バランサが構成されます。多種のサービスおよびシステムにとってハードウェア・ロード・バランサは呼出しを行う唯一のアクセス・ポイントとなり、保護されていない場合にはシステム全体の単一障害点(SPOF)となるため、このことは重要です。

2.2.3.1.2 Oracle SOA Suite for Healthcare IntegrationのMLLPリクエスト

Oracle SOA Suite for healthcare integrationを構成する予定がある場合、ハードウェア・ロード・バランサはMinimum Lower Layer Protocol (MLLP)プロトコルを介してリクエストを渡す必要があります。MLLPは、Health Level 7 (HL7)標準を使用してヘルスケア・ドキュメントをやり取りする場合に必要になります。

詳細は、Oracle SOA Suite Healthcare Integrationユーザーズ・ガイドのHL7ドキュメント・プロトコルの使用に関する項を参照してください。

2.2.3.1.3 Oracle MFT IntegrationのSFTPリクエスト

MFTがデプロイされる場合、ロード・バランサは、DMZの異なるOTDインスタンス間でsFTPリクエストをロード・バランシングするTCP仮想サーバーも構成する必要があります。sFTPは、各エンタープライズ・デプロイメント・ガイドのMFTにファイル転送を提供するために使用されるセキュアなプロトコルです。詳細は、『Oracle Fusion Middleware Oracle Managed File Transferの使用』の埋込みFTPおよびsFTPサーバーに関する項を参照してください。

2.2.3.1.4 アプリケーション層のコンポーネント間特有の内部専用通信

さらに、ハードウェア・ロード・バランサは、Oracle Fusion Middlewareコンポーネントとアプリケーション層のアプリケーション間に特有の通信をルーティングします。内部専用のリクエストも、ロード・バランサを介してルーティングされます(一意の仮想ホスト名を使用する)。

2.2.3.2 標準的なロード・バランサの仮想サーバー名のサマリー

サーバー上のロードのバランシングと高可用性の提供のために、ハードウェア・ロード・バランサは一連の仮想サーバー名を認識するように構成されています。ダイアグラムに示すように、このトポロジではハードウェア・ロード・バランサによって次の仮想サーバー名が認識されます。

- soa.example.com: この仮想サーバー名はすべての受信トラフィックに使用されます。
ユーザーはこのURLを入力して、デプロイしたOracle Fusion Middleware製品およびこのサーバー上で使用可能なカスタム・アプリケーションにアクセスします。その後、ロード・バランサによってそれらのリクエストが(ロード・バランシング・アルゴリズムを使用して)Web層内のサーバーの1つにルーティングされます。このようにすることで、1つの仮想サーバー名を使用してトラフィックを複数のサーバーにルーティングすることが可能になり、Webサーバー・インスタンスのロード・バランシングと高可用性が実現されます。

- soainternal.example.com: この仮想サーバー名は、内部通信専用です。
ロード・バランサは、そのネットワーク・アドレス変換(NAT)機能を使用して、アプリケーション層コンポーネントからこのURLへのすべての内部通信をルーティングします。このURLは、インターネット上の外部顧客またはユーザーには公開されていません。各製品の内部URLの使用目的はそれぞれ固有であるため、デプロイメント手順では、先頭に製品名を付けています。

- admin.example.com: この仮想サーバー名は、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle WebLogic Server管理コンソール・インタフェースにアクセスする必要がある管理者用です。
このURLは、内部管理者のみが知っています。また、ロード・バランサのNAT機能を使用することで、管理者はドメイン内のアクティブな管理サーバーにルーティングされます。

自身のトポロジに対して定義する必要がある仮想サーバー名の完全なセットについては、製品固有のトポロジが記載されている章を参照してください。

2.2.3.3 外部仮想サーバー名に対するHTTPSリクエストとHTTPリクエストの対比

ハードウェア・ロード・バランサを構成する場合は、メインの外部URL (たとえば、http://myapplication.example.com)をポート80およびポート443に割り当てることをお薦めします。

ポート80 (非SSLプロトコル)に対するリクエストはすべて、ポート443 (SSLプロトコル)にリダイレクトする必要があります。このルールの例外としては、パブリックWSDLからのリクエストがあります。詳細は、「ハードウェア・ロード・バランサでの仮想ホストの構成」を参照してください。

2.2.4 Web層の理解

参照用トポロジのWeb層は、ロード・バランサからリクエストを受信するWebサーバーで構成されています。標準的なエンタープライズ・デプロイメントでは、Web層に2つ以上のOracle HTTP Serverインスタンスまたは2つ以上のOracle Traffic Directorインスタンスが構成されています。次の各項で、詳細を説明します。

- リクエストのルーティングにWeb層を使用する利点

- Web層の使用にかわる方法

- Web層でのOracle HTTP Serverの構成

- Mod_WL_OHSについて

2.2.4.1 リクエストのルーティングにWeb層を使用する利点

Oracle HTTP ServerまたはOracle Traffic Directorを含むWeb層の使用は、多くのOracle Fusion Middleware製品の必要条件ではありません。アプリケーション層でハードウェア・ロード・バランサからWLSサーバーへ直接トラフィックをルーティングできます。ただし、Web層にはいくつかの利点があり、それが、参照用トポロジの一部としてお薦めする理由です。

- Web層はDMZパブリック・ゾーンを提供します。これはセキュリティ監査における一般的な必要条件です。ロード・バランサがWebLogic Serverに直接ルーティングを行うと、リクエストがロード・バランサからアプリケーション層に1回のHTTPジャンプで移動するため、セキュリティ上の問題を引き起こす可能性があります。

- Web層では、Webサーバー構成を変更することなく、WebLogic Serverクラスタ・メンバーシップを再構成(新規サーバーの追加とサーバーの削除)できます(構成したリスト内のサーバーのいくつかがアライブであることが条件)。

- Oracle HTTP ServerはWebLogic Serverより効率的かつ高速に静的コンテンツを提供します。また、一部のエンタープライズ・デプロイメントに必要なFTPサービス、およびOracle HTTP Server構成ファイルによる仮想ホストおよびプロキシの作成機能も提供します。

- Web層は、WebLogic Serverが提供する機能に加えてHTTPリダイレクションを提供します。Oracle HTTP Serverを多様なWebLogic Serverクラスタのフロント・エンドとして使用でき、場合によっては、コンテンツ・ベースのルーティングを実行してルーティングを制御できます。

- Oracle HTTP Serverは、エンタープライズ・デプロイメントにシングル・サインオン機能を統合する機能を提供します。たとえば、Oracle Identity and Access Management製品ファミリの一部であるOracle Access Managerを使用して、後からシングル・サインオンをエンタープライズ・デプロイメントに実装できます。

- Oracle HTTP Serverは、WebLogic Server内にデプロイされているWebSocket接続のサポートを提供します。

Oracle HTTP Serverの詳細は、『Oracle HTTP Server管理者ガイド』のOracle HTTP Serverの概要に関する項を参照してください。

Oracle Traffic Directorの詳細は、『Oracle Traffic Director管理者ガイド』のOracle Traffic Directorのスタート・ガイドに関する項を参照してください。

2.2.4.2 Web層の使用にかわる方法

Web層はエンタープライズ・トポロジに様々な利点をもたらしますが、中間層でハードウェア・ロード・バランサから管理対象サーバーへリクエストを直接ルーティングする方法もサポートされています。

この方法には、次の利点があります。

- フロントエンドOracle HTTP ServerのWeb層フロントエンドを使用するよりも構成と処理のオーバーヘッドが小さい。

- 管理対象サーバーごとに固有のURLを監視するようにLBRを構成できるので、アプリケーション・レベルでの監視が可能(Oracle HTTP Serverでは不可能)。
このロード・バランサ機能を使用して、SOAコンポジット・アプリケーションのURLを監視することもできます。この場合、すべてのコンポジットがデプロイされたときにのみ管理対象サーバーへのルーティングが可能になります。また、適切な監視ソフトウェアを使用する必要があります。

2.2.4.3 Web層でのOracle HTTP Serverの構成

Oracle Fusion Middleware 12c以降、Oracle HTTP Serverソフトウェアは、既存のOracle WebLogic Serverドメインの一部としてまたは独自のスタンドアロン・ドメインで、の2つの方法のいずれかで構成できるようになりました。各構成には固有の利点があります。

Oracle HTTP Serverインスタンスを既存のWebLogic Serverドメインの一部として構成する場合、Oracle Enterprise Manager Fusion Middleware Controlを使用して、WebサーバーとOracle WebLogic Server管理対象サーバー間の通信のワイヤリングなど、Oracle HTTP Serverインスタンスの管理を行うことができます。Oracle HTTP Serverをスタンドアロン構成で構成する場合、Oracle HTTP Serverインスタンスをアプリケーション層ドメインとは別個に構成および管理できます。

このエンタープライズ・デプロイメント・ガイドでは、Oracle HTTP ServerインスタンスはWeb層ホストごとに1つずつ、別個のスタンドアロン・ドメインとして構成されます。Oracle HTTP Serverインスタンスをアプリケーション層ドメインの一部として構成することはできますが、このエンタープライズ・デプロイメント・ガイドには、この方法でOracle HTTP Serverインスタンスを構成する手順は示されていません。

詳細は、Oracle HTTP Serverのインストールと構成のOracle HTTP Serverインストール・オプションの理解に関する項参照してください。

2.2.4.4 Mod_WL_OHSについて

ダイアグラムに示すように、Oracle HTTP Serverインスタンスは、Oracle HTTP Serverからアプリケーション層のOracle WebLogic Server管理対象サーバーへのHTTPリクエストのプロキシに、WebLogicプロキシ・プラグイン(mod_wl_ohs)を使用します。

詳細は、Oracle WebLogic Serverプロキシ・プラグイン12.1.3の使用のWeb Serverプロキシ・プラグイン12.1.3の概要に関する項を参照してください。

2.2.5 アプリケーション層の理解

アプリケーション層は2つの物理ホスト・コンピュータで構成されており、そこにOracle WebLogic ServerおよびOracle Fusion Middleware製品がインストールされて構成されます。アプリケーション層のコンピュータは、ファイアウォール1とファイアウォール2の間のセキュリティ保護されたゾーンに配置されます。

詳細は、次の各項を参照してください。

- 管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成

- アプリケーション層でのOracle Web Services Managerの使用

- アプリケーション層におけるクラスタとホストの構成のベスト・プラクティスとバリエーション

- 標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について

- アプリケーション層内での通信のためのユニキャストの使用について

- OPSSおよび認証ストアと認可ストアへのリクエストの理解

- 標準的なエンタープライズ・デプロイメントでのCoherenceクラスタについて

2.2.5.1 管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成

ドメイン内の管理対象サーバーとは異なり、管理サーバーはアクティブ/パッシブ高可用性構成を使用します。これは、Oracle WebLogic Serverドメイン内で実行できる管理サーバーは1つのみであるためです。

トポロジ・ダイアグラムでは、HOST1上の管理サーバーがアクティブな状態で、HOST2上の管理サーバーがパッシブ(非アクティブ)の状態です。

システム障害時に管理サーバーの手動フェイル・オーバーをサポートする標準的なエンタープライズ・デプロイメント・トポロジには、次のものが含まれます。

- 管理サーバーのリクエストのルーティング用の仮想IPアドレス(VIP)

- 共有記憶域デバイス上の管理サーバー・ドメイン・ディレクトリの構成

システム障害(HOST1の障害など)が発生した場合、管理サーバーのVIPアドレスをドメイン内の別のホストに手動で再割当てし、管理サーバーのドメイン・ディレクトリをその新しいホストにマウントして、新しいホスト上で管理サーバーを起動できます。

ただし、管理サーバーと違い、管理対象サーバーを共有記憶域に格納するメリットはありません。実際に、管理対象サーバーの構成データをホスト・コンピュータのローカル・ディスクに格納しないと、パフォーマンスに影響するおそれがあります。

したがって、標準的なエンタープライズ・デプロイメントでは、管理サーバーのドメインを共有記憶域上で構成すると、ドメイン構成のコピーが各ホスト・コンピュータのローカル記憶域デバイスに配置され、このドメイン構成のコピーから管理対象サーバーが起動されます。このコピーの作成には、Oracle WebLogic Serverのpackおよびunpackユーティリティを使用します。

結果として、各ホストに別個のドメイン・ディレクトリを配置する構成となります。つまり、管理サーバー(共有記憶域上)と管理対象サーバー(ローカル記憶域上)に1つずつ配置します。必要なアクションに応じて、いずれかのドメイン・ディレクトリから構成タスクを実行する必要があります。

管理サーバーのドメイン・ディレクトリと管理対象サーバーのドメイン・ディレクトリの構造、およびこれらのディレクトリの参照に使用する変数の詳細は、「エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解」を参照してください。

複数ドメイン・ディレクトリ・モデルには、他にも利点があります。管理サーバーを管理対象サーバーから分離できます。デフォルトのプライマリ・エンタープライズ・デプロイメント・トポロジでは、アプリケーション層のホストの1つに管理サーバーのドメイン・ディレクトリが存在することを想定していますが、管理サーバーによるCPUまたはRAMの消費量が多いときなど、必要な場合に管理サーバーを独自のホストから実行することで、管理サーバーをさらに分離できます。管理者によっては、管理サーバーを別個の専用ホストに構成することを好みますが、複数ドメイン・ディレクトリ・モデルではそれを実現できます。

2.2.5.2 アプリケーション層でのOracle Web Services Managerの使用

Oracle Web Services Manager (Oracle WSM)は、エンタープライズ・デプロイメント・トポロジにおけるWebサービスの管理と保護を目的としたポリシー・フレームワークを提供します。

ほとんどのエンタープライズ・デプロイメント・トポロジでは、Oracle Web Services Manager Policy Managerは、アクティブ/アクティブの高可用性構成でデプロイできる、別のクラスタ内の管理対象サーバー上で実行されます。

影響を理解していれば、Oracle Web Services ManagerおよびFusion Middleware製品またはアプリケーションを同じクラスタにターゲット設定できます。

Oracle Web Services Managerを専用の管理対象サーバーにデプロイする主な理由は、パフォーマンスと可用性の分離性を高めるためです。Oracle Web Services Managerは、多くの場合、カスタムWebサービスまたはドメイン内の他の製品やコンポーネントにポリシーを提供します。この場合、Oracle Web Services Managerの追加アクティビティがOracle Web Services Managerと同じ管理対象サーバーまたはクラスタを共有するアプリケーションのパフォーマンスに影響を及ぼすことは望ましくありません。

スケール・アウトやスケール・アップのプロセスが発生した場合でも、コンポーネント同士が分離されていれば、より適切な対応が可能です。他の製品に影響を及ぼすことなく、製品がデプロイされているFusion Middlewareアプリケーション管理対象サーバーのみ、またはOracle Web Services Managerがデプロイされている管理対象サーバーのみをスケール・アウトしたりスケール・アップしたりできます。

2.2.5.3 アプリケーション層におけるクラスタとホストの構成のベスト・プラクティスとバリエーション

標準的なエンタープライズ・デプロイメントでは、アプリケーション層内の2つ以上のホスト上にあるクラスタで管理対象サーバーを構成します。特定のOracle Fusion Middleware製品について、エンタープライズ・デプロイメント参照トポロジは、管理対象サーバー数、クラスタ数および各クラスタをターゲットとするサービスに関するベスト・プラクティスを示しています。

これらのベスト・プラクティスは、各製品の標準的なパフォーマンス、メンテナンスおよびスケールアウトの各要件を考慮したものです。その結果、管理対象サーバーは、ドメイン内の適切なクラスタ・セットにグループ化されます。

エンタープライズ・デプロイメント・トポロジのバリエーションとして、特定の製品またはコンポーネントを追加のクラスタまたはホストにターゲット設定できます。これにより、パフォーマンスと独立性が向上します。

たとえば、管理サーバーを別個の小規模なホスト・コンピュータでホストして、FMWコンポーネントおよび製品を管理サーバーから隔離することを検討できます。

別の例として、Oracle SOA Suiteデプロイメントで、Oracle SOA SuiteとOracle Service Busを別々のホストにデプロイできます。同様に、Oracle Business Activity MonitoringとOracle Enterprise Schedulerを別のホスト・コンピュータ上にある別のクラスタにターゲット設定できます。

トポロジのこれらのバリエーションはサポートされていますが、エンタープライズ・デプロイメント参照トポロジでは、高可用性、スケーラビリティおよびセキュリティに留意しながら最小のハードウェア・リソースを使用します。各種サーバーのシステム要件と、システムが対応する必要のある負荷に応じて、適切なリソース・プランニングおよびサイジングを実施してください。これらの決定に基づいて、これらのバリエーションをインストールおよび構成する手順を、このガイドに記載の説明から適切に変更する必要があります。

2.2.5.4 標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について

Oracle Fusion Middleware 12c以降、ドメインごとのノード・マネージャまたはホストごとのノード・マネージャを使用できます。次の各項では、標準的なエンタープライズ・デプロイメントでのノード・マネージャ構成の影響について詳しく説明します。

注意:

これらの2つのタイプのノード・マネージャについての一般情報は、『Oracle WebLogic Serverノード・マネージャの管理』の概要に関する項を参照してください。

ドメインごとのノード・マネージャ構成の使用について

ドメインごとのノード・マネージャ構成では、ホストごとのノード・マネージャ構成とは異なり、管理サーバー・ホスト上で実際に2つのノード・マネージャ・インスタンスを起動します。1つは管理サーバーのドメイン・ディレクトリから、もう1つは管理対象サーバーのドメイン・ディレクトリから起動します。さらに、トポロジ内の他のホストで、別個のノード・マネージャ・インスタンスが実行されます。

管理サーバーを制御するノード・マネージャは、管理サーバーに作成された仮想ホスト名のリスニング・アドレスを使用します。管理対象サーバーを制御するノード・マネージャは、物理ホストのリスニング・アドレスを使用します。管理サーバーが別のホストにフェイルオーバーすると、フェイルオーバー・ホスト上の管理サーバーを制御するために、ノード・マネージャの追加のインスタンスが起動されます。

ドメインごと構成の主な利点は、ノード・マネージャの初期設定が容易かつ簡易であることと、管理サーバーに固有のノード・マネージャ・プロパティを設定できることです。後者は、前のリリースでは重要でした。クラッシュ・リカバリなど一部の機能が、管理サーバーにのみ適用され、管理対象サーバーには適用されていなかったためです。現在のリリースでは、Oracle SOA Suite製品に対して、サーバー全体の移行ではなく自動サービス移行を構成できます。これは、管理サーバーだけでなく管理対象サーバーもクラッシュ・リカバリを利用できるため、管理サーバー・ドメイン・ディレクトリと管理対象サーバー・ドメイン・ディレクトリに異なるプロパティを適用する必要がないということです。

もう1つの利点は、ドメインごとのノード・マネージャでは、各ドメインに作成されたデモ・アイデンティティ・ストアに基づいて、ノード・マネージャとサーバーとの通信にデフォルトのSSL構成が提供される点です。

ホストごとのドメイン・マネージャ構成の使用について

ホストごとのノード・マネージャ構成では、単一のノード・マネージャ・インスタンスを起動して、管理サーバーおよびホスト上のすべての管理対象サーバー(別のドメインに配置されているものも含む)を制御します。これにより、特に同一マシン上に複数のドメインが共存する場合に、管理サーバー・ホストでのフットプリントおよびリソース使用率が削減されます。

ホストごとのノード・マネージャ構成では、すべてのノード・マネージャが任意のリスニング・アドレスを使用できるため、ノード・マネージャはホスト上で使用可能なすべてのアドレスでリスニングします。これは、管理サーバーが新しいホストにフェイルオーバーする際に、追加の構成が必要ないことを意味します。ホストごとの構成では、各ホストで複数のノード・マネージャ・プロパティ・ファイルではなく単一のノード・マネージャ・プロパティ・ファイルを更新および保守できるため、保守が簡易化されます。

ホストごとのノード・マネージャ構成では、追加の構成手順が必要になります。ノード・マネージャとサーバーとの通信にSSLが必要な場合は、追加のアイデンティティ・ストアおよびトラスト・ストアを構成する必要があり、またノード・マネージャは複数のアドレスでリスニングするため、Subject Alternate Names (SAN)を使用する必要もあります。なお、2つのファイアウォールで保護されているため、通常はアプリケーション層にSSL通信は必要ありません。

2.2.5.5 アプリケーション層内での通信のためのユニキャストの使用について

エンタープライズ・デプロイメントにおける管理対象サーバーとOracle WebLogic Serverクラスタ内のホストの間の通信にはユニキャスト通信プロトコルをお薦めします。マルチキャスト通信と異なり、ユニキャストではネットワーク間構成は不要です。また、これによって、マルチキャスト・アドレス競合により発生する場合がある潜在的なネットワーク・エラーも減少します。

独自のデプロイメントでマルチキャストかユニキャストのどちらのプロトコルを使用するかを検討するときは、ネットワークの種類、クラスタ内のメンバー数、およびクラスタ・メンバーシップの信頼性要件を考慮してください。また、各プロトコルが持つ次の利点も考慮してください。

エンタープライズ・デプロイメントにおけるユニキャストの利点:

- グループ・リーダーを使用し、このリーダーにすべてのサーバーがメッセージを直接送信します。このリーダーは、他のすべてのグループ・メンバーと他のグループ・リーダー(該当する場合)にメッセージを再送信する役割を担います。

- ほとんどのネットワーク・トポロジでそのまま動作します。

- ネットワーク・トポロジに関係なく、追加の構成は不要です。

- 単一の欠落ハートビートを使用して、サーバーをクラスタ・メンバーシップ・リストから削除します。

エンタープライズ・デプロイメントにおけるマルチキャストの利点:

- マルチキャストは、より拡張性の高いピア・ツー・ピア・モデルを採用します。このモデルでは、サーバーが各メッセージを一度だけネットワークに直接送信し、各クラスタ・メンバーがネットワークからメッセージを直接受信することをネットワークが保証します。

- クラスタ・メンバーが単一のサブネット内にある最近のほとんどの環境でそのまま動作します。

- クラスタ・メンバーが複数のサブネットにまたがっている場合は、ルーターとWebLogic Server (マルチキャストTTL)で追加構成が必要です。

- 連続する3つの欠落ハートビートを使用して、サーバーをクラスタ・メンバーシップ・リストから削除します。

どちらのモデルの方がより適切に動作するかは、クラスタ内のサーバー数と、基礎となるアプリケーションにとってクラスタ・メンバーシップが不可欠かどうか(たとえば、セッション・レプリケーションを大量に行うアプリケーションやクラスタ全体でRMI呼出しが大量に発生するクラスタなど)によって異なります。

使用するトポロジがアクティブ/アクティブ型の障害時リカバリ・システムに参加するかどうか、またクラスタが複数のサブネットを横断するどうかを考慮してください。一般に、これらの場合にはユニキャストの方がより適切に動作します。

詳細は、次のリソースを参照してください。

- 『高可用性ガイド』のWebLogic Serverクラスタのマルチキャスト・メッセージングの構成に関する項

- 『Oracle WebLogic Serverクラスタの管理』のユニキャストを使用した1対多通信に関する項

2.2.5.6 OPSSおよび認証ストアと認可ストアへのリクエストの理解

Oracle Fusion Middleware製品およびコンポーネントの多くでは、認証プロバイダ(アイデンティティ・ストア)、ポリシー、資格証明、キーストアおよび監査データのためにOracle Platform Security Services (OPSS)セキュリティ・ストアが必要です。結果として、アプリケーション層とセキュリティ・プロバイダとの間でリクエストを送受信できるように通信を有効化する必要があります。

認証の場合、この通信は、一般的にポート389または636で通信するOracle Internet Directory (OID)、Oracle Unified Directory (OUD)などのLDAPディレクトリ宛てです。Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダを使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用する必要があります。

認可(およびポリシー・ストア)の場合、層によってセキュリティ・ストアの位置が異なります。

- アプリケーション層では、認可ストアはデータベース・ベースです。したがって、必要なOPSSデータを取得するために、Oracle WebLogic Server管理対象サーバーからデータベースへの頻繁な接続が必要になります。

- Web層では、認可ストアはファイル・ベースです。したがって、データベースへの接続は必要ありません。

OPSSセキュリティ・ストアの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の次の項を参照してください。

- 認証の基本

- OPSSポリシー・モデル

2.2.5.7 標準的なエンタープライズ・デプロイメントでのCoherenceクラスタについて

標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントには、記憶域が有効な管理対象Coherenceサーバーを含むCoherenceクラスタが含まれます。

この構成はCoherenceの使用には適切な出発点ですが、特定の要件によっては、本番環境でのパフォーマンスを向上させるため、またはポートの競合を解決するために、Coherenceをチューニングして再構成することを検討できます。

ポートの割当てを確認する際、Oracle Fusion Middleware製品およびコンポーネントが、構成ウィザードの「Coherenceクラスタ」画面で指定されたポートを使用するウェル・ノウン・アドレス(WKA)リストにデフォルト設定されていることに注意してください。WKAリストでは、coherenceクラスタに参加しているすべてのサーバーのリスニング・アドレスも、WKAリストのリスニング・アドレスとして使用されます。これらの設定は、WLS管理コンソールを使用してカスタマイズできます。

詳細は、次のマニュアルを参照してください。

- Coherenceクラスタの詳細は、『Oracle WebLogic Serverクラスタの管理』のCoherenceクラスタの構成および管理に関する項を参照してください。

- Coherenceのチューニングの詳細は、『Oracle Coherenceの管理』を参照してください。

- CoherenceにおけるHTTPセッション・データの格納の詳細は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』のWebLogicサーバーでのCoherence*Webの使用に関する項を参照してください。

- Coherenceアプリケーションの作成とデプロイの詳細は、『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発 』を参照してください。

2.2.6 データ層について

データ層では、Oracle RACデータベースは2つのホスト(DBHOST1とDBHOST2)上で実行されます。データベースには、Oracle SOA SuiteコンポーネントとOracle Platform Security Services (OPSS)ポリシー・ストアが必要とするスキーマが含まれています。

エンタープライズ・デプロイメントでは製品およびコンポーネントごとに複数のサービスを定義することで、スループットとパフォーマンスの分離および優先順位の決定ができます。このガイドでは、例として1つのデータベース・サービスを使用します。また、データベースを保護する他の高可用性データベース・ソリューションも使用できます。

- Oracle Data Guard: 詳細は、Oracle Data Guard概要および管理を参照してください。

- Oracle RAC One Node: 詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドのOracle RAC One Nodeの概要に関する項を参照してください。

これらのソリューションは、エンタープライズ・デプロイメントに一般に適用されるスケーラビリティと可用性の要件を満たす場合、Oracle RACデータベースの使用に重点を置いたこのガイドに記載されている情報以上のデータベース保護を実現します。

高可用性環境でのOracleデータベースの使用の詳細は、『高可用性ガイド』のデータベースの考慮事項に関する項を参照してください。

3 Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジの理解

次の各項では、Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジについて概説します。これらのトポロジは、「標準的なエンタープライズ・デプロイメントの理解」で説明した概念の具体的な参照用実装です。

- プライマリおよび独自構築のエンタープライズ・デプロイメント・トポロジの理解
この項では、プライマリ・トポロジのインストールおよび構成の手順および環境に必要なコンポーネントの追加に関する情報を示します。

- プライマリOracle SOA Suiteエンタープライズ・トポロジのダイアグラム
この項では、2つのプライマリOracle SOA Suiteエンタープライズ・デプロイメント・トポロジのダイアグラムを示します。

- プライマリOracle SOA Suiteトポロジ・ダイアグラムの理解
この項では、プライマリ・トポロジに特有の要素に関する情報を示します。

- プライマリOracle SOA Suiteエンタープライズ・トポロジの実装のフロー・チャートとロードマップ
この項では、フロー・チャートとロードマップの形式でエンタープライズ・デプロイメント・トポロジのインストールと構成の手順を示します。

- 独自のOracle SOA Suiteエンタープライズ・トポロジの構築
この項では、実装可能ないくつかの代替トポロジについて、このガイドに示した手順に多少の変更を加えて説明します。

- カスタム・エンタープライズ・トポロジのインストールと構成について
このガイドで説明されていないトポロジを実装する場合は、トポロジに含める製品の動作保証情報、システム要件および相互運用性要件を確認してください。

- Oracle SOA Suiteエンタープライズ・トポロジでの自動サービス移行の使用について
Oracle SOA Suite製品およびコンポーネントの高可用性を実現するために、このガイドでは、参照用トポロジの一部として作成するクラスタに対してOracle WebLogic Serverの自動サービス移行を有効にすることをお薦めします。

親トピック: エンタープライズ・デプロイメントの理解

3.1 プライマリおよび独自構築のエンタープライズ・デプロイメント・トポロジの理解

この項では、プライマリ・トポロジのインストールおよび構成の手順および環境に必要なコンポーネントの追加に関する情報を示します。

このガイドでは、選択した製品の1つ以上のプライマリ参照用トポロジを中心に説明しています。組織でインストールおよび構成するトポロジは、正確にはこのプライマリ・トポロジと異なる可能性がありますが、このガイドでは、これらのトポロジをインストールして構成するための詳細な手順を説明します。

また、このガイドでは、独自のエンタープライズ・デプロイメント・トポロジを設計および構築する方法について概要情報を提供します。独自構築のトポロジのために、このガイドでは、特定環境に必要な特定のコンポーネントまたは製品を追加する方法についても説明します。

3.2 プライマリOracle SOA Suiteエンタープライズ・トポロジのダイアグラム

この項では、2つのプライマリOracle SOA Suiteエンタープライズ・デプロイメント・トポロジのダイアグラムを示します。

- Oracle SOA SuiteおよびOracle Service Busのトポロジのダイアグラム

- Oracle SOA SuiteおよびOracle Business Activity Monitoringのトポロジのダイアグラム

3.2.1 Oracle SOA SuiteおよびOracle Service Busのトポロジのダイアグラム

図3-1は、Oracle SOAおよびOracle Service Busエンタープライズ・デプロイメント・トポロジのダイアグラムを示しています。

注意:

Oracle Service BusはOracle SOA Suiteと同じドメインまたは独自のドメインに構成できます。詳細は、「Oracle Service Busのトポロジ・オプションの理解」を参照してください。

ダイアグラムに示す標準的な要素の説明は、「標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムの理解」を参照してください。

ダイアグラムに示す要素の説明は、「プライマリOracle SOA Suiteトポロジ・ダイアグラムの理解」を参照してください。

図3-1 Oracle SOA SuiteおよびOracle Service Busエンタープライズ・デプロイメント参照用トポロジのダイアグラム

3.2.2 Oracle SOA SuiteおよびOracle Business Activity Monitoringのトポロジのダイアグラム

図3-2は、Oracle SOA SuiteおよびOracle Business Activity Monitoringエンタープライズ・トポロジのダイアグラムを示しています。

ダイアグラムに示す標準的な要素の説明は、「標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムの理解」を参照してください。

Oracle SOA Suiteトポロジに固有の要素の説明は、「プライマリOracle SOA Suiteトポロジ・ダイアグラムの理解」を参照してください。

図3-2 Oracle SOA SuiteおよびOracle Business Activity Monitoringエンタープライズ・トポロジのダイアグラム

3.3 プライマリOracle SOA Suiteトポロジ・ダイアグラムの理解

この項では、プライマリ・トポロジに特有の要素に関する情報を示します。

Oracle SOA Suiteトポロジのほとんどの要素は、オラクル社が推奨するベスト・プラクティスに準拠したエンタープライズ・トポロジの標準機能に相当します。これらの要素については、「標準的なエンタープライズ・デプロイメントの理解」で詳しく説明しています。

ここで説明する情報は、「標準的なエンタープライズ・デプロイメントの理解」の情報を確認したこと、およびエンタープライズ・デプロイメント・トポロジの一般的概念を理解していることを前提としています。

この章で説明するトポロジに特有の要素については、次の各項を参照してください。

- Oracle Service Busのトポロジ・オプションの理解

- Oracle SOA Suiteのロード・バランサ仮想サーバー名のサマリー

- SOAコンポジット・リクエストのルーティングの理解

- SOAアプリケーション層の管理対象サーバーとクラスタのサマリー

3.3.1 Oracle Service Busのトポロジ・オプションの理解

このガイドのOracle SOA SuiteおよびOracle Service Busトポロジ・ダイアグラムでは、SOA SuiteとOracle Service Busの両方を含む単一のドメインを想定しています。ただし一般に、Oracle Service Busを独自のドメイン内に構成すると便利です。

たとえば、Oracle Service Busをエンタープライズ規模で使用している場合、別個のドメインを検討します。このシナリオでは、それによりOracle Service Busを使用して複数のSOAドメインおよび他のサービスにルーティングできます。

他方、Oracle Service Busを主としてSOA Suiteコンポジット・アプリケーションの仲介およびルーティングに使用している場合は、最適なパフォーマンスおよびスケーラビリティを実現するために、Oracle Service Busを同じドメインの別個のクラスタに構成します。

これらのオプションを検討する際、パッチ適用操作およびその他のライフサイクル保守操作も考慮してください。たとえば、Oracle SOA SuiteとOracle SOA Suiteでパッチ適用要件が異なることがあります。2つの製品が別個のドメイン内にある場合、もう一方に影響を与えずに一方に容易にパッチを適用できます。

3.3.2 Oracle SOA Suiteのロード・バランサ仮想サーバー名のサマリー

サーバー上のロードのバランシングと高可用性の提供のために、ハードウェア・ロード・バランサは一連の仮想サーバー名を認識するように構成されています。

これらの各サーバー名の用途については、「標準的なロード・バランサの仮想サーバー名のサマリー」を参照してください。

Oracle SOA Suiteトポロジでは、ハードウェア・ロード・バランサによって次の仮想サーバー名が認識されます。

- soa.example.com: この仮想サーバー名はすべての受信トラフィックに使用されます。これは、ランタイムSOAコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして機能します。ロード・バランサは、この仮想サーバー名へのすべてのリクエストをSSLを介してルーティングします。その結果、クライアントは、次のセキュア・アドレスを使用してこのサービスにアクセスします。

soa.example.com:443

- osb.example.com: この仮想サーバー名は、ランタイムOracle Service Busリソースおよびプロキシ・サービスへのすべてのHTTPトラフィックのアクセス・ポイントとして機能します。ロード・バランサは、この仮想サーバー名へのすべてのリクエストをSSLを介してルーティングします。その結果、クライアントは、次のセキュア・アドレスを使用してこのサービスにアクセスします。

osb.example.com:443

- soainternal.example.com: この仮想サーバー名は、アプリケーション層のコンポーネント間の内部通信専用であり、インターネットには公開されません。
具体的には、Oracle SOA Suiteエンタープライズ・トポロジでは、このURLがOracle SOA SuiteとOracle Service Bus両方の内部通信に使用されます。

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

soainternal.example.com:80

このURLは、コンポジットのモデリングの際、または適切なEnterprise Manager MBeanによる実行時に、内部サービスの起動に使用するURLとしても設定できます。詳細は、「soainternal仮想サーバー名の詳細」を参照してください。

- admin.example.com: この仮想サーバー名は、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle WebLogic Server管理コンソール・インタフェースにアクセスする必要がある管理者用です。

注意:
システムに対するHTTP以外のアクセス用にフロント・エンドLBRで特定のTCP仮想サーバーを使用するいくつかのコンポーネントがあります。これは、Oracle SOA HC IntegrationおよびOracle MFTのMLLPの場合です。これらの仮想サーバーでは、同じホスト名と異なるポートを使用するか、異なるホスト名を使用する可能性があります。異なるホスト名の使用は、トラフィックの制御にネットワーク・ツールが使用される場合にあり得るオプションです(たとえば、宛先アドレスに基づいてトラフィック・タイプの優先順位を決定する場合)。ただし、必要なDNSシステムに追加のホスト名アドレスが必要です。

このガイドの後半で、次の方法について説明します。

- リクエストを認識し、仮想ホスト名にルーティングするようにハードウェア・ロード・バランサを構成する

- 仮想ホスト名へのリクエストを認識し、正しいホスト・コンピュータに適切にルーティングできるように、Web層のOracle HTTP Serverインスタンスを構成する。

3.3.3 SOAコンポジット・リクエストのルーティングの理解

次の各項では、Oracle SOA Suiteコンポジット・アプリケーション用のエンタープライズ・デプロイメントの構成に関する追加情報を提供します。

- soainternal仮想サーバー名の詳細

- SOAコンポジット・アプリケーション用のWebサービスの最適化について

- Oracle HTTP Serverを介したSOAコンポジット・アプリケーションへのアクセスについて

- ロード・バランサを介したOracle SOA Suiteコンポジット・アプリケーションへのアクセスについて

3.3.3.1 soainternal仮想サーバー名の詳細

sointernal.example.com仮想サーバー名は、イントラネット・クライアントおよびコールバックによってのみ呼び出されることを除き、soa.example.comとまったく同じように機能します。この項では、その他の詳細を説明します。

soainternal.example.com仮想サーバー名がエンタープライズ・デプロイメントのインストールおよび構成時に明示的に使用されることはありませんが、カスタム・システムではしばしば、内部専用クライアントによって使用されるべきサービスが公開されます。このような場合、効率性およびセキュリティ上の理由により、soa.example.comなどの外部URLの使用は避ける必要があります。かわりに、インターネット・クライアントからは呼び出せないアドレスを使用する必要があります。SOAコンポジット・アプリケーションは特に、直接またはデプロイメント・プランを介してエンドポイントでこの内部URLを使用できます。

soainternal.example.comアドレスを使用する場合、システムに指定されたフロントエンド・アドレスに関係があります。クラスタのフロントエンド・アドレスが呼出しエンドポイントと一致する場合、Webサービスの最適化(たとえば、ロード・バランサ・エンドポイントへのフル・ループバックを伴う呼び出しではなく、直接RMI呼び出し)がトリガーされます。このため、予定される内部呼出しの数および関連性に応じて、クラスタにフロントエンドURLを設定し、ServerURLおよびHTTPServerURLプロパティを外部または内部に設定することを検討してください。

クラスタへのフロントエンドURLの設定は、構成ウィザードでクラスタを作成する際に行うことができます。後から、WebLogic Server管理コンソールを使用して変更することもできます。詳細は、管理コンソール・オンライン・ヘルプのHTTPプロトコルの構成に関する項を参照してください。

ServerURLおよびHTTPServerURLプロパティの設定の詳細は、「SOAインフラストラクチャ・プロパティの構成」を参照してください。

3.3.3.2 SOAコンポジット・アプリケーション用のWebサービスの最適化について

SOAコンポジット・アプリケーションがエンタープライズ・デプロイメント内で効率的に通信できるように内部コールバックを構成する場合、システムで各リクエストの正しいエンドポイント・アドレスがどのように確認されるかを把握しておく必要があります。

Webサービスのローカルでの最適化のための基本的な要件は、2つのSOAコンポジットが同じ管理対象サーバーまたはプロセスに配置されるようにすることです。コンポジットが同じサーバーに配置されているかどうかを特定するために、Oracle SOA Suiteはターゲット・サービス・コンポジットがデプロイされているサーバー(ホストおよびポート構成)と、参照サービス・エンドポイントURIで指定されているものを比較します。

- ターゲット・サービス・ホスト値をチェックする順序を、優先度が高い順に示します。

- SOAインフラストラクチャの「共通プロパティ」ページで、サーバーURLの構成プロパティ値をチェックします。

- 指定されていない場合は、クラスタMBeanのFrontendHostおよびFrontendHTTPPort (また、SSLが有効化されている場合はFrontendHTTPSPort)の構成プロパティ値をチェックします。

- 指定されていない場合は、Oracle WebLogic Server MBeanからFrontendHostおよびFrontendHTTPPort(または、SSLが有効な場合はFrontendHTTPSPort)構成プロパティ値をチェックします。

- 指定されていない場合は、DNS解決されたINETアドレスのlocalhostを使用します。

- ターゲット・サービス・ポート値をチェックする順序を、優先度が高い順に示します。

- SOAインフラストラクチャの「共通プロパティ」ページで、HttpServerURLに構成されているポートをチェックします。

- 指定されていない場合は、SOAインフラストラクチャの「共通プロパティ」ページでサーバーURLに構成されているポートをチェックします。

- 指定されていない場合は、クラスタMBeanのFrontendHostおよびFrontendHTTPPort (また、SSLが有効化されている場合はFrontendHTTPSPort)の構成プロパティ値をチェックします。

- 指定されていない場合は、Oracle WebLogic Server MBeanからFrontendHostおよびFrontendHTTPPort(または、SSLが有効な場合はFrontendHTTPSPort)構成プロパティ値をチェックします。

- 指定されていない場合は、HTTPには80、HTTPS URLには443が想定されます。

3.3.3.3 Oracle HTTP Serverを介したSOAコンポジット・アプリケーションへのアクセスについて

Web層のOracle HTTP Serverインスタンスからアプリケーション上の特定のOracle SOA Suiteコンポジット・アプリケーションURLにリクエストをルーティングする場合は、次の点を考慮してください。

- 旧リリースのOracle Fusion Middlewareでは、Oracle SOA Suiteコンポジット・アプリケーションへのリクエストが管理対象サーバーで受信され、かつそのコンポジット・アプリケーションがまだロードされていない場合、Oracle HTTP ServerはHTTP 503 (サービスが使用できません)メッセージを生成していました。

- Oracle Fusion Middleware 12cでは、この動作が変更されました。コンポジットがアクティブになる前にコンポジットへのリクエストが到着した場合、必要なアーティファクトが利用可能になり、コンポジットがアクティブ状態になるまで、HTTPリクエストは保留になります。

この動作の変更により、Oracle SOA Suite管理対象サーバーの起動時にまだロードされていないコンポジット・アプリケーションへのリクエストのルーティングが可能になります。ただし、Oracle HTTP ServerとOracle WebLogic Server間の通信で、応答の受信が大幅に遅延する可能性に対応する必要があります。

この問題に対処するには、Oracle HTTP ServerとOracle WebLogic Serverの間のファイアウォールを構成するときに、適切なタイムアウトを設定することで、コンポジットのロードを待機中の接続がシャットダウンされないようにします。

詳細は、「エンタープライズ・デプロイメントのファイアウォールとポートの構成」を参照してください。

Oracle HTTP Serverインスタンスは、特定のアプリケーションの可用性ではなく、Oracle WebLogic Serverサーバーの可用性に基づいてリクエストをルーティングします。このインスタンスは、Oracle WebLogic Serverが稼働している間はリクエストをルーティングし続けます。

3.3.3.4 ロード・バランサを介したOracle SOA Suiteコンポジット・アプリケーションへのアクセスについて

デフォルトの構成では、ハードウェア・ロード・バランサがすべてのリクエストをWeb層にルーティングし、Web層がそれらのリクエストをアプリケーション層の適切なりソースにルーティングします。

ただし、アプリケーション層の管理対象サーバーに直接ルーティングするようにハードウェア・ロード・バランサを構成できます。この構成には、特にOracle SOA Suiteエンタープライズ・デプロイメントにおいて、いくつかの利点があります。

- Oracle HTTP Serverを使用する場合と比べ構成と処理のオーバーヘッドが小さい。

- 各WLSサーバーで固有のURLを監視するようにロード・バランサを構成できるので、アプリケーション・レベルでの監視が可能(Oracle HTTP Serverでは不可能)。

この方法には、少なくとも1つの短所があります。リクエストがロード・バランサから管理対象サーバーに直接ルーティングされる場合、各リクエストはプロキシまたはインターセプトなしに2つのファイアウォールを超えることになります。組織のネットワーク・セキュリティ・ポリシーによっては、これはセキュリティ上の問題になります。

Oracle HTTP Serverがコンポジットに対するHTTPリクエストをOracle SOA Suite管理対象サーバーにルーティングしても、soa-infraアプリケーションがまだアクティブでない場合、そのリクエストは失敗します。したがって、サーバーの起動、再起動または移行後には、soa-infraアプリケーションがアクティブであることを必ず確認してください。

3.3.4 SOAアプリケーション層の管理対象サーバーとクラスタのサマリー

アプリケーション層は、Oracle WebLogic Serverドメイン内の管理サーバーおよび管理対象サーバーをホストします。

選択したトポロジに応じて、Oracle SOA Suiteドメイン用のOracle WebLogic Serverドメインは、表3-1に示すクラスタで構成されています。これらのクラスタは、アクティブ/アクティブ高可用性構成として機能します。

表3-1 Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジのクラスタのサマリー

クラスタ

管理対象サーバー

Oracle SOA Suite、Oracle Business Process ManagementおよびOracle B2Bクラスタ

WLS_SOA1、WLS_SOA2

Oracle Web Services Managerクラスタ

WLS_WSM1、WLS_WSM2

Oracle Service Busクラスタ

WLS_OSB1、WLS_OSB2

Oracle Oracle Enterprise Scheduler

WLS_ESS1、WLS_ESS2

Oracle Business Activity Monitoringクラスタ

WLS_BAM1、WLS_BAM2

3.4 プライマリOracle SOA Suiteエンタープライズ・トポロジの実装のフロー・チャートとロードマップ

この項では、フロー・チャートとロードマップの形式でエンタープライズ・デプロイメント・トポロジのインストールと構成の手順を示します。

次の項は、この章で説明するエンタープライズ・トポロジをインストールおよび構成するために実行する必要がある大まかな手順を示しています。

- プライマリOracle SOA Suiteエンタープライズ・トポロジをインストールおよび構成する手順のフロー・チャート

- エンタープライズ・デプロイメントの計画と準備のためのロードマップ表

- Oracle SOA SuiteおよびOracle Service Busエンタープライズ・トポロジの構成のためのロードマップ表

- Oracle SOA SuiteおよびOracle Business Activity Monitoringエンタープライズ・トポロジの構成のためのロードマップ表

3.4.1 プライマリOracle SOA Suiteエンタープライズ・トポロジをインストールおよび構成する手順のフロー・チャート

図3-3は、この章で説明するプライマリ・エンタープライズ・デプロイメント・トポロジをインストールおよび構成するために必要な手順のフロー・チャートです。フロー・チャートに続くセクションで、フロー・チャート内の各手順について説明します。

このガイドは、作業用のOracle SOA Suiteドメインから始めて、後でドメインを拡張して追加機能を加えられるように設計されています。

トポロジを構築するためのこのモジュラ・アプローチにより、ご使用のハードウェアおよびソフトウェア・リソース、さらに組織にとって最も重要なOracle SOA Suite機能に基づいて、戦略的な決定を行えます。

また、個々の製品またはコンポーネントを構成する際、検証とトラブルシューティングを行うこともできます。

これは、1つの構成ウィザード・セッションで複数の製品を構成できないという意味ではありません。このガイドで示すような様々な拡張機能を1回の構成ウィザード実行でグループ化できます。ただし、このガイドで説明する手順では、主にモジュラ・アプローチを中心にエンタープライズ・デプロイメントを構築します。

図3-3 エンタープライズ・トポロジ構成手順のフロー・チャート

3.4.2 エンタープライズ・デプロイメントの計画と準備のためのロードマップ表

次の表は、エンタープライズ・トポロジ・フロー・チャートに示した計画と準備の各手順について説明したものです。

フロー・チャート手順

詳細情報

標準的なエンタープライズ・デプロイメントの基礎の理解

標準的なエンタープライズ・デプロイメントの理解

デプロイする予定の製品の特定の参照用トポロジの理解。

必要な仮想サーバーや製品固有のデプロイメントに推奨されるクラスタや管理対象サーバーのサマリーなど、製品固有のトポロジおよびトポロジの説明を確認します。

Oracle SOA Suite EDGワークブックの確認

エンタープライズ・デプロイメント・ワークブックの使用

ハードウェア、IPアドレスおよびソフトウェア・ダウンロードの入手

エンタープライズ・デプロイメント用のリソースの取得

ハードウェア・ロード・バランサとファイアウォールの準備

エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備

ファイル・システムの準備

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

システム要件の確認、共有記憶域のマウントおよび仮想IPの有効化

エンタープライズ・デプロイメント用のホスト・コンピュータの準備

サポートされているOracle RACデータベースの特定またはインストール

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

3.4.3 Oracle SOA SuiteおよびOracle Service Busエンタープライズ・トポロジの構成のためのロードマップ表

表3-2は、図3-1に示したOracle SOA SuiteおよびOracle Service Busトポロジを構成するときに必要な各手順を説明したものです。

これらの手順は、図3-3のフロー・チャートに示したOracle SOA SuiteおよびOracle Service Busトポロジの手順に対応しています。

注意:

Oracle Service BusはOracle SOA Suiteと同じドメインまたは独自のドメインに構成できます。詳細は、「Oracle Service Busのトポロジ・オプションの理解」を参照してください。

表3-2 Oracle SOA SuiteおよびOracle Service Busエンタープライズ・トポロジの構成のためのロードマップ表

フロー・チャート手順

詳細情報

初期インフラストラクチャ・ドメインの作成

エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成

Web層を追加するドメインの拡張

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

Oracle SOA Suiteを含めるドメインの拡張

Oracle SOA Suiteを含めるドメインの拡張

Oracle Service Busを含めるドメインの拡張

Oracle Service Busを含めるドメインの拡張

Enterprise Schedulerを含めるドメインの拡張

Oracle Enterprise Schedulerを含めるドメインの拡張

Enterprise Schedulerを含めるドメインの拡張はオプションです。Enterprise Schedulerを構成する場合にのみ、この章の手順を実行してください。

Oracle B2Bを含めるドメインの拡張

Oracle B2Bを含めるドメインの拡張

Oracle B2Bを含めるドメインの拡張はオプションです。Oracle B2Bを構成する場合にのみ、この章の手順を実行してください。

3.4.4 Oracle SOA SuiteおよびOracle Business Activity Monitoringエンタープライズ・トポロジの構成のためのロードマップ表

表3-3は、図3-2に示したOracle SOA SuiteおよびOracle Business Activity Monitoringトポロジを構成するときに必要な各手順を説明したものです。

これらの手順は、図3-3のフロー・チャートに示したOracle SOA SuiteおよびOracle Business Activity Monitoringトポロジの構成手順に対応しています。

表3-3 Oracle SOA SuiteおよびOracle Business Activity Monitoringエンタープライズ・トポロジの構成のためのロードマップ表

フロー・チャート手順

詳細情報

初期インフラストラクチャ・ドメインの作成

エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成

Web層を追加するドメインの拡張

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

Oracle SOA Suiteを含めるドメインの拡張

Oracle SOA Suiteを含めるドメインの拡張

Business Process Managementを含めるドメインの拡張

Business Process Managementを含めるドメインの拡張

Oracle Business Activity Monitoringを含めるドメインの拡張

Business Activity Monitoringを含めるドメインの拡張

Oracle B2Bを含めるドメインの拡張

Oracle B2Bを含めるドメインの拡張

3.5 独自のOracle SOA Suiteエンタープライズ・トポロジの構築

この項では、実装可能ないくつかの代替トポロジについて、このガイドに示した手順に多少の変更を加えて説明します。

このドキュメントの「プライマリOracle SOA Suiteエンタープライズ・トポロジのダイアグラム」では、Oracle SOA Suiteの2つのプライマリ・エンタープライズ・トポロジを構成する手順を説明しています。

ただし、お客様が購入するOracle Fusion Middleware製品セットやデプロイするアプリケーションのタイプによって、組織の要件が異なる場合があります。

多くの場合、代替トポロジ(追加コンポーネントを含むトポロジ、またはプライマリ・トポロジ・ダイアグラムに示したOracle SOA Suite製品の一部を含まないトポロジ)のインストールおよび構成が可能です。

- 独自構築のエンタープライズ・トポロジのフロー・チャート

- サポートされている独自構築トポロジの説明

3.5.1 独自構築のエンタープライズ・トポロジのフロー・チャート

独自のエンタープライズ・トポロジを構築するには、どのOracle Fusion Middleware製品を使用し、どのような構成手順に従ってトポロジを構築するかの選択が伴います。

図3-4に、いくつかの代表的な代替Oracle SOA Suiteエンタープライズ・トポロジの構築に必要な構成手順の概要を示します。それぞれの構成手順は、このガイドの1つの章に対応しています。

独自構築のトポロジを実装するには、このガイドに示した手順を変更する必要があります。詳細は、「サポートされている独自構築トポロジの説明」を参照してください。

図3-4 Oracle SOA Suiteの独自構築トポロジのフロー・チャート

3.5.2 サポートされている独自構築トポロジの説明

表3-4は、図3-4に示したエンタープライズ・トポロジをこのガイドの説明に従って構築する場合に実行する構成手順を説明したものです。

また、このガイドの現行の説明に従って各トポロジを構築するときに考慮が必要となるいくつかの相違点も明示しています。

表3-4 独自のエンタープライズ・トポロジを構築するためのロードマップ表

トポロジ

Web層の構成後に次の章を参照してください

考慮事項と依存関係

SOA SuiteとBusiness Process Managementのみ

1. Oracle SOA Suiteを含めるドメインの拡張

2. Business Process Managementを含めるドメインの拡張

これらの説明は、Oracle SOA SuiteおよびBusiness Process Managementのインストーラを2回実行することを前提としています(1回はOracle SOA Suiteをインストールため、もう1回はOracle Business Process Managementをインストールするため)。

または、インストール時に「BPM」インストール・タイプを選択すると、Oracle SOA SuiteとOracle Business Process Managementを同時にインストールできます。

同様に、構成ウィザード・セッションでSOAとOracle Business Process Managementの両方のテンプレートを選択すると、構成ウィザードを1回実行するだけで、このトポロジを構成できます。

Oracle SOA SuiteとOracle B2Bのみ

1. Oracle SOA Suiteを含めるドメインの拡張

2. Oracle B2Bを含めるドメインの拡張

特に説明は不要。

SOA SuiteとEnterprise Schedulerのみ

1. Oracle SOA Suiteを含めるドメインの拡張

2. Oracle Enterprise Schedulerを含めるドメインの拡張

特に説明は不要。

Oracle Service BusとEnterprise Schedulerのみ

参照先

1. Oracle Service Busを含めるドメインの拡張

2. Oracle Enterprise Schedulerを含めるドメインの拡張

このトポロジはOracle SOA Suiteを必要としません。ただし、「Oracle Service Busを含めるドメインの拡張」の説明は、2つのSOA管理対象サーバーのクラスタがすでに作成されていることを前提としています。

したがって、このトポロジの作成時には、SOA管理対象サーバーやSOAクラスタへの参照はすべて無視してください。

また、リポジトリ作成ユーティリティ(RCU)を実行して、SOAINFRAスキーマを作成する必要があります。このスキーマはOracle Service Busでも必要になります。

Oracle Business Activity Monitoringのみ

Business Activity Monitoringを含めるドメインの拡張

「Business Activity Monitoringを含めるドメインの拡張」の説明は、既存のOracle SOA Suiteドメインを拡張すること、およびOracle SOA Suiteソフトウェア(Oracle BAMを含む)が共有記憶域上のOracleホームにすでにインストールされていることを前提としています。

このOracle BAMのみのトポロジでは、Oracle SOA SuiteをOracle Fusion MiddlewareインフラストラクチャのOracleホームにインストールしてから、Oracle BAMクラスタを含めるようにドメインを構成する必要があります。

また、リポジトリ作成ユーティリティ(RCU)を実行して、必要なSOAスキーマを作成する必要があります。

Oracle SOA Suite for healthcare integration

1. Oracle SOA Suiteを含めるドメインの拡張

2. Oracle SOA Suite for Healthcare Integrationを含めるドメインの拡張

特に説明は不要。

Oracle SOA Suite for MFT Integration

1. Oracle SOA Suiteを含めるドメインの拡張

2. エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

Oracle Managed File Transferでは、Web層のWebサーバーとしてOracle Traffic Directorが必要です。

3.6 カスタム・エンタープライズ・トポロジのインストールと構成について

このガイドで説明されていないトポロジを実装する場合は、トポロジに含める製品の動作保証情報、システム要件および相互運用性要件を確認してください。

トポロジがサポートされていることを確認したら、必要なコンポーネントのインストールと構成を行うためのガイドとしてこのガイドの説明を使用するか、またはOracle Fusion Middleware 12cのインストレーション・ガイドを使用して標準インストール・トポロジをインストールおよび構成し、スモール・スタート/スケール・アウト型アプローチで環境を構成できます。

詳細は、『Oracle Fusion Middlewareのインストールのプランニング』の本番環境のプランニングに関する項を参照してください。

3.7 Oracle SOA Suiteエンタープライズ・トポロジでの自動サービス移行の使用について

Oracle SOA Suite製品およびコンポーネントの高可用性を実現するために、このガイドでは、参照用トポロジの一部として作成するクラスタに対してOracle WebLogic Serverの自動サービス移行を有効にすることをお薦めします。

詳細は、「エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用」を参照してください。

第II部 エンタープライズ・デプロイメントの準備

ここでは、次の内容について説明します。

- エンタープライズ・デプロイメント・ワークブックの使用
この章では、エンタープライズ・デプロイメント・ワークブックの概要を示します。ワークブックを使用して組織のエンタープライズ・デプロイメントを計画する方法について説明します。

- エンタープライズ・デプロイメント用のリソースの取得
Oracle SOA Suite参照用トポロジの構成を開始する前に、この章を使用して必要なハードウェア、ソフトウェアおよびネットワーク設定を取得します。

- エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備
この章では、エンタープライズ・デプロイメント用にネットワークを構成する方法について説明します。

- エンタープライズ・デプロイメント用のファイル・システムの準備
ローカルおよび共有記憶域の要件、およびエンタープライズ・トポロジのインストール時および構成時における重要なディレクトリとファイルの場所の参照に使用される用語の理解が含まれます。

- エンタープライズ・デプロイメント用のホスト・コンピュータの準備
必要な共有記憶域システムをホストにマウントする方法や、各ホストで必要な仮想IPアドレスを有効化する方法について説明します。

- エンタープライズ・デプロイメント用のデータベースの準備
この章では、Oracle SOA Suiteエンタープライズ・デプロイメント用のデータベースの準備手順について説明します。

4 エンタープライズ・デプロイメント・ワークブックの使用

この章では、エンタープライズ・デプロイメント・ワークブックの概要を示します。ワークブックを使用して組織のエンタープライズ・デプロイメントを計画する方法について説明します。

この章では、エンタープライズ・デプロイメント・ワークブックの概要、ユースケースおよびエンタープライズ・デプロイメント・ワークブックを使用すべきユーザーの情報を提供します。

- エンタープライズ・デプロイメント・ワークブックの概要
この項では、エンタープライズ・デプロイメント・ワークブックについて簡単に説明します。

- ワークブックの標準的なユース・ケース
この項では、エンタープライズ・デプロイメント・ワークブックの標準的なユース・ケースに関係するロールおよびタスクを示します。

- Oracle SOA Suiteエンタープライズ・デプロイメント・ワークブックの使用
この項では、エンタープライズ・デプロイメント・ワークブックの使用について詳しく説明します。

- エンタープライズ・デプロイメント・ワークブックの使用対象者
エンタープライズ・デプロイメント・ワークブックの情報はカテゴリごとに分かれています。組織構成およびチームで規定されているロールに応じて、ワークブックの詳細を記入する組織内の特定の個人を割り当てることができます。同様に、カテゴリごとの情報を、各カテゴリのリソースの計画、取得または設定を担当する個人またはチームに割り当てることができます。

親トピック: エンタープライズ・デプロイメントの準備

4.1 エンタープライズ・デプロイメント・ワークブックの概要

この項では、エンタープライズ・デプロイメント・ワークブックについて簡単に説明します。

Oracle Fusion Middlewareエンタープライズ・デプロイメント・ワークブックは、このガイドの付属ドキュメントです。アーキテクト、システム・エンジニア、データベース管理者などが環境インストールの詳細(サーバー名、URL、ポート番号、インストール・パス、その他のリソースなど)をすべて計画したり記録したりするために使用できるスプレッドシートです。

エンタープライズ・デプロイメント・ワークブックは、プロセス全体の入力変数の追跡に使用できる唯一のドキュメントとしての役割を果たします。これにより、次のことが可能になります。

- アーキテクト、システム・エンジニア、データベース管理者および組織上重要な他のロール間での作業の切り分け

- 実装前の包括的な計画

- 計画内容を実際の実装前に検証

- 実装時の一貫性

- 将来の使用に備えた環境の記録

4.2 ワークブックの標準的なユース・ケース

この項では、エンタープライズ・デプロイメント・ワークブックの標準的なユース・ケースに関係するロールおよびタスクを示します。

Oracle Fusion Middlewareエンタープライズ・デプロイメントの準備として、エンタープライズ・デプロイメント・ワークブックの標準的なユース・ケースには次のロールと作業が関わります。

- アーキテクトがこのガイドの最初から第5章までを読み、ワークブックの対応する各項を記入します。

- ワークブックを他のアーキテクトとシステム・エンジニアが検証します。

- アーキテクトが検証済のワークブックを使用して、ネットワークとシステムの変更リクエストをシステム・エンジニアリング部門とともに開始します。

- ソフトウェアのインストールと構成を担当する管理者とシステム・インテグレータがワークブックとこのガイドの以降の章を参照して、インストールと構成の作業を行います。

4.3 Oracle SOA Suiteエンタープライズ・デプロイメント・ワークブックの使用

この項では、エンタープライズ・デプロイメント・ワークブックの使用について詳しく説明します。

次の項では、Oracle SOA Suiteエンタープライズ・デプロイメント・ワークブックの場所と内容について説明します。

- Oracle SOA Suiteエンタープライズ・デプロイメント・ワークブックの入手方法

- Oracle SOA Suiteエンタープライズ・デプロイメント・ワークブックの内容の理解

4.3.1 Oracle SOA Suiteエンタープライズ・デプロイメント・ワークブックの入手方法

Oracle SOA Suiteエンタープライズ・デプロイメント・ワークブックは、Oracle Fusion Middlewareドキュメント・ライブラリにMicrosoft Excelスプレッドシートとして用意されています。ライブラリのインストール、パッチおよびアップグレード・ページのリンクから入手できます。

4.3.2 Oracle SOA Suiteエンタープライズ・デプロイメント・ワークブックの内容の理解

次の項では、Oracle SOA Suiteエンタープライズ・デプロイメント・ワークブックの内容について説明します。ワークブックは複数のタブに分かれており、各タブには、エンタープライズ・デプロイメント・トポロジのインストールと構成に必要な一連の関連する変数と値が含まれます。

- スタート・タブの使用

- ハードウェア - ホスト・コンピュータ・タブの使用

- ネットワーク - 仮想ホストとポート・タブの使用

- ストレージ - ディレクトリ変数タブの使用

- 「データベース - 接続の詳細」タブの使用

4.3.2.1 スタート・タブの使用

エンタープライズ・デプロイメント・ワークブックのスタート・タブは、このワークブックの目次の役割を果たします。また、スプレッドシートの記入者を特定する目的にも使用できます。

スタート・タブには、値が必要なワークブック・フィールドや情報提供を目的としたフィールドの識別に使用する色を指定するためのキーも用意されています。

次の図は、スプレッドシートのスタート・タブを示しています。

4.3.2.2 ハードウェア - ホスト・コンピュータ・タブの使用

ハードウェア - ホスト・コンピュータ・タブには、Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジのインストールと構成に必要なホスト・コンピュータの一覧が記載されています。

参照用トポロジは通常、少なくとも6台のホスト・コンピュータ(Web層に2台、アプリケーション層に2台、データ層のOracle RACデータベース用に2台)を必要とします。環境を拡張してシステムを追加する場合は、追加するホスト・コンピュータごとに行を追加してください。

抽象ホスト名は、このガイド全体を通してホスト名の記述に使用される名前です。各行のホスト・コンピュータを調達し、実際のホスト名を入力してください。これにより、このガイドで抽象名が記述されているときに実際のホスト名を参照できるようになります。

たとえば、このガイドの手順にSOAHOST1と記述されている場合、このSOAHOST1という変数を、ワークブックのハードウェア - ホスト・コンピュータ・タブに記載されている実際の名前に置き換えることができます。

簡単に参照できるように、各ホストのIPアドレス、オペレーティング・システム(バージョンを含む)、CPU数およびRAMの量も記入しておくことをお薦めします。この情報は、エンタープライズ・デプロイメントのインストール、構成および保守時に役立つことがあります。

詳細は、「エンタープライズ・デプロイメント用のホスト・コンピュータの準備」を参照してください。

4.3.2.3 ネットワーク - 仮想ホストとポート・タブの使用

ネットワーク - 仮想ホストとポート・タブには、エンタープライズ・デプロイメント・トポロジのインストールと構成を行う前に、ネットワーク管理者が定義する必要のある仮想ホストの一覧が記載されています。

ポート番号は様々な理由から重要です。管理コンソールにアクセスするためには、ポート番号のクイック・リファレンスが必要です。また、特定のポート経由のネットワーク・トラフィックを許可するようにファイアウォールを構成する必要があります。

仮想ホスト、仮想IPアドレスおよびネットワーク・ポートはデプロイメントでそれぞれ異なる役割を果します。詳細は、「エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備」を参照してください。

ネットワーク - 仮想ホスト表で、抽象仮想ホストまたは仮想IP名列の項目を確認してください。これらは、このガイドの手順で使用される仮想ホストと仮想IP名です。それぞれの抽象名に対して、ネットワーク管理者が定義した実際の仮想ホスト名を入力します。このガイドで抽象仮想ホストまたは抽象仮想IP名が記述されている箇所では、このテーブル内の対応する実際値に置き換えてください。

また、多くの場合、このガイドでは、インストールおよび構成するコンポーネントまたは製品にデフォルトのポート番号を使用することを前提としています。しかし実際には、異なるポート番号を使用する可能性があります。ネットワーク - ポート番号表を使用すると、デフォルトのポート値を、特定のインストールで使用する実際の値にマッピングできます。

4.3.2.4 ストレージ - ディレクトリ変数タブの使用

エンタープライズ・デプロイメントの準備の一環として、Oracleエンタープライズ・デプロイメントで推奨される標準ディレクトリ構造を使用することが前提となっています。

また、このガイドの手順では、特定のディレクトリ場所が記述されています。手順内でディレクトリごとに一貫して割り当てられている変数を、インストールにおける実際のディレクトリの場所に置き換える必要があります。

このタブに掲載されている各ディレクトリ場所に、インストールにおける実際のディレクトリ・パスを入力してください。

また、アプリケーション層では、これらの標準ディレクトリの多くを共有記憶域デバイス上に作成することをお薦めします。このようなディレクトリのために、共有記憶域場所の名前と共有場所をマウントするときに使用したマウント・ポイントを入力できる欄もこの表に用意されています。

詳細は、「エンタープライズ・デプロイメント用のファイル・システムの準備」を参照してください。

4.3.2.5 「データベース - 接続の詳細」タブの使用

エンタープライズ・デプロイメント・トポロジのインストールおよび構成時には、多くの場合、高可用性のOracle Real Application Clusters (RAC)データベースに接続する必要があります。このガイドの手順では、構成ウィザードやリポジトリ作成ユーティリティなどのツールからデータベースに接続するために指定する必要がある情報を示す一連の変数が記述されています。

このタブを使用して、これらの変数の、データベース・インストールにおける実際の値を入力し、いつでも参照できるようにしておいてください。

詳細は、「エンタープライズ・デプロイメント用のデータベースの準備」を参照してください。

4.4 エンタープライズ・デプロイメント・ワークブックの使用対象者

エンタープライズ・デプロイメント・ワークブックの情報はカテゴリごとに分かれています。組織構成およびチームで規定されているロールに応じて、ワークブックの詳細を記入する組織内の特定の個人を割り当てることができます。同様に、カテゴリごとの情報を、各カテゴリのリソースの計画、取得または設定を担当する個人またはチームに割り当てることができます。

たとえば、ワークブックは組織内の次のロールを担う人物が記入、確認および使用できます。

- 情報テクノロジ(IT)担当責任者

- アーキテクト

- システム管理者

- ネットワーク・エンジニア

- データベース管理者

5 エンタープライズ・デプロイメント用のリソースの取得

Oracle SOA Suite参照用トポロジの構成を開始する前に、次の項を使用して必要なハードウェア、ソフトウェアおよびネットワーク設定を取得します。

この章では、エンタープライズ・デプロイメントに必要なIPアドレスを予約し、ソフトウェア・ダウンロードを識別して取得する方法について説明します。

- エンタープライズ・デプロイメント・トポロジ用のハードウェアおよびソフトウェアの要件
この項では、エンタープライズ・デプロイメント・トポロジのハードウェア・ロード・バランサの要件、ホスト・コンピュータのハードウェア要件およびオペレーティング・システム要件を示します。

- エンタープライズ・デプロイメント用の必須IPアドレスの予約
この項では、インストールおよび構成の前に取得および予約する必要のある一連のIPアドレスを示します。

- エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得
エンタープライズ・トポロジのインストールおよび構成を開始する前に、トポロジの実装に必要なソフトウェア・ディストリビューションを見つけてダウンロードする必要があります。

親トピック: エンタープライズ・デプロイメントの準備

5.1 エンタープライズ・デプロイメント・トポロジ用のハードウェアおよびソフトウェアの要件

この項では、エンタープライズ・デプロイメント・トポロジのハードウェア・ロード・バランサの要件、ホスト・コンピュータのハードウェア要件およびオペレーティング・システム要件を示します。

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

- ハードウェア・ロード・バランサの要件
この項では、外部ロード・バランサに必要な機能を示します。

- ホスト・コンピュータのハードウェア要件
この項では、エンタープライズ・デプロイメント・トポロジをサポートするように構成されるホスト・コンピュータの取得に役立つ情報を提供します。

- エンタープライズ・デプロイメント・トポロジのオペレーティング・システム要件
この項では、オペレーティング・システム要件について説明します。

5.1.1 ハードウェア・ロード・バランサの要件

この項では、外部ロード・バランサに必要な機能を示します。

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

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

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

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

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

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

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

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

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

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

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

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

- SSLアクセラレーション(これは推奨する機能ですが、エンタープライズ・トポロジに必須ではありません)。

- TCP/IPリクエストをルーティングする機能。これは、Minimum Lower Layer Protocol (MLLP) over TCPを使用するOracle SOA Suite for healthcare integrationの要件です。

5.1.2 ホスト・コンピュータのハードウェア要件

この項では、エンタープライズ・デプロイメント・トポロジをサポートするように構成されるホスト・コンピュータの取得に役立つ情報を提供します。

内容は次のとおりです。

- エンタープライズ・デプロイメントのホスト・コンピュータに関する一般的な考慮事項
この項では、エンタープライズ・デプロイメントのホスト・コンピュータに必要な一般的な考慮事項を示します。

- Oracle Fusion Middlewareシステム要件の確認
この項では、環境が必要最小限の要件を満たしていることを確認するために役立つシステム要件情報の参照先を示します。

- エンタープライズ・デプロイメントに必要な標準的なメモリー、ファイル・ディスクリプタおよびプロセス数
この項では、エンタープライズ・デプロイメントに必要な標準的なメモリー、ファイル・ディスクリプタ数、オペレーティング・システム・プロセス数およびタスクの詳細を示します。

- エンタープライズ・デプロイメントの標準的なディスク領域要件
この項では、このエンタープライズ・デプロイメントに必要な標準的なディスク領域を示します。

5.1.2.1 エンタープライズ・デプロイメントのホスト・コンピュータに関する一般的な考慮事項

この項では、エンタープライズ・デプロイメントのホスト・コンピュータに必要な一般的な考慮事項を示します。

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

この章で提供する情報は、ホスト・コンピュータ要件を判断するために役立つ一般的なガイドラインおよび情報です。これにより、個別の本番環境に対するキャパシティ・プランニングを実行する必要がなくなるわけではありません。

注意:

この項でホスト・コンピュータを取得し確保したら、ホスト名とシステム特性をエンタープライズ・デプロイメント・ワークブックに記録してください。これらのアドレスは、後で各ホスト・コンピュータでIPアドレスを有効化するときに使用します。

詳細は、「エンタープライズ・デプロイメント・ワークブックの使用」を参照してください

5.1.2.2 Oracle Fusion Middlewareシステム要件の確認

この項では、環境が必要最小限の要件を満たしていることを確認するために役立つシステム要件情報の参照先を示します。

Oracle Fusion Middlewareのシステム要件および仕様を参照し、環境がインストールする製品の最小インストール要件を満たしていることを確認します。

要件および仕様のドキュメントには、Oracle Fusion Middlewareの一般的なハードウェアとソフトウェアの要件、ディスク領域とメモリーの最小要件、データベース・スキーマの要件、および必要なシステム・ライブラリおよびパッケージに関する情報が記載されています。

また、Oracle Fusion Middlewareデプロイメントのメモリー要件を見積るための一般的なガイドラインも記載されています。

5.1.2.3 エンタープライズ・デプロイメントに必要な標準的なメモリー、ファイル・ディスクリプタおよびプロセス数

この項では、エンタープライズ・デプロイメントに必要な標準的なメモリー、ファイル・ディスクリプタ数、オペレーティング・システム・プロセス数およびタスクの詳細を示します。

次の表は、標準的なOracle SOA Suiteエンタープライズ・デプロイメントにおける管理サーバーおよび各管理対象サーバー・コンピュータに必要なメモリー、ファイル・ディスクリプタおよびプロセス数をまとめたものです。これらの値はあくまで例にすぎませんが、初期エンタープライズ・デプロイメントに最小限必要なメモリー量の見積りに使用できます。

この項の例は、参照用トポロジに示されているSOAHOST1に必要な管理対象サーバーおよび他のサービスを構成するための最少要件を反映しています。

マシンの調達時には、各ホスト・コンピュータに搭載する必要がある最小物理メモリーを判断するときの目安として、「概算最大メモリー」列の情報を使用してください。

ホスト・コンピュータ・ハードウェアを調達し、オペレーティング・システム要件を確認したら、ソフトウェア構成を調査して、オペレーティング・システムの設定が「ファイル・ディスクリプタ」列に記載されているオープン・ファイル数と「オペレーティング・システムのプロセスおよびタスク数」列に記載されているプロセス数に対応できるように構成されていることを確認します。

詳細は、「UNIXシステムでのオープン・ファイル制限とプロセス数の設定」を参照してください。

管理対象サーバー、ユーティリティまたはサービス

概算最大メモリー

ファイル・ディスクリプタ数

オペレーティング・システムのプロセスおよびタスク数

管理サーバー

3.5 GB

3500

165

WLS_WSM

3.0 GB

2000

130

WLS_SOA

4.0 GB

3100

240

WLS_OSB

4.0 GB

2200

180

WLS_ESS

3.5 GB

1300

35

WLS_BAM

3.5 GB

2300

210

WLST (ノード・マネージャへの接続)

1.5 GB

910

20

構成ウィザード

1.5 GB

700

20

ノード・マネージャ

1.0 GB

720

15

合計

27.0 GB*

17000

1200

*オペレーティング・システムとその他の追加メモリー要件を考慮した概算合計。

5.1.2.4 エンタープライズ・デプロイメントの標準的なディスク領域要件

この項では、このエンタープライズ・デプロイメントに必要な標準的なディスク領域を示します。

Oracle SOA Suite製品を含むOracle Fusion Middleware 12c (12.2.1)製品の最新のディスク領域要件は、Oracle Fusion Middlewareのシステム要件と仕様を確認してください。

また、次の表は、Oracle SOA Suiteエンタープライズ・デプロイメントに通常必要なディスク領域をまとめたものです。

この情報と「エンタープライズ・デプロイメント用のファイル・システムの準備」の情報に基づいて、デプロイメントに必要なディスク領域を判断してください。

サーバー

ディスク

データベース

nXm

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

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

WEBHOSTn

10 GB

SOAHOSTn (SOAのみ)

10 GB*

SOAHOSTn (SOAおよびOSB)

11 GB*

*共有記憶域のOracleホーム構成の場合、2つのインストールで合計20GBになるようにすると十分です。

5.1.3 エンタープライズ・デプロイメント・トポロジのオペレーティング・システム要件

この項では、オペレーティング・システム要件について説明します。

このガイドで説明するOracle Fusion Middlewareソフトウェア製品およびコンポーネントは、Oracle Fusion Middlewareシステム要件と仕様に記載されている様々なオペレーティング・システムおよびプラットフォームで動作保証されています。

注意:

このガイドでは、Oracle Linuxシステムにおけるエンタープライズ・デプロイメント参照用トポロジの実装を中心に取り上げています。

このトポロジは、動作保証済でサポートされている任意のオペレーティング・システムで実装可能ですが、このガイドの例には、多くの場合、Oracle Linux上でbashシェルを使用して実行する必要があるコマンドと構成手順が示されています。

5.2 エンタープライズ・デプロイメント用の必須IPアドレスの予約

この項では、インストールおよび構成の前に取得および予約する必要のある一連のIPアドレスを示します。

エンタープライズ・トポロジのインストールおよび構成を開始する前に、次の一連のIPアドレスを取得および予約する必要があります。

- トポロジのために取得した各ホスト・コンピュータの物理IP (IP)アドレス

- 管理サーバーの仮想IP (VIP)アドレス

- サーバー全体の移行に構成された、各管理対象サーバーの追加のVIPアドレス
自動サービス移行をサポートするOracle SOA SuiteなどのFusion Middleware 12c製品の場合、管理対象サーバーのVIPは通常不要です。

- 各VIPにマップされる一意の仮想ホスト名。

ネットワーク管理者と協力して、これらの必須VIPが、ご使用のDNSサーバーに定義されていることを確認できます。(非本番環境では、かわりに/etc/hostsファイルを使用してこれらの仮想ホストを定義できます)。

詳細な情報は、次のトピックを参照してください

- 仮想IP (VIP)アドレスとは
この項では、仮想IPアドレスについて定義し、その用途を示します。

- 仮想ホスト名と仮想IPアドレスを使用する理由
特にエンタープライズ・デプロイメントの場合、一連のVIPおよびそれらがマップされている仮想ホスト名を、社内ネットワーク上で予約して有効化することが重要です。

- エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス
この項では、標準的なOracle SOA Suiteエンタープライズ・デプロイメント・トポロジで管理サーバーと各管理対象サーバーに必要な物理IP (IP)と仮想IP (VIP)アドレスを示します。

5.2.1 仮想IP (VIP)アドレスとは

この項では、仮想IPアドレスについて定義し、その用途を示します。

仮想IPアドレスは、ホストの主要IPアドレスと同じサブネットに属する、未使用のIPアドレスです。これは、ホストに手動で割り当てられます。ホスト・コンピュータで障害が発生した場合、トポロジ内の新しいホストに仮想アドレスを割り当てることができます。このガイドの目的のために、あるホストから別のホストに再割当てできるものを仮想IPアドレス、ハードウェア・ホスト・コンピュータに永続的に割り当てられるものを物理IPアドレスと呼びます。

5.2.2 仮想ホスト名と仮想IPアドレスを使用する理由

特にエンタープライズ・デプロイメントの場合、一連のVIPおよびそれらがマップされている仮想ホスト名を、社内ネットワーク上で予約して有効化することが重要です。

ホスト名は、様々なノードを通して伝播される適切な/etc/hostsファイルをかわりに使用して解決できます。

IPアドレスが割り当てられたホスト・コンピュータに障害が発生した場合は、割り当てられた管理対象サーバーの実行を新しいホストが引き継ぐことができるように、このIPアドレスは同じサブネット内の別のホスト・コンピュータに割り当てることができます。

管理サーバーの仮想IPアドレスの再割当ては手動で実行する必要がありますが、管理対象サーバーの仮想IPアドレスの再割当ては、Oracle WebLogic Serverのサーバー全体の移行機能を使用して自動的に実行できます。

サーバー全体の移行を使用すべきか否かは、デプロイする製品およびそれらが自動サービス移行をサポートするかどうかによって決まります。

たとえば、Oracle SOA Suite 12c以降、SOA Suite製品は自動サービス移行をサポートするようになりました。その結果、ドメイン内の管理対象サーバーごとにVIPを予約する必要はなくなりました。VIPが必要なのは管理サーバーのみになりました。

5.2.3 エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス

この項では、標準的なOracle SOA Suiteエンタープライズ・デプロイメント・トポロジで管理サーバーと各管理対象サーバーに必要な物理IP (IP)と仮想IP (VIP)アドレスを示します。

エンタープライズ・デプロイメントのインストールおよび構成を開始する前に、表5-1のVIPに対応する一連のホスト名およびIPアドレスを予約します。

VIPには任意の一意のホスト名を割り当てることができますが、このガイドでは、この表の推奨ホスト名を使用して各VIPを参照します。

注意:

この項でIPアドレスおよび対応する仮想ホスト名を取得および予約したら、それらのIPアドレスとホスト名の値をエンタープライズ・デプロイメント・ワークブックに記録してください。これらのアドレスは、後で各ホスト・コンピュータでIPアドレスを有効化するときに使用します。

詳細は、「エンタープライズ・デプロイメント・ワークブックの使用」を参照してください

表5-1 エンタープライズ・デプロイメントに必要な仮想IPアドレスのサマリー

仮想IP

VIPのマップ先

説明

VIP1

ADMINVHN

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

5.3 エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得

エンタープライズ・トポロジのインストールおよび構成を開始する前に、トポロジの実装に必要なソフトウェア・ディストリビューションを見つけてダウンロードする必要があります。

次の表に、入手する必要があるダウンロードの一覧を示します。

Oracle Fusion Middlewareソフトウェアの入手方法に関する一般情報は、『Oracle Fusion Middlewareのインストールのプランニング』の製品のディストリビューションの理解と入手に関する項を参照してください。

特定のOracle Fusion Middleware製品の場所およびダウンロードに関する個別情報は、OTNのOracle Fusion Middlewareのダウンロード、インストールおよび構成のREADMEファイルを参照してください。

ディストリビューション

説明

Oracle Fusion Middleware 12c (12.2.1.0.0) Infrastructure

このディストリビューションをダウンロードしてOracle Fusion Middleware Infrastructureをインストールします。これには、Oracle WebLogic ServerおよびOracle Fusion Middleware製品に必要なJava Required Filesソフトウェアが含まれています。

このディストリビューションによってリポジトリ作成ユーティリティ(RCU)もインストールされます。これは、以前のOracle Fusion Middlewareリリースでは独自のディストリビューションにパッケージされていました。

Oracle HTTP Server 12c (12.2.1.0.0)

Oracle HTTP ServerをWeb層ホストにダウンロードするには、このディストリビューションをダウンロードします。

Oracle Fusion Middleware 12c (12.2.1.0.0) SOA SuiteおよびBusiness Process Management

このディストリビューションをダウンロードしてSOA FoundationとBPMソフトウェアをインストールします。これには、Oracle Business Activity Monitoring (BAM)およびOracle Enterprise Scheduler (ESS)が含まれています。

Oracle Fusion Middleware 12c (12.2.1.0.0) Service Bus

Oracle SOA Suiteエンタープライズ・トポロジの一部としてOracle Service Busをインストールおよび構成する場合は、このディストリビューションをダウンロードします。

Oracle Fusion Middleware 12c (12.2.1.0.0) B2BおよびHealthcare

Oracle SOA Suiteエンタープライズ・トポロジの一部としてOracle B2BまたはOracle B2B Healthcareをインストールおよび構成する場合は、このディストリビューションをダウンロードします。

6 エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備

この章では、エンタープライズ・デプロイメント用にネットワークを構成する方法について説明します。

- ハードウェア・ロード・バランサでの仮想ホストの構成
この項では、エンタープライズ・デプロイメント用にハードウェア・ロード・バランサを構成する方法について説明します。

- エンタープライズ・デプロイメントのファイアウォールとポートの構成
この項では、ファイアウォールでエンタープライズ・デプロイメント用に開く必要のあるポートを示します。

親トピック: エンタープライズ・デプロイメントの準備

6.1 ハードウェア・ロード・バランサでの仮想ホストの構成

この項では、エンタープライズ・デプロイメント用にハードウェア・ロード・バランサを構成する方法について説明します。

次の各項で、ハードウェア・ロード・バランサの構成方法について説明し、必要な仮想サーバーのサマリーとこれらの仮想サーバーに関する追加指示を示します。

- ハードウェア・ロード・バランサ構成の概要

- ハードウェア・ロード・バランサの構成の一般的な手順

- エンタープライズ・デプロイメントに必要な仮想サーバーのサマリー

- admin.example.comに関する追加手順

- soa.example.comに関する追加手順

- soainternal.example.comに関する追加手順

- osb.example.comに関する追加手順

- soahealthcare.example.comに関する追加手順

- mft.example.comに関する追加手順

6.1.1 ハードウェア・ロード・バランサ構成の概要

トポロジのダイアグラムに示すように、リクエストを認識し、様々な種類のネットワーク・トラフィックや監視に対応する複数の仮想サーバーと関連ポートにリクエストをルーティングできるように、ハードウェア・ロード・バランサを構成する必要があります。

ロード・バランシング・デバイスにおける仮想サーバーとは、ロード・バランシングのために複数の物理サーバーを1つのサーバーのように見せかけることができる構成です。仮想サーバーは通常、IPアドレスとサービスによって表され、受信したクライアント・リクエストをサーバー・プール内の各サーバーに配信するために使用されます。

仮想サーバーは、(エンタープライズ・デプロイメントで使用可能な各種サービス用の)適切なホスト・コンピュータおよびポートにトラフィックをルーティングするように構成しておく必要があります。

さらに、サービスが停止したときに特定のサーバーへのトラフィックをできるだけ早く停止できるように、ホスト・コンピュータとポートの可用性を監視するようにロード・バランサを構成する必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。

ロード・バランサを構成した後で、同じ名前を持つ一連の仮想ホストを、ロード・バランサに定義した仮想サーバーとして認識するように、Web層のWebサーバー・インスタンスを構成することも可能です。Webサーバーは、ハードウェア・ロード・バランサから受信した各リクエストを、リクエストのヘッダーに記述されているサーバー名に基づいて適切にルーティングできます。詳細は、「管理およびOracle Web Services Manager用のOracle HTTP Serverの構成」を参照してください。

6.1.2 ハードウェア・ロード・バランサの構成の一般的な手順

次の手順では、エンタープライズ・デプロイメントのハードウェア・ロード・バランサを構成する一般的な手順を示します。

特定のロード・バランサを構成する実際の手順は、ロード・バランサのタイプによって異なります。ロード・バランシングされるプロトコルのタイプによっては、複数の相違点が存在することもあります。たとえば、TCP仮想サーバーおよびHTTP仮想サーバーでは、そのプールに対して異なるタイプの監視を使用します。実際の手順については、ベンダーが提供するマニュアルを参照してください。

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

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

3. ロード・バランサ上に、アプリケーションのリクエストを受信するアドレスおよびポート用の必須仮想サーバーを作成します。
エンタープライズ・デプロイメントに必要な仮想サーバーの完全なリストは、「エンタープライズ・デプロイメントに必要な仮想サーバーのサマリー」を参照してください。

ロード・バランサで各仮想サーバーを定義するときは、次のことを考慮します。

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

b. 適用可能な場合は、仮想サーバーに対するSSL終端を構成します。

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

6.1.3 エンタープライズ・デプロイメントに必要な仮想サーバーのサマリー

この項では、エンタープライズ・デプロイメントに必要な仮想サーバーについて説明します。

次の表は、Oracle SOA Suiteエンタープライズ・トポロジのハードウェア・ロード・バランサで定義する必要がある仮想サーバーの一覧です。

仮想ホスト

サーバー・プール

プロトコル

SSL終端

外部

admin.example.com:80

WEBHOST1.example.com:7777 WEBHOST2.example.com:7777

HTTP

いいえ

いいえ

soa.example.com:443

WEBHOST1.example.com:7777 WEBHOST2.example.com:7777

HTTPS

はい

はい

soainternal.example.com:80

WEBHOST1.example.com:7777 WEBHOST2.example.com:7777

HTTP

いいえ

いいえ

osb.example.com:443

WEBHOST1.example.com:7777 WEBHOST2.example.com:7777

HTTPS

いいえ

はい

mft.example.com:7501

WEBHOST1.example.com:7501WEBHOST2.example.com:7501

TCP

いいえ

はい

soahealthcare.example.com:95nn

WEBHOST1.example.com:7777WEBHOST2.example.com:7777

TCP

いいえ

はい

注意:

SOA SuiteとOracle Managed File Transferが同じホストにデプロイされている場合、Managed File Transferは、SOAによって使用されるHTTP仮想サーバーとHTTPS仮想サーバーを共有して、Managed File Transferコンソールにアクセスできます。ただし、(SFTリクエストをロード・バランシングするために使用される) TCPプロトコル7に対しては、個別のManaged File Transfer仮想サーバーが必要です。

6.1.4 admin.example.comに関する追加手順

この項では、仮想サーバーadmin.example.comに必要な追加手順を示します。

ハードウェア・ロード・バランサでこの仮想サーバーを構成する場合:

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

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

6.1.5 soa.example.comに関する追加手順

ハードウェア・ロード・バランサでこの仮想サーバーを構成する場合:

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

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

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

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

- この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。
これらのコンテキスト文字列は、リクエストをOracle WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlにルーティングするため、admin.example.comからシステムへのアクセス時にのみ使用する必要があります。

6.1.6 soainternal.example.comに関する追加手順

ハードウェア・ロード・バランサでこの仮想サーバーを構成する場合:

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

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

- soa.example.comと同様に、この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。

6.1.7 osb.example.comに関する追加手順

ハードウェア・ロード・バランサでこの仮想サーバーを構成する場合:

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

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

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

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

- この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。
これらのコンテキスト文字列は、リクエストをOracle WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlにルーティングするため、admin.example.comからシステムへのアクセス時にのみ使用する必要があります。

6.1.8 soahealthcare.example.comに関する追加手順

Healthcare Minimum Lower Layer Protocol (MLLP)の各エンドポイントには、ロード・バランサ上の別個の仮想サーバーが必要です。ロード・バランサは、特定ポートでいずれかのHealthcare管理対象サーバーで実行されているMLLPサービスにルーティングします。この仮想サーバーのプールは、Healthcareコンソールでエンドポイントの作成に使用されたホスト名とポートをポイントしています。

たとえば、SOAHOST1:9501 (SOAHOST2:9501にフェイルオーバー)でエンドポイントが作成されている場合、9501をサービス・ポートとして、SOAHOST1:9501およびSOAHOST2:9501を含むプールで仮想サーバーを作成する必要があります。Healthcareロード・バランサ仮想サーバーは、TCPをプロトコルとして使用し、接続のソート・ポートを維持するアドレスおよびポート・トランザクションを使用する必要があります。

6.1.9 mft.example.comに関する追加手順

Managed File Transferでは、Secure File Transfer Protocol (SFTP)に対して単一のOracle Traffic Director仮想サーバーが必要です。詳細は、「エンタープライズ・デプロイメントでのOracle Managed File Transferの構成」を参照してください。

Managed File Transferのシナリオでは、ロード・バランサによって、2つのOracle Traffic Directorインスタンス間でSFTPリクエストがルーティングされます。Oracle Traffic Directorインスタンスによって、Managed File Transfer管理対象サーバーで実行されているSFTP埋込みサーバーにリクエストがルーティングされます。一貫性を維持するため、ハードウェア・ロード・バランサ、Oracle File TransferおよびSFTPサーバーで使用されるポートは、7501です。

6.2 エンタープライズ・デプロイメントのファイアウォールとポートの構成

この項では、ファイアウォールでエンタープライズ・デプロイメント用に開く必要のあるポートを示します。

管理者は、様々なOracle Fusion Middleware製品およびサービスで使用されるポート番号を熟知している必要があります。これにより、同じポート番号が1つのホスト上の2つのサービスによって使用されないようにし、エンタープライズ・トポロジで正しいポートがファイアウォールで開かれるようにすることができます。

次の表に、トポロジ内のファイアウォールで開く必要のあるポートをリストします。

注意:

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

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

- FW0は、最も外側のファイアウォールを表します。

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

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

すべてのFusion Middlewareエンタープライズ・デプロイメントに共通のファイアウォール・ポート

タイプ

ファイアウォール

ポートとポートの範囲

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

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

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

ブラウザ・リクエスト

FW0

80

HTTP/ロード・バランサ

インバウンド

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

ブラウザ・リクエスト

FW0

443

HTTPS/ロード・バランサ

インバウンド

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

ブラウザ・リクエスト

FW1

80

HTTPS/ロード・バランサ

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

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

ブラウザ・リクエスト

FW1

443

HTTPS/ロード・バランサ

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

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

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

FW1

80

HTTPS/ロード・バランサ

アウトバウンド

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

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

FW1

443

HTTPS/ロード・バランサ

アウトバウンド

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

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

n/a

7777

HTTP

n/a

n/a

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

FW1

7001

HTTP/t3

インバウンド

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

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

FW1

OHS管理ポート(7779)

それぞれTCPとHTTP

アウトバウンド

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

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

n/a

n/a

n/a

n/a

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

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

FW1

7001

HTTP/管理サーバーとEnterprise Manager

t3

両方

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

データベース・アクセス

FW2

1521

SQL*Net

両方

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

デプロイメント用Coherence

n/a

8088

範囲: 8000から8090

n/a

n/a

Oracle Unified Directoryアクセス

FW2

389

636 (SSL)

LDAPまたはLDAP/ssl

インバウンド

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

Oracle Notification Server (ONS)

FW2

6200

ONS

両方

Gridlinkに必要。ONSサーバーは各データベース・サーバー上で稼働します。

*外部クライアントは、RMIまたはJMSでSOAサーバーに直接アクセスできます(JDeveloperデプロイメント、JMXモニタリングなど)。この場合、実装するセキュリティ・モデルによってFW0を開く必要がある場合とない場合があります。

Oracle SOA Suiteエンタープライズ・デプロイメントに固有のファイアウォール・ポート

タイプ

ファイアウォール

ポートとポートの範囲

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

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

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

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への接続は開いたまま維持されます。これによって、ユーザー・セッションの最長持続可能時間と同じ時間のタイムアウトを設定します。

MLLPリクエスト

FW0、FW1

9500 — 95nn

アプリケーション: MLLP/HC

インバウンド

タイムアウトは、予想されるMLLP転送サイズによって異なります。

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

ローカルおよび共有記憶域の要件、およびエンタープライズ・トポロジのインストール時および構成時における重要なディレクトリとファイルの場所の参照に使用される用語の理解が含まれます。

この章では、Oracle Fusion Middlewareエンタープライズ・デプロイメント用にファイル・システムを準備する方法について説明します。

- エンタープライズ・デプロイメント用のファイル・システムの準備の概要
この項では、エンタープライズ・デプロイメント用のファイル・システムの準備のプロセスの概要を示します。

- エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項
この項では、エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項の参照先を示します。

- エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解
この項の各ダイアグラムは、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントで推奨されるディレクトリ構造を示しています。

- このガイドで使用するファイル・システムとディレクトリ変数
この項では、このガイドで使用するファイル・システムとディレクトリ変数をリストし、説明します。

- エンタープライズ・デプロイメントのディレクトリの作成とマウントについて
この項では、エンタープライズ・デプロイメントで最上位ディレクトリを作成およびマウントする場合に従う必要のあるベスト・プラクティスを示します。

- エンタープライズ・デプロイメントの共有記憶域ボリュームの概要
この項では、エンタープライズ・デプロイメントに必要な共有記憶域ボリュームの概要を示します。

親トピック: エンタープライズ・デプロイメントの準備

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

この項では、エンタープライズ・デプロイメント用のファイル・システムの準備のプロセスの概要を示します。

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

この章を参照情報として使用すると、インストールおよび構成手順で使用されているディレクトリ変数について理解できます。

その他のディレクトリ・レイアウトも可能であり、サポートされていますが、このガイドで採用するモデルは、可用性を最大化するために設計されており、コンポーネントの最良の独立性と構成の対称性の両方を実現し、バックアップおよび障害時リカバリを容易にします。ドキュメントの残りの部分では、このディレクトリ構造およびディレクトリ用語を使用します。

7.2 エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項

この項では、エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項の参照先を示します。

この章で詳述する推奨事項を実行する前に、『高可用性ガイド』で共有記憶域の使用に関する推奨事項と一般情報を確認してください。

この章の推奨事項は、『高可用性ガイド』に記載されている概念とガイドラインに基づいています。

表7-1に、確認しておく必要がある項の一覧と、それらの概念がエンタープライズ・デプロイメントにどのように適用されるかを示します。

表7-1 『高可用性ガイド』の共有記憶域に関するリソース

『高可用性ガイド』の項

エンタープライズ・デプロイメントにおける意義

共有記憶域に関する前提条件

共有記憶域向けに最適化された、ディスク形式のガイドラインとハードウェア・デバイス要件について説明します。

バイナリ(Oracleホーム)ディレクトリ用の共有記憶域の使用

複数のホストから使用可能な共有記憶域デバイスにOracleホームを格納する際のオプションについて説明しています。

エンタープライズ・デプロイメントの用途では、別々のストレージ・ボリューム上に格納した冗長Oracleホームを使用することをお薦めします。

別のボリュームがない場合は、共有ディスク上の別のパーティションを使用して、アプリケーション層のホストに冗長Oracleホームを用意してください。

ドメイン構成ファイル用の共有記憶域の使用

ドメイン内の管理サーバーと管理対象サーバーに別々のドメイン・ホームを作成する概念について説明しています。

エンタープライズ・デプロイメントでは、管理サーバーのドメイン・ホームの場所をASERVER_HOME変数で表します。

JMSストアおよびJTAログ用の共有記憶域の要件

エンタープライズ・デプロイメント用のトランザクション・ログとJMSストアの場所を設定する手順について説明しています。

7.3 エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解

この項の各ダイアグラムは、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントで推奨されるディレクトリ構造を示しています。

ダイアグラムに示す各ディレクトリには、Oracle Fusion Middlewareインストーラによってディスク上にインストールされるバイナリ・ファイル、ドメイン構成プロセスを通じて生成されるドメインごとのファイルの他に、Oracle WebLogic Serverのpackコマンドとunpackコマンドによって様々なホスト・コンピュータに伝播されるドメイン構成ファイルが格納されます。

- 図7-1は、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントのインストールおよび構成が完了した時点で共有記憶域デバイスに作成されているディレクトリ構造を示しています。共有記憶域のディレクトリは、アプリケーション層のホスト・コンピュータからアクセス可能です。

- 図7-2は、Oracle Fusion Middlewareエンタープライズ・デプロイメントのインストールおよび構成が完了した時点で、標準的なアプリケーション層のホスト用のローカル記憶域デバイスに作成されているディレクトリ構造を示しています。特に、管理対象サーバーはアプリケーション層のホスト・コンピュータ用のローカル記憶域デバイスに格納されます。

- 図7-3は、Oracle Fusion Middlewareエンタープライズ・デプロイメントのインストールおよび構成が完了した時点で、標準的なWeb層のホスト用のローカル記憶域デバイスに作成されているディレクトリ構造を示しています。ソフトウェア・バイナリ(Oracleホーム内)は、Web層のホストごとのローカル記憶域デバイスにインストールされます。

注意:
図7-3では、Web層でOracle HTTP Serverを使用することを前提としています。ただし、Oracle Traffic Directorを使用して、HTTPや他のリクエストをアプリケーション層にルーティングすることもできます。詳細は、「エンタープライズ・デプロイメントでのOracle Traffic Directorについて」を参照してください。

該当する場合、ダイアグラムには、このガイドのインストールおよび構成手順でディレクトリ場所を表すために使用する標準変数も記載されています。

図7-1 エンタープライズ・デプロイメントで推奨される共有記憶域ディレクトリ構造

*詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

図7-2 エンタープライズ・デプロイメントで推奨されるアプリケーション層のホスト・コンピュータ向けローカル記憶域ディレクトリ構造

*詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

図7-3 エンタープライズ・デプロイメントで推奨されるWeb層のホスト・コンピュータ向けローカル記憶域ディレクトリ構造

7.4 このガイドで使用するファイル・システムとディレクトリ変数

この項では、このガイドで使用するファイル・システムとディレクトリ変数をリストし、説明します。

表7-2は、ファイル・システムのディレクトリとアプリケーション層のディレクトリの参照に使用されるディレクトリ変数を示しています。表7-3は、ファイル・システムのディレクトリおよびWeb層のディレクトリの参照に使用される変数を示しています。

共有記憶域を使用している場合にこれらのディレクトリをマウントする方法の詳細は、「エンタープライズ・デプロイメントのディレクトリの作成とマウントについて」を参照してください。

このガイド全体を通して、トポロジのインストールおよび構成に関する手順では、ここに示す変数を使用してディレクトリの場所を参照します。

この項に列挙する各ディレクトリに対してオペレーティング・システム変数を定義することもできます。システム変数をご使用のUNIXシェルで定義しておけば、このドキュメントの記載どおりに変数を使用できるので、変数を実環境における実際の値と対応付ける必要がなくなります。

注意:

ストレージ・デバイスを構成して推奨ディレクトリ構造を作成したら、実際のディレクトリ・パスをエンタープライズ・デプロイメント・ワークブックに記録してください。これらのアドレスは、後で各ホスト・コンピュータでIPアドレスを有効化するときに使用します。

詳細は、「エンタープライズ・デプロイメント・ワークブックの使用」を参照してください。

表7-2 アプリケーション層の主要なディレクトリ変数のサンプル値

ディレクトリ変数

説明

アプリケーション層のサンプル値

ORACLE_BASE

Oracle製品がインストールされるベース・ディレクトリ。

/u01/oracle

ORACLE_HOME

製品バイナリ用の読取り専用場所。アプリケーション層のホスト・コンピュータの場合は、共有ディスクに格納されます。

Oracleホームは、Oracle Fusion Middleware Infrastructureソフトウェアのインストール時に作成されます。

その後、その他のOracle Fusion Middleware製品を同じOracleホームにインストールできます。

/u01/oracle/products/fmw

ORACLE_COMMON_HOME

共通のユーティリティ、ライブラリおよび他の共有Oracle Fusion Middleware製品を格納する、Oracle Fusion MiddlewareのOracleホーム内のディレクトリ。

/u01/oracle/products/fmw/oracle_common

WL_HOME

Oracle WebLogic Serverソフトウェア・バイナリを格納するOracleホーム内のディレクトリ。

/u01/oracle/products/fmw/wlserver

PROD_DIR

インストールするOracle Fusion Middleware製品ごとの製品ディレクトリ。

/u01/oracle/products/fmw/prod_dir
製品は、エンタープライズ・デプロイメントに応じてsoa、wcc、biまたはその他の値になります。

EM_DIR

Oracle Enterprise Manager Fusion Middleware Controlソフトウェア・バイナリの格納に使用される製品ディレクトリ。

/u01/oracle/products/fmw/em

JAVA_HOME

サポートされているJava Development Kit (JDK)のインストール先。

/u01/oracle/products/jdk

SHARED_CONFIG_DIR

ドメイン構成、キーストア、ランタイム・アーティファクトおよびアプリケーション・デプロイメントを含む共有環境構成ファイルの共有親ディレクトリ

/u01/oracle/config

ASERVER_HOME

管理サーバーのドメイン・ホーム。共有ディスクにインストールされます。

/u01/oracle/config/domains/domain_name

この例では、domain_nameをWebLogic Serverドメインの名前に置き換えます。

MSERVER_HOME

管理対象サーバーのドメイン・ホーム。unpackコマンドによってアプリケーション層のホストごとのローカル・ディスクに作成されます。

/u02/oracle/config/domains/domain_name

APPLICATION_HOME

アプリケーションのホーム・ディレクトリ。アプリケーション層のすべてのホスト・コンピュータからアクセスできるように、共有ディスクにインストールされます。

/u01/oracle/config/applications
/domain_name

ORACLE_RUNTIME

このディレクトリには、JMSログやTLogなどのOracleランタイム・アーティファクトが含まれます。

一般にこのディレクトリは、ドメイン内のすべてのホストからアクセスできる別個の共有ファイル・システムとしてマウントします。

構成ウィザードの実行時または構成後タスクの実行時に、JMSストアまたはtlog永続ストアの場所を認識している場合、ドメイン名、クラスタ名およびディレクトリの目的で修飾されたこのディレクトリを使用できます。

例:

ORACLE_RUNTIME/cluster_name/jms

/u01/oracle/runtime/

NM_HOME

マシンごとのノード・マネージャ起動スクリプトおよび構成ファイルによって使用されるディレクトリ。

注意:

このディレクトリは、マシンごとのノード・マネージャ構成を使用している場合にのみ必要です。

詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

/u02/oracle/config/node_manager

DEPLOY_PLAN_HOME

デプロイメント・プランのディレクトリ。アプリケーション・デプロイメント・プラン用のデフォルトの場所として使用されます。

注意:

このディレクトリは、アプリケーション層にカスタム・アプリケーションをデプロイする場合にのみ必要です。

/u01/oracle/config/dp

KEYSTORE_HOME

カスタム証明書およびキーストアの共有の場所。

/u01/oracle/config/keystores

表7-3 Web層の主要なディレクトリ変数のサンプル値

ディレクトリ変数

説明

Web層のサンプル値

WEB_ORACLE_HOME

Webサーバー製品バイナリ用の読取り専用場所。Web層のホスト・コンピュータの場合、このディレクトリはローカル・ディスクに格納されます。

Oracleホームは、Web層ホストにOracle HTTP ServerまたはOracle Traffic Directorソフトウェアをインストールすると作成されます。

このディレクトリは、Oracle HTTP ServerをWebサーバーとして使用している場合、OHS_ORACLE_HOMEと呼ばれることもあります。

/u02/oracle/products/fmw

ORACLE_COMMON_HOME

共通のユーティリティ、ライブラリおよび他の共有Oracle Fusion Middleware製品を格納する、Oracle HTTP ServerのOracleホーム内のディレクトリ。

/u02/oracle/products/fmw
/oracle_common

WL_HOME

Oracle WebLogic Serverソフトウェア・バイナリを格納するOracleホーム内のディレクトリ。

/u02/oracle/products/fmw/wlserver

PROD_DIR

インストールするOracle Fusion Middleware製品ごとの製品ディレクトリ。

/u02/oracle/products/fmw/ohs

JAVA_HOME

サポートされているJava Development Kit (JDK)のインストール先。

/u02/oracle/products/jdk

WEB_DOMAIN_HOME

各Web層ホストのローカル・ディスクにOracle HTTP ServerまたはOracle Traffic Directorをインストールする際に作成される、スタンドアロンWebサーバー・ドメインのドメイン・ホーム。

このディレクトリは、Oracle HTTP ServerをWebサーバーとして使用している場合、OHS_DOMAIN_HOMEと呼ばれることもあります。

/u02/oracle/config/domains/domain_name

OHS_CONFIG_DIR

Oracle HTTP ServerをWebサーバーとして使用している場合に、各WebホストでOracle HTTP Server構成ファイル(httpd.conf、moduleconf/*.confなど)を編集する場所。

このディレクトリは、OHSステージング・ディレクトリとも呼ばれます。ここで行った変更は、OHS実行時ディレクトリに伝播されます。

詳細は、『Oracle HTTP Server管理者ガイド』のステージング・ディレクトリおよび実行時構成ディレクトリに関する項を参照してください。

/u02/oracle/config/domains
/domain_name/config/fmwconfig
/components/OHS
/instance_name

7.5 エンタープライズ・デプロイメントのディレクトリの作成とマウントについて

この項では、エンタープライズ・デプロイメントで最上位ディレクトリを作成およびマウントする場合に従う必要のあるベスト・プラクティスを示します。

最上位ディレクトリを作成およびマウントするときには、次のベスト・プラクティスに注意してください。

- アプリケーション層については、SOAHOST2にマウントされる別の共有記憶域ボリュームまたは別のパーティションにOracleホーム(ソフトウェア・バイナリの格納先)をインストールします。SOAHOST2上のバイナリへのディレクトリ・パスが、SOAHOST1上のディレクトリ・パスと同一であることを確認してください。
例:

/u01/oracle/products/fmw/

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

- このエンタープライズ・デプロイメント・ガイドでは、Oracle Web Tierソフトウェアがローカル・ディスクにインストールされることを想定しています。
Web層のインストールは通常、WEBHOSTノードのローカル記憶域で実行されます。共有記憶域を使用している場合、Oracle Web層バイナリを共有ディスクにインストール(およびOracle HTTP Serverインスタンスを作成)できます。ただし、これを行う場合、共有ディスクをアプリケーション層で使用される共有ディスクと区別する必要があり、層間での記憶域デバイスへのアクセスに対する適切なセキュリティ制限を検討する必要があります。

アプリケーション層サーバー(SOAHOST1およびSOAHOST2)の場合と同様に、両方のコンピュータで同じディレクトリ・パスを使用します。

例:

/u02/oracle/products/fmw/

- Oracle Service Bus (OSB)を独自のドメイン内に(ただし、Oracle SOA Suiteと同じホスト上に)構成する場合、OSBバイナリ用の追加のOracleホーム(ORACLE_HOME)を作成し、そのOracleホームをSOAのOracleホームとは別個にマウントする必要があります。
たとえば、OSB_ORACLE_HOMEは次のようにマウントされます。

/u03/oracle/products/fmw/osb

- 同様に、OSBを独自のドメイン内に(ただし、Oracle SOA Suiteと同じホスト上に)構成する場合、ドメイン・ディレクトリをOracle SOA Suiteドメイン・ディレクトリとは別個にマウントする必要があります。
たとえば、OSB管理サーバーのドメイン・ディレクトリは次のようにマウントされます。

/u03/oracle/config/domains/osb_domain_name

また、OSB管理対象サーバーのドメイン・ディレクトリは次のようにマウントされます。

u04/oracle/config/domains/osb_domain_name

- Oracle Managed File Transfer(MFT)を独自のドメイン内に(ただし、Oracle SOA Suiteと同じホスト上に)構成する場合、MFTバイナリ用の追加のOracleホーム(ORACLE_HOME)を作成し、そのOracleホームをSOAのOracleホームとは別個にマウントする必要があります。MFTをOracle SOA Suiteと同じドメインにインストールすることはできません。
たとえば、MFT_ORACLE_HOMEは次のようにマウントされます。

/u03/oracle/products/fmw/mft

- 同様に、MFTをOracle SOA Suiteと同じホスト上に構成する場合、ドメイン・ディレクトリをOracle SOA Suiteドメイン・ディレクトリとは別個にマウントする必要があります。
たとえば、MFT管理サーバーのドメイン・ディレクトリは次のようにマウントされます。

/u03/oracle/config/domains/mft_domain_name

また、MFT管理対象サーバーのドメイン・ディレクトリは次のようにマウントされます。

u04/oracle/config/domains/mft_domain_name

7.6 エンタープライズ・デプロイメントの共有記憶域ボリュームの概要

この項では、エンタープライズ・デプロイメントに必要な共有記憶域ボリュームの概要を示します。

次の表に、一般的なOracle Fusion Middlewareエンタープライズ・デプロイメントでの共有ボリュームおよびその目的をまとめます。

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

共有記憶域のボリューム

マウント先ホスト

マウント・ディレクトリ

説明および目的

NFSボリューム1

SOAHOST1

/u01/oracle/products/

SOAHOST1によって使用される製品バイナリのローカル記憶域。Oracleホーム・ディレクトリおよび製品ディレクトリがインストールされている場所です。

NFSボリューム2

SOAHOST2

/u01/oracle/products/

SOAHOST2によって使用される製品バイナリのローカル記憶域。Oracleホーム・ディレクトリおよび製品ディレクトリがインストールされている場所です。

NFSボリューム3

SOAHOST1 SOAHOST2

/u01/oracle/config/

すべてのホストにマウントされる管理サーバー・ドメイン。最初はSOAHOST1によって使用されますが、任意のホストにフェイルオーバーできます。

NFSボリューム4

SOAHOST1 SOAHOST2

/u01/oracle/runtime/

すべてのホストにマウントされるランタイム・アーティファクト・ディレクトリで、JMSログ、ブログなどの実行時アーティファクトおよび必要なクラスタ依存共有ファイルが含まれます。

NFSボリューム5

SOAHOST1

/u02/oracle/config/

プライベート管理対象サーバー・ドメイン・ディレクトリが共有記憶域にある場合に、SOAHOST1によって使用される管理対象サーバー・ドメイン・ディレクトリのローカル記憶域。

NFSボリューム6

SOAHOST2

/u02/oracle/config/

プライベート管理対象サーバー・ドメイン・ディレクトリが共有記憶域にある場合に、SOAHOST2によって使用される管理対象サーバー・ドメイン・ディレクトリのローカル記憶域。

NFSボリューム7

WEBHOST1

/u02/oracle/

プライベート管理対象サーバー・ドメイン・ディレクトリが共有記憶域にある場合に、WEBHOST1によって使用されるOracle HTTP Serverソフトウェア・バイナリ(Oracleホーム)およびドメイン構成ファイルのローカル記憶域。

NFSボリューム8

WEBHOST2

/u02/oracle/

プライベート管理対象サーバー・ドメイン・ディレクトリが共有記憶域にある場合に、WEBHOST2によって使用されるOracle HTTP Serverソフトウェア・バイナリ(Oracleホーム)およびドメイン構成ファイルのローカル記憶域。

8 エンタープライズ・デプロイメント用のホスト・コンピュータの準備

必要な共有記憶域システムをホストにマウントする方法や、各ホストで必要な仮想IPアドレスを有効化する方法について説明します。

この章では、エンタープライズ・デプロイメントをホストする各コンピュータまたはサーバーから実行する必要があるタスクについて説明します。

- 各ホストの最小ハードウェア要件の検証
この項では、各ホストの最小ハードウェア要件に関する情報を示します。

- Linuxオペレーティング・システムの要件の検証
エンタープライズ・デプロイメント用の一般的なLinuxオペレーティング・システムの設定については、この項を確認してください。

- オペレーティング・システムのユーザーおよびグループの構成
この項のリストでは、エンタープライズ・デプロイメントをホストする各コンピュータで定義するユーザーおよびグループを示します。

- Unicodeサポートの有効化
この項では、Unicodeのサポートの有効化について説明します。

- 各ホストへの必要な共有ファイル・システムのマウント
この項では、各ホストでの必要な共有ファイル・システムのマウントについて説明します。

- 各ホストでの必要な仮想IPアドレスの有効化
この項では、各ホストでの必要な仮想IPアドレスの有効化の手順を示します。

親トピック: エンタープライズ・デプロイメントの準備

8.1 各ホストの最小ハードウェア要件の検証

この項では、各ホストの最小ハードウェア要件に関する情報を示します。

エンタープライズ・デプロイメントに必要なハードウェアを取得したら、各ホスト・コンピュータにログインし、「エンタープライズ・デプロイメント・トポロジ用のハードウェアおよびソフトウェアの要件」に示すシステム要件を確認します。

Oracle Exalogicなどの仮想サーバー環境にデプロイしている場合、仮想サーバーそれぞれが最小要件を満たしていることを確認します。

十分なローカル・ディスク記憶域があり、共有記憶域が「エンタープライズ・デプロイメント用のファイル・システムの準備」で説明されているように構成されていることを確認します。

十分なスワップ領域および一時領域を確保します。具体的には、次のとおりです。

- スワップ領域: システムに500 MB以上ある必要があります。

- 一時領域: /tmpに500 MB以上の空き領域がある必要があります。

8.2 Linuxオペレーティング・システムの要件の検証

エンタープライズ・デプロイメント用の一般的なLinuxオペレーティング・システムの設定については、この項を確認してください。

ホスト・コンピュータが最小オペレーティング・システム要件を満たしていることを確認するには、動作保証済のオペレーティング・システムがインストールされていることと、そのオペレーティング・システムに必要なパッチがすべて適用されていることを確認してください。

さらに、エンタープライズ・デプロイメント用の一般的なLinuxオペレーティング・システムの設定について、次の項を確認してください。

- Linuxのカーネル・パラメータの設定

- UNIXシステムでのオープン・ファイル制限とプロセス数の設定

- DNSまたはホスト・ファイルでのIPアドレスとホスト名の確認

8.2.1 Linuxのカーネル・パラメータの設定

下に示すカーネル・パラメータおよびシェル制限の値は、単なる推奨値です。これらの値をチューニングしてシステムのパフォーマンスを最適化することをお薦めします。カーネル・パラメータの調整については、ご使用のオペレーティング・システムのマニュアルを参照してください。

カーネル・パラメータの値は、トポロジのすべてのノードで表の最小値に設定する必要があります。

次の表の値は、現行のLinuxの推奨値です。Linuxおよびその他のオペレーティング・システムの最新の推奨値は、Oracle Fusion Middlewareのシステム要件と仕様を参照してください。

データベースをホストにデプロイしている場合、追加のカーネル・パラメータを変更する必要がある場合があります。ご使用のプラットフォームの12c (12.2.1) Oracle Grid Infrastructureインストレーション・ガイドを参照してください。

表8-1 UNIXのカーネル・パラメータ

パラメータ

値

kernel.sem

256 32000 100 142

kernel.shmmax

4294967295

これらのパラメータを設定するには:

1. rootとしてログインし、ファイル/etc/sysctl.confのエントリを追加または修正します。

2. ファイルを保存します。

3. 次のコマンドを発行して変更をアクティブ化します。
/sbin/sysctl -p

8.2.2 UNIXシステムでのオープン・ファイル制限とプロセス数の設定

UNIXオペレーティング・システムでは、オープン・ファイル制限は重要なシステム設定です。ホスト・コンピュータ上で動作するソフトウェアのパフォーマンス全体に影響を及ぼす可能性があります。

Oracle Fusion Middlewareエンタープライズ・デプロイメントに適したオープン・ファイル制限の設定のための指針として、「 ホスト・コンピュータのハードウェア要件」を参照してください。

注意:

次の例はLinuxオペレーティング・システム用です。オペレーティング・システムのドキュメントを確認して、システムで使用するコマンドを判別します。

詳細は、次の項を参照してください。

- 現在開いているファイル数の表示

- オペレーティング・システムのオープン・ファイルおよびプロセス制限の設定

8.2.2.1 現在開いているファイル数の表示

次のコマンドでオープンになっているファイル数を確認できます。

/usr/sbin/lsof | wc -l

オープン・ファイル制限を確認するには、次のコマンドを使用します。

Cシェル:

limit descriptors

Bash:

ulimit -n

8.2.2.2 オペレーティング・システムのオープン・ファイルおよびプロセス制限の設定

オープン・ファイル制限の値を変更する手順:

1. rootとしてログインして、次のファイルを編集します。

/etc/security/limits.conf

2. limits.confファイルに次の行を追加します。(ここに示す値は例にすぎません):

* soft  nofile  4096
* hard  nofile  65536
* soft  nproc   2047
* hard  nproc   16384

nofilesの値はオープン・ファイル制限を表します。nproc値はプロセス制限を表します。

3. 変更内容を保存して、limits.confファイルを閉じます。

4. ホスト・コンピュータを再起動します。

8.2.3 DNSまたはホスト・ファイルでのIPアドレスとホスト名の確認

Oracleソフトウェアのインストールを開始する前に、ホストのIPアドレス、完全修飾ホスト名および短縮名がすべてDNSサーバーに登録されていることを確認します。または、ローカルhostsファイルを使用して、次のようなエントリを追加することもできます。

IP_Address Fully_Qualified_Name Short_Name

例:

10.229.188.205  host1.example.com  host1

8.3 オペレーティング・システムのユーザーおよびグループの構成

この項のリストでは、エンタープライズ・デプロイメントをホストする各コンピュータで定義するユーザーおよびグループを示します。

グループ

各ノードに次のグループを作成する必要があります。

- oinstall

- dba

ユーザー

各ノードに次のユーザーを作成する必要があります。

- nobody: 権限のないユーザー。

- oracle: Oracleソフトウェアの所有者。別の名前も使用できます。このアカウントのプライマリ・グループはoinstallにする必要があります。このアカウントは、dbaグループにも属している必要があります。

注意:

- グループoinstallは、Oracleソフトウェアが使用する共有記憶域およびローカル記憶域のすべてのファイル・システムに対する書込み権限を持っている必要があります。

- 各グループは、ノードごとに同じグループIDを持っている必要があります。

- 各ユーザーは、ノードごとに同じユーザーIDを持っている必要があります。

8.4 Unicodeサポートの有効化

この項では、Unicodeのサポートの有効化について説明します。

オペレーティング・システムの構成がOracle Fusion Middleware製品でサポートされる文字の動作に影響を与えることがあります。

UNIXオペレーティング・システムでは、LANGとLC_ALLの各環境変数をUTF-8文字セットを使用したロケールに設定し、Unicodeサポートを有効化することを強くお薦めします。これにより、Unicodeのすべての文字が処理できるようになります。たとえば、Oracle SOA SuiteテクノロジはUnicodeに基づいています。

オペレーティング・システムがUTF-8以外のエンコードを使用するように構成されている場合、Oracle SOA Suiteコンポーネントが予期しない動作をする可能性があります。たとえば、ASCII以外のファイル名の場合は、ファイルにアクセスできず、エラーが発生する可能性があります。オペレーティング・システムの制約によって発生する問題はサポート対象外となります。

8.5 各ホストへの必要な共有ファイル・システムのマウント

この項では、各ホストでの必要な共有ファイル・システムのマウントについて説明します。

「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」の説明に従って構成された共有記憶域が、それを使用するホスト上で使用可能になっている必要があります。

エンタープライズ・デプロイメントでは、ハードウェア記憶域ファイラが存在することと、それがデプロイメント用に取得した各ホスト・コンピュータに接続されて使用可能になっていることが前提とされています。

共有記憶域を、アクセスが必要なすべてのサーバーにマウントする必要があります。

各ホストでは、適切な権限をNetwork Attached Storage (NAS)またはStorage Area Network (SAN)内で設定し、共有記憶域への書込みを可能にする必要があります。

共有記憶域のマウントについては、組織のベスト・プラクティスに従ってください。この項では、NFS記憶域を使用してLinuxでこれを行う方法の例を示します。

共有記憶域の場所を作成してマウントし、SOAHOST1とSOAHOST2が2つの別々のボリュームへのバイナリ・インストールである場合に、それらが同じ場所を参照できるようにする必要があります。

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

次のコマンドを使用して、共有記憶域をNAS記憶域デバイスからLinuxホストにマウントします。別のタイプの記憶域デバイスまたはオペレーティング・システムを使用している場合、これを行う方法の詳細は製造元のドキュメントを参照してください。

注意:

共有記憶域のファイル・システムの作成に使用されるユーザー・アカウントは、これらのファイルに対する読取り、書込みおよび実行権限を持ちます。オペレーティング・システム・グループにおける他のユーザーは、ファイルの読取りや実行は可能ですが、書込み権限はありません。

インストールと構成の権限の詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストレーション・ユーザーの選択に関する項を参照してください。

次の例では、nasfilerは共有記憶域ファイラを表します。これらは単なる例であることに注意してください。通常、これらの共有記憶域場所のマウントは、UNIXシステム上の/etc/fstabsファイルを使用して行う必要があります。これにより、再起動しても、これらのデバイスのマウントが維持されます。詳細は、オペレーティング・システムのドキュメントを参照してください。

1. 「エンタープライズ・デプロイメントの共有記憶域ボリュームの概要」に説明されているとおりにSOAHOST1にマウント・ディレクトリを作成してから、共有記憶域をマウントします。例:

mount -t nfs nasfiler:VOL1/oracle/products/ /u01/oracle/products/

2. VOL2を使用してSOAHOST2で手順を繰り返します。

共有記憶域の構成の検証

構成した共有記憶域にテスト・ファイルを作成し、新しくマウントしたディレクトリでファイルの読取りおよび書込みができることを確認します。

例:

$ cd newly mounted directory
$ touch testfile

所有者と権限が正しいことを確認します。

$ ls -l testfile

ファイルを削除します。

$ rm testfile

注意:

共有記憶域には、NASデバイスまたはSANデバイスを使用できます。次は、NASデバイスの記憶域をSOAHOST1から作成する例を示しています。オプションは、具体的な記憶域デバイスに応じて異なる場合があります。

mount -t nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768 nasfiler:VOL1/Oracle /u01/oracle

使用する環境に適切なオプションについては、ストレージ・ベンダーとマシン管理者と相談してください。

8.6 各ホストでの必要な仮想IPアドレスの有効化

この項では、各ホストでの必要な仮想IPアドレスの有効化の手順を示します。

エンタープライズ・デプロイメント用に各ホストを準備するには、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」で説明されている仮想IP (VIP)アドレスを有効化する必要があります。

すでにVIPアドレスおよびホスト名を予約済であり、ネットワーク管理者がそれらを有効化していることを前提とします。その後、適切なホストでVIPを有効化できます。

エンタープライズ・トポロジで使用する仮想IPアドレスは、サーバー全体の移行(選択した管理対象サーバーおよびクラスタの場合)または手動フェイルオーバー(管理サーバーの場合)によって管理されるため、永続化されません。

各ホストでこのVIPアドレスを有効にするには、次のコマンドを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

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

この章では、Oracle SOA Suiteエンタープライズ・デプロイメント用のデータベースの準備手順について説明します。

この章では、データベース要件、データベース・サービスの作成、およびデータベース・バックアップ戦略に関する情報を提供します。

- エンタープライズ・デプロイメント用のデータベースの準備の概要
この項では、Oracle Fusion Middlewareエンタープライズ・デプロイメントの一環として、サポートされているデータベースを構成する方法について説明します。

- データベース要件について
データベースが次の各項に記載されている要件を満たしていることを確認します。

- データベース・サービスの作成
複数のOracle Fusion Middleware製品が同じデータベースを共有する場合は、個別の専用のデータベース・サービスに接続するように、各製品を構成する必要があります。

- Oracleデータベースでのラージ・オブジェクト(LOB)に対するSecureFilesの使用
Oracle Database 11gリリース1以降、新しいLOB記憶域アーキテクチャであるSecureFilesが導入されました。Oracle Fusion Middlewareスキーマ、特にOracle SOA SuiteスキーマにはSecureFilesの使用をお薦めします。

- データベース・バックアップ戦略について
この項では、データベース・バックアップ戦略の必要性について簡単に説明します。

- Oracle SOA Suiteへのデータベース増分管理戦略の導入
Oracle SOA Suiteエンタープライズ・デプロイメントでは、Oracle SOA Suiteデータベースの増分管理など、データベース管理者にかかわる課題がいくつか存在します。データベース管理の重要性を軽視すると、データベースが本番環境に移行したときに問題が発生する可能性があります。

親トピック: エンタープライズ・デプロイメントの準備

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

この項では、Oracle Fusion Middlewareエンタープライズ・デプロイメントの一環として、サポートされているデータベースを構成する方法について説明します。

ほとんどのOracle Fusion Middleware製品では、サポートされているデータベースに特定の一連のスキーマがインストールされている必要があります。これらのスキーマは、Oracle Fusion Middlewareのリポジトリ作成ユーティリティ(RCU)を使用してインストールします。

エンタープライズ・デプロイメントでは、Oracle Fusion Middleware製品スキーマに高可用性Real Application Clusters (Oracle RAC)データベースをお薦めします。

9.2 データベース要件について

データベースが次の各項に記載されている要件を満たしていることを確認します。

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

- その他のデータベース・ソフトウェア要件

- エンタープライズ・デプロイメントのPROCESSESデータベース初期化パラメータの設定

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

次の情報を利用して、Oracle Fusion Middlewareの各リリースでサポートされているデータベース、および現在稼働中のOracleデータベースのバージョンを確認してください。

- 動作保証済のデータベースの全リストは、Oracle Fusion Middlewareのサポートされるシステム構成のページを参照してください。

- データベースのリリースを確認するには、PRODUCT_COMPONENT_VERSIONビューに問い合せます。

SQL> SELECT VERSION FROM SYS.PRODUCT_COMPONENT_VERSION WHERE
PRODUCT LIKE 'Oracle%';

Oracle Fusion Middlewareでは、データベースがAL32UTF8文字セットに対応している必要があります。データベースの文字セットの選択に関する情報は、データベースのドキュメントを確認してください。

エンタープライズ・デプロイメントでは、Oracle RACデータベースへの接続にGridLinkデータ・ソースを使用することをお薦めします。

注意:

GridLinkデータ・ソースおよびSCANの使用方法の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のアクティブなGridLinkデータ・ソースの使用に関する項を参照してください。

9.2.2 その他のデータベース・ソフトウェア要件

エンタープライズ・トポロジでは、RACデータベースの2つのインスタンスをホストする2つのデータベース・ホスト・コンピュータがデータ層にあります。これらのホストをDBHOST1、DBHOST2と呼びます。

エンタープライズ・トポロジをインストールまたは構成する前に、次のソフトウェアがDBHOST1とDBHOST2にインストール済であり使用可能であることを確認する必要があります。

- Oracle Clusterware
詳細は、Oracle Grid Infrastructureインストレーション・ガイド(Linux版)を参照してください。

- Oracle Real Application Cluster
詳細は、Oracle Real Application Clustersインストレーション・ガイド(LinuxおよびUNIX版)を参照してください。

- Oracle RACデータベース・インスタンス間の時間同期
データベース・インスタンスのクロックは、サーバー移行で構成されたFusion Middlewareクラスタ内のサーバーで使用されている場合、同期化されている必要があります。

- 自動ストレージ管理(オプション)
詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

9.2.3 エンタープライズ・デプロイメントのPROCESSESデータベース初期化パラメータの設定

表9-1に、いくつかの標準的なOracle SOA Suiteエンタープライズ・トポロジと、各トポロジでPROCESSES初期化パラメータの設定時に使用する必要がある値を示します。

この情報は、Oracle RACデータベースをエンタープライズ・デプロイメント用に構成するときの指針として利用してください。

表9-1 必要な初期化パラメータ

構成

パラメータ

必要な値

パラメータ・クラス

SOA

PROCESSES

300以上

静的

BAM

PROCESSES

100以上

静的

SOAおよびBAM

PROCESSES

400以上

静的

SOAおよびOSB

PROCESSES

800以上

静的

SQL*Plusを使用して初期化パラメータの値をチェックするには、SHOW PARAMETERコマンドを次のように使用します。

1. SYSユーザーとして、SHOW PARAMETERコマンドを次のように発行します。

SQL> SHOW PARAMETER processes;

2. 次のコマンドを使用して初期化パラメータを設定します。

SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE;

3. データベースを再起動します。

パラメータ値の変更に使用する方法は、パラメータが静的であるか動的であるかと、データベースがパラメータ・ファイルとサーバー・パラメータ・ファイルのどちらを使用するかによって異なります。

注意:

パラメータ・ファイル、サーバー・パラメータ・ファイル、およびパラメータ値の変更方法の詳細は、Oracle Database管理者ガイドを参照してください。

9.3 データベース・サービスの作成

複数のOracle Fusion Middleware製品が同じデータベースを共有する場合は、個別の専用のデータベース・サービスに接続するように、各製品を構成する必要があります。

注意:

この項に示す手順は、Oracle Database 12c (12.1)リリースを対象としています。これ以外のサポートされているデータベースをご使用の場合は、該当するドキュメント・ライブラリで最新のリリース別の情報を参照してください。

サービスを使用したOracleデータベースへの接続の詳細は、Real Application Clusters管理およびデプロイメント・ガイドの動的なデータベース・サービスを使用したOracleデータベースへの接続に関する項を参照してください。

また、データベース・サービスはデフォルトのデータベース・サービスとは別のものにしてください。Oracle Database 12cデータベースのデータベース・サービスを作成および管理する完全な手順は、Oracle Real Application Clusters管理およびデプロイメント・ガイドの動的データベース・サービスによる自動ワークロード管理の概要に関する項を参照してください。

実行時接続ロード・バランシングでは、ロード・バランシングが有効になっている各サービスのサービス・レベルの目標を使用してOracle RACロード・バランシング・アドバイザを構成する必要があります。

SERVICE_TIMEまたはTHROUGHPUTについて、Oracle RACロード・バランシング・アドバイザを構成できます。接続ロード・バランシングの目標をSHORTに設定します。

srvctlユーティリティを使用してOracle Databaseサービスを作成および変更します。

データベース・サービスを作成および変更する手順:

1. SQL*Plusにログインして、サービスを作成します。

sqlplus "sys/password as sysdba"

SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE
(SERVICE_NAME => 'soaedg.example.com',
NETWORK_NAME => 'soaedg.example.com'
);

注意:

Oracle RACデータベースのサービス名には小文字を使用し、続けてドメイン名を指定します。例:

soaedg.example.com

注意:

EXECUTE DBMS_SERVICEコマンドを1行で入力します。

DBMS_SERVICEパッケージの詳細は、Oracle Database PL/SQLパッケージおよびタイプのリファレンスを参照してください。

2. サービスをデータベースに追加し、srvctlを使用してインスタンスに割り当てます。

srvctl add service -d soadb -s soaedg.example.com -r soadb1,soadb2

3. サービスを起動します。

srvctl start service -d soadb -s soaedg.example.com

注意:

SRVCTLを使用したデータベース・サービスの作成および管理の完全な手順については、Real Application Clusters管理およびデプロイメント・ガイドのSRVCTLでのサービスの作成に関する説明を参照してください。

4. 実行時接続ロード・バランシングにロード・バランシング・アドバイザおよび適切なサービス・レベルの目標を使用するように、サービスを変更します。

具体的には、Oracle Database 12c Oracle Real Application Clusters管理およびデプロイメント・ガイドの次のリソースを使用して、サービス・レベル目標SERVICE_TIMEおよびTHROUGHPUTを設定します。

- 「ロード・バランシング・アドバイザの概要」

- 「ロード・バランシング・アドバイザを使用する環境の構成」

9.4 Oracleデータベースでのラージ・オブジェクト(LOB)に対するSecureFilesの使用

Oracle Database 11gリリース1以降、新しいLOB記憶域アーキテクチャであるSecureFilesが導入されました。Oracle Fusion Middlewareスキーマ、特にOracle SOA SuiteスキーマにはSecureFilesの使用をお薦めします。

詳細は、Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイドのOracle SecureFiles LOBの使用に関する項を参照してください。

Oracle 12cデータベースでは、SecureFilesを使用するためのデフォルト設定はPREFERREDです。これは、LOBまたは親LOB (LOBがパーティションまたはサブパーティション内にある場合)でBasicFiles LOBが明示的に指定されていなければ、データベースがSecureFiles LOBの作成を試みることを意味します。Oracle Fusion MiddlewareスキーマではBasicFilesを明示的に指定しません。したがって、Oracle 12cデータベースがインストールされている場合、Oracle Fusion MiddlewareのLOBはデフォルトでSecureFilesになります。

Oracle 11gデータベースでは、db_securefileシステム・パラメータによってSecureFiles使用ポリシーが制御されます。このパラメータは動的に変更できます。SecureFilesを使用するには次のオプションがあります。

- PERMITTED: SecureFilesの作成を許可します(これがdb_securefileのデフォルト設定です。デフォルトの格納方式ではBasicFilesが使用されます)

- FORCE: すべての(新規) LOBをSecureFilesとして作成します

- ALWAYS: LOBをSecureFilesとして作成しようと試みますが、作成できない場合(ASSMが無効の場合)はBasicFilesに戻します

この他にも、db_securefileパラメータには次の値があります。

- IGNORE: SecureFilesを作成する試行を無視します

- NEVER: 新しいSecureFilesの作成を許可しません

Oracle 11gデータベースの場合、リポジトリ作成ユーティリティ(RCU)でOracle Fusion Middlewareスキーマを作成する前に、db_securefileパラメータをFORCEに設定することをお薦めします。

SecureFilesセグメントは、表領域を自動セグメント領域管理(ASSM)によって管理する必要があります。つまり、ASSMが無効になっていると、SecureFilesでのLOB作成が失敗します。ただし、Oracle Fusion Middlewareの表領域は、デフォルトではASSMが有効な状態で作成されます。したがって、デフォルトの構成では、Oracle Fusion Middlewareスキーマに対してSecureFilesを有効にするために何かを変更する必要はありません。

9.5 データベース・バックアップ戦略について

この項では、データベース・バックアップ戦略の必要性について簡単に説明します。

エンタープライズ・デプロイメントのインストールおよび構成の重要な点として、現在の環境をバックアップすることをお薦めします。たとえば、製品ソフトウェアをインストールし、特定のOracle Fusion Middleware製品のスキーマを作成した後で、データベース・バックアップを実行してください。バックアップを実行すれば、後の構成手順で何か問題が発生しても、すばやくリカバリを実行できます。

この目的のために独自のデータベース・バックアップ戦略を使用することも、オペレーティング・システムのツールやRMANを使用して単純にバックアップすることもできます。

特に、Oracle Automatic Storage Managementを使用してデータベースを作成した場合は、Oracle Recovery Managerの使用をお薦めします。可能な場合、オペレーティング・システムのツール(tarなど)を使用してコールド・バックアップも実行できます。

9.6 Oracle SOA Suiteへのデータベース増分管理戦略の導入

Oracle SOA Suiteエンタープライズ・デプロイメントでは、Oracle SOA Suiteデータベースの増分管理など、データベース管理者にかかわる課題がいくつか存在します。データベース管理の重要性を軽視すると、データベースが本番環境に移行したときに問題が発生する可能性があります。

容量、テストおよび監視のための適切な戦略および計画の決定方法については、Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理のデータベースの増大に対する計画の概要に関する項を参照してください。

第III部 エンタープライズ・デプロイメントの構成

ここでは、次の内容について説明します。

- エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成
次の各項では、エンタープライズ・デプロイメントの開始点として使用できる初期ドメインのインストールおよび構成方法について説明します。このガイドの後の章では、デプロイしようとしているエンタープライズ・トポロジを構成する各種製品およびコンポーネントを含めることで、この初期ドメインを拡張する方法について説明します。

- エンタープライズ・デプロイメント用のOracle HTTP Serverの構成
Web層を構成する場合、Oracle HTTP ServerまたはOracle Traffic Directorの使用を選択できます。Oracle HTTP Serverを選択して使用する場合、各Web層ホストにOracle HTTP Serverをインストールし、各ホストでOracle HTTPスタンドアロン・ドメインを構成する必要があります。

- Oracle Traffic Directorを含めるドメインの拡張
Web層を構成する場合、リクエストをアプリケーション層にルーティングするように、Oracle HTTP ServerではなくOracle Traffic Directorを使用できます。Oracle Traffic Directorの構成手順は、Oracle HTTP Serverの構成手順とは異なります。Oracle Traffic Directorを使用する場合、Web層ホストとアプリケーション層ホストの両方にOracle Traffic Directorをインストールする必要があります。その後、Oracle Traffic Directorを含めるようにエンタープライズ・デプロイメント・ドメインを拡張します。

- Oracle SOA Suiteを含めるドメインの拡張
次の各項では、Oracle SOA Suiteソフトウェアを含めることでエンタープライズ・デプロイメント・ドメインを拡張する方法について説明します。

- トポロジへのOracle Service Busの追加
次の各項では、エンタープライズ・デプロイメント・トポロジにOracle Service Bus (OSB)を追加する手順について説明します。

- Business Process Managementを含めるドメインの拡張
次の各項では、Business Process Managementを追加するためのドメイン拡張の手順を説明します。

- Oracle Enterprise Schedulerを含めるドメインの拡張
次の各項では、Oracle Enterprise Schedulerソフトウェアを含めることでエンタープライズ・デプロイメント・ドメインを拡張する方法について説明します。

- Business Activity Monitoringを含めるドメインの拡張
次の各項では、Oracle Business Activity Monitoringを追加するためのドメイン拡張の方法について説明します。

- Oracle B2Bを含めるドメインの拡張
この章では、Oracle B2Bを追加するためのドメイン拡張の手順を説明します。

- Oracle SOA Suite for Healthcare Integrationを含めるドメインの拡張
次の各項では、Oracle SOA Suite for healthcare integration (Oracle Healthcare)を追加するためのドメイン拡張の手順を説明します。

- エンタープライズ・デプロイメントでのOracle Managed File Transferの構成
次の各項では、エンタープライズ・デプロイメントにOracle Managed File Transferを追加する手順について説明します。

10 エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成

次の各項では、エンタープライズ・デプロイメントの開始点として使用できる初期ドメインのインストールおよび構成方法について説明します。このガイドの後の章では、デプロイしようとしているエンタープライズ・トポロジを構成する各種製品およびコンポーネントを含めることで、この初期ドメインを拡張する方法について説明します。

- インフラストラクチャ・ドメインの作成時に使用する変数
この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

- 初期インフラストラクチャ・ドメインの理解
初期インフラストラクチャ・ドメインの作成を開始する前に、次の重要な概念を確認してください。

- エンタープライズ・デプロイメントの準備におけるOracle Fusion Middleware Infrastructureのインストール
エンタープライズ・デプロイメント用の新規ドメインを構成する準備として、次の各項を参照してOracle Fusion Middleware Infrastructureソフトウェアをインストールします。

- データベース・スキーマの作成
Fusion Middleware Infrastructureドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに、この項にリストされたスキーマをインストールする必要があります。

- Infrastructureドメインの構成
次の各項では、Fusion Middleware構成ウィザードを使用してWebLogic Serverドメインを作成するための手順を示します。

- エンタープライズ・デプロイメントに対するホストごとのノード・マネージャの構成
エンタープライズ・デプロイメントによっては、デフォルトのドメインごとのノード・マネージャではなく、ホストごとのノード・マネージャを構成した方がよい場合があります。

- ドメイン・ディレクトリの構成とMFTHOST1上のサーバーの起動
ドメインを作成し、ノード・マネージャを構成したら、MFTHOST1で追加のドメイン・ディレクトリを構成し、管理サーバーおよび管理対象サーバーを起動できます。

- ドメインの伝播とMFTHOST2上のサーバーの起動
MFTHOST1で管理サーバーとWLS_WSM1管理対象サーバーを起動して検証したら、MFTHOST2で次のタスクを実行できます。

- uploadおよびstageディレクトリの絶対パスへの変更
ドメインを構成し、すべてのホスト上の管理対象サーバーのドメイン・ディレクトリにそのドメインを解凍した後、新しい管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

- 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング
Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダ(DefaultAuthenticator)を使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用することをお薦めします。

- Administratorsグループへのwsm-pmロールの追加
新しいLDAPベースの認可プロバイダを構成して管理サーバーを再起動したら、エンタープライズ・デプロイメント管理LDAPグループ(SOA Administrators)をメンバーとしてwsm-pmアプリケーション・ストライプのpolicy.Updaterロールに追加します。

親トピック: エンタープライズ・デプロイメントの構成

10.1 インフラストラクチャ・ドメインの作成時に使用する変数

この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

これらのディレクトリ変数については、「このガイドで使用するファイル・システムとディレクトリ変数」に定義されています。

- ORACLE_HOME

- ASERVER_HOME

- MSERVER_HOME

- APPLICATION_HOME

- JAVA_HOME

- NM_HOME

さらに、「エンタープライズ・トポロジによって必要とされる物理および仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスとホスト名を参照することになります。

- ADMINVHN

- SOAHOST1

- SOAHOST2

- DBHOST1

- DBHOST2

- Oracle RACデータベースのSCANアドレス(DB-SCAN.examle.com)

10.2 初期インフラストラクチャ・ドメインの理解

初期インフラストラクチャ・ドメインの作成を開始する前に、次の重要な概念を確認してください。

- インフラストラクチャ・ディストリビューションについて

- ドメインの特徴

10.2.1 インフラストラクチャ・ディストリビューションについて

エンタープライズ・デプロイメントの初期インフラストラクチャ・ドメインの作成には、Oracle Fusion Middleware Infrastructureディストリビューションを使用します。このディストリビューションには、Oracle WebLogic ServerソフトウェアとOracle JRFソフトウェアの両方が含まれています。

Oracle JRFソフトウェアは、Oracle Web Services Manager、Oracle Application Development Framework (Oracle ADF)、Oracle Enterprise Manager Fusion Middleware Control、リポジトリ作成ユーティリティ(RCU)およびOracle Fusion Middleware製品のサポートに必要なその他のライブラリおよびテクノロジで構成されています。

このガイドの後のほうでは、エンタープライズ・デプロイメントに必要なOracle Fusion Middleware製品をサポートするために、そのドメインを拡張します。

詳細は、Oracle Fusion Middlewareの理解のOracle Fusion Middleware Infrastructureの理解に関する項を参照してください。

10.2.2 ドメインの特徴

次の表に、作成するドメインの主な特徴を示します。これらの特徴を確認して理解することで、ドメインの構成手順の目的やコンテキストに対する理解が深まります。

これらの特徴の多くについては、「標準的なエンタープライズ・デプロイメントの理解」で詳しく説明しています。

ドメインの特徴

詳細情報

管理サーバーに別個の仮想IP (VIP)アドレスを使用。

管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成

ドメイン内の管理サーバーと管理対象サーバーに別個のドメイン・ディレクトリを使用。

管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成

Oracle Web Services Managerの専用クラスタを含む。

アプリケーション層でのOracle Web Services Managerの使用

ホストごとのノード・マネージャ構成を使用します。

標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について

別途インストールされたLDAPベースの認証プロバイダが必要。

OPSSおよび認証ストアと認可ストアへのリクエストの理解

10.3 エンタープライズ・デプロイメントの準備におけるOracle Fusion Middleware Infrastructureのインストール

エンタープライズ・デプロイメント用の新規ドメインを構成する準備として、次の各項を参照してOracle Fusion Middleware Infrastructureソフトウェアをインストールします。

- サポートされているJDKのインストール

- SOAHOST1でのInfrastructureインストーラの起動

- Infrastructureインストール画面のナビゲート

- 他のホスト・コンピュータへのOracle Fusion Middleware Infrastructureのインストール

- ディレクトリ構造のチェック
Oracle Fusion Middleware InfrastructureをインストールしてOracleホームを作成した後は、この項にリストされたディレクトリとサブディレクトリが表示されます。インストールの内容は、インストール中に選択したオプションによって異なります。

10.3.1 サポートされているJDKのインストール

Oracle Fusion Middlewareでは、動作保証されたJava Development Kit (JDK)がシステムにインストールされている必要があります。詳細は、次の各項を参照してください。

- JDKソフトウェアの検索とダウンロード

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

10.3.1.1 JDKソフトウェアの検索とダウンロード

動作保証されているJDKを調べるには、Oracle Fusion Middlewareのサポートされるシステム構成ページで、ご使用のリリース向けの動作保証ドキュメントを参照してください。

現在のOracle Fusion MiddlewareリリースのOracle JDKを特定したら、Oracle Technology Networkの次の場所からOracle JDKをダウンロードできます。

http://www.oracle.com/technetwork/java/index.html

Java SE JDKのダウンロードに必ず移動してください。

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

JDKを次の場所にインストールします。

- アプリケーション層の各ホスト・コンピュータからアクセスできる共有記憶域デバイス/u01/oracle/products/jdkディレクトリにJDKをインストールします。

- Web層の各ホスト・コンピュータのローカル記憶域デバイス
DMZに配置されるWeb層ホスト・コンピュータは、アプリケーション層の共有記憶域に必ずしもアクセスできるとはかぎりません。

JDKソフトウェアの推奨場所の詳細は、「エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解」を参照してください。

次の例では、JDK 1.8の最新バージョンをインストールする方法について説明します。

1. ディレクトリを、JDKアーカイブ・ファイルをダウンロードした場所に変更します。

2. アーカイブをJDKホーム・ディレクトリに解凍してから、次のコマンドを実行します。

cd download_dir
tar -xzvf jdk-8u74-linux-x64.tar.gz

ここに記載されたJDKバージョンは、このドキュメントの発行時点のものです。サポートされている最新のJDKについては、Oracle Fusion Middlewareのシステム要件と仕様で現在のOracle Fusion Middlewareリリースを参照してください。

3. JDKディレクトリを、ディレクトリ構造内の推奨される場所に移動します。

例:

mv ./jdk1.8.0_74/u01/oracle/products/jdk

詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

4. ホスト・コンピュータでJavaを実行するためのJAVA_HOMEおよびPATH環境変数を定義します。

例:

export JAVA_HOME=/u01/oracle/products/jdk
export PATH=$JAVA_HOME/bin:$PATH

5. 次のコマンドを実行して、適切なjava実行可能ファイルがそのパスにあり、環境変数が適切に設定されていることを確認します。

java -version
java version "1.8.0_74"
Java(TM) SE Runtime Environment (build 1.8.0_74-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode)

10.3.2 SOAHOST1でのInfrastructureインストーラの起動

インストール・プログラムを起動するには、次の手順を実行します。

1. SOAHOST1にログインします。

2. インストール・プログラムがダウンロードされたディレクトリに移動します。

3. 次の例に示すとおり、ご使用のシステムのJDKディレクトリからjava実行可能ファイルを実行し、インストール・プログラムを起動します。

JAVA_HOME/bin/java -d64 -jar distribution_file_name.jar

この例では、次のようになります。

- JAVA_HOMEを、ご使用のシステムの環境変数または実際のJDKの場所に置き換えます。

- distribution_file_nameを、ディストリビューションJARファイルの実際の名前に置き換えます。
ディストリビューションをOracle Technology Network (OTN)からダウンロードする場合、通常、JARファイルはダウンロード可能なZIPファイル内にパッケージされています。

初期Infrastructureドメインに必要なソフトウェアをインストールする場合は、インストールするディストリビューションはfmw_12.2.1.0.0_infrastructure_generic.jarです。

各ディストリビューションの実際のファイル名の詳細は、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」を参照してください。

インストール・プログラムが表示されると、インストールを開始する準備ができています。各インストール・プログラム画面の説明については、「インストール画面のナビゲート」を参照してください。

10.3.3 インフラストラクチャ・インストール画面のナビゲート

インストール・プログラムでは、次の表にリストされている順序で一連の画面が表示されます。

インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。

画面

説明

インストール・インベントリの設定

この画面は、UNIXオペレーティング・システムで、このホストに初めてOracle製品をインストールする場合に表示されます。中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名には、中央インベントリの場所への書込み権限があることを確認してください。

中央インベントリの詳細は、Oracle Universal InstallerによるソフトウェアのインストールでOracle中央インベントリの理解に関する項を参照してください。

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面では、使用可能なパッチを探してMy Oracle Supportを自動的に検索するか、組織にすでにダウンロードしたパッチを探してローカル・ディレクトリを自動的に検索します。

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

エンタープライズ・デプロイメントのためには、表7-2に示すORACLE_HOME変数の値を入力します。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

このトポロジの場合は、「Fusion Middleware Infrastructure」を選択します。

注意: このドキュメントのトポロジには、サーバーの例は含まれていません。例を本番環境にインストールしないことを強くお薦めします。

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告またはエラー・メッセージが表示される場合、Oracle Technology Network (OTN)のOracle Fusion Middlewareシステム要件と仕様を参照してください。

セキュリティ・アップデート

Oracle Supportアカウントをすでに所持している場合は、この画面を使用して、セキュリティ・アップデートの受取り方法を指定します。

アカウントを所持していないときに、この手順を省略してもかまわない場合は、チェック・ボックスの選択を解除して、その選択を後続のダイアログ・ボックスで確認します。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを確認します。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。レスポンス・ファイルは、今後、サイレント・インストールを実行する場合に使用できます。

サイレント・インストールやコマンド行インストールの詳細は、Oracle Universal Installerによるソフトウェアのインストールでサイレント・モードにおけるOracle Universal Installerの使用方法に関する項を参照してください。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

インストール完了

インストールが完了すると、この画面が表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

10.3.4 他のホスト・コンピュータへのOracle Fusion Middleware Infrastructureのインストール

SOAHOST2用に別の共有記憶域ボリュームまたはパーティションを構成している場合は、SOAHOST2にもインフラストラクチャをインストールする必要があります。

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

トポロジ内の他のホスト・コンピュータにソフトウェアをインストールするには、各ホストにログインして、「SOAHOST1でのInfrastructureインストーラの起動」と「Infrastructureインストール画面のナビゲート」の手順に従って、適切な記憶域デバイスにOracleホームを作成します。

注意:

前のリリースでは、推奨されるエンタープライズ・トポロジに、同じ場所に配置されたOracle HTTP Serverインスタンスのセットが含まれていました。こうしたリリースでは、InfrastructureをWeb層ホストにインストールする必要がありました(WEBHOST1およびWEBHOST2)。しかし、このリリースの場合、エンタープライズ・デプロイメント・トポロジでは、Webサーバーがスタンドアロン・モードでインストールおよび構成されると想定しているため、これらがアプリケーション層ドメインに含まれるとは考えられていません。詳細は、「エンタープライズ・デプロイメント用のOracle HTTP Serverの構成」を参照してください

10.3.5 ディレクトリ構造のチェック

Oracle Fusion Middleware InfrastructureをインストールしてOracleホームを作成した後は、この項にリストされたディレクトリとサブディレクトリが表示されます。インストールの内容は、インストール中に選択したオプションによって異なります。

ディレクトリ構造をチェックするには:

1. InfrastructureをインストールしたORACLE_HOMEディレクトリに移動します。

2. 次のコマンドを入力します。
ls -l

システム上のディレクトリ構造は、次の例に示す構造と一致する必要があります。

/u01/oracle/products/fmw/

cfgtoollogs
coherence
em
install
inventory
OPatch
oracle_common
oraInst.loc
oui
wlserver

インストールの完了後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解のOracle Fusion Middlewareの主要ディレクトリに関する項を参照してください。

10.4 データベース・スキーマの作成

Fusion Middleware Infrastructureドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに、この項にリストされたスキーマをインストールする必要があります。

- メタデータ・サービス(MDS)

- 監査サービス(IAU)

- 監査サービスへの追加(IAU_APPEND)

- 監査サービス・ビューア(IAU_VIEWER)

- OPSS (Oracle Platform Security Services)

- ユーザー・メッセージング・サービス(UMS)

- WebLogicサービス(WLS)

- Common Infrastructure Services (STB)

リポジトリ作成ユーティリティ(RCU)を使用して、スキーマを作成します。このユーティリティは各Oracle Fusion Middleware製品のOracleホームにインストールされています。RCUの詳細とスキーマを作成してデータベースに格納する方法の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』でスキーマ作成の準備に関する項を参照してください。

この項の手順に従って、必要なスキーマをインストールします。

- 動作保証されたデータベースのインストールと構成

- リポジトリ作成ユーティリティ(RCU)の起動

- スキーマ作成のためのRCU画面のナビゲート

10.4.1 動作保証されたデータベースのインストールと構成

動作保証されたデータベースを適切にインストールして構成し、そのデータベースを起動して稼働させておく必要があります。

詳細は、「エンタープライズ・デプロイメント用のデータベースの準備」を参照してください。

10.4.2 リポジトリ作成ユーティリティ(RCU)の起動

リポジトリ作成ユーティリティ(RCU)を起動するには:

1. 対象のシステムで、ORACLE_HOME/oracle_common/binディレクトリに移動します。

2. 対象のシステムで、JAVA_HOME環境変数に、動作保証されたJDKの場所が設定されていることを確認します。この場所は、binディレクトリより上の階層にする必要があります。たとえば、JDKが/u01/oracle/products/jdkに存在する場合は、次のようになります。

UNIXオペレーティング・システムの場合:

export JAVA_HOME=/u01/oracle/products/jdk

3. RCUを起動します。

UNIXオペレーティング・システムの場合:

./rcu

10.4.3 スキーマ作成のためのRCU画面のナビゲート

Fusion Middleware Infrastructureドメインにスキーマを作成するには、この項の手順に従います。

- タスク1「RCUの導入」

- タスク2「スキーマ作成の方法の選択」

- タスク3「データベース資格証明の指定」

- タスク4「カスタム接頭辞の指定とスキーマの選択」

- タスク5「スキーマのパスワードの指定」

- タスク6「スキーマ作成の実行」

タスク1   RCUの導入

「ようこそ」画面でRCUのバージョン番号を確認します。「次へ」をクリックして開始します。

タスク2   スキーマ作成の方法の選択

データベースでDBAアクティビティを実行するために必要な権限を持っている場合は、「リポジトリの作成」画面で「システム・ロードおよび製品ロード」を選択します。このドキュメントの手順では、必要な権限があることを想定しています。

データベースに対するDBAアクティビティの実行に必要なパーミッションまたは権限が付与されていない場合は、この画面で、「システム・ロードに対するスクリプトの準備」を選択する必要があります。これによってSQLスクリプトが生成され、これをデータベース管理者が利用できます。リポジトリ作成ユーティリティを使用したスキーマの作成のシステム・ロードおよび製品ロードの理解に関する項を参照してください。

ヒント:

この画面の選択内容の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』でリポジトリの作成に関する項を参照してください。

タスク3   データベース資格証明の指定

「データベース接続の詳細」画面に、データベースに接続するためのRCUに関するデータベース接続の詳細が表示されます。

「ホスト名」フィールドに、Oracle RACデータベースのSCANアドレスを入力します。

「次へ」をクリックして先に進み、データベースへの接続が成功したことを確認するダイアログ・ウィンドウで、「OK」をクリックします。

ヒント:

この画面の選択内容の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』でデータベース接続の詳細に関する項を参照してください。

タスク4   カスタム接頭辞の指定とスキーマの選択

1. Oracle Fusion Middlewareスキーマの識別に使用するカスタム接頭辞を指定します。
カスタム接頭辞は、これらのスキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。このガイドでは、FMW1221という接頭辞を使用します。

ヒント:

ここで入力したカスタム接頭辞を書き留めてください。これは後でドメインの作成時に必要になります。

カスタム接頭辞の詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のカスタム接頭辞の理解に関する項を参照してください。

2. 「AS共通スキーマ」を選択します。
「AS共通スキーマ」を選択すると、このセクションのすべてのスキーマが自動的に選択されます。

このセクションのスキーマが自動的に選択されない場合、必要なスキーマを選択してください。

Common Infrastructure Servicesと呼ばれるスキーマも自動的に作成されます。このスキーマはグレー表示されており、選択も選択解除もできません。このスキーマ(STBスキーマ)を使用すると、ドメインの構成中にRCUから情報を取得できます。詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解に関する項を参照してください。

ヒント:

マルチドメイン環境でスキーマを編成する方法の詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のスキーマ作成の計画に関する項を参照してください。

「次へ」をクリックして先に進み、スキーマ作成の前提条件チェックが成功したことを確認するダイアログ・ウィンドウの「OK」をクリックします。

タスク5   スキーマのパスワードの指定

スキーマのパスワードをデータベースに設定する方法を指定してから、パスワードの指定と確認を行います。

ヒント:

この画面で設定するパスワードは、メモしておく必要があります。このパスワードは、後述するドメイン作成のプロセスで必要になります。

タスク6   スキーマ作成の完了

RCU画面の残りの部分を先に進めて、スキーマ作成を完了します。

このガイドでは、残りの画面のデフォルト設定を受け入れるか、RCUでのOracle Fusion Middlewareスキーマの作成方法および必要な表領域の使用方法をカスタマイズします。

RCUおよびその機能と概念については、『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。

「完了サマリー」画面に到達したら、「閉じる」をクリックしてRCUを終了します。

10.5 Infrastructureドメインの構成

次の各項では、Fusion Middleware構成ウィザードを使用してWebLogic Serverドメインを作成するための手順を示します。

ドメイン作成に使用可能なその他の方法の詳細は、構成ウィザードを使用したWebLogicドメインの作成のWebLogicドメインの作成、拡張および管理のための追加ツールに関する項を参照してください。

- 構成ウィザードの起動

- Infrastructureドメインを構成するための構成ウィザード画面のナビゲート

10.5.1 構成ウィザードの起動

ドメインの構成を開始するには、Oracle Fusion Middleware Oracleホームで次のコマンドを実行します。

ORACLE_HOME/oracle_common/common/bin/config.sh

10.5.2 Infrastructureドメインを構成するための構成ウィザード画面のナビゲート

この項で説明する手順を実行して、目的のトポロジのドメインを作成して構成します。

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「新規ドメインの作成」を選択します。

「ドメインの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、ASERVER_HOME変数の値を指定します。

ヒント:

構成ウィザードのこの画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面では、「製品テンプレートを使用してドメインを作成」が選択されていることを確認し、次のテンプレートを選択します。

- Oracle Enterprise Manager - 12.2.1.0 [em]
このテンプレートを選択すると、次の依存性が自動的に選択されます。

- Oracle JRF - 12.2.1.0 [oracle_common]

- WebLogic Coherenceクラスタの拡張 - 12.2.1.0 [wlserver]

- Oracle WSM Policy Manager - 12.2.1.0 [oracle_common]

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「テンプレート」に関する項を参照してください。

タスク3   アプリケーション・ホームの場所の選択

「アプリケーションの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、APPLICATION_HOME変数の値を指定します。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「アプリケーションの場所」に関する項を参照してください。

タスク4   管理者アカウントの構成

「管理者アカウント」画面では、ドメインに対するデフォルトのWebLogic管理者アカウントにユーザー名とパスワードを指定します。

この画面で指定したユーザー名およびパスワードを書き留めておいてください。これらの資格証明は後でドメインの管理サーバーを起動して接続する際に必要になります。

タスク5   ドメイン・モードとJDKの指定

「ドメイン・モードおよびJDK」画面では、次の操作を実行します。

- 「ドメイン・モード」フィールドで、「本番」を選択します。

- 「JDK」フィールドで「Oracle Hotspot JDK」を選択します。

「本番モード」をこの画面で選択すると、環境で高度なセキュリティが実現され、アプリケーションのデプロイと管理サーバーの起動でユーザー名とパスワードが必要になります。

ヒント:

開発モードと本番モードの違いなど、この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のドメイン・モードとJDKに関する項を参照してください。

本番モードでは、起動アイデンティティ・ファイルを作成することで、管理サーバーの起動時に必要なユーザー名とパスワードの指定を省略できます。詳細は、「boot.propertiesファイルの作成」を参照してください。

タスク6   データベース構成タイプの指定

「RCUデータ」を選択して、この画面に示されるフィールドをアクティブ化します。

「RCUデータ」オプションによってデータベースおよびサービス表(STB)スキーマに接続し、ドメインの構成に必要なスキーマのスキーマ情報を自動的に受け取るように構成ウィザードで指定できます。

注意:

この画面の「手動構成」を選択した場合は、「JDBCコンポーネント・スキーマ」画面でスキーマのパラメータを手動で入力する必要があります。

「RCUデータ」を選択したら、次の表に示すフィールドに入力します。図10-1のサンプルの「データベース構成タイプ」画面の部分的なスクリーン・ショットを参照してください。

フィールド

説明

DBMS/サービス

製品スキーマをインストールするOracle RACデータベースのサービス名を入力します。例:

orcl.example.com

必ずOracle RACデータベース内のすべてのインスタンスの識別に使用される共通サービス名を指定してください。ホスト固有のサービス名は使用しないでください。

ホスト名

Enterprise Deployment Workbookに入力したOracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

ポート

データベースがリスニングするポート番号を入力します。例: 1521。

スキーマ所有者

スキーマ・パスワード

データベースのサービス表スキーマに接続するためのユーザー名とパスワードを入力します。

これはRCUの「スキーマ・パスワード」画面でサービス表コンポーネントに指定したスキーマ(「データベース・スキーマの作成」を参照)のユーザー名およびパスワードです。

デフォルトのユーザー名はprefix_STBであり、この場合prefixはRCUで定義したカスタム接頭辞です。

図10-1 エンタープライズ・デプロイメントのデータベース構成タイプの設定

データベース接続情報の指定が完了したら、「RCU構成の取得」をクリックします。操作に成功すると、「接続結果ログ」に次の出力が示されます。

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

データベースへの接続に成功したら、「次へ」をクリックします。

ヒント:

「RCUデータ」オプションの詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のサービス表スキーマの理解に関する項を参照してください。

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「データソース・デフォルト」に関する項を参照してください。

タスク7   JDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」画面に示される値が、すべてのスキーマに対して適切であることを確認します。

前の画面でRCUデータの取得を選択しているため、スキーマ表は移入済のはずです。その結果、構成ウィザードはこのドメインに必要なすべてのスキーマのデータベース接続値を見つけることができます。

この時点では、これらの値は単一インスタンスのデータベースに接続するように構成されています。ただし、エンタープライズ・デプロイメントの場合、「エンタープライズ・デプロイメント用のデータベースの準備」の説明のように、可用性の高いReal Application Clusters (RAC)データベースを使用する必要があります。

さらに、各コンポーネント・スキーマでアクティブなGridLinkデータ・ソースを使用することをお薦めします。GridLinkデータ・ソースを使用してRACデータベースに接続する利点の詳細は、高可用性ガイドのデータベースの考慮事項に関する項を参照してください。

データ・ソースをGridLinkに変換する手順は次のとおりです。

1. スキーマ表の最初のヘッダー行にあるチェック・ボックスを選択することですべてのスキーマを選択します。

2. 「GridLinkへ変換」をクリックし、「次へ」をクリックします。

タスク8   GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

要素

説明と推奨値

SCAN、ホスト名とポート

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドに、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

データベースがFANイベントを受信して処理できるように、「FANの有効化」チェック・ボックスが選択されていることを確認します。

図10-2 「GridLink Oracle RACコンポーネント・スキーマ」画面のサンプル値

この画面で情報を指定する方法の詳細および適切なSCANアドレスの特定方法については、『高可用性ガイド』のOracle RACでのアクティブなGridLinkデータ・ソースの構成に関する項を参照してください。

また、「ヘルプ」をクリックすると、画面の各フィールドの簡単な説明を表示できます。

タスク9   JDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「コンポーネント・スキーマのテスト」に関する項を参照してください。

タスク10   拡張構成の選択

目的のトポロジに応じたドメインの構成を完了するには、「拡張構成」画面で次のオプションを選択します。

- 管理サーバー
これは、管理サーバーのリスニング・アドレスを適切に構成するために必要です。

- ノード・マネージャ
これは、ノード・マネージャを構成するために必要です。

- 管理対象サーバー、クラスタおよびCoherence
これは、管理対象サーバーとクラスタの構成で必要ですが、マシンを構成して管理対象サーバーをマシンにターゲット指定するためにも必要です。

- JMSファイル・ストア
これは、JMS永続ストア用に適切な共有記憶域を構成するために必要です。

注意:

構成ウィザードの「拡張構成」画面を使用するときは、次のようにします。

- この画面で前述のオプションのいずれかが使用可能でない場合は、「テンプレート」画面に戻り、このトポロジに必要なテンプレートが選択されていることを確認します。

- 「ドメイン・フロントエンド・ホストのキャプチャ」拡張構成オプションを選択しないでください。後で、ドメインに対してではなく特定のクラスタに対してフロントエンド・ホスト・プロパティを構成します。

タスク11   管理サーバーのリスニング・アドレスの構成

「管理サーバー」画面で、次の手順を実行します。

1. 「サーバー名」フィールドで、デフォルト値(「AdminServer」)を維持します。

2. 「リスニング・アドレス」フィールドに、「エンタープライズ・デプロイメント用のリソースの取得」で取得し、「エンタープライズ・デプロイメント用のホスト・コンピュータの準備」で有効化した、ADMINVHNのVIPに対応する仮想ホスト名を入力します。
ADMINVHN仮想ホストを使用する理由の詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。

3. 他のフィールドでは、デフォルト値をそのまま使用します。
特に、管理サーバーにサーバー・グループが割り当てられていないことを確認してください。

タスク12   ノード・マネージャの構成

ノード・マネージャ・タイプとして「手動ノード・マネージャ・セットアップ」を選択します。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のノード・マネージャに関する項を参照してください。

ドメインごとおよびホストごとのノード・マネージャの実装の詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

詳細は、『Oracle WebLogic Serverノード・マネージャの管理』の複数マシンでのノード・マネージャの構成に関する項を参照してください。

タスク13   管理対象サーバーの構成

「管理対象サーバー」画面で、2台の管理対象サーバーを新規作成します。

1. 「追加」ボタンをクリックして、1台の管理対象サーバーを新規作成します。

2. 「サーバー名」列でWLS_WSM1を指定します。

3. 「リスニング・アドレス」列にSOAHOST1と入力します。
SOAHOST1に対応するホスト名を必ず入力して、IPアドレスは使用しないでください。

4. 「リスニング・ポート」列に7010と入力します。

5. 「サーバー・グループ」ドロップダウン・リストで、JRF-MAN-SVR、WSM-CACHE-SVR、およびWSMPM-MAN-SVRを選択します。(図10-3を参照。)
これらのサーバー・グループによって、Oracle JRFとOracle Web Services Manager (OWSM)のサービスが、作成中の管理対象サーバーにターゲット設定されます。

サーバー・グループは、定義されたアプリケーション・サービスのグループをそれぞれに定義されたサーバー・グループにマッピングすることで、Fusion Middlewareアプリケーションおよびサービスを1つ以上のサーバーにターゲット設定します。特定のサーバー・グループにマップされた任意のアプリケーション・サービスは、そのグループに割り当てられたすべてのサーバーに自動的にターゲット指定されます。詳細は、『ドメイン・テンプレート・リファレンス』のアプリケーション・サービス・グループ、サーバー・グループおよびアプリケーション・サービス・マッピングに関する項を参照してください。

注意:

Oracle Web ServicesのNonceキャッシュは、WSM-CACHE-SVRサーバー・グループによって自動的に構成され、ほとんどのアプリケーションに適しています。Nonceは、SOAPリクエストで1回のみ使用できる一意の番号で、リプレイ攻撃を防止するために使用されます。Nonceキャッシュは、追加されたWebサービス・アプリケーションを実行中の管理対象サーバーの数によって必然的に拡大します。

拡張キャッシュ構成については、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のOracle CoherenceによるNonceのキャッシュに関する項を参照してください。この項では、NonceキャッシュとWSM-CACHE-SVRサーバー・グループの使用に関する追加のガイダンスを提供します。

6. このプロセスを繰り返して、WLS_WSM2という名前の2つ目の管理対象サーバーを作成します。
「リスニング・アドレス」にSOAHOST2と入力します。「リスニング・ポート」に7010と入力します。最初の管理対象サーバーに適用したものと同じサーバー・グループをWLS_WSM2に適用します。

この手順で推奨する管理対象サーバー名(WLS_WSM1およびWLS_WSM2)はこのドキュメント全体で参照します。別の名前を選択した場合は、必要に応じてそれらの名前に置き換えてください。

図10-3 エンタープライズ・デプロイメント用に管理対象サーバーを定義するための構成ウィザードの使用

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「管理対象サーバー」に関する項を参照してください。

タスク14   クラスタの構成

「クラスタ」画面を使用して、新しいクラスタを作成します。

1. 「追加」ボタンをクリックします。

2. 「クラスタ名」フィールドで、WSM-PM_Clusterを指定します。

3. 他のフィールドは空のままにします。

ヒント

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項を参照してください。

タスク15   クラスタへの管理対象サーバーの割当て

「サーバーのクラスタへの割当」画面を使用して、WLS_WSM1およびWLS_WSM2を新規クラスタWSM-PM_Clusterに割り当てます。

1. 「クラスタ」ペインで、サーバーを割り当てるクラスタ(ここではWSM-PM_Cluster)を選択します。

2. 「サーバー」ペインで、次のいずれかの操作を実行して、WLS_WSM1をWSM-PM_Clusterに割り当てます。

- 「WLS_WSM1」を1回クリックして選択し、右矢印をクリックして「クラスタ」ペインの選択されているクラスタ(WSM-PM_Cluster)の下に移動します。
または

- 「WLS_WSM1」をダブルクリックして、クラスタ・ペインの選択されているクラスタ(WSM-PM_Cluster)の下に移動します。

3. これらの手順を繰り返して、WLS_WSM2管理対象サーバーをWSM-PM_Clusterに割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのクラスタへの割当」に関する項を参照してください。

タスク16   Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。

「クラスタ・リスニング・ポート」に9991と入力します。

注意:

Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報』のOracle Coherenceに関する項を参照してください。

タスク17   マシンの作成

「マシン」画面を使用して、ドメイン内に3つの新規マシンを作成します。マシンは、ノード・マネージャでサーバーを起動または停止できるようにするために必要です。

1. 「Unixマシン」タブを選択します。

2. 「追加」ボタンをクリックし、3つの新しいUnixマシンを作成します。
表10-1の値を使用して、各マシンの名前およびノード・マネージャ・リスニング・アドレスを定義します。図10-4は、各マシンの値の例が入力された「マシン」画面の一部を示しています。

3. 「ノード・マネージャ・リスニング・ポート」フィールドのポート番号を確認します。
この例に示されているポート番号5556は、このドキュメントの別の例でも引用されることがあります。このポート番号は、必要に応じて各自のポート番号に置換してください。

表10-1 Unixマシンの作成時に使用する値

名前

ノード・マネージャのリスニング・アドレス

ノード・マネージャのリスニング・ポート

SOAHOST1

SOAHOST1ホスト名変数の値。例: SOAHOST1.example.com。

5556

SOAHOST2

SOAHOST2ホスト名変数の値。例: SOAHOST2.example.com。

5556

ADMINHOST

ADMINVHN変数の値を入力します。

5556

図10-4 構成ウィザードの「Unixマシン」画面の値の例

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のマシンに関する項を参照してください。

タスク18   マシンへのサーバーの割当て

「サーバーのマシンへの割当」画面を使用して、管理サーバーと2つの管理対象サーバーを適切なマシンに割り当てます。

「サーバーのマシンへの割当」画面は、管理対象サーバーのクラスタへの割当て画面に似ています。「マシン」列でターゲット・マシンを選択し、左の列で管理対象サーバーを選択した後、右矢印をクリックしてそのサーバーを適切なマシンに割り当てます。

次のように、サーバーを割り当てます。

- AdminServerをADMINHOSTマシンに割り当てます。

- WLS-WSM1管理対象サーバーをSOAHOST1マシンに割り当てます。

- WLS-WSM2管理対象サーバーをSOAHOST2マシンに割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのマシンへの割当」に関する項を参照してください。

タスク19 JMSファイル・ストアの構成

Oracle WSM Policy Manager構成テンプレートを使用してドメインを構成する場合、特にエンタープライズ・デプロイメントを構成しているときには、メタデータ・サービス(MDS)のJMSファイル・ストアの適切な場所を選択する必要があります。

「JMSファイル・ストア」画面の「ディレクトリ」列に次の場所を入力します。

ORACLE_RUNTIME/domain_name/WSM-PM_Cluster/jms

注意:
このストアには、非共有記憶域の場所を指定できます。これは、WSMの開発モードでのみ使用されます。本番環境では、これをホストするためにかわりにデータベースが使用されます。

「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、ORACLE_RUNTIMEを変数の実際の値に置き換えます。

domain_nameを作成しているドメインの名前に置き換えます。

タスク20   仮想ターゲットの作成

「次へ」をクリックして次の画面に進みます。

タスク21   パーティションの作成

「次へ」をクリックして次の画面に進みます。

タスク22   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

ドメイン作成は、「作成」をクリックするまでは開始されません。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

タスク23   ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

- ドメインの場所

- 管理サーバーURL

どちらの項目も後で必要になるため、メモしておく必要があります。ドメインの場所は、管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

10.6 エンタープライズ・デプロイメントに対するホストごとのノード・マネージャの構成

エンタープライズ・デプロイメントによっては、デフォルトのドメインごとのノード・マネージャではなく、ホストごとのノード・マネージャを構成した方がよい場合があります。

ホストごとのノード・マネージャの利点の詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください

- ホストごとのノード・マネージャ構成の作成
ホストごとのノード・マネージャの構成の手順では、構成ディレクトリおよび2つの新規ノード・マネージャ構成ファイルを作成します。デフォルトのstartNodeManager.shファイルを編集する必要もあります。

- boot.propertiesファイルの作成
ノード・マネージャの資格証明を要求されることなくノード・マネージャを起動する必要がある場合、boot.propertiesを作成します。この手順は、エンタープライズ・デプロイメントで必要です。このファイルに入力した資格証明は、管理サーバーの起動時暗号化されます。

- SOAHOST1でのノード・マネージャの起動
ホストごとのノード・マネージャ構成を使用するようノード・マネージャを手動で設定したら、startNodeManager.shスクリプトを使用してSOAHOST1でノード・マネージャを起動できます。

- ノード・マネージャ資格証明およびタイプの構成
デフォルトでは、ホストごとのノード・マネージャ構成では、ノード・マネージャからサーバーへの通信にSecure Socket Layer (SSL)は使用されません。このため、ドメイン内の各マシンを、SSLではなく"プレーン"通信タイプを使用するように構成する必要があります。また、ドメイン内の管理サーバーおよび管理対象サーバーに接続できるようにノード・マネージャ資格証明を設定する必要があります。

10.6.1 ホストごとのノード・マネージャ構成の作成

ホストごとのノード・マネージャの構成の手順では、構成ディレクトリおよび2つの新規ノード・マネージャ構成ファイルを作成します。デフォルトのstartNodeManager.shファイルを編集する必要もあります。

ホストごとのノード・マネージャ構成を作成するには、次のタスクをまずSOAHOST1で実行し、その後SOAHOST2で実行します。

1. SOAHOST1にログインして、ノード・マネージャ構成ファイルのディレクトリを作成します。

例:

mkdir —p /u02/oracle/config/nodemanager

このディレクトリはホストに固有であるため、ローカル・ディスクに配置する必要があります。このディレクトリの場所はノード・マネージャ・ホームと呼ばれており、このガイドの各例ではNM_HOMEディレクトリ変数によって識別されます。

2. ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。

cd NM_HOME

3. nodemanager.propertiesという新しいテキスト・ファイルを作成し、例10-1に示されている値をこの新しいファイルに追加します。

nodemanager.propertiesファイルに追加できるプロパティの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのプロパティに関する項を参照してください。

nodemanager.propertiesファイルのこの構成の一部として、ノード・マネージャに対してクラッシュ・リカバリを有効にします。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャとシステム・クラッシュ・リカバリに関する項を参照してください。

4. 次のディレクトリでstartNodeManager.shファイルを見つけます。

WL_HOME/server/bin

5. startNodeManager.shファイルをノード・マネージャ・ホーム・ディレクトリにコピーします。

6. 新しいstartNodeManager.shファイルを編集し、NODEMGR_HOMEプロパティを次のように追加します。

NODEMGR_HOME="NM_HOME"

この例では、NM_HOMEをノード・マネージャ・ホームの実際のパスに置き換えます。

7. ノード・マネージャ・ホーム・ディレクトリに、nodemanager.domainsという新しいファイルを作成します。

nodemanager.domainsファイルではノード・マネージャ・クライアントのアクセスがファイル内に表示されたドメインに制限されるので、セキュリティがさらに強化されます。

8. SOAHOST2で手順1から7を実行します。

9. 次のエントリを新しいnodemanager.domainsファイルに追加します。

SOAHOST1で、管理サーバー・ドメイン・ホームと管理対象サーバー・ドメイン・ホームの値を追加します。

soaedg_domain=MSERVER_HOME;ASERVER_HOME

注意:

最初に指定されたパス(MSERVER_HOME)は、primaryDomainPathとみなされ、管理対象サーバーはこの場所から実行されます。

SOAHOST2で、管理対象サーバー・ドメイン・ホームのみの値を追加します。

soaedg_domain=MSERVER_HOME

これらの例では、ASERVER_HOMEおよびMSERVER_HOMEを、「このガイドで使用するファイル・システムとディレクトリ変数」に示されているそれぞれの変数に置き換えます。

例10-1 nodemanager.propertiesファイルのコンテンツ

DomainsFile=/u02/oracle/config/nodemanager/nodemanager.domains
LogLimit=0
PropertiesVersion=12.2.1
AuthenticationEnabled=true
NodeManagerHome=/u02/oracle/config/nodemanager
#Include the specific JDK home
JavaHome=/u01/oracle/products/jdk
LogLevel=INFO
DomainsFileEnabled=true
StartScriptName=startWebLogic.sh
#Leave blank for listening on ANY
ListenAddress=
NativeVersionEnabled=true
ListenPort=5556
LogToStderr=true
SecureListener=false
LogCount=1
StopScriptEnabled=false
QuitEnabled=false
LogAppend=true
StateCheckInterval=500
CrashRecoveryEnabled=true
StartScriptEnabled=true
LogFile=/u02/oracle/config/nodemanager/nodemanager.log
LogFormatter=weblogic.nodemanager.server.LogFormatter
ListenBacklog=50

10.6.2 boot.propertiesファイルの作成

ノード・マネージャの資格証明を要求されることなくノード・マネージャを起動する必要がある場合、boot.propertiesを作成します。この手順は、エンタープライズ・デプロイメントで必要です。このファイルに入力した資格証明は、管理サーバーの起動時暗号化されます。

管理サーバーのboot.propertiesファイルを作成する手順は次のとおりです。

1. 次のようなディレクトリ構造を作成します。

mkdir -p ASERVER_HOME/servers/AdminServer/security

2. テキスト・エディタで、前述の手順で作成したsecurityディレクトリにboot.propertiesというファイルを作成し、構成ウィザードを実行してドメインを作成したときに定義した、次の管理サーバー資格証明を入力します。

username=adminuser
password=password

注意:

管理サーバーを起動すると、ファイル内のusernameとpasswordのエントリは暗号化されます。

セキュリティ上の理由から、ファイル内のエントリが暗号化されていない時間を短くします。ファイルを編集した後、できるかぎり速やかにサーバーを起動し、エントリを暗号化してください。

3. ファイルを保存してエディタを閉じます。

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

ホストごとのノード・マネージャ構成を使用するようノード・マネージャを手動で設定したら、startNodeManager.shスクリプトを使用してSOAHOST1でノード・マネージャを起動できます。

SOAHOST1でノード・マネージャを起動するには、次のようにします。

1. ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。

cd NM_HOME

2. 次のコマンドを実行してノード・マネージャを起動し、コマンドの出力を現在のターミナル・シェルではなく出力ファイルに送信します。

nohup ./startNodeManager.sh > ./nodemanager.out 2>&1 &

3. nodemanager.outファイルを監視し、ノード・マネージャが正常に起動することを確認します。出力には最終的に、次のような文字列が含まれます。
<INFO><Plain socket listener started on port 5556>

10.6.4 ノード・マネージャ資格証明およびタイプの構成

デフォルトでは、ホストごとのノード・マネージャ構成では、ノード・マネージャからサーバーへの通信にSecure Socket Layer (SSL)は使用されません。このため、ドメイン内の各マシンを、SSLではなく"プレーン"通信タイプを使用するように構成する必要があります。また、ドメイン内の管理サーバーおよび管理対象サーバーに接続できるようにノード・マネージャ資格証明を設定する必要があります。

次の手順では、これらのタスクを実行できるように、一時的に管理サーバーをデフォルトの起動スクリプトで起動します。これらのタスクを実行したら、この一時セッションを停止し、ノード・マネージャを使用して管理サーバーを起動できます。

1. デフォルトの起動スクリプトを使用して管理サーバーを起動します。

a. ディレクトリを次のディレクトリに変更します。

cd ASERVER_HOME/bin

b. 起動スクリプトを実行します。

./startWebLogic.sh

次が表示されるまで、端末への出力を確認します。

<Server state changed to RUNNING>

2. WebLogic管理者ユーザーおよびパスワードを使用してWebLogic Server管理コンソールにログインします。

3. ノード・マネージャ・タイプを構成します。

注意:

ドメイン内のWebLogic Serverマシンごとに必ずこのタスクを実行してください。

a. 「ロックして編集」をクリックします。

b. 「ドメイン構造」ナビゲーション・ツリーで「ドメイン」、「環境」の順に開きます。

c. 「マシン」をクリックします。

d. ADMINHOSTマシンのリンクをクリックします。

e. 「ノード・マネージャ」タブをクリックします。

f. 「タイプ」プロパティをSSLから「プレーン」に変更します。

g. 「保存」をクリックします。

h. ドメイン内のマシンごとに、このタスクを繰り返します。

i. 「変更のアクティブ化」をクリックします。

4. ノード・マネージャ資格証明を設定します。

a. 「ロックして編集」をクリックします。

b. 「ドメイン構造」ナビゲーション・ペインでドメイン名をクリックします。

c. 「セキュリティ」タブを選択します。
「セキュリティ」>「一般」タブが選択されているはずです。

d. 下方向にスクロールして「詳細」セキュリティ・オプションを開きます。

e. 「ノード・マネージャのユーザー名」フィールドのユーザー名を書き留めます。
オプションで、値を編集して新しいノード・マネージャ・ユーザー名を作成できます。

f. 「ノード・マネージャのパスワード」および「ノード・マネージャのパスワードを確認」フィールドに新しいパスワードを入力します。

g. 「保存」をクリックし、「変更のアクティブ化」をクリックします。

5. 新しいターミナル・ウィンドウで、次の手順を使用してSystemSerialized.datファイルをリフレッシュします。この手順を行わないと、ノード・マネージャに接続してドメイン内のサーバーを起動することができません。

a. ディレクトリを次に変更します
cd ORACLE_COMMON_HOME/common/bin

b. WebLogic Server Scripting Tool (WLST)を起動します。
./wlst.sh

c. 次のWLSTコマンドを使用して管理サーバーに接続します。
connect('admin_user','admin_password','admin_url')

例:

connect('weblogic','mypassword','t3://ADMINVHN:7001')

d. nmEnrollコマンドを使用して、ノード・マネージャが指定したWebLogicドメイン内のサーバーを管理できるようにします。
nmEnroll('ASERVER_HOME')
例:

nmEnroll('/u01/oracle/config/domains/soaedg_domain')

6. オプションで、管理サーバーの起動プロパティをカスタマイズする場合は、次のWLSTコマンドを使用して管理サーバー用のstartup.propertiesファイルを作成できます。
nmGenBootStartupProps('AdminServer')
次のディレクトリに、startup.propertiesファイルが作成されます。

ASERVER_HOME/servers/AdminServer/data/nodemanager/

7. 起動スクリプトで管理サーバーを起動したターミナル・ウィンドウに戻ります。

8. ［Ctrl］+［C］を押して、管理サーバーのプロセスを停止します。

管理サーバーのプロセスが停止し、ターミナル・コマンド・プロンプトが表示されるのを待ちます。

10.7 ドメイン・ディレクトリの構成とMFTHOST1上のサーバーの起動

ドメインを作成し、ノード・マネージャを構成したら、MFTHOST1で追加のドメイン・ディレクトリを構成し、管理サーバーおよび管理対象サーバーを起動できます。

- ノード・マネージャを使用した管理サーバーの起動
ドメインを構成し、ノード・マネージャを構成したら、ノード・マネージャを使用して管理サーバーを起動できます。エンタープライズ・デプロイメントでは、ドメイン内の管理サーバーおよびすべての管理対象サーバーの起動および停止にノード・マネージャが使用されます。

- 管理サーバーの検証
構成手順に進む前に、管理サーバーにインストールおよび構成されているOracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認し、管理サーバーが正常に起動したことを確認します。

- Derbyデータベースの無効化

- SOAHOST1での管理対象サーバーの個別ドメイン・ディレクトリの作成
エンタープライズ・デプロイメント用にドメインを初期作成すると、ドメイン・ディレクトリは共有ディスクにあります。このデフォルト・ドメイン・ディレクトリは、管理サーバーの実行に使用されます。これで、SOAHOST1とSOAHOST2の両方で、ローカル記憶域にドメインのコピーを作成できるようになりました。ローカル(またはプライベート)記憶域上のドメイン・ディレクトリは、管理対象サーバーの実行に使用されます。

- SOAHOST1でのWLS_WSM1管理対象サーバーの起動と検証
ノード・マネージャを構成して管理対象サーバー・ドメイン・ディレクトリを作成したら、Oracle Enterprise Manager Fusion Middleware Controlを使用してSOAHOST1でWLS_WSM1管理対象サーバーを起動できます。

10.7.1 ノード・マネージャを使用した管理サーバーの起動

ドメインを構成し、ノード・マネージャを構成したら、ノード・マネージャを使用して管理サーバーを起動できます。エンタープライズ・デプロイメントでは、ドメイン内の管理サーバーおよびすべての管理対象サーバーの起動および停止にノード・マネージャが使用されます。

ノード・マネージャを使用して管理サーバーを起動する手順は次のとおりです。

1. WebLogic Scripting Tool(WLST)を起動します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

2. ノード・マネージャ資格証明を使用してノード・マネージャに接続します。

wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
'ADMINVHN','5556','domain_name',
'ASERVER_HOME','PLAIN')

注意:

このユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバー管理者IDおよびパスワードとは無関係であり、次のディレクトリにあるnm_password.propertiesファイルに格納されます。

ASERVER_HOME/config/nodemanager

3. 管理サーバーを起動します。

nmStart('AdminServer')

注意:

管理サーバーを起動すると、WebServicesポリシーのためにOracle Web Services Managerに接続しようとします。WSM-PM管理対象サーバーはまだ起動されていないため、管理サーバー・ログには次のメッセージが表示されると予想されます。

<Warning><oracle.wsm.resources.policymanager>
<WSM-02141><Unable to connect to the policy access service due to Oracle WSM policy manager host server being down.>

4. WLSTを終了します。

exit()

10.7.2 管理サーバーの検証

構成手順に進む前に、管理サーバーにインストールおよび構成されているOracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認し、管理サーバーが正常に起動したことを確認します。

Fusion Middleware Controlに移動するには、次のURLを入力し、Oracle WebLogic Server管理者の資格証明を使用してログインします。

ADMINVHN:7001/em

Oracle WebLogic Server管理コンソールに移動するには、次のURLを入力し、同じ管理者資格証明を使用してログインします。

ADMINVHN:7001/console

10.7.3 Derbyデータベースの無効化

管理対象サーバー・ディレクトリを作成して管理対象サーバーを起動する前に、Oracle WebLogic Serverに含まれるファイルベースのデータベースである組込みDerbyデータベースを無効にします。Derbyデータベースは主に開発環境に使用されます。そのため、本番対応のエンタープライズ・デプロイメント環境を構成する場合は無効にする必要があります。そうしないと、管理対象サーバーの起動時にDerbyデータベース・プロセスが自動的に起動されます。

Derbyを無効にするには、次のようにします。

1. Oracleホームの次のディレクトリに移動します。
WL_HOME/common/derby/lib

2. Derberライブラリjarファイル名を変更します。
mv derby.jar disable_derby.jar

3. SOAHOST1およびSOAHOST2の各ORACLE_HOMEで手順1から2を完了します(別個の共有ファイル・システムを使用している場合)。

10.7.4 SOAHOST1での管理対象サーバーの個別ドメイン・ディレクトリの作成

エンタープライズ・デプロイメント用にドメインを初期作成すると、ドメイン・ディレクトリは共有ディスクにあります。このデフォルト・ドメイン・ディレクトリは、管理サーバーの実行に使用されます。これで、SOAHOST1とSOAHOST2の両方で、ローカル記憶域にドメインのコピーを作成できるようになりました。ローカル(またはプライベート)記憶域上のドメイン・ディレクトリは、管理対象サーバーの実行に使用されます。

サーバーが共有記憶域にログを書き込むことによって発生する潜在的な競合とオーバーヘッドを排除するために、MSERVER_HOMEをローカル記憶域に配置することをお薦めします。また、必要なクラスおよびjarをドメイン・ディレクトリからロードするほうが高速であるため、管理対象サーバーがドメイン・ディレクトリから使用するtmpまたはキャッシュのデータのほうがより迅速に処理されます。

「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のように、管理サーバー・ドメイン・ホームのパスはASERVER_HOME変数によって表され、管理対象サーバー・ドメイン・ホームのパスはMSERVER_HOME変数によって表されます。

管理対象サーバーのドメイン・ディレクトリを作成する手順は次のとおりです。

1. SOAHOST1にログインし、次のようにpackコマンドを実行してテンプレートを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true
-domain=ASERVER_HOME
-template=complete_path/soadomaintemplate.jar
-template_name=soa_domain_template

この例では、次のようになります。

- ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

- complete_pathを、ドメイン・テンプレートJARファイルを作成する場所の完全なパスに置き換えます。ドメイン・テンプレートJARファイルをコピーまたは解凍する際に、この場所を参照する必要があります。

- soadomaintemplate.jarは作成するJARファイルのサンプル名であり、これにはドメイン構成ファイルが含まれます。

- soa_domain_templateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

2. packコマンドで作成したばかりのsoadomaintemplate.jarファイルの場所を書き留めます。

テンプレートJARファイルの完全なパスを、packコマンドの-template引数の一部として指定する必要があります。

ORACLE_COMMON_HOME/common/bin/

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

3. まだ作成していない場合は、SOAHOST1のローカル記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME \
-overwrite_domain=true \
-template=complete_path/soadomaintemplate.jar \
-log_priority=DEBUG \
-log=/tmp/unpack.log \
-app_dir=APPLICATION_HOME \

注意:

unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

また、ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverrides.shというファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のjavaコマンド行オプションの指定、追加の環境変数の指定などを行うよう構成できます。このファイルに追加されたカスタマイズはドメインのアップグレード操作中に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。

この例では、次のようになります。

- MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

- complete_pathを、テンプレートJARファイルを作成またはコピーした場所の完全なパスに置き換えます。

- soadomaintemplate.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートJARファイルの名前です。

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

5. ディレクトリを、新しく作成した管理対象サーバー・ディレクトリに変更して、ドメイン構成ファイルがSOAHOST1のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

10.7.5 SOAHOST1でのWLS_WSM1管理対象サーバーの起動と検証

ノード・マネージャを構成して管理対象サーバー・ドメイン・ディレクトリを作成したら、Oracle Enterprise Manager Fusion Middleware Controlを使用してSOAHOST1でWLS_WSM1管理対象サーバーを起動できます。

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

http://ADMINVHN:7001/em

この例では、次のようになります。

- ADMINVHNを、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」でADMINVHN仮想IPアドレスに割り当てたホスト名に置き換えます。

- ポート7001は、管理サーバー・コンソールおよびFusion Middleware Controlで一般的に使用されるポートです。ただし、ドメインを作成したときに構成ウィザードのセッションの終わりに表示された実際のURLを使用する必要があります。

ヒント:

Oracle Enterprise Manager Fusion Middlewareを使用したOracle Fusion Middlewareの管理の詳細は、Oracle Fusion Middlewareの管理のOracle Enterprise Manager Fusion Middleware Controlの使用のスタート・ガイドを参照してください。

2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

3. 「サーバー」ペインを選択して、ドメイン内の管理対象サーバーを表示します。

4. WLS_WSM1管理対象サーバーのみを選択して、ツールバーで「コントロール」>「起動」をクリックします。

5. 管理対象サーバーが正しく機能していることを検証するには、ブラウザを開き、次のURLを入力します。

SOAHOST1:7010/wsm-pm/

要求に従って、ドメイン管理ユーザー名とパスワードを入力します。

10.8 ドメインの伝播とMFTHOST2上のサーバーの起動

MFTHOST1で管理サーバーとWLS_WSM1管理対象サーバーを起動して検証したら、MFTHOST2で次のタスクを実行できます。

- MFTHOST2でのドメイン構成の解凍

- SOAHOST2でのドメインの解凍

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

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

10.8.1 MFTHOST2でのドメイン構成の解凍

MFTHOST1で管理サーバーと最初のWLS_WSM1管理対象サーバーを実行した後、MFTHOST2でドメインを構成できます。

1. MFTHOST2にログインします。

2. まだ作成していない場合は、MFTHOST2の記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

3. MFTHOST2からmftdomaintemplate.jarにアクセスできることを確認します。
たとえば、MFTHOST2に別の共有記憶域ボリュームまたはパーティションを使用している場合は、MFTHOST2にマウントされているボリュームまたはパーティションにテンプレートをコピーします。

4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME
-overwrite_domain=true
-template=complete_path/mftdomaintemplate.jar
-log_priority=DEBUG
-log=/tmp/unpack.log
-app_dir=APPLICATION_HOME

この例では、次のようになります。

- MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

- complete_path/mftdomaintemplate.jarを、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したドメイン・テンプレートJARファイルの完全なパスとファイル名に置き換えます。

- APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

5. ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがMFTHOST2のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

10.8.2 SOAHOST2でのドメインの解凍

この手順では、以前に作成したファイルを、SOAHOST1とSOAHOST2の両方からアクセスできる場所(たとえば、共有記憶域ファイラ上のASERVER_HOMEディレクトリなど)にコピー済であることを想定しています。

1. SOAHOST2にログインします。

2. まだ作成していない場合は、SOAHOST2の記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

3. SOAHOST2からsoadomaintemplate.jarにアクセスできることを確認します。
たとえば、SOAHOST2に別の共有記憶域ボリュームまたはパーティションを使用している場合は、SOAHOST2にマウントされているボリュームまたはパーティションにテンプレートをコピーします。

4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME
-overwrite_domain=true
-template=complete_path/soadomaintemplate.jar
-log_priority=DEBUG
-log=/tmp/unpack.log
-app_dir=APPLICATION_HOME

この例では、次のようになります。

- MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

- complete_path/soadomaintemplate.jarを、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したドメイン・テンプレートJARファイルの完全なパスとファイル名に置き換えます。

- APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

5. ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがSOAHOST2のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

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

ホストごとのノード・マネージャ構成を使用するようにノード・マネージャを手動で設定したら、SOAHOST2で次のコマンドを使用してノード・マネージャを起動できます。

1. ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。

cd NM_HOME

2. 次のコマンドを実行してノード・マネージャを起動し、コマンドの出力を現在のターミナル・シェルではなく出力ファイルに送信します。

nohup ./startNodeManager.sh > nodemanager.out 2>&1 &

10.8.4 SOAHOST2でのWLS_WSM2管理対象サーバーの起動と検証

「SOAHOST1でのWLS_WSM1管理対象サーバーの起動と検証」の手順を使用して、SOAHOST2上のWLS_WSM2管理対象サーバーを起動および検証します。

10.9 uploadおよびstageディレクトリの絶対パスへの変更

ドメインを構成し、すべてのホスト上の管理対象サーバーのドメイン・ディレクトリにそのドメインを解凍した後、新しい管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

この手順は、リモート・デプロイメントの実行時の潜在的な問題の回避とステージ・モードが必要なデプロイメントのために必要です。

管理対象サーバー・ドメイン・ホーム・ディレクトリ内のすべての管理対象サーバーについてこれらのディレクトリ・パスを更新する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 左側のナビゲーション・ツリーで、「ドメイン」→「環境」を開きます。

3. 「ロックして編集」をクリックします。

4. 「サーバー」をクリックします。

5. 管理対象サーバー・ドメイン・ホーム・ディレクトリ内の新しい管理対象サーバーごとに次の操作を実行します。

a. 管理対象サーバーの名前をクリックします。

b. 「構成」タブをクリックし、「デプロイメント」タブをクリックします。

c. 「ステージング・ディレクトリ名」が次のように設定されていることを確認します。

MSERVER_HOME/servers/server_name/stage

MSERVER_HOMEをMSERVER_HOMEディレクトリのディレクトリ・パスに置き換え、server_nameを編集しているサーバーの名前に置き換えます。

d. 「アップロード・ディレクトリ名」を次の値に更新します。

ASERVER_HOME/servers/AdminServer/upload

ASERVER_HOMEをASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。

e. 「保存」をクリックします。

f. 「サーバーのサマリー」画面に戻ります。

6. 各管理対象サーバーについてこれらの値を変更したら、「変更のアクティブ化」をクリックします。

7. すべての管理対象サーバーを再起動します。

10.10 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング

Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダ(DefaultAuthenticator)を使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用することをお薦めします。

次の各項では、Oracle WebLogic Server管理コンソールを使用してエンタープライズ・デプロイメント・ドメイン用の新しい認証プロバイダを作成する方法を説明します。この手順では、サポートされているLDAPディレクトリ(Oracle Unified DirectoryやOracle Internet Directoryなど)をすでにインストールおよび構成していることを想定しています。

- サポートされている認証プロバイダについて

- エンタープライズ・デプロイメントのユーザーおよびグループについて

- 新しい認証プロバイダの作成と新しいユーザーおよびグループのプロビジョニングの前提条件

- LDAPディレクトリでのドメイン・コネクタ・ユーザーのプロビジョニング

- 新しい認証プロバイダの作成

- エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング

- 管理グループへの新しい管理ユーザーの追加

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

10.10.1 サポートされている認証プロバイダについて

Oracle Fusion Middlewareでは、様々なLDAP認証プロバイダをサポートしています。詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のアイデンティティ・ストア・タイプおよびWebLogicオーセンティケータに関する項を参照してください。

このガイドの手順では、次のいずれかのプロバイダを使用していることを想定しています。

- Oracle Unified Directory

- Oracle Internet Directory

- Oracle Virtual Directory

注意:

ここに示す手順では、デフォルトで単一のLDAPアイデンティティ・ストアに対する問合せをサポートするようにアイデンティティ・サービス・インスタンスを構成する方法を説明します。

ただし、LibOVDを使用して、複数のLDAPアイデンティティ・ストアに問合せを行う仮想アイデンティティ・ストアをサポートするようにサービスを構成できます。

複数LDAP参照に関する詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のアイデンティティ・ストア・サービスの構成に関する項を参照してください。

10.10.2 エンタープライズ・デプロイメント・ユーザーおよびグループについて

次の各項では、エンタープライズ・デプロイメント管理ユーザーおよびグループの用途と特性に関する重要な情報を提供します。

- 各ドメインで一意の管理ユーザーの使用について

- ドメイン・コネクタ・ユーザーについて

- 集中LDAPディレクトリへのユーザーの追加について

- Oracle SOA Suiteの製品固有のロールとグループについて

- このガイドで使用するサンプル・ユーザーとサンプル・ロール

10.10.2.1 各ドメインで一意の管理ユーザーの使用について

集中LDAPユーザー・ストアを使用すると、複数のOracle WebLogic Serverドメインで使用するユーザーおよびグループをプロビジョニングできます。その結果、あるWebLogic管理ユーザーがエンタープライズ内のすべてのドメインにアクセスできてしまうことにもなります。

このようなアプローチはお薦めしません。かわりに、Oracle Fusion Middlewareドメインの管理用にプロビジョニングするユーザーおよびグループにディレクトリ・ツリー内で一意の識別名(DN)を割り当てる方法をお薦めします。

たとえば、Oracle SOA Suiteエンタープライズ・デプロイメント・ドメインをインストールおよび構成する場合は、weblogic_soaというユーザーとSOA Administratorsという管理グループを作成します。

10.10.2.2 ドメイン・コネクタ・ユーザーについて

Oracleでは、LDAPディレクトリに別個のドメイン・コネクタ・ユーザー(soaLDAPなど)を作成することをお薦めしています。こうすることで、ドメインでユーザー認証のためにLDAPディレクトリに接続できます。このユーザーは非管理ユーザーにすることをお薦めします。

標準的なOracle Identity and Access Managementデプロイメントでは、このユーザーはsystemidsコンテナで作成します。このコンテナは、通常ユーザーには表示されないシステム・ユーザーに使用されます。このユーザーをsystemidsコンテナに配置することで、Oracle Identity Managerを持つユーザーがこのユーザーを調整しないようにできます。

10.10.2.3 集中LDAPディレクトリへのユーザーの追加について

集中LDAPディレクトリをエンタープライズ・ドメインのオーセンティケータとして構成した後は、すべての新規ユーザーをデフォルトのWebLogic Serverオーセンティケータではなく新しいオーセンティケータに追加する必要があります。

集中LDAPディレクトリに新規ユーザーを追加する際、WebLogic管理コンソールは使用できません。かわりに、ldapbrowserやJXplorerなどの適切なLDAP変更ツールを使用する必要があります。

複数のオーセンティケータを使用している場合(エンタープライズ・デプロイメントの要件)、ログインや認証は実行できますが、ロール取得は実行できません。ロールは、最初のオーセンティケータからのみ取得できます。他のオーセンティケータを使用してロールを取得する場合は、ドメインの仮想化を有効にする必要があります。

仮想化の有効化には、次の手順が含まれます。

1. 次の構成ファイルを探してテキスト・エディタで開きます。

DOMAIN_HOME/config/fmwconfig/jps-config.xml

2. name="idstore.ldap"およびprovider="idstore.ldap.provider"を持つserviceInstanceタグで、次のプロパティを追加または更新します。

<property name="virtualize" value="true"/>

仮想化プロパティの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のOPSSシステムおよび構成プロパティに関する項を参照してください。

10.10.2.4 Oracle SOA Suiteの製品固有のロールとグループについて

Oracle Fusion Middleware製品ごとに、管理および監視のために事前定義された独自のロールおよびグループが実装されます。

そのため、ドメインを拡張して他の製品を追加するときに、これらの製品固有のロールをSOA Administratorsグループに割り当てることができます。ロールがSOA Administratorsグループに追加されると、各製品管理者ユーザーは管理タスクを実行するための同じ権限セットを使用してドメインを管理できます。

SOA Administratorsグループに他のロールを追加する手順については、「エンタープライズ・デプロイメントの共通の構成および管理タスク」を参照してください。

10.10.2.5 このガイドで使用するサンプル・ユーザーとサンプル・ロール

このガイドで使用するサンプルでは、下に示すDNを持つ次の管理ユーザーおよび管理グループをプロビジョニングすることを想定しています。

- 管理ユーザーのDN:

cn=weblogic_soa,cn=users,dc=example,dc=com

- 管理グループDN:

cn=SOA Administrators,cn=groups,dc=example,dc=com

- 製品固有のLDAPコネクタ・ユーザー:

cn=soaLDAP,cn=systemids,dc=example,dc=com
これは、WebLogic管理対象サーバーをLDAP認証プロバイダに接続するときに使用するユーザーです。このユーザーには、ディレクトリに対する読取り権限および書込み権限が必要です。

cn=users,dc=example,dc=com
cn=groups,dc=example,dc=com

注意:

Oracle Unified Directoryを使用する場合、このユーザーに次のグループのメンバーシップが付与され、読取りおよび書込みアクセス権が付与される必要があります。

cn=orclFAUserReadPrivilegeGroup,cn=groups,dc=example,dc=com
cn=orclFAUserWritePrivilegeGroup,cn=groups,dc=example,dc=com
cn=orclFAGroupReadPrivilegeGroup,cn=groups,dc=example,dc=com
cn=orclFAGroupWritePrivilegeGroup,cn=groups,dc=example,dc=com

10.10.3 新しい認証プロバイダの作成とユーザーおよびグループのプロビジョニングの前提条件

新しいLDAP認証プロバイダを作成する前に、関連する構成ファイルをバックアップする必要があります。

ASERVER_HOME/config/config.xml
ASERVER_HOME/config/fmwconfig/jps-config.xml
ASERVER_HOME/config/fmwconfig/system-jazn-data.xml

さらに、次のディレクトリにある管理サーバーのboot.propertiesファイルをバックアップする必要があります。

DOMAIN_HOME/servers/AdminServer/security

10.10.4 LDAPディレクトリでのドメイン・コネクタ・ユーザーのプロビジョニング

この例では、集中LDAPディレクトリでsoaLDAPというユーザーを作成する方法を示します。

LDAPプロバイダでユーザーをプロビジョニングするには:

1. 次に示す内容のdomain_user.ldifという名前のldifファイルを作成して保存します。

dn: cn=soaLDAP,cn=systemids,dc=example,dc=com
changetype: add
orclsamaccountname: soaLDAP
userpassword: password
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: orcluser
objectclass: orcluserV2
mail: soaLDAP@example.com
givenname: soaLDAP
sn: soaLDAP
cn: soaLDAP
uid: soaLDAP

注意:

Oracle Unified Directoryを使用する場合、次の4つのグループ・メンバーシップをLDIFファイルの最後に追加して適切な読取り/書込み権限を付与します。

dn:
cn=orclFAUserReadPrivilegeGroup,cn=groups,dc=example,dc=example
changetype: modify
add: uniquemember
uniquemember: cn=soaLDAP,cn=systemids,dc=example,dc=example

dn: cn=orclFAGroupReadPrivilegeGroup,cn=groups,dc=example,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=soaLDAP,cn=systemids,dc=example,dc=example

dn: cn=orclFAUserWritePrivilegeGroup,cn=groups,dc=example,dc=example
changetype: modify
add: uniquemember
uniquemember: cn=soaLDAP,cn=systemids,dc=example,dc=com

dn: cn=orclFAGroupWritePrivilegeGroup,cn=groups,dc=example,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=soaLDAP,cn=systemids,dc=example,dc=com

2. LDAPディレクトリでユーザーをプロビジョニングします。
たとえば、Oracle Unified Directory LDAPプロバイダの場合は次のように記述します。

OUD_INSTANCE_HOME/bin/ldapmodify -a \
-h oudhost.example.com
-D "cn=oudadmin" \
-w password \
-p 1389 \
-f domain_user.ldif

Oracle Internet Directoryの場合:

OID_ORACLE_HOME/bin/ldapadd -h oidhost.example.com \
-p 3060 \
-D cn="orcladmin" \
-w password \
-c \
-v \
-f domain_user.ldif

10.10.5 新しい認証プロバイダの作成

新しいLDAPベースの認証プロバイダを構成する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインします。

2. 左のナビゲーション・バーにある「セキュリティ・レルム」をクリックします。

3. myrealmというデフォルト・レルム・エントリをクリックします。

4. 「プロバイダ」タブをクリックします。
このレルムに対してDefaultAuthenticatorというプロバイダが構成されていることに注目してください。これは、デフォルトのWebLogic Server認証プロバイダです。

5. 「チェンジ・センター」で「ロックして編集」をクリックします。

6. 「認証プロバイダ」表の下の「新規」ボタンをクリックします。

7. プロバイダの名前を入力します。
資格証明ストアとして使用する予定のLDAPディレクトリ・サービスに基づいて、次のいずれかの名前を使用します。

- OUDAuthenticator (Oracle Unified Directoryの場合)

- OIDAuthenticator (Oracle Internet Directoryの場合)

- OVDAuthenticator (Oracle Virtual Directoryの場合)

8. 「タイプ」ドロップダウン・リストでオーセンティケータ・タイプを選択します。
資格証明ストアとして使用する予定のLDAPディレクトリ・サービスに基づいて、次のいずれかのタイプを選択します。

- OracleUnifiedDirectoryAuthenticator (Oracle Unified Directoryの場合)

- OracleInternetDirectoryAuthenticator (Oracle Internet Directoryの場合)

- OracleVirtualDirectoryAuthenticator (Oracle Virtual Directoryの場合)

9. 「OK」をクリックして「プロバイダ」画面に戻ります。

10. 「プロバイダ」画面の表で、新しく作成したオーセンティケータをクリックします。

11. 「制御フラグ」ドロップダウン・メニューで「SUFFICIENT」を選択します。

制御フラグをSUFFICIENTに設定すると、そのオーセンティケータがユーザーを正常に認証できる場合はその認証を受け入れ、それ以上のオーセンティケータを起動しません。

認証に失敗した場合、そのユーザーは、チェーンにある次の順番の認証プロバイダに引き継がれます。以降のすべてのオーセンティケータの制御フラグもSUFFICIENTに設定されていることを確認してください。特にDefaultAuthenticatorをチェックして、その制御フラグがSUFFICIENTに設定されていることを確認します。

12. 「保存」をクリックして制御フラグの設定を保存します。

13. 「プロバイダ固有」タブをクリックし、次の表に示すように、使用するLDAPサーバーに固有の詳細を入力します。
この手順では、必須フィールドのみを説明しています。このページのすべてのフィールドの詳細は、次のリソースを参照してください。

- 各フィールドの説明を表示するには、「プロバイダ固有」タブの「ヘルプ」をクリックします。

- 「ユーザー・ベースDN」、「名前指定によるユーザー・フィルタ」、「ユーザー属性」の各フィールドの設定に関する詳細は、『Oracle WebLogic Serverセキュリティの管理』のOracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダでのユーザーおよびグループの構成に関する項を参照してください。

パラメータ

サンプル値

値の説明

ホスト

例: oud.example.com

LDAPサーバーのサーバーID。

ポート

例: 1689

LDAPサーバーのポート番号。

プリンシパル

例: cn=soaLDAP, cn=systemids,dc=example,dc=com

LDAPサーバーへの接続に使用されるLDAPユーザーのDN。

資格証明

LDAPパスワードを入力します。

LDAPサーバーへの接続に使用されるパスワード。

SSL有効

未チェック(クリア)

LDAPサーバーに接続するときにSSLプロトコルを使用するかどうかを指定します。

ユーザー・ベースDN

例: cn=users,dc=example,dc=com

ユーザーが開始時に使用するDNを指定します。

すべてのユーザーのフィルタ

(&(uid=*)(objectclass=person))

すべてのユーザーのフィルタのデフォルトの検索条件のかわりにuid値に基づいてすべてのユーザーを検索します。

LDAPディレクトリ構造のユーザー・オブジェクト・クラスの「ユーザー名属性」がuid以外のタイプである場合は、「名前指定によるユーザー・フィルタ」フィールドでそのタイプを変更します。

たとえば、「ユーザー名属性」のタイプがcnである場合は、このフィールドを次のように設定する必要があります。

(&(cn=*)(objectclass=person)))

名前指定によるユーザー・フィルタ

例:

(&(uid=%u)(objectclass=person))

LDAPディレクトリ構造のユーザー・オブジェクト・クラスの「ユーザー名属性」がuid以外のタイプである場合は、「名前指定によるユーザー・フィルタ」の設定で、そのタイプを変更します。

たとえば、「ユーザー名属性」のタイプがcnである場合は、このフィールドを次のように設定する必要があります。

(&(cn=%u)(objectclass=person)))

ユーザー名属性

例: uid

グループの名前を指定するLDAPユーザー・オブジェクトの属性。

グループ・ベースDN

例: cn=groups,dc=example,dc=com

グループ・ノードを指すDNを指定します。

取得したユーザー名をプリンシパルとして使用する

チェック・ボックスを選択

オンにする必要があります。

GUID属性

entryuuid

OUDにOracleUnifiedDirectoryAuthenticatorが使用される場合、この値にはentryuuidが事前に移入されます。認証プロバイダとしてOracle Unified Directoryを使用している場合はこの値を入力します。

14. 「保存」をクリックして変更を保存します。

15. 右のナビゲーション・ペインで「セキュリティ・レルム」をクリックして、デフォルトのレルム名(myrealm)をクリックし、「プロバイダ」をクリックして「プロバイダ」ページに戻ります。

16. 「並替え」をクリックし、表示されたページを使用して、作成したプロバイダを認証プロバイダのリストの先頭に配置します。

17. 「OK」をクリックします。

18. チェンジ・センターで、変更のアクティブ化 をクリックします。

19. 管理サーバーとすべての管理対象サーバーを再起動します。

管理対象サーバーを停止するには、Fusion Middleware Controlにログインし、ターゲットのナビゲータで管理対象サーバーを選択して、ツールバーで「停止」をクリックします。

ノード・マネージャを使用して管理サーバーを停止および起動する手順は次のとおりです。

a. WLSTを起動します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

b. 構成ウィザードでドメインを作成したときに定義した、次のノード・マネージャ資格証明を使用してノード・マネージャに接続します。

wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
'ADMINVHN','5556','domain_name',
'ASERVER_HOME','PLAIN')

c. 管理サーバーを停止します。

nmKill('AdminServer')

d. 管理サーバーを起動します。

nmStart('AdminServer')

e. WLSTを終了します。

exit()

管理対象サーバーを起動するには、Fusion Middleware Controlにログインし、管理対象サーバーを選択して、ツールバーで「起動」をクリックします。

20. 再起動後に、次のログ・ファイルの内容を確認します。

ASERVER_HOME/servers/AdminServer/logs/AdminServer.log

LDAP接続エラーが発生していないことを確認します。たとえば、次のようなエラーを探します。

The LDAP authentication provider named "OUDAuthenticator" failed to make connection to ldap server at ...

ログ・ファイルでこのようなエラーが見つかった場合は、認可プロバイダ接続の詳細をチェックして、それらが適切であることを確認し、管理サーバーの保存と再起動をもう一度試みます。

21. 再起動後、LDAP接続エラーがログ・ファイルに記述されていないことを確認し、LDAPプロバイダ内に存在するユーザーとグループの参照を試みます。
管理コンソールで、「セキュリティ・レルム」→「myrealm」→「ユーザーとグループ」ページに移動します。LDAPプロバイダ構造内に存在するすべてのユーザーおよびグループを表示できるようになります。

10.10.6 エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング

この例では、weblogic_soaというユーザーとSOA Administratorsというグループを作成する方法を示します。

LDAPプロバイダで管理ユーザーおよび管理グループをプロビジョニングする手順は次のとおりです。

1. 次に示す内容のadmin_user.ldifという名前のldifファイルを作成して保存します。

dn: cn=weblogic_soa,cn=users,dc=example,dc=com
changetype: add
orclsamaccountname: weblogic_soa
userpassword: password
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: orcluser
objectclass: orcluserV2
mail: weblogic_soa@example.com
givenname: weblogic_soa
sn: weblogic_soa
cn: weblogic_soa
uid: weblogic_soa

2. LDAPディレクトリでユーザーをプロビジョニングします。
たとえば、Oracle Unified Directory LDAPプロバイダの場合は次のように記述します。

OUD_INSTANCE_HOME/bin/ldapmodify -a \
-h oudhost.example.com
-D "cn=oudadmin" \
-w password \
-p 1389 \
-f admin_user.ldif

Oracle Internet Directoryの場合:

OID_ORACLE_HOME/bin/ldapadd -h oidhost.example.com \
-p 3060 \
-D cn="orcladmin" \
-w password \
-c \
-v \
-f admin_user.ldif

3. admin_group.ldifという名前のldifファイルを作成して、次の内容を入力してからこのファイルを保存します。

dn: cn=SOA Administrators,cn=Groups,dc=example,dc=com
displayname: SOA Administrators
objectclass: top
objectclass: SOA Administrators
objectclass: orclGroup
uniquemember: cn=weblogic_soa,cn=users,dc=example,dc=com
cn:SOA Administrators
description: Administrators Group for the Oracle SOA Suite Domain

4. LDAPディレクトリでグループをプロビジョニングします。
Oracle Unified Directoryの場合:

OUD_INSTANCE_HOME/bin/ldapmodify -a \
-D "cn=oudadmin" \
-h oudhost.example.com \
-w password \
-p 3060 \
-f admin_group.ldif

Oracle Internet Directoryの場合:

OID_ORACLE_HOME/bin/ldapadd -h oid.example.com \
-p 3060 \
-D cn="orcladmin" \
-w password \
-c \
-v \
-f admin_group.ldif

5. 変更が正常に行われたことを確認します。

a. Oracle WebLogic Server管理コンソールにログインします。

b. コンソールの左ペインで「セキュリティ・レルム」をクリックします。

c. デフォルト・セキュリティ・レルム(myrealm)をクリックします。

d. 「ユーザーとグループ」タブをクリックします。

e. プロビジョニングした管理者ユーザーおよびグループがページに表示されていることを確認します。

10.10.7 管理グループへの新しい管理ユーザーの追加

Oracle Internet Directoryにユーザーおよびグループを追加したら、WebLogicドメインのセキュリティ・レルム内でそのグループに管理ロールを割り当てる必要があります。これにより、このグループに属するすべてのユーザーがそのドメインの管理者になることができます。

管理ロールを新しいエンタープライズ・デプロイメント管理グループに割り当てる手順は次のとおりです。

1. 構成ウィザードで指定した管理資格証明を使用してWebLogic管理サーバー・コンソールにログインします。

作成して新しい認証プロバイダに提供した管理ユーザーの資格証明は使用しないでください。

2. 管理コンソールの左ペインで「セキュリティ・レルム」をクリックします。

3. デフォルト・セキュリティ・レルム(myrealm)をクリックします。

4. 「ロールとポリシー」タブをクリックします。

5. 表の「グローバル・ロール」エントリを開き、「ロール」をクリックします。

6. 「管理」ロールをクリックします。

7. 「ロール条件の表示」ボタンをクリックします。

8. 「述部リスト」ドロップダウン・メニューで「グループ」を選択し、「次へ」をクリックします。

9. 「グループ引数名」フィールドにSOA Administratorsと入力して、「追加」をクリックします。

引数のリスト・ボックスにSOA Administratorsが追加されます。

10. 「終了」をクリックして、「グローバル・ロールの編集」ページに戻ります。

SOA Administratorsグループが表示されています。

11. 「保存」をクリックすると、SOA Administratorsグループに管理ロールを追加する処理が終了します。

12. 新しいweblogic_soaユーザー資格証明を使用してWebLogic管理サーバー・コンソールにログインし、変更されていることを確認します。

新しい認証プロバイダでプロビジョニングした新しい管理ユーザーの資格証明を使用してOracle WebLogic Server管理コンソールとFusion Middleware Controlにログインできる場合は、プロバイダは正常に構成されています。

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

新しい管理ユーザーおよびグループを作成したら、LDAPディレクトリで作成した管理ユーザー資格証明を使用して管理サーバーのboot.propertiesファイルを更新する必要があります。

1. SOAHOST1で、次のディレクトリに移動します。

ASERVER_HOME/servers/AdminServer/security

2. 既存のboot.propertiesファイルの名前を変更します。

mv boot.properties boot.properties.backup

3. テキスト・エディタを使用して、セキュリティ・ディレクトリにboot.propertiesというファイルを作成します。

4. 次の行をこのファイルに入力します。

username=weblogic_soa
password=password

5. ファイルを保存します。

6. 管理サーバーを再起動します。

10.11 Administratorsグループへのwsm-pmロールの追加

新しいLDAPベースの認可プロバイダを構成して管理サーバーを再起動したら、エンタープライズ・デプロイメント管理LDAPグループ(SOA Administrators)をメンバーとしてwsm-pmアプリケーション・ストライプのpolicy.Updaterロールに追加します。

1. Oracle WebLogic Server管理サーバーの資格証明を使用して、Oracle Enterprise Manager Fusion Middleware Controlにログインします。

これらは、最初にドメインを構成し、Oracle WebLogic Server管理ユーザー名(通常weblogic_soa)とパスワードを作成したときに作成した資格証明です。

2. 「WebLogicドメイン」メニューから、「セキュリティ」→「アプリケーション・ロール」を選択します。

3. policy.Updaterロールに対して、「アプリケーション・ストライプ」ドロップダウン・メニューからwsm-pmアプリケーション・ストライプを選択します。

4. 「アプリケーション・ロールの検索」アイコンをクリックして、ドメインで利用できるすべてのアプリケーション・ロールを表示します。

5. エンタープライズ・デプロイメントの管理グループに追加するpolicy.Updaterロールの行を選択します。

6. 「編集」アイコンをクリックして、ロールを編集します。

7. 「アプリケーション・ロールの編集」ページの「追加」アイコンをクリックします。

8. 「プリンシパルの追加」ダイアログ・ボックスで、「タイプ」ドロップダウン・メニューから「グループ」を選択します。

9. 「プリンシパル名」の「次で始まる」フィールドにグループ名SOA Administratorsを入力し、右矢印をクリックして検索を開始して、エンタープライズ・デプロイメントの管理者グループを検索します。

10. 検索結果で管理者グループを選択し、「OK」をクリックします。

11. 「アプリケーション・ロールの編集」ページで、「OK」をクリックします。

11 エンタープライズ・デプロイメント用のOracle HTTP Serverの構成

Web層を構成する場合、Oracle HTTP ServerまたはOracle Traffic Directorの使用を選択できます。Oracle HTTP Serverを選択して使用する場合、各Web層ホストにOracle HTTP Serverをインストールし、各ホストでOracle HTTPスタンドアロン・ドメインを構成する必要があります。

Web層のOracle HTTP Serverインスタンスによって、HTTPリクエストがハードウェア・ロード・バランサからアプリケーション層の特定の管理対象サーバーに転送されます。

Oracle HTTP Serverを構成する前に、「Web層の理解」を確認してください。

注意:

Oracle Managed File Transferを構成する予定の場合、TCPを介してFTPおよびSFTPリクエストをルーティングするようにOracle Traffic Directorを構成する必要があります。詳細は、「エンタープライズ・デプロイメントでのOracle Managed File Transferの構成」を参照してください。

- Oracle HTTP Serverの構成時に使用される変数
この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

- Oracle HTTP Serverドメインについて
エンタープライズ・デプロイメントでは、各Oracle HTTP Serverインスタンスは別個のホストおよび独自のスタンドアロン・ドメイン内に構成されます。これにより、実行および管理に必要な構成およびリソースを最小限に抑えた簡易な構成が可能になります。

- WEBHOST1へのOracle HTTP Serverのインストール
次の項では、Web層にOracle HTTP Serverソフトウェアをインストールする方法について説明します。

- WEBHOST1でのOracle HTTP Serverドメインの作成
次の項では、最初のWeb層ホストで新しいOracle HTTP Serverスタンドアロン・ドメインを作成する方法について説明します。

- WEBHOST2でのOracle HTTP Serverドメインのインストールおよび構成
WEBHOST1でOracle HTTP Serverをインストールしてドメインを構成したら、同じタスクをWEBHOST2でも実行する必要があります。

- WEBHOST1およびWEBHOST2でのノード・マネージャおよびOracle HTTP Serverインスタンスの起動
次の項では、WEBHOST1およびWEBHOST2でOracle HTTP Serverインスタンスを起動する方法について説明します。

- リクエストをアプリケーション層にルーティングするようにOracle HTTP Serverを構成
次の各項では、Webサーバー・インスタンスがリクエストをドメイン内のサーバーにルーティングするようにOracle HTTP Server構成ファイルを更新する方法を説明します。

親トピック: エンタープライズ・デプロイメントの構成

11.1 Oracle HTTP Serverの構成時に使用される変数

この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

いくつかのディレクトリ変数の値については、「このガイドで使用するファイル・システムとディレクトリ変数」に定義されています。

- OHS_ORACLE_HOME

- OHS_DOMAIN_HOME

さらに、仮想IP (VIP)アドレスとホスト名を参照することになります。

- ADMINVHN

- WEBHOST1

- WEBHOST2

11.2 Oracle HTTP Serverドメインについて

エンタープライズ・デプロイメントでは、各Oracle HTTP Serverインスタンスは別個のホストおよび独自のスタンドアロン・ドメイン内に構成されます。これにより、実行および管理に必要な構成およびリソースを最小限に抑えた簡易な構成が可能になります。

Web層でのOracle HTTP Serverインスタンスのロールおよび構成の詳細は、「Web層の理解」を参照してください。

11.3 WEBHOST1へのOracle HTTP Serverのインストール

次の項では、Web層にOracle HTTP Serverソフトウェアをインストールする方法について説明します。

- WEBHOST1でのインストーラの起動

- Oracle HTTP Serverのインストール画面のナビゲート

- Oracle HTTP Serverインストールの確認

11.3.1 WEBHOST1でのインストーラの起動

インストール・プログラムを起動するには、次の手順を実行します。

1. WEBHOST1にログインします。

2. インストール・プログラムをダウンロードしたディレクトリに移動します。

3. 次のコマンドを入力して、インストール・プログラムを起動します。

./fmw_12.2.1.0.0_ohs_linux64.bin

インストール・プログラムが表示されると、インストールを開始する準備ができています。

11.3.2 Oracle HTTP Serverのインストール画面のナビゲート

次の表に、インストール・プログラムで表示される順序で画面をリストします。

インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。

画面

説明

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面では、使用可能なパッチを探してMy Oracle Supportを自動的に検索するか、組織にすでにダウンロードしたパッチを探してローカル・ディレクトリを自動的に検索します。

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

エンタープライズ・デプロイメントのためには、表7-3に示すOHS_ORACLE_HOME変数の値を入力します。

インストール・タイプ

「スタンドアロンHTTPサーバー(WebLogic Serverとは別に管理される)」を選択します。

このインストール・タイプでは、他の既存のOracle WebLogic Serverドメインとは別個にOracle HTTP Serverインスタンスを構成できます。

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告またはエラー・メッセージが表示された場合、ホスト・コンピュータおよび必須ソフトウェアが「ホスト・コンピュータのハードウェア要件」および「エンタープライズ・デプロイメント・トポロジのオペレーティング・システム要件」に示すシステム要件および動作保証情報を満たしていることを確認してください。

セキュリティ・アップデート

Oracle Supportアカウントをすでに所持している場合は、この画面を使用して、セキュリティ・アップデートの受取り方法を指定します。

アカウントを所有していない場合、またはこの手順をスキップする場合は、チェック・ボックスの選択を解除し、フォローアップのダイアログ・ボックスで選択を確認します。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを確認します。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。レスポンス・ファイルは、今後、サイレント・インストールを実行する場合に使用できます。

サイレント・インストールやコマンド行インストールの詳細は、Oracle Universal Installerによるソフトウェアのインストールでサイレント・モードにおけるOracle Universal Installerの使用方法に関する項を参照してください。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

インストール完了

インストールが完了すると、この画面が表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

11.3.3 Oracle HTTP Serverインストールの確認

Oracle HTTP Serverのインストールが正常に完了したことを確認するために、新しいOracleホームにインストールされたファイルをリストします。Oracle HTTP ServerのOracleホームには、次のディレクトリが表示されるはずです。

ldap
ohs
css
srvm
has
crs
nls
oracore
precomp
rdbms
plsql
jlib
slax
sqlplus
xdk
oracle_common
webgate
bin
wlserver
OPatch
plugins
oui
perl
network
lib
oraInst.loc
install
cfgtoollogs
inventory
root.sh

11.4 WEBHOST1でのOracle HTTP Serverドメインの作成

次の項では、最初のWeb層ホストで新しいOracle HTTP Serverスタンドアロン・ドメインを作成する方法について説明します。

- WEBHOST1での構成ウィザードの起動

- Oracle HTTP Serverドメインの構成ウィザード画面のナビゲート

11.4.1 WEBHOST1での構成ウィザードの起動

構成ウィザードを起動するには、次のディレクトリに移動し、次のようにWebLogic Server構成ウィザードを起動します。

cd OHS_ORACLE_HOME/oracle_common/common/bin
./config.sh

11.4.2 Oracle HTTP Serverドメインの構成ウィザード画面のナビゲート

各Web層ホストでOracle HTTP Serverインスタンスのスタンドアロン・ドメインを作成することをお薦めします。

次の項では、新しいスタンドアロンOracle HTTP Serverドメインを作成する方法について説明します。

- タスク1「ドメイン・タイプとドメイン・ホームの場所の選択」

- タスク2「構成テンプレートの選択」

- タスク3「Web層ドメインのJDKの選択」

- タスク4「システム・コンポーネントの構成」

- タスク5「OHSサーバー画面」

- タスク7「構成仕様の確認およびドメインの構成」

- タスク8「ドメイン・ホームのメモ」

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「新規ドメインの作成」を選択します。

「ドメインの場所」フィールドに、OHS_DOMAIN_HOME変数に割り当てられている値を入力します。

次の点に注意してください。

- 構成ウィザードにより、ここで指定した新しいディレクトリが作成されます。

- WebサーバーがDMZ外部の記憶域デバイスと依存関係を持たないように、ディレクトリはローカル記憶域に作成します。

注意:

- ドメイン・ホーム・ディレクトリの詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のドメイン・ホームの選択に関する項を参照してください。

- この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。

- Web層とDMZの詳細は、「標準的なエンタープライズ・デプロイメントのファイアウォールとゾーンの理解」を参照してください。

- OHS_DOMAIN_HOMEディレクトリ変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で、Oracle HTTP Server (スタンドアロン) - 12.2.1.1.0 [ohs]を選択します。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のテンプレートに関する項を参照してください。

タスク3   Web層ドメインのJDKの選択。

Oracle HTTP Serverソフトウェアのインストール時にWeb層のOracleホームにインストールされた、Oracle Hotspot JDKを選択します。

タスク4   システム・コンポーネントの構成

「システム・コンポーネント」画面で、1つのOracle HTTP Serverインスタンスを構成します。画面には、デフォルトで1つのインスタンスが定義されています。作成する必要のあるインスタンスは、これ1つのみです。

1. デフォルトのインスタンス名は、「システム・コンポーネント」フィールドのohs1です。このデフォルト名を使用します。

2. 「コンポーネント・タイプ」フィールドで、OHSが選択されていることを確認します。

3. 「再起動間隔秒数」フィールドを使用して、アプリケーションが応答しない場合に、再起動を試行する前に待機する秒数を指定します。

4. 「再起動遅延秒数」フィールドを使用して、再起動を再度試行する前に待機する秒数を指定します。

タスク5   OHSサーバー画面

「OHSサーバー」画面を使用して、ドメイン内のOHSサーバーを構成します。

1. 「システム・コンポーネント」ドロップダウン・メニューから、ohs1を選択します。

2. 「リスニング・アドレス」フィールドにWEBHOST1と入力します。
残りのフィールドはすべて事前に移入されていますが、組織での必要に応じて値を変更できます。この画面のフィールドの詳細は、『構成ウィザードによるWebLogicドメインの作成』のOHSサーバーに関する項を参照してください。

3. 「サーバー名」フィールドで、リスニング・アドレスとリスニング・ポートの値を確認します。
正しくは次のようになります。

WEBHOST1:7777

タスク6   ノード・マネージャの構成

ノード・マネージャのタイプとして「ドメインごとのデフォルトの場所」を選択して、ノード・マネージャのユーザー名とパスワードを指定します。

注意:

この画面におけるオプションの詳細は、『構成ウィザードによるドメインの作成』のノード・マネージャに関する項を参照してください。

ノード・マネージャのタイプの詳細は、Oracle WebLogic Serverのノード・マネージャの管理でノード・マネージャの概要に関する項を参照してください。

タスク7   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

ドメイン作成は、「作成」をクリックするまでは開始されません。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「構成サマリー」に関する項を参照してください。

タスク8   ドメイン・ホームのメモ

「構成に成功しました」画面には、ドメイン・ホームの場所が表示されます。

ここに表示された情報は、サーバーの起動時および管理サーバーへのアクセス時に必要になるため、メモします。

「終了」をクリックして、構成ウィザードを閉じます。

11.5 WEBHOST2でのOracle HTTP Serverドメインのインストールおよび構成

WEBHOST1でOracle HTTP Serverをインストールしてドメインを構成したら、同じタスクをWEBHOST2でも実行する必要があります。

1. WEBHOST2にログインし、「WEBHOST1でのOracle HTTP Serverのインストール」の手順を使用してOracle HTTP Serverをインストールします。

2. 「WEBHOST1でのWeb層ドメインの作成」の手順を使用して、WEBHOST2で新しいスタンドアロン・ドメインを構成します。
WEBHOST2上のインスタンスにはohs2という名前を使用し、各例で出現するすべてのWEBHOST1をWEBHOST2に置き換え、すべてのohs1をohs2に置き換えます。

11.6 WEBHOST1およびWEBHOST2でのノード・マネージャおよびOracle HTTP Serverインスタンスの起動

次の項では、WEBHOST1およびWEBHOST2でOracle HTTP Serverインスタンスを起動する方法について説明します。

- WEBHOST1およびWEBHOST2でのノード・マネージャの起動

- Oracle HTTP Serverインスタンスの起動

11.6.1 WEBHOST1およびWEBHOST2でのノード・マネージャの起動

Oracle HTTP Serverインスタンスを起動する前に、WEBHOST1およびWEBHOST2でノード・マネージャを起動する必要があります。

1. WEBHOST1にログインし、次のディレクトリに移動します。

OHS_DOMAIN_HOME/bin

2. 出力ファイルとしてnohupおよびnodemanager.outを使用して、次のようにノード・マネージャを起動します。

nohup OHS_DOMAIN_HOME/bin/startNodeManager.sh > OHS_DOMAIN_HOME/nodemanager/nodemanager.out 2>&1 &

3. WEBHOST2にログインし、手順1および2を実行します。

ノード・マネージャの追加の構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

11.6.2 Oracle HTTP Serverインスタンスの起動

Oracle HTTP Serverインスタンスを起動するには:

1. WEBHOST1上の次のディレクトリに移動します。

OHS_DOMAIN_HOME/bin

OHS_DOMAIN_HOMEディレクトリの場所の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

2. 次のコマンドを入力します。

./startComponent.sh ohs1

3. プロンプトが表示されたら、ノード・マネージャ・パスワードを入力します。

4. WEBHOST2上のohs2インスタンスごとに、手順1から3を繰り返します。

詳細は、『Oracle HTTP Serverの管理』のOracle HTTP Serverインスタンスの起動に関する説明を参照してください。

11.7 リクエストをアプリケーション層にルーティングするようにOracle HTTP Serverを構成

次の各項では、Webサーバー・インスタンスがリクエストをドメイン内のサーバーにルーティングするようにOracle HTTP Server構成ファイルを更新する方法を説明します。

- エンタープライズ・デプロイメント用のOracle HTTP Server構成について

- 仮想ホスト構成ファイルを追加するためのhttpd.confファイルの変更

- 仮想ホスト構成ファイルの作成

- ロード・バランサでの仮想サーバー構成の検証

- 管理サーバーおよびOracle Web Services Managerへのルーティングの構成

- 管理コンソールおよび管理サーバーへのアクセスの確認

11.7.1 エンタープライズ・デプロイメント用のOracle HTTP Server構成について

次の各項では、エンタープライズ・デプロイメントのOracle HTTP Server構成に必要な変更に関する概要情報を提供します。

- Oracle HTTP Server仮想ホストの目的

- <VirtualHost>ディレクティブのWebLogicClusterパラメータについて

- Oracle HTTP Server構成ファイルの推奨構造

11.7.1.1 Oracle HTTP Server仮想ホストの目的

このガイドの参照用トポロジでは、ハードウェア・ロード・バランサで一連の仮想サーバーを定義することが必要になります。これにより、Oracle HTTP Serverインスタンスの構成ファイルに<VirtualHost>ディレクティブを追加して、(ロード・バランサ仮想サーバーにマップされた)個別の仮想ホストへのリクエストを認識するようにOracle HTTP Serverを構成できます。

各Oracle HTTP Server仮想ホストについては、ロード・バランサからOracle HTTP Serverインスタンスを経由してOracle WebLogic Serverドメイン内の該当する管理サーバーまたは管理対象サーバーにリクエストをルーティングする特定のURL (またはコンテキスト文字列)のセットを定義します。

11.7.1.2 <VirtualHost>ディレクティブのWebLogicClusterパラメータについて

Oracle HTTP Serverの<VirtualHost>ディレクティブのキー・パラメータは、Oracle HTTP ServerのWebLogicプロキシ・プラグインの一部であるWebLogicClusterパラメータです。エンタープライズ・デプロイメント用にOracle HTTP Serverを構成する場合は、Oracle HTTP Server構成ファイルにこのパラメータを追加するときに次の情報を考慮してください。

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つ以上を実行しておくことで、クラスタに確実に到達できます。

11.7.1.3 Oracle HTTP Server構成ファイルの推奨構造

httpd.confファイルに複数の仮想ホスト定義を追加するのではなく、デプロイする製品に必要な各仮想サーバーに対してより小さくより具体的な別個の構成ファイルを作成することをお薦めします。そうすることで、すでに大きなhttpd.confファイルに追加のコンテンツを移入するのを回避できます。また、構成の問題のトラブルシューティングが容易になることがあります。

たとえば、通常のOracle Fusion Middleware Infrastructureドメインでは、admin_vh.confという名前の特定の構成ファイルを追加できます。この構成ファイルには、管理サーバー仮想ホスト(ADMINVHN)の仮想ホスト定義が含まれています。

11.7.2 仮想ホスト構成ファイルを追加するためのhttpd.confファイルの変更

次のタスクを実行して、エンタープライズ・トポロジに必要な追加の仮想ホストのhttpd.confファイルを準備します。

1. WEBHOST1にログインします。

2. ドメイン・ディレクトリで最初のOracle HTTP Serverインスタンス(ohs1)のhttpd.confファイルを見つけます。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/

3. テキスト・エディタでhttpd.confファイルを開いて、次の変更を行います。

a. httpd.confファイルのVirtual Hostsセクションで、次のように# Virtual Hostsコメント・ブロックの下および# VirtualHost Example:コメントの前にNameVirtualHostエントリを作成します。

##### Virtual hosts ######

# Virtual Hosts
#
# If you want to maintain multiple domains/hostnames on your
# machine you can setup VirtualHost containers for them. Most configurations
# use only name-based virtual hosts so the server doesn't need to worry about
# IP addresses. This is indicated by the asterisks in the directives below.
#
# Please see the documentation at
# URL
# for further details before you try to setup virtual hosts.

NameVirtualHost WEBHOST1:7777

#
# VirtualHost example:

この例では、WEBHOST1をWEBHOST1変数の値に置き換えます。詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

b. httpd.confにmoduleconfサブディレクトリのすべての*.confファイルをインクルードするINCLUDE文があることを確認します。

IncludeOptional "moduleconf/*.conf"

この文により、各コンポーネントに対して個別に仮想ホスト・ファイルを作成することが可能になり、仮想ホスト定義の更新、維持およびスケールアウトが容易になります。

4. httpd.confファイルを保存します。

5. WEBHOST2にログインし、手順2から4を実行して、ohs2インスタンスのhttpd.confファイルを更新します。
WEBHOST2で、WEBHOST1のすべてのインスタンスをWEBHOST2に置き換え、ohs1のすべてのインスタンスをohs2に置き換えます。

11.7.3 仮想ホスト構成ファイルの作成

仮想ホスト構成ファイルを作成するには:

注意:
仮想ホスト構成ファイルを作成する前に、「Oracle HTTP Server仮想ホストの目的」に説明されているとおりにロード・バランサで仮想サーバーが構成されていることを確認します。

1. WEBHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(ohs1)の構成ディレクトリに変更します。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf

2. admin_vh.confファイルを作成し、次のディレクティブを追加します。

<VirtualHost WEBHOST1:7777>
ServerName admin.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

3. soainternal_vh.confファイルを作成し、次のディレクティブを追加します。

<VirtualHost WEBHOST1:7777>
ServerName soainternal.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

4. ohs1インスタンスを再起動します。

a. ディレクトリを次の場所に変更します。

cd OHS_DOMAIN_HOME/bin

b. 次のコマンドを入力し、インスタンスを停止して起動します。求められたら、ノード・マネージャ・パスワードを入力します。

./stopComponent.sh ohs1
./startComponent.sh ohs1

5. WEBHOST2でadmin_vh.confファイルおよびsoainternal_vh.confファイルを2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。

OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf

6. admin_vh.confファイルおよびsoainternal_vh.confファイルを編集して、<VirtualHost>ディレクティブ内のWEBHOST1からの参照をWEBHOST2からの参照に変更します。

7. ohs2インスタンスを再起動します。

a. ディレクトリを次の場所に変更します。

cd OHS_DOMAIN_HOME/bin

b. 次のコマンドを入力し、インスタンスを停止して起動します。

./stopComponent.sh ohs2
./startComponent.sh ohs2

11.7.4 ロード・バランサでの仮想サーバー構成の検証

ロード・バランサから次のURLにアクセスして、ロード・バランサとOracle HTTP Serverが正しく構成されていることを確認します。これらのURLは、Oracle HTTP Server 12cの初期Webページを示しています。

- http://admin.example.com/index.html

- http://soainternal.example.com/index.html

11.7.5 管理サーバーおよびOracle Web Services Managerへのルーティングの構成

Oracle HTTP Serverが管理サーバーと、WLS_WSM管理対象サーバーが含まれているWSM-PM_Clusterにルーティングできるようにするには、一連の<Location>ディレクティブを追加して、WebLogicClusterパラメータをクラスタ内のノードのリストに追加する必要があります。

WebLogicClusterパラメータを設定する手順は次のとおりです。

1. WEBHOST1にログインし、ディレクトリを次の場所に変更します。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/

2. 次のディレクティブをadmin_vh.confファイルの<VirtualHost>タグ内に追加します。

# Admin Server and EM
<Location /console>
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /consolehelp>
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /em>
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

admin_vh.confファイルは、例1「admin_vh.confファイル」のように表示されます。

3. 次のディレクティブをsoainternal_vh.confファイルの<VirtualHost>タグ内に追加します。

# WSM-PM
<Location /wsm-pm>
WLSRequest ON
WebLogicCluster SOAHOST1:7010,SOAHOST2:7010
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

soainternal_vh.confファイルは、例2「soainternal_vh.confファイル」のように表示されます。

この例のWebLogicClusterパラメータの詳細は、「<VirtualHost>ディレクティブのWebLogicClusterパラメータについて」を参照してください。

4. ohs1インスタンスを再起動します。

a. ディレクトリを次の場所に変更します。

cd OHS_DOMAIN_HOME/bin

b. 次のコマンドを入力し、インスタンスを停止して起動します。

./stopComponent.sh ohs1
./startComponent.sh ohs1

5. WEBHOST2でadmin_vh.confファイルおよびsoainternal_vh.confファイルを2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。

OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf/

6. admin_vh.confファイルおよびsoainternal_vh.confファイルを編集して、<VirtualHost>ディレクティブ内のWEBHOST1への参照をWEBHOST2への参照に変更します。

7. ohs2インスタンスを再起動します。

a. ディレクトリを次の場所に変更します。

cd OHS_DOMAIN_HOME/bin

b. 次のコマンドを入力し、インスタンスを停止して起動します。

./stopComponent.sh ohs2
./startComponent.sh ohs2

例1   admin_vh.confファイル

<VirtualHost WEBHOST1:7777>
ServerName admin.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# Admin Server and EM
<Location /console>
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /consolehelp>
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /em>
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
</VirtualHost>

例2   soainternal_vh.confファイル

このファイルの内容:

<VirtualHost WEBHOST1:7777>
ServerName soainternal.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# WSM-PM
<Location /wsm-pm>
WLSRequest ON
WebLogicCluster SOAHOST1:7010,SOAHOST2:7010
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>
</VirtualHost>

11.7.6 管理コンソールおよび管理サーバーへのアクセスの確認

この章で行った変更を確認する手順は次のとおりです。

1. 次のハードウェア・ロード・バランサへのURLを使用してOracle WebLogic Server管理コンソールを表示し、Oracle WebLogic Server管理者資格証明を使用してログインします。

http://admin.example.com/console

これによって、ロード・バランサ上のadmin.example.com仮想ホストがWeb層のOracle HTTP Serverインスタンスにリクエストをルーティングでき、さらに、このOracle HTTP ServerインスタンスがOracle WebLogic Server管理コンソールのリクエストをアプリケーション層の管理サーバーにルーティングできることが検証されます。

2. 同様に、類似したURLを使用してFusion Middleware Controlにアクセスできます。

http://admin.example.com/em

12 Oracle Traffic Directorを含めるドメインの拡張

Web層を構成する場合、リクエストをアプリケーション層にルーティングするように、Oracle HTTP ServerではなくOracle Traffic Directorを使用できます。Oracle Traffic Directorの構成手順は、Oracle HTTP Serverの構成手順とは異なります。Oracle Traffic Directorを使用する場合、Web層ホストとアプリケーション層ホストの両方にOracle Traffic Directorをインストールする必要があります。その後、Oracle Traffic Directorを含めるようにエンタープライズ・デプロイメント・ドメインを拡張します。

Oracle Traffic Directorを構成する前に、「Web層の理解」を確認してください。

注意:

Oracle Managed File Transferを構成する予定の場合、TCPを介してFTPおよびSFTPリクエストをルーティングするようにOracle Traffic Directorを構成する必要があります。詳細は、「エンタープライズ・デプロイメントでのOracle Managed File Transferの構成」を参照してください。

- Oracle Traffic Directorについて
Oracle Traffic Directorは、アプリケーション層に対するHTTP/SおよびTCPトラフィックをロード・バランシングするためのソフトウェア・ロード・バランサです。Oracle Traffic Directorからのリクエストを受信するアプリケーション層サーバーは、Oracle Traffic Directorオリジン・サーバーと呼ばれます。オリジン・サーバーは、アプリケーション・サーバー、Webサーバー、Oracle Managed File Transfer、LDAPディレクトリ・サーバー、MLLPサーバーまたは任意の種類のTCPサーバーのいずれかです。

- エンタープライズ・デプロイメントでOracle Traffic Directorの構成時に使用される変数
Oracle Traffic Diretor参照をインストールして構成する手順では、環境内で使用される実際の値に置換できる一連の変数を使用します。

- エンタープライズ・デプロイメントでのOracle Traffic Directorについて
Oracle Traffic Directorは、Web層のOracle HTTP Serverのかわりとして使用できます。Oracle HTTP Serverと同様に、これはHTTPリクエストをフロントエンド・ロード・バランサからアプリケーション層のWebLogic管理対象サーバーにルーティングできます。ただし、TCPロード・バランシングおよびフェイルオーバーを提供できるのは、Oracle Traffic Directorのみです。

- コロケート・モードでのアプリケーション層ホストへのOracle Traffic Directorのインストール
次の項では、Oracle Universal Installerによる対話的なグラフィカル・ウィザードを使用して、Oracle Traffic Directorをインストールする手順を説明します。高可用性に対応するようにOracle Traffic Directorを構成するには、2つのマウント・ポイントで手順を実行します。

- スタンドアロン・モードでのWeb層ホストへのOracle Traffic Directorのインストール
この項では、Oracle Universal Installerによる対話的なグラフィカル・ウィザードを使用して、Oracle Traffic Directorをインストールする手順を説明します。このスタンドアロン・インストールは、エンタープライズ・デプロイメントで使用される2つのWEBHOSTシステムで実行します。

- Oracle Traffic Directorシステム・コンポーネントを含めるドメインの拡張
次の項では、Web層ホストで新しいOracle HTTP Serverスタンドアロン・ドメインを作成する方法について説明します。

- ドメインの伝播とWeb層ホスト上のノード・マネージャの起動
アプリケーション層ホストにOracle Traffic Directorをインストールし、Oracle Traffic Directorシステム・コンポーネントを含めるようにドメインを拡張したら、Web層のホストにドメイン構成をコピーしてノード・マネージャを構成できます。

- Oracle Traffic Director構成の作成
Oracle Traffic Director構成は、Oracle Traffic Directorサーバーの実行時の特性を定義するメタデータの集合です。構成を作成した後、構成を使用して、1つ以上の管理ノードにOracle Traffic Directorサーバーのインスタンスを作成できます。

- Oracle Traffic Directoryデフォルト・インスタンスの起動

- エンタープライズ・デプロイメント用のOracle Traffic Director仮想サーバーの定義
デフォルトでは、構成を作成すると、HTTPアクセス用のデフォルト仮想サーバー(edg_config)が作成されます。ただし、各エンタープライズ・デプロイメントでは、固有の目的で追加のOracle Traffic Director仮想サーバーおよびオリジン・サーバー・プールを使用します。たとえば、新しいFusion Middleware製品を含めるようにドメインを拡張するたびに、追加の仮想サーバーを定義する必要があります。

- Managed File TransferのTCPプロキシの作成
Oracle MFTでは、TCPプロキシを使用して、SFTPリクエストをバックエンドMFT WLSサーバーにルーティングします。

- 仮想ホストのフェイルオーバー・グループの作成

上位トピック: 「エンタープライズ・ドメインの構成」

12.1 Oracle Traffic Directorについて

Oracle Traffic Directorは、アプリケーション層に対するHTTP/SおよびTCPトラフィックをロード・バランシングするためのソフトウェア・ロード・バランサです。Oracle Traffic Directorからのリクエストを受信するアプリケーション層サーバーは、Oracle Traffic Directorオリジン・サーバーと呼ばれます。オリジン・サーバーは、アプリケーション・サーバー、Webサーバー、Oracle Managed File Transfer、LDAPディレクトリ・サーバー、MLLPサーバーまたは任意の種類のTCPサーバーのいずれかです。

Oracle Fusion Middleware 12c (12.2.1)以降、Oracle Traffic Directorは、エンジニアド・システム(Oracle LinuxやOracle Solarisが稼働するOracle ExalogicまたはOracle Solarisが稼働するOracle SuperCluster)と組み合せて使用できることに加え、Oracle WebLogic Server Multi-tenancyまたはOracle WebLogic Server Continuous Availabilityアドオン・オプションを保持するユーザーが使用できるようになりました。

詳細は、『Oracle Traffic Director管理者ガイド』のOracle Traffic Directorのスタート・ガイドに関する項を参照してください。

12.2 エンタープライズ・デプロイメントでOracle Traffic Directorの構成時に使用される変数

Oracle Traffic Diretor参照をインストールして構成する手順では、環境内で使用される実際の値に置換できる一連の変数を使用します。

これらの手順では、次のディレクトリの場所の変数が使用されます。

- WEB_ORACLE_HOME

- ASERVER_HOME

- MSERVER_HOME

- WEB_DOMAIN_HOME

- JAVA_HOME

- NM_HOME

詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

さらに、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」で定義されている次の仮想IP (VIP)アドレスを参照することになります。

- ADMINVHN

この章のアクションは、次のホスト・コンピュータで実行します。

- APPHOST1

- APPHOST2

- WEBHOST1

- WEBHOST2

注意:

この章では、APPHOST1とAPPHOST2は、アプリケーション層ホストのより汎用的な変数を示すことに注意してください。この理由は、作成されるドメインに応じて、ホスト名変数が異なるためです。

たとえば、Oracle SOA Suiteドメイン用にOracle Traffic Directorを構成する場合、APPHOST1はSOAHOST1と同じです。ただし、通常は独自のドメイン内に構成されるOracle Managed File Transferドメイン用にOracle Traffic Directorを構成する場合、APPHOST1はMFTHOST1と同じです。

12.3 エンタープライズ・デプロイメントでのOracle Traffic Directorについて

Oracle Traffic Directorは、Web層のOracle HTTP Serverのかわりとして使用できます。Oracle HTTP Serverと同様に、これはHTTPリクエストをフロントエンド・ロード・バランサからアプリケーション層のWebLogic管理対象サーバーにルーティングできます。ただし、TCPロード・バランシングおよびフェイルオーバーを提供できるのは、Oracle Traffic Directorのみです。

(SFTPリクエストのルーティングおよびロード・バランシングを必要とする) Managed File Transferを構成する場合、Oracle Traffic Directorを使用する必要があります。

エンタープライズ・デプロイメントでは、システム管理目的でOracle Traffic Directorがアプリケーション層ホストのドメインに追加されるため、Web層ホストとアプリケーション層ホストの両方にOracle Traffic Directorをインストールします。

各アプリケーション層ホストで、アプリケーション層ソフトウェアをインストールした場所と同じOracleホームに、コロケート・モードでOracle Traffic Directorをインストールします。

各Web層ホストで、スタンドアロン・モードでOracle Traffic Directorをインストールします。

その後、Fusion Middleware構成ウィザードを使用して、Oracle Traffic Directorシステム・コンポーネントを含めるようにアプリケーション層ドメインを拡張します。これにより、ドメインの管理対象サーバーの制御に使用するものと同じ管理サーバーによって、Oracle Traffic Directorコンポーネントを管理できます。

次の項では、Managed File Transferに必要なOracle Traffic Director構成を使用するための具体的な手順について説明します。ただし、エンタープライズ・デプロイメント・トポロジの他のコンポーネントに対するWeb層としてOracle Traffic Directorを構成するために、これらの項の手順を使用できます。

12.4 コロケート・モードでのアプリケーション層ホストへのOracle Traffic Directorのインストール

次の項では、Oracle Universal Installerによる対話的なグラフィカル・ウィザードを使用して、Oracle Traffic Directorをインストールする手順を説明します。高可用性に対応するようにOracle Traffic Directorを構成するには、2つのマウント・ポイントで手順を実行します。

- Oracle Traffic Directorインストーラの起動

- Oracle Traffic Directorのインストール画面のナビゲート(コロケート)

- アプリケーション層ホストのインストールの確認

12.4.1 Oracle Traffic Directorインストーラの起動

インストール・プログラムを起動する手順は次のとおりです。

1. インストーラをダウンロードしたディレクトリに移動します

2. 次のコマンドを実行して、インストール・ウィザードを起動します。

- Linuxの場合

fmw_12.2.1.1.0_otd_linux64.bin

インストール・プログラムが表示されると、インストールを開始する準備ができています。

12.4.2 Oracle Traffic Directorのインストール画面のナビゲート(コロケート)

次の表では、最初のアプリケーション層ホストにコロケート・モードでOracle Traffic Directorをインストールするためにインストーラ画面を使用する方法について説明します。

インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。

画面

説明

インストール・インベントリの設定

この画面は、UNIXオペレーティング・システムで、このホストに初めてOracle製品をインストールする場合に表示されます。中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名には、中央インベントリの場所への書込み権限があることを確認してください。

中央インベントリの詳細は、『Oracle Fusion Middleware Oracle Universal Installerによるソフトウェアのインストール』のOracle Fusion Middleware Oracle Universal Installerによるソフトウェアのインストールに関する項を参照してください

ようこそ

「次へ」をクリックします。

自動更新

この製品の自動更新を受け取るかどうかを選択します。

インストールの場所

既存のアプリケーション層のOracleホームへのパスを入力します。

ランタイム・プロセスからこのディレクトリに書き込むことはできないので注意してください。

このエンタープライズ・デプロイメントのためには、表7-2に示すORACLE_HOME変数の値を入力します。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

- 「同じ場所に配置されたOTD(WebLogic Server経由で管理)」を選択します。

前提条件のチェック

前提条件が満たされているか確認するために、ホスト・コンピュータがインストーラによって分析されます。前提条件チェックの結果が画面に表示されます。

前提条件チェックが失敗した場合は、エラーまたは警告メッセージが表示されます。

- エラーを修正し、「再実行」をクリックします。たとえば、「Oracle Traffic Directorのインストールの前提条件」に示されている必須パッケージのいずれかがシステムにない場合は、そのパッケージをインストールします。

- エラーや警告を無視してインストールを続行する場合は、「スキップ」をクリックします。

- 前提条件のチェック・プロセスを中止するには、「停止」をクリックします。

「次へ」をクリックして続行します。

セキュリティ・アップデートの指定

Oracle Supportアカウントをすでに所持している場合は、この画面を使用して、セキュリティ・アップデートの受取り方法を指定します。

アカウントを所持していないときに、この手順を省略してもかまわない場合は、チェック・ボックスの選択を解除して、その選択を後続のダイアログ・ボックスで確認します。

インストール・サマリー

この画面には、前に指定したOracleホーム・ディレクトリが表示されます。また、インストールに使用されるディスク領域と使用可能な空き領域も示されます。

この画面の情報を確認します。

インストール・ウィザードでこれまで指定した設定をテキスト・ファイル(レスポンス・ファイル)に保存するには、「保存」をクリックします。必要な場合は、このレスポンス・ファイルを使用して、同じインストールをコマンドラインから実行できます。

「インストール」をクリックしてインストールを開始します。

サイレント・インストールやコマンド行インストールの詳細は、Oracle Universal Installerによるソフトウェアのインストールでサイレント・モードにおけるOracle Universal Installerの使用方法に関する項を参照してください。

インストールの進行状況

この画面には、インストール・プロセスの進捗状況とステータスが表示されます。

インストールを取り消す場合は、「取消」をクリックします。インストールを取り消す前にシステムにコピーされたファイルは、システムにそのまま残ります。これらは手作業で削除する必要があります。

「次へ」をクリックして続行します。

インストール完了

「終了」をクリックします。

12.4.3 アプリケーション層ホストのインストールの確認

インストールおよびインストール後の手順を完了したら、Oracleホーム・ディレクトリ(ORACLE_HOME/otd)に次のディレクトリが含まれることを確認します。

common
lib
plugins

12.5 スタンドアロン・モードでのWeb層ホストへのOracle Traffic Directorのインストール

この項では、Oracle Universal Installerによる対話的なグラフィカル・ウィザードを使用して、Oracle Traffic Directorをインストールする手順を説明します。このスタンドアロン・インストールは、エンタープライズ・デプロイメントで使用される2つのWEBHOSTシステムで実行します。

- Oracle Traffic Directorインストーラの起動

- Oracle Traffic Directorのインストール画面のナビゲート(スタンドアロン)

- Web層ホストのインストールの確認

12.5.1 Oracle Traffic Directorインストーラの起動

インストール・プログラムを起動する手順は次のとおりです。

1. インストーラをダウンロードしたディレクトリに移動します

2. 次のコマンドを実行して、インストール・ウィザードを起動します。

- Linuxの場合

fmw_12.2.1.1.0_otd_linux64.bin

インストール・プログラムが表示されると、インストールを開始する準備ができています。

12.5.2 Oracle Traffic Directorのインストール画面のナビゲート(スタンドアロン)

インストール・プログラムでは次の表に記載された順番で一連の画面が表示されます。

インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。

画面

説明

インストール・インベントリの設定

この画面は、UNIXオペレーティング・システムで、このホストに初めてOracle製品をインストールする場合に表示されます。中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名には、中央インベントリの場所への書込み権限があることを確認してください。

中央インベントリの詳細は、『Oracle Fusion Middleware Oracle Universal Installerによるソフトウェアのインストール』のOracle Fusion Middleware Oracle Universal Installerによるソフトウェアのインストールに関する項を参照してください。

ようこそ

「次へ」をクリックします。

自動更新

この製品の自動更新を受け取るかどうかを選択します。

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

Oracleホームは、Oracle製品のソフトウェア・バイナリが格納されているディレクトリです。ランタイム・プロセスからこのディレクトリに書き込むことはできないので注意してください。エンタープライズ・デプロイメントのためには、表7-3に示すWEB_ORACLE_HOME変数の値を入力します。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

- 「スタンドアロンOTD(WebLogic Serverとは切り離して管理)」を選択します。

前提条件のチェック

前提条件が満たされているか確認するために、ホスト・コンピュータがインストーラによって分析されます。前提条件チェックの結果が画面に表示されます。

前提条件チェックが失敗した場合は、エラーまたは警告メッセージが表示されます。

- エラーを修正し、「再実行」をクリックします。たとえば、「Oracle Traffic Directorのインストールの前提条件」に示されている必須パッケージのいずれかがシステムにない場合は、そのパッケージをインストールします。

- エラーや警告を無視してインストールを続行する場合は、「スキップ」をクリックします。

- 前提条件のチェック・プロセスを中止するには、「停止」をクリックします。

「次へ」をクリックして続行します。

セキュリティ・アップデートの指定

Oracle Supportアカウントをすでに所持している場合は、この画面を使用して、セキュリティ・アップデートの受取り方法を指定します。

アカウントを所持していないときに、この手順を省略してもかまわない場合は、チェック・ボックスの選択を解除して、その選択を後続のダイアログ・ボックスで確認します。

インストール・サマリー

この画面には、前に指定したOracleホーム・ディレクトリが表示されます。また、インストールに使用されるディスク領域と使用可能な空き領域も示されます。

この画面の情報を確認します。

インストール・ウィザードでこれまで指定した設定をテキスト・ファイル(レスポンス・ファイル)に保存するには、「保存」をクリックします。必要な場合は、このレスポンス・ファイルを使用して、同じインストールをコマンドラインから実行できます。

「インストール」をクリックしてインストールを開始します。

サイレント・インストールやコマンド行インストールの詳細は、Oracle Universal Installerによるソフトウェアのインストールでサイレント・モードにおけるOracle Universal Installerの使用方法に関する項を参照してください。

インストールの進行状況

この画面には、インストール・プロセスの進捗状況とステータスが表示されます。

インストールを取り消す場合は、「取消」をクリックします。インストールを取り消す前にシステムにコピーされたファイルは、システムにそのまま残ります。これらは手作業で削除する必要があります。

「次へ」をクリックして続行します。

インストール完了

「終了」をクリックします。

12.5.3 Web層ホストのインストールの確認

インストールおよびインストール後の手順を完了したら、Oracleホーム・ディレクトリに次のディレクトリが含まれることを確認します。

bin
crs
inventory
ldap
network
OPatch
oracore
otd
plsql
precomp
slax
srvm
wlservercfgtoollogs
css
install
jlib
lib
nls
oracle_common
oraInst.loc
oui
plugins
rdbms
sqlplus
webgate
xdk

12.6 Oracle Traffic Directorシステム・コンポーネントを含めるドメインの拡張

次の項では、Web層ホストで新しいOracle HTTP Serverスタンドアロン・ドメインを作成する方法について説明します。

- <otd_apptier_hostname>での構成ウィザードの起動

- ドメインを拡張するために構成ウィザード画面へ移動
構成ウィザードを起動したら、既存のドメインを拡張するために必要な情報を提供する画面の指示に従うことができます。

12.6.1 <otd_apptier_hostname>での構成ウィザードの起動

構成ウィザードを起動するには、次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

cd WEB_ORACLE_HOME/oracle_common/common/bin
./config.sh

12.6.2 ドメインを拡張するために構成ウィザード画面へ移動

構成ウィザードを起動したら、既存のドメインを拡張するために必要な情報を提供する画面の指示に従うことができます。

1. ドメイン・タイプとドメインの場所の選択

2. Oracle Traffic Directorの構成テンプレートの選択

3. 拡張構成オプションの選択

4. Oracle Traffic Directorのシステム・コンポーネントの追加

5. Oracle Traffic DirectorのWebLogic Serverマシンの作成

6. 構成の指定内容の確認とドメインの構成

7. ドメイン・ホームと管理サーバーURLの記録

12.6.2.1 ドメイン・タイプとドメインの場所の選択

ドメイン・タイプとドメインの場所を選択する手順は次のとおりです。

1. 「構成タイプ」画面で、「既存ドメインの更新」を選択します。

2. 「ドメインの場所」フィールドに、ASERVER_HOME変数に割り当てられている値を入力します。

注意:

- ドメイン・ホーム・ディレクトリの詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のドメイン・ホームの選択に関する項を参照してください。

- この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。

- Web層およびDMZの詳細は、「標準的なエンタープライズ・デプロイメントのファイアウォールとゾーンの理解」を参照してください。

- ASERVER_HOMEディレクトリ変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

12.6.2.2 Oracle Traffic Directorの構成テンプレートの選択

構成テンプレートを選択する手順は次のとおりです。

1. 「テンプレート」画面で、Oracle Traffic Director - 12.2.1.1.0 [otd]を選択します。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のテンプレートに関する項を参照してください。

12.6.2.3 拡張構成オプションの選択

トポロジのドメイン構成を完了するには、「拡張構成」画面で次のオプションを選択します。

- システム・コンポーネント

12.6.2.4 Oracle Traffic Directorのシステム・コンポーネントの追加

「システム・コンポーネント」画面で、「次へ」をクリックします。

構成ウィザードでシステム・コンポーネントを構成する必要はありません。このガイドの後半の手順で、エンタープライズ・デプロイメントに必要なOracle Traffic Directorインスタンスの作成方法について説明します。

12.6.2.5 Oracle Traffic DirectorのWebLogic Serverマシンの作成

「マシン」画面を使用して、ドメイン内に3つの新規マシンを作成します。マシンは、ノード・マネージャでサーバーを起動または停止できるようにするために必要です。

1. 「Unixマシン」タブを選択します。

2. 「追加」ボタンをクリックして、2つの新しいUnixマシンを作成します(OTDインスタンスごとに1つ)。

3. 各マシンで、「ノード・マネージャ・リスニング・アドレス」フィールドにWebHOSTnを、「ノード・マネージャ・リスニング・ポート」フィールドに556を指定します。

12.6.2.6 構成の指定内容の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

「更新」をクリックするまで、ドメインの作成は開始されません。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

12.6.2.7 ドメイン・ホームと管理サーバーURLの記録

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

- ドメインの場所

- 管理サーバーURL

どちらの項目も後で必要になるため、メモしておく必要があります。ドメインの場所は、管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

12.7 ドメインの伝播とWeb層ホスト上のノード・マネージャの起動

アプリケーション層ホストにOracle Traffic Directorをインストールし、Oracle Traffic Directorシステム・コンポーネントを含めるようにドメインを拡張したら、Web層のホストにドメイン構成をコピーしてノード・マネージャを構成できます。

- アプリケーション層でのドメインの圧縮

- Web層ホストでのドメイン構成の解凍

- Web層ホストでのノード・マネージャの構成および起動
Oracle Traffic Directorは、Web層ホストで単独で実行されるため、Web層ホストごとにノード単位でノード・マネージャを作成する必要はありません。かわりに、Oracle Traffic Directorノードでは、デフォルトのドメイン単位のノード・マネージャを使用します。

12.7.1 アプリケーション層でのドメインの圧縮

次の手順を使用して、ドメイン構成情報が含まれるテンプレートJARファイルを作成します。

1. APPHOST1にログインし、次のようにpackコマンドを実行してテンプレートJARファイルを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true
-domain=ASERVER_HOME
-template=full_path/soadomaintemplate.jar
-template_name=extend_otd_template

この例では、次のようになります。

- ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

- full_pathを、テンプレートJARファイルを保存するディレクトリの完全なパスで置き換えます。

- extend_otd_templateは、作成するJARファイルのサンプル名です。これには、Oracle HTTP Serverインスタンスの構成ファイルなどのドメイン構成ファイルが含まれます。

- extend_otd_templateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

- テンプレートJARファイルの完全なパスを、packコマンドの-template引数の一部として指定する必要があります。

2. packコマンドで作成したばかりのテンプレートJARファイルの場所を書き留めます。

ヒント:

packおよびunpackコマンドの詳細は、『WebLogic Server PackおよびUnpackコマンドによるテンプレートとドメインの作成』のPackおよびUnpackコマンドの概要に関する項を参照してください。

3. Web層ホストで使用可能な場所にテンプレートJARファイルをコピーします。

12.7.2 Web層ホストでのドメイン構成の解凍

次の手順を使用して、Oracle Traffic Directoryのドメイン構成情報をWeb層ホストにコピーします。

1. WEBHOST1にログインします。

2. まだ作成していない場合は、WEBHOST1の記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

3. packコマンドで作成したテンプレートJARファイルにWEBHOST1からアクセスできることを確認します。

4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME
-overwrite_domain=true
-template=complete_path/extend_otd_template.jar
-log_priority=DEBUG
-log=/tmp/unpack.log
-app_dir=APPLICATION_HOME

この例では、次のようになります。

- MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

- complete_pathを、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したドメイン・テンプレートJARファイルの完全なパスに置き換えます。

- APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

5. ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがWEBHOST1のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

6. WEBHOST2で解凍手順を繰り返します。

12.7.3 Web層ホストでのノード・マネージャの構成および起動

Oracle Traffic Directorは、Web層ホストで単独で実行されるため、Web層ホストごとにノード単位でノード・マネージャを作成する必要はありません。かわりに、Oracle Traffic Directorノードでは、デフォルトのドメイン単位のノード・マネージャを使用します。

セキュリティ上の理由から、DMZでSSLノード・マネージャを使用することもお薦めします。

必要なノード・マネージャ構成を作成して各Web層ホストでノード・マネージャを起動するには、次の手順を実行します。Web層ホストごとに繰り返してください。

1. WEB_DOMAIN_HOME/nodemanagerに移動します。

2. nodemanager.propertiesファイルを編集して次のプロパティを変更します。

- ListenAddress = WEBHOSTn

- SecureListener = true

3. ディレクトリをWEB_DOMAIN_HOME/binに変更します。

4. 次のコマンドを実行してノード・マネージャを起動します。

./startNodeManager.sh

12.8 Oracle Traffic Director構成の作成

Oracle Traffic Director構成は、Oracle Traffic Directorサーバーの実行時の特性を定義するメタデータの集合です。構成を作成した後、構成を使用して、1つ以上の管理ノードにOracle Traffic Directorサーバーのインスタンスを作成できます。

注意:

構成に指定されたサーバー・ユーザーは、次の要件を満たしている必要があります。

- 管理サーバーがrootとして実行されている場合、サーバー・ユーザーはrootであるか、Oracle Traffic Directorをインストールしたユーザーと同じグループに属している必要があります。

- 管理サーバーがrootユーザー以外で実行されている場合、サーバー・ユーザーは管理サーバーのサーバー・ユーザーと同じである必要があります。

構成がデプロイされるノードは、これらのシステムに構成されているユーザー・アカウントおよびグループの点から同種である必要があります。

構成を作成するには、次のようにします。

1. アプリケーション層ドメインのFusion Middleware Controlにログインします。

2. 「WebLogicドメイン」メニューで、「管理」→「OTD構成」を選択します。

3. 「チェンジ・センター」メニュー(ロック・アイコン)で、「ロックして編集」を選択します。

4. 「作成」をクリックします
「新規構成ウィザード」画面が表示されます。

5. 構成名とオリジン・サーバー・タイプを指定します。
たとえば、構成名としてedgconfigを指定し、「オリジン・サーバー・タイプ」として「HTTP」を選択して、「次へ」をクリックします。

6. 「構成の作成: リスナー」画面で、デフォルト値を受け入れて「次へ」をクリックします。

7. 「構成の作成: オリジン・サーバー・プール」画面で、「次へ」をクリックします。
エンタープライズ・デプロイメントで構成している製品の他のオリジン・サーバーおよびオリジン・サーバー・プールは、後から追加できます。

8. 「構成の作成: デプロイメント」画面で、デプロイメントのWebLogic ServerマシンとしてWEBHOST1およびWEBHOST2を選択します。「次へ」をクリックします。

9. 構成定義が表示された画面を確認し、「構成の作成」をクリックして構成を作成します。

10. 「チェンジ・センター」メニュー(ロック・アイコン)で、「変更のアクティブ化」を選択して変更を有効にします。

注意:

構成を作成すると、次のものが自動的に作成されます。

- edgconfigという名前の1つの仮想サーバー。

- 構成に対して定義されたホストごとに1つのインスタンス。

12.9 Oracle Traffic Directoryデフォルト・インスタンスの起動

Oracle Traffic Directorデフォルト・インスタンスを起動する手順は次のとおりです。

1. Traffic DirectorのFusion Middleware Controlにログインします。

2. 「WebLogicドメイン」で、「管理」→「OTD構成」を選択します。

3. .
使用可能な構成のリストが表示されます。

4. 前に作成した構成を選択します。

5. 「Traffic Director構成」メニューで、「管理」→「インスタンス」を選択します。
「インスタンス」ページが表示されます。

6. インスタンスのリストからインスタンスを選択し、「起動」をクリックして、操作が正常に完了したことを確認します。

12.10 エンタープライズ・デプロイメント用のOracle Traffic Director仮想サーバーの定義

デフォルトでは、構成を作成すると、HTTPアクセス用のデフォルト仮想サーバー(edg_config)が作成されます。ただし、各エンタープライズ・デプロイメントでは、固有の目的で追加のOracle Traffic Director仮想サーバーおよびオリジン・サーバー・プールを使用します。たとえば、新しいFusion Middleware製品を含めるようにドメインを拡張するたびに、追加の仮想サーバーを定義する必要があります。

エンタープライズ・デプロイメントで必要な仮想サーバーの一覧は、「エンタープライズ・デプロイメントに必要な仮想サーバーのサマリー」を参照してください

Oracle Traffic Director仮想サーバーの作成の一般情報は、『Oracle Traffic Director管理者ガイド』の仮想サーバーの作成に関する項を参照してください。
仮想サーバーを作成して構成するには、オリジン・サーバー・プールを作成して仮想サーバーを定義する必要があります。

- 必要なオリジン・サーバー・プールの作成

- 仮想サーバーの作成

- 仮想サーバー・ルートの作成

- オリジン・サーバーおよび仮想ホストのサマリー

12.10.1 必要なオリジン・サーバー・プールの作成

Fusion Middleware Controlを使用して必要なオリジン・サーバー・プールを作成する手順は、次のとおりです。

1. Fusion Middleware Controlにログインします。

2. 「WebLogicドメイン」メニューで、「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

3. オリジン・サーバー・プールを追加する構成を選択します。

4. 「Traffic Director構成」メニューで、「管理」→「オリジン・サーバー・プール」を選択します。
「サーバー・プール」ページが表示されます。その構成に定義されているサーバー・プール(HTTP/SおよびTCPサーバー・プール)のリストが表示されます。

5. 「チェンジ・センター」メニュー(ロック・アイコン)で、「ロックして編集」を選択します。

6. 「HTTP/Sオリジン・サーバー・プール」で、「作成」をクリックして必要なHTTPオリジン・サーバー・プールを作成します。
エンタープライズ・デプロイメントに必要なHTTPオリジン・サーバー・プールのリストは、「オリジン・サーバーおよび仮想ホストのサマリー」を参照してください。

7. 「オリジン・サーバー情報」で、オリジン・サーバー・プールに関連付けられたサーバーのアドレスを指定します。
各HTTPオリジン・サーバー・プールに必要なサーバーのリストは、「オリジン・サーバーおよび仮想ホストのサマリー」を参照してください。

8. 画面の右上にある「OK」をクリックします。

オリジン・プール・ページに戻ります。

9. 「TCPオリジン・サーバー・プール」で、「作成」をクリックしてTCPオリジン・サーバー・プールを作成します。
エンタープライズ・デプロイメントに必要なTCPオリジン・サーバー・プールのリストは、「オリジン・サーバーおよび仮想ホストのサマリー」を参照してください。

10. 「オリジン・サーバー情報」で、オリジン・サーバー・プールに関連付けられたサーバーのアドレスを指定します。
各TCPオリジン・サーバー・プールに必要なサーバーのリストは、「オリジン・サーバーおよび仮想ホストのサマリー」を参照してください。

11. 画面の右上にある「OK」をクリックします。

オリジン・プール・ページに戻ります。

12. 画面の右上にあるロック・アイコンをクリックすると表示されるサブメニューの「変更のアクティブ化」を選択します。
作成したオリジン・サーバー・プールの詳細が、「オリジン・サーバー・プール」ページに表示されます。

13. エンタープライズ・デプロイメントに必要な追加のオリジン・サーバー・プールについて手順を繰り返します。

オリジン・サーバー・プールが作成された後、新規オリジン・サーバー・プール・ウィザードの「結果」画面にオリジン・サーバー・プールの作成が成功したことを示すメッセージが表示されます。

14. 画面の右上にあるロック・アイコンをクリックすると表示されるサブメニューの「変更のアクティブ化」を選択します。

12.10.2 仮想サーバーの作成

仮想サーバーを作成する手順は次のとおりです。

1. Fusion Middleware Controlにログインします。

2. 「WebLogicドメイン」メニューで、「管理」→「OTD構成」を選択します
使用可能な構成のリストが表示されます。

3. 仮想サーバーを作成する構成を選択します。

4. 「Traffic Director構成」メニューで、「管理」→「仮想サーバー」を選択します。

5. 「チェンジ・センター」メニュー(ロック・アイコン)で、「ロックして編集」を選択します。

6. 「仮想サーバー」で、「作成」をクリックします。
新規仮想サーバー・ウィザードが開始されます。

7. 仮想サーバーの名前を入力します。

エンタープライズ・デプロイメントに必要な仮想サーバーのリストは、「オリジン・サーバーおよび仮想ホストのサマリー」を参照してください。

8. 「この仮想サーバー用にリスナーを選択」を選択し、「次へ」をクリックします。

9. 構成を使用して作成したリスナーを選択し、他のデフォルトを受け入れます。「次へ」をクリックします。

10. 「仮想サーバーの作成: オリジン・サーバー・プール」画面で、「オリジン・サーバーのプールの選択」を選択します。

11. 各仮想サーバーで、「オリジン・サーバーおよび仮想ホストのサマリー」に示されているプールを選択します。

必要な情報の入力を完了したら、「次へ」をクリックします

12. 「仮想サーバーの作成: 確認」画面のデータを確認し、「仮想サーバーの作成」をクリックします。
仮想サーバーが作成された後、新規仮想サーバー・ウィザードの「結果」画面に、仮想サーバーの作成が成功したことを示すメッセージが表示されます。

13. 画面の右上にあるロック・アイコンをクリックすると表示されるサブメニューの「変更のアクティブ化」を選択します。

12.10.3 仮想サーバー・ルートの作成

一部のOracle Fusion Middleware製品では、特定のリクエストを適切な管理対象サーバーに適切なプロトコルでルーティングできるように、特定のURIを定義する必要があります。Oracle Traffic Directorでは、作成済の選択した仮想サーバーに対して特定のルートを作成することで、これらのURIを定義できます。

1. 「オリジン・サーバーおよび仮想ホストのサマリー」に記載されている情報を確認します。

この項には、特定のOracle Fusion Middleware製品のそれぞれに必要なすべてのルートがリストされています。デプロイする製品について、仮想サーバー、ルートの名前、URIのリストおよびオリジン・サーバー・プールを書き留めてください。その情報を使用して、必要な各ルートを作成できます。

2. Fusion Middleware Controlにログインします。

3. 「WebLogicドメイン」メニューで、「管理」→「OTD構成」を選択します
使用可能な構成のリストが表示されます。

4. 仮想サーバーを作成する構成をクリックします。
「Traffic Director構成」ページが表示されます。

5. 「Traffic Director構成」メニューで、「管理」→「仮想サーバー」を選択します。

6. 編集する仮想サーバーの名前をクリックします。

7. 「ルート」タブを選択します。

8. 「チェンジ・センター」メニュー(ロック・アイコン)で、「ロックして編集」を選択します。

9. 「作成」をクリックします。
「ルートの作成」ページが表示されます。

10. 「名前」フィールドに、ルートの名前を入力します。

各Fusion Middleware製品に対して作成する必要があるルートのリストを参照してください。

11. 「条件」フィールドに、ルーティング情報を割り当てる特定のURIを指定する次の構文を入力します。
$uri =~ '/context_string'
例:

$uri =~ '/soa-infra'
複数のURIを入力する必要がある場合、それらを"or"で区切ります。例:

$uri =~ '/soa-infra' or $uri=~'/inspection.wsil'

12. 「オリジン・サーバー・プール」ドロップダウン・メニューから、このルートに関連付けられたプールを選択します。

このルートの条件に一致するリクエストが、選択したプールに転送されます。

12.10.4 オリジン・サーバーおよび仮想ホストのサマリー

各Oracle Fusion Middleware製品では、特定のOracle Traffic Directorオリジン・サーバー、仮想サーバー、および仮想サーバーごとのルーティング情報が必要です。

各製品に必要なオリジン・サーバー・プール

次の表は、Fusion Middleware製品に必要なオリジン・サーバー・プールを示しています。この情報は、Fusion Middleware ControlのOracle Traffic Director管理ページを使用してオリジン・サーバー・プールを作成するときに使用できます。

製品

オリジン・サーバー・プール

タイプ

オリジン・サーバー

すべての製品(ドメインごとに1つ)

admin-pool

HTTP

ADMINVHN.example.com:7001

Oracle Web Services Manager。

wsm-pool

HTTP

soahost1.example.com:7010

soahost2.example.com:7010

Oracle SOA Suite

Business Process Management

Oracle SOA Suite for Healthcare

soa-pool

HTTP

soahost1.example.com:8001

soahost2.example.com:8001

Oracle Enterprise Scheduler

ess-pool

HTTP

soahost1.example.com:8021

soahost2.example.com:8021

Business Activity Monitoring

bam-pool

HTTP

soahost1.example.com:9001

soahost2.example.com:9001

Oracle Service Bus

osb-pool

HTTP

soahost1.example.com:8011

soahost2.example.com:8011

Oracle Managed File Transfer。

mft-pool

HTTP

mfthost1.example.com:7500

mfthost2.example.com:7500

Oracle Managed File Transfer。

mft-sftp-pool

TCP

mfthost1.example.com:7022*

mfthost2.example.com:7022*

Oracle SOA Suite for Healthcare

healthcare-tcp-pool

TCP

soahost1.example.com:95nn

soahost2.example.com:95nn

注意:
*7022は、Managed File TransferサーバーのSFTPリスナーで使用されるデフォルト・ポートです。

各製品に必要な仮想サーバー

次の表は、Fusion Middleware製品に必要な仮想サーバーを示しています。この情報は、Fusion Middleware ControlのOracle Traffic Director管理ページを使用して必要な仮想サーバーを作成するときに使用できます。

製品

仮想サーバー名

提供ホスト

プール

リスナー

すべての製品(ドメインごとに1つ)

admin.example.com

admin.example.com

admin-pool

*

Oracle SOA Suite

Business Process Management

Oracle SOA Suite for Healthcare

soa.example.com

soa.example.com

soa-pool

*

Oracle Enterprise Scheduler

soa.example.com

soa.example.com

ess-pool

*

Business Activity Monitoring

soa.example.com

soa.example.com

bam-pool

*

Oracle SOA Suite

Business Process Management

soainternal.example.com

WEBHOST1-V1*

soa-pool

*

Oracle Web Services Manager。

soainternal.example.com

WEBHOST1-V1*

wsm-pool

*

Oracle Enterprise Scheduler

soainternal.example.com

WEBHOST1-V1*

ess-pool

*

Business Activity Monitoring

soainternal.example.com

WEBHOST1-V1*

bam-pool

*

Oracle Service Bus

osb.example.com

osb.example.com

osb-pool

*

Oracle Service Bus

osbinternal.example.com

WEBHOST2-V1*

osb-pool

*

Oracle Managed File Transfer。

mft-http.example.com

mft.example.com

mft-pool

*

Oracle Managed File Transfer。

mft-sftp.example.com

mft.example.com

mft-sftp-pool

*

Oracle SOA Suite for Healthcare

soahealthcare.example.com

soahealthcare.example.com

healtchare-tcp-pool

*

注意:
*WEBHOST1-V1とWEBHOST2-V1は、対応するOracle Traffic Directorフェイルオーバー・グループで使用されるVIPです。

各製品に必要な仮想サーバー・ルート

次の表は、Fusion Middleware製品に必要な仮想サーバー・ルート(またはURI)を示しています。この情報は、Fusion Middleware ControlのOracle Traffic Director管理ページを使用して必要なルートを作成するときに使用できます。

製品

仮想サーバー名

ルート

オリジン・サーバー・プール

URI

すべての製品(ドメインごとに1つ)

admin.example.com

admin-route

admin-pool

/console
/em
/consolehelp

Oracle Web Services Manager。

soainternal.example.com

soa-route

wsm-pool

/wsm-pm

Oracle SOA Suite

soa.example.com

soa-route

soa-pool

/soa-infra
/inspection.wsi
/integration
/b2bconsole
/b2b/services/ws/sdpmessaging/userprefs-ui
/DefaultToDoTaskFlow
/workflow
/ADFAttachmentHelper
/soa/composer
/frevvo

Oracle Service Bus

osb.example.com

osb-route

osb-pool

/sbinspection.wsil
/sbresource
/osb
/alsb

Business Process Management

soa.example.com

soa-route

soa-pool

/bpm/composer
/bpm/workspace

Oracle Enterprise Scheduler

soa.example.com

soa-route

ess-pool

/ess
/EssHealthCheck
/ess-async
/ess-wsjob

Business Activity Monitoring

soa.example.com

soa-route

bam-pool

/bam/composer
/OracleBAMWS
/oracle/bam/server

Oracle B2B

soa.example.com

soa-route

soa-pool

/b2bconsole
/b2b

Oracle SOA Suite for Healthcare

soa.example.com

soa-route

healthcare-TCP-pool

/healthcare

Oracle SOA Suite for Healthcare

soainternal.example.com

soa-route

healthcare-pool

/healthcare

Oracle Managed File Transfer。

mft-http-example.com

mft-route

mft-pool

/mftconsole

12.11 Managed File TransferのTCPプロキシの作成

Oracle MFTでは、TCPプロキシを使用して、SFTPリクエストをバックエンドMFT WLSサーバーにルーティングします。

MFTのTCPプロキシを作成する手順は次のとおりです。

1. Fusion Middleware Controlにログインします。ページの左上にある「WebLogicドメイン」ボタンをクリックします。

2. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

3. TCPプロキシを作成する構成を選択します。

4. 「共通タスク」ペインで、「Traffic Director構成」をクリックします。

5. 「管理」→「TCPプロキシ」を選択します。

6. 「TCPプロキシ」表で、「ロックして編集」をクリックし、「作成」をクリックします。
新規TCPプロキシ・ウィザードが開始されます。

7. FTPを選択せずにプロキシの名前を入力し、「次へ」をクリックします。

8. 「TCPプロキシの作成: リスナー」画面で、ポートとして7022を、アドレスとして*を入力します。「次へ」をクリックします。

9. 「TCPプロキシの作成: オリジン・サーバー・プール」画面で、前の手順で作成したmftsftp-poolを選択します。「次へ」をクリックします。

10. 次の画面を確認して、「TCPプロキシの作成」をクリックします。

11. 画面の右上にあるロック・アイコンをクリックすると表示されるサブメニューの「変更のアクティブ化」を選択します。

12.12 仮想ホストのフェイルオーバー・グループの作成

EDGの仮想ホストの1つにリクエストが送信されると、フロントエンド・ロード・バランサは、リクエストのロード・バランシング先として構成されたIPアドレスにそのリクエストをリダイレクトします。このIPアドレスは、いずれかのOTDインスタンスで有効化されますが、障害が発生した場合は別のOTDインスタンスに移行できます。1つまたは2つの仮想IP (VIP)アドレスで表されたフェイルオーバー・グループ内で2つのOracle Traffic Directorインスタンスを組み合せることによって、Oracle Traffic Directorインスタンスの高可用性を確保できます。

これを行うには、そのIPアドレスに対してアクティブ-パッシブ・フェイルオーバー・グループを作成します。このフェイルオーバー・グループには、1つのプライマリ・インスタンスと複数のセカンダリ・インスタンスがリストされます。

次の手順では、構成内の異なる仮想サーバーに関連付けられたIPアドレスに対してフェイルオーバー・グループを作成する方法について説明します。ロード・バランサは、2つのOracle Traffic Directorインスタンス間でリスエストをフェイルオーバーするため、MFT OTD IPアドレス用のフェイルオーバー・グループはオプションですが、それによって通常のロード・バランサ監視より障害検出とフェイルオーバーが高速化します。

Oracle Traffic Directorのフェイルオーバー・グループまたは他の高可用性構成を作成する方法の詳細は、『Oracle Traffic Director管理者ガイド』の高可用性を提供するためのOracle Traffic Directorの構成に関する項を参照してください。

- フェイルオーバー・グループの作成
この項では、フェイルオーバー・グループを作成してOracle Traffic Directorインスタンスの高可用性ペアを実装する方法を説明します。

12.12.1 フェイルオーバー・グループの作成

この項では、フェイルオーバー・グループを作成してOracle Traffic Directorインスタンスの高可用性ペアを実装する方法を説明します。

開始する前に:

- フェイルオーバー・グループに割り当てる一意のVIPアドレスを決定します。

- VIPアドレスは、フェイルオーバー・グループ内のノードと同じサブネットに属している必要があります。

- クライアントはこれらのVIPアドレスにアクセスできる必要があります。

注意:
Oracle Traffic Directorインスタンスのアクティブ-アクティブ・ペアを構成するには、同じインスタンスを含む2つのフェイルオーバー・グループを作成する必要がありますが、その際、フェイルオーバー・グループごとに異なるVIPアドレスを割り当て、プライマリ・ノードとバックアップ・ノード・ロールを逆にします。

- • VIPを管理するインタフェースのネットワーク接頭辞を特定します。このネットワーク接頭辞は、次の例のようなClassless Inter-Domain Routing (CIDR)形式で表されたサブネット・マスクです。

- 256個のアドレスを含むサブネット(8ビット)内のIPv4 VIPアドレスの場合、サブネット・マスク255.255.255.0のCIDR表記は24であり、この値は使用可能なIPv4アドレスの最大数(32ビット)から、指定されたサブネットのアドレス数(8ビット)を引くことによって計算できます。

- 同様に、4096個のアドレスを含むサブネット(12ビット)内のIPv4 VIPアドレスの場合、サブネット・マスク255.255.240.0のCIDR表記は20 (=32-12)となります。

- IPv6サブネットのサブネット・マスクのCIDR表記を計算するには、使用可能なIPv6アドレスの最大数である128ビットから、サブネットのアドレス空間のビット・サイズを引く必要があります。

IPv4 VIPまたはIPv6 VIPのデフォルトのネットワーク・プレフィックス長は、それぞれ24または64です。NICを自動的に選択するため、およびVIPが指定したNICと同じサブネットにある場合は検証するために、指定されていない場合はデフォルトのネットワーク接頭辞長が使用されます。

VIPを実際にプラミングする際には、そのノードからのすべての発信トラフィックがVIPをソース・アドレスとして使用しないように、ホストマスク(IPv4には32、IPv6には128)を使用することをお薦めします。

- フェイルオーバー・グループ内のプライマリ・ノードおよびバックアップ・ノードとして構成するOracle Traffic Director管理ノードを識別します。これらのノードは同じサブネットに属している必要があります。
ここで選択する管理ノードに、指定した構成に使用するOracle Traffic Directorインスタンスが存在している必要があります。

- 各ノードのネットワーク・インタフェースを識別します。
現在ホスト上で稼働しているネットワーク・インタフェースごとに、管理サーバーによって、インタフェースのIPアドレスのネットワーク部が、指定したVIPのネットワーク部と比較されます。結果が一致した最初のネットワーク・インタフェースが、VIPのネットワーク・インタフェースとして使用されます。

この管理サーバーによる比較では、フェイルオーバー・グループ用に指定されたVIPがIPv4アドレスであるかIPv6アドレスであるかに応じて、それぞれIPv4アドレスまたはIPv6アドレスで構成されたホスト上のネットワーク・インタフェースのみが検証されます。

- 存在しないアドレスにバインドできるようにする(転送バインディングのような)システム構成を実行することで、HTTPリスナーのVIP IPアドレスにバインドできます。次のシステム構成のどちらかを実行します。

echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind

または

sysctl net.ipv4.ip_nonlocal_bind=1

(再起動後も維持する場合は/etc/sysctl.confで変更)

フェイルオーバー・グループを作成する構成では、リスナーのIPアドレスがアスタリスク(*)またはVIPと同じアドレスであることを確認してください。それ以外の場合、VIPに送信されたリクエストが仮想サーバーにルーティングされません。

- 各フェイルオーバー・グループのルーターIDは一意である必要があります。後続のフェイルオーバー・グループを作成するたびに、デフォルトのルーターIDは、254、253のように1つずつ減ります。

Fusion Middleware Controlを使用してフェイルオーバー・グループを作成するには、次を実行します。

1. Fusion Middleware Controlにログインします。

2. ページの左上にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. フェイルオーバー・グループを作成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「フェイルオーバー・グループ」を選択します。
フェイルオーバー・グループ・ページが表示されます。これには、構成に定義されているフェールオーバー・グループのリストが表示されます。

7. 「ロックして編集」をクリックし、次に「作成」をクリックします。

8. フェイルオーバー・グループの作成画面で、次のように入力します

- 仮想IP: ノード間で移動されるフローティング・ホスト名を入力します。これは、WEBHOST1とWEBHOST2の両方で有効化できる有効な仮想IPにマップする必要があります。このVIPがまだノードで有効化されていないことを確認してください。

- ルーターID: 前述の指示を参照してネットワーク構成のCDRを入力します。

- VIPをホストするプライマリおよびバックアップ・インスタンスを選択し、VIPを有効化する場所となる必要なネットワーク・インタフェースを入力します。

9. 結果画面で、「閉じる」をクリックします。
フェイルオーバー・グループ・ページに、作成したフェイルオーバー・グループの詳細が表示されます。

注意:
この時点では、2つのノードはアクティブ-パッシブ・ペアになっています。これらをアクティブ-アクティブ・ペアに変更するには、同じ2つのノードを含む別のフェイルオーバー・グループを作成しますが、その際、異なるVIPを割り当て、プライマリおよびバックアップ・ロールを逆にします。

注意:
フェイルオーバー・グループを作成する場合は、それらのマシン上でrootユーザーとしてotd_startFailoverを実行する必要があります。これはフェイルオーバーを手動で開始するためです。このコマンドを実行しないとフェイルオーバーは開始しないため、高可用性を実現できません。otd_startFailoverの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください
otd_startFailoverコマンドを実行するには、次の手順を実行します。

rootとして、またはsudo権限を持つユーザーとしてWLSTを起動します。

[root@webhost1]# ./wlst.sh
Initializing WebLogic Scripting Tool (WLST) ...
Jython scans all the jar files it can find at first startup. Depending on the
system, this process may take a few minutes to complete, and WLST may not
return a prompt right away.

wls:/offline> wls:/offline> props = {}

wls:/offline> props['domain-home'] =
/u01/oracle/config/domains/mftedg_domain/'

wls:/offline> props['instance'] ='otd_mftedg_WEBHOST1'

wls:/offline> otd_startFailover(props)

注意:
otd_startFailoverには、オペレーティング・システムのkeepalivedパッケージが必要です。このパッケージは、すべてのLinuxディストリビューションにバンドルされているわけではなく、オペレーティング・システムに手動でインストールする必要があります。詳細およびインストール方法は、オペレーティング・システムを参照してください。

13 Oracle SOA Suiteを含めるドメインの拡張

次の各項では、Oracle SOA Suiteソフトウェアを含めることでエンタープライズ・デプロイメント・ドメインを拡張する方法について説明します。

- Oracle SOA Suiteを含めるドメインの拡張時に使用する変数
この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

- システム・クロックの同期
Oracle SOA Suiteを追加するためにドメインを拡張する前に、各ホスト・コンピュータのシステム・クロックが同期していることを確認します。これは、各クラスタ内のホストで可能なかぎり同時にdateコマンドを実行することで行えます。

- エンタープライズ・デプロイメント用のソフトウェアのインストール
次の各項では、エンタープライズ・デプロイメント用のソフトウェアのインストール方法を説明します。

- Oracle SOA Suiteデータベース・スキーマの作成
Oracle SOA Suiteドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに必要なスキーマをインストールする必要があります。

- Oracle SOA Suiteを含めるエンタープライズ・デプロイメント・ドメインの拡張
この項では、Oracle SOA Suiteソフトウェアを含めることで既存のエンタープライズ・デプロイメント・ドメインを拡張する手順について説明します。

- トランザクション・リカバリ用のデフォルト永続ストアの構成
各管理対象サーバーでは、サーバーが調整およびコミットする、完了していない可能性のあるトランザクションに関する情報を格納するトランザクション・ログを使用します。Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、管理対象サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

- ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播
Oracle SOA Suiteインスタンスを含めることでドメインを拡張し、SOAHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリとマシンに伝播する必要があります。

- WLS_SOA1管理対象サーバーの起動および検証
これでドメインの拡張、管理サーバーの起動、およびドメインの他のホストへの伝播を完了したので、新しく構成したOracle SOA Suite管理対象サーバーを起動できます。

- 管理対象サーバーWLS_SOA2の起動と検証
WLS_SOA1管理対象サーバーの正常な構成と起動を検証したら、WLS_SOA2管理対象サーバーを起動して検証できます。

- トランザクション・ログの場所と作成の検証
WLS_SOA1およびWLS_SOA2が起動して稼働したら、トランザクション・ログ・ディレクトリを確認し、トランザクション・ログが予期したように作成されたことを確認します。

- 拡張したドメイン用のWeb層の構成
次の項では、Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをルーティングする方法について説明します。

- Oracle SOA Suiteの構成後手順
Oracle SOA Suiteをインストールして構成した後、次のような構成後タスクを検討します。

- Oracle SOA Suiteに対する自動サービス移行およびJDBC永続ストアの有効化
Oracle SOA Suiteが高可用性を実現するように構成するには、自動サービス移行でOracle SOA Suite管理対象サーバーを構成します。

親トピック: エンタープライズ・デプロイメントの構成

13.1 Oracle SOA Suiteを含めるドメインの拡張時に使用する変数

この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

いくつかのディレクトリ変数の値については、「このガイドで使用するファイル・システムとディレクトリ変数」に定義されています。

- ORACLE_HOME

- ASERVER_HOME

- MSERVER_HOME

- APPLICATION_HOME

- DEPLOY_PLAN_HOME

- OHS_DOMAIN_HOME

- JAVA_HOME

- ORACLE_RUNTIME

さらに、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」で定義されている次の仮想IP (VIP)アドレスを参照することになります。

- ADMINVHN

この章のアクションは、次のホスト・コンピュータで実行します。

- SOAHOST1

- SOAHOST2

- WEBHOST1

- WEBHOST2

13.2 システム・クロックの同期

Oracle SOA Suiteを追加するためにドメインを拡張する前に、各ホスト・コンピュータのシステム・クロックが同期していることを確認します。これは、各クラスタ内のホストで可能なかぎり同時にdateコマンドを実行することで行えます。

また、そのために使用できるサードパーティおよびオープンソースのユーティリティもあります。

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

次の各項では、エンタープライズ・デプロイメント用のソフトウェアのインストール方法を説明します。

- SOAHOST1でのOracle SOA Suiteインストーラの起動

- インストール画面への移動

- 他のホスト・コンピュータへのOracle SOA Suiteのインストール

- インストールの確認

13.3.1 SOAHOST1でのOracle SOA Suiteインストーラの起動

インストール・プログラムを起動する手順は次のとおりです。

1. SOAHOST1にログインします。

2. インストール・プログラムがダウンロードされたディレクトリに移動します。

3. 次の例に示すとおり、ご使用のシステムのJDKディレクトリからjava実行可能ファイルを実行し、インストール・プログラムを起動します。

JAVA_HOME/bin/java -d64 -jar Installer File Name

これらの例にあるJDKの場所は、ご使用のシステムの実際のJDKの場所に読み替えてください。

Installer File Nameは、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」にリストされているご使用の製品の実際のインストーラ・ファイルの名前に読み替えてください。

インストール・プログラムが表示されると、インストールを開始する準備ができています。

13.3.2 インストール画面への移動

インストール・プログラムでは、次の表にリストされている順序で一連の画面が表示されます。

インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。

画面

説明

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面では、使用可能なパッチを探してMy Oracle Supportを自動的に検索するか、組織にすでにダウンロードしたパッチを探してローカル・ディレクトリを自動的に検索します。

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middlewareのインストールのプランニングでインストールと構成のディレクトリの選択に関する項を参照してください。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

- 「SOA Suite」を選択します

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告メッセージまたはエラー・メッセージが表示された場合は、Oracle Fusion Middleware Infrastructureのインストール計画のシステム環境の検証ロードマップに関する項のいずれかのドキュメントを参照してください。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを確認します。

「インストール」をクリックしてインストールを開始します。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

進捗バーが100%完了になった後で、「次へ」をクリックします。

インストール完了

この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

13.3.3 他のホスト・コンピュータへのOracle SOA Suiteのインストール

SOAHOST2で製品マウント・ポイントおよびORACLE_HOME用に別の共有記憶域ボリュームまたはパーティションを構成している場合は、SOAHOST2でも製品インストールを実行する必要があります。

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

トポロジ内の他のホスト・コンピュータにソフトウェアをインストールするには、各ホストにログインして、「SOAHOST1でのInfrastructureインストーラの起動」と「Infrastructureインストール画面のナビゲート」の手順に従って、適切な記憶域デバイスにOracleホームを作成します。

注意:

以前のリリースでは、同一場所に配置されるOracle HTTP Serverインスタンスのセットが推奨エンタープライズ・トポロジに含まれていました。これらのリリースでは、インフラストラクチャをWeb層ホスト(WEBHOST1およびWEBHOST2)にインストールする要件がありました。ただし、このリリースでは、エンタープライズ・デプロイメント・トポロジは、Webサーバーがスタンドアロン・モードでインストールおよび構成されていると仮定するため、Webサーバーがアプリケーション層ドメインの一部とはみなされません。詳細は、「エンタープライズ・デプロイメント用のOracle HTTP Serverの構成」を参照してください

13.3.4 インストールの確認

インストールの完了後、次のタスクを正常に実行することでインストールを検証できます。

- インストール・ログ・ファイルの確認

- ディレクトリ構造のチェック

- Oracleホームの内容の表示

13.3.4.1 インストール・ログ・ファイルの確認

インストール・ログ・ファイルの内容を確認し、何も問題が発生していないことを確認します。ログ・ファイルの説明とその場所の詳細は、Oracle Universal Installerを使用したソフトウェアのインストールのインストール・ログ・ファイルの理解に関する項を参照してください。

13.3.4.2 ディレクトリ構造のチェック

インストールの内容は、インストール中に選択したオプションによって異なります。

Oracle SOA Suiteを追加すると、次のディレクトリおよびサブディレクトリが追加されます。

/u01/oracle/products/fmw/soa

bam
bin
bpm
common
integration
jlib
plugins
readme.txt
reports
soa

インストール後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解の「Oracle Fusion Middlewareの主要ディレクトリとは」を参照してください。

13.3.4.3 Oracleホームの内容の表示

Oracleホームの内容を、viewInventoryスクリプトを使用して表示することもできます。詳細は、Oracle Universal Installerを使用したソフトウェアのインストールのOracleホームの内容の表示に関する項を参照してください。

13.4 Oracle SOA Suiteデータベース・スキーマの作成

Oracle SOA Suiteドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに必要なスキーマをインストールする必要があります。

- リポジトリ作成ユーティリティ(RCU)の起動

- スキーマ作成のためのRCU画面のナビゲート

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

13.4.1 リポジトリ作成ユーティリティ(RCU)の起動

リポジトリ作成ユーティリティ(RCU)を起動するには:

1. 対象のシステムで、ORACLE_HOME/oracle_common/binディレクトリに移動します。

2. 対象のシステムで、JAVA_HOME環境変数に、動作保証されたJDKの場所が設定されていることを確認します。この場所は、binディレクトリより上の階層にする必要があります。たとえば、JDKが/u01/oracle/products/jdkに存在する場合は、次のようになります。

UNIXオペレーティング・システムの場合:

export JAVA_HOME=/u01/oracle/products/jdk

3. RCUを起動します。

UNIXオペレーティング・システムの場合:

./rcu

13.4.2 スキーマ作成のためのRCU画面のナビゲート

スキーマ作成に必要なタスクは、次のとおりです。

- タスク1「RCUの導入」

- タスク2「スキーマ作成の方法の選択」

- タスク3「データベース接続の詳細の指定」

- タスク4「カスタム接頭辞の指定とスキーマの選択」

- タスク5「スキーマのパスワードの指定」

- タスク6「カスタム変数の指定」

- タスク7「必須スキーマの表領域の検証」

- タスク8「スキーマ作成の実行」

- タスク9「スキーマの作成の検証」

タスク1   RCUの導入

「次へ」をクリックします。

タスク2   スキーマ作成の方法の選択

対象のデータベースに対するDBAアクティビティの実行に必要なパーミッションと権限が付与されている場合は、「システム・ロードおよび製品ロード」を選択します。この手順は、必要な権限が付与されていることを前提としています。

データベースに対するDBAアクティビティの実行に必要なパーミッションまたは権限が付与されていない場合は、この画面で、「システム・ロードに対するスクリプトの準備」を選択する必要があります。このオプションによってSQLスクリプトが生成され、必要なスキーマを作成するためにデータベース管理者が利用できます。リポジトリ作成ユーティリティを使用したスキーマの作成のシステム・ロードおよび製品ロードの理解に関する項を参照してください。

タスク3   データベース接続の詳細の指定

RCUがデータベースに接続できるようにするために、データベース接続の詳細を指定します。

「ホスト名」フィールドに、Oracle RACデータベースのSCANアドレスを入力します。

「DBMS/サービス」詳細を入力します。

「スキーマ所有者」および「スキーマ・パスワード」詳細を入力します。

「次へ」をクリックして先に進み、データベースへの接続が成功したことを確認するダイアログ・ウィンドウで、「OK」をクリックします。

タスク4   カスタム接頭辞の指定とスキーマの選択

「既存の接頭辞の選択」を選択し、初期ドメインを作成したときに使用した接頭辞を選択します。

スキーマのリストから「SOA Suite」スキーマを選択します。これにより、「SOAインフラストラクチャ」が自動的に選択されます。また、次の依存スキーマがInfrastructureとともにすでにインストールされて灰色表示されています。

- メタデータ・サービス

- 監査サービス

- 監査サービスへの追加

- 監査サービス・ビューア

- Oracle Platform Security Services

- ユーザー・メッセージング・サービス

カスタム接頭辞は、これらのスキーマを論理的にグループ化して、このドメイン内でのみ使用することを目的としています。複数のドメイン間でのスキーマの共有はサポートされていないため、ドメインごとに固有のスキーマのセットを作成する必要があります。

ヒント:

カスタム接頭辞の詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のカスタム接頭辞の理解に関する項を参照してください。

マルチドメイン環境でスキーマを編成する方法の詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のスキーマ作成の計画に関する項を参照してください。

「次へ」をクリックして先に進み、スキーマ作成の前提条件チェックが成功したことを確認するダイアログ・ウィンドウの「OK」をクリックします。

タスク5   スキーマのパスワードの指定

スキーマのパスワードをデータベースに設定する方法を指定してから、パスワードの指定と確認を行います。

ヒント:

この画面で設定するパスワードは、メモしておく必要があります。このパスワードは、後述するドメイン作成のプロセスで必要になります。

タスク6   カスタム変数の指定

SOAインフラストラクチャ・スキーマのカスタム変数を指定します。

エンタープライズ・デプロイメント・トポロジの場合、Database Profileのカスタム変数としてLARGEを入力し、Oracle Healthcareの使用を予定している場合は、Healthcare Integrationの変数としてYESを入力します。

Oracle Healthcareの使用を予定している場合は、Healthcare Integrationの変数としてYESを入力します。

詳細は、『Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成』のSOA Suiteスキーマに必要なカスタム変数に関する項を参照してください。

タスク7   必須スキーマの表領域の検証

「表領域のマップ」画面で情報を確認し、「次へ」をクリックして、デフォルト値を受け入れます。

確認ダイアログ・ボックスで「OK 」をクリックします。

タスク8   スキーマ作成の完了

RCU画面の残りの部分を先に進めて、スキーマ作成を完了します。「完了サマリー」画面に到達したら、「閉じる」をクリックしてRCUを終了します。

タスク9   スキーマの作成の検証

スキーマが正常に作成されたことと、データベース接続詳細を確認するためには、SQL*Plusまたは別のユーティリティで、SOAINFRAスキーマ名および指定したパスワードを使用してデータベースに接続します。

例:

./sqlplus

SQL*Plus: Release 11.2.0.4.0 Production on Fri Nov 1 08:44:18 2013

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Enter user-name: FMW1221_SOAINFRA
Enter password: soainfra_password

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

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

Oracle SOA Suiteスキーマを正常にインストールしたら、この項の手順に従ってトランザクション・リカバリのスキーマを構成します。

この手順では、WebLogic Serverが予期せずに使用不可になった後、進行中のトランザクションをリカバリする際に、Oracle WebLogic Serverトランザクション・マネージャでトランザクション状態の情報を問い合せて該当するコマンド(commitやrollbackなど)を発行できるように適切なデータベース権限を設定します。

これらの権限は、リポジトリ作成ユーティリティでスキーマを作成したときに定義した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>

13.5 Oracle SOA Suiteを含めるエンタープライズ・デプロイメント・ドメインの拡張

この項では、Oracle SOA Suiteソフトウェアを含めることで既存のエンタープライズ・デプロイメント・ドメインを拡張する手順について説明します。

ドメインを拡張するには、次のタスクを実行する必要があります。

- 構成ウィザードの起動

- Oracle SOA Suiteを含めるドメイン拡張を行うための構成ウィザード画面のナビゲート

13.5.1 構成ウィザードの起動

構成ウィザードを起動する手順は次のとおりです。

1. WebLogic Serverコンソールで、このドメイン拡張によって変更されるすべての管理対象サーバーを停止します。影響を受けない管理対象サーバーは、オンラインのままにすることができます。

2. 管理対象サーバーのステータスを確認してから、管理サーバーを停止します。

3. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

cd ORACLE_HOME/oracle_common/common/bin
./config.sh

13.5.2 Oracle SOA Suiteを含めるドメイン拡張を行うための構成ウィザード画面のナビゲート

この項で説明する手順を実行して、目的のトポロジのドメインを作成して構成します。

注意:

この項で説明する手順を使用して、既存のドメインを拡張することもできます。この手順の説明では要件が満たされない場合は、その要件に応じた選択を行うか、サポート・ドキュメントで追加の詳細を参照してください。

ドメインを作成して構成するためのタスクは次のとおりです。

- タスク1「ドメイン・タイプとドメイン・ホームの場所の選択」

- タスク2「構成テンプレートの選択」

- タスク3「高可用性オプションの指定」

- タスク4「データベース構成タイプの指定」

- タスク5「JDBCコンポーネント・スキーマの情報の指定」

- タスク6「GridLink Oracle RACデータベース接続の詳細情報の指定」

- タスク7「JDBC接続のテスト」

- タスク9「詳細構成の選択」

- タスク10「管理対象サーバーの構成」

- タスク11「クラスタの構成」

- タスク12「クラスタへの管理対象サーバーの割当て」

- タスク13「Coherenceクラスタの構成」

- タスク14「既存のマシンの検証」

- タスク15「マシンへのサーバーの割当て」

- タスク16「仮想ターゲット」

- タスク17「パーティション」

- タスク18「JMSファイル・ストアの構成」

- タスク19「構成の仕様の確認とドメインの構成」

- タスク20「ドメイン・ホームと管理サーバーURLのメモ」

- タスク21「管理サーバーの起動」

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、初期ドメイン作成時に作成した管理サーバー・ドメイン・ホームの完全なパスを表します。

MSERVER_HOME変数の値は入力しないでください。これは、管理対象サーバー・ドメイン・ディレクトリの場所を表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「構成タイプ」に関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

- Oracle SOA Suite - 12.2.1.1.0 [soa]

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「テンプレート」に関する項を参照してください。

タスク3   高可用性オプションの指定

「データベース構成タイプ」画面で、次のオプションを選択します。

1. 「JTAトランザクション・ログ永続性」で、「デフォルトの永続ストア」を選択します。

2. 「JMSサーバー永続性」で、「JMSファイル・ストア」を選択します。

タスク4   データベース構成タイプの指定

「データベース構成タイプ」画面で、「RCUデータ」を選択します。

Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。

すべてのフィールドにおける資格証明が、Oracle Fusion Middleware Infrastructureの構成中に指定したものと同じであることを確認します。

データベース接続情報の確認が完了した後で、「RCU構成の取得」をクリックします。操作に成功すると、「接続結果ログ」に次の出力が示されます。

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

ヒント:

「RCUデータ」オプションの詳細は、リポジトリ作成ユーティリティによるスキーマの作成のサービス表スキーマの理解に関する項を参照してください。

この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のデータ・ソース・デフォルトに関する項を参照してください。

タスク5   JDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」画面で、表にあるSOAスキーマをすべて選択します。

スキーマを選択すると、ページ上のフィールドがアクティブ化され、データベース接続フィールドに自動的に値が移入されます。

「GridLinkへ変換」をクリックし、「次へ」をクリックします。

タスク6   GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

要素

説明と推奨値

SCAN、ホスト名とポート

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドに、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

データベースがFANイベントを受信して処理できるように、「FANの有効化」チェック・ボックスが選択されていることを確認します。

タスク7   JDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

ヒント:

この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のコンポーネント・スキーマのテストに関する項を参照してください。

タスク8   キーストア

この画面を使用して、ドメインで使用されるキーストアの詳細を指定します。

標準的なエンタープライズ・デプロイメントの場合、デフォルト値をそのまま使用できます。

詳細は、『構成ウィザードによるWebLogicドメインの作成』のキーストアに関する項を参照してください。

タスク9   拡張構成の選択

目的のトポロジに応じたドメインの構成を完了するには、「拡張構成」画面で次のオプションを選択します。

- トポロジ
サーバー・テンプレート、管理対象サーバー、クラスタ、仮想ターゲットおよびCoherenceの設定の追加、削除または変更。

- ファイル・ストア

タスク10   管理対象サーバーの構成

「管理対象サーバー」画面で、サーバーのリストにOracle SOA Suite用の新しい管理対象サーバーが表示されます。このサーバーは、タスク2「構成テンプレートの選択」で選択したOracle SOA Suite構成テンプレートによって自動的に作成されました。

次のタスクを実行して、デフォルトのOracle SOA Suite管理対象サーバーを変更して2つ目のOracle SOA Suite管理対象サーバーを作成します。

1. デフォルトのOracle SOA Suite管理対象サーバーの名前をWLS_SOA1に変更します。

2. 「追加」をクリックして新しいOracle SOA Suite管理対象サーバーを作成し、それにWLS_SOA2という名前を付けます。

ヒント:

ここで推奨するサーバー名は、このドキュメント全体で使用します。別の名前を選択する場合は、必要に応じてそれらの名前に置き換えてください。

3. 次の表の情報を使用して、各Oracle SOA Suite管理対象サーバーの残りの列を入力します。

ヒント:

「管理対象サーバー」画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の管理対象サーバーに関する項を参照してください。

サーバー名

リスニング・アドレス

リスニング・ポート

SSLの有効化

SSLリスニング・ポート

サーバー・グループ

WLS_WSM1

SOAHOST1

7010

いいえ

無効

WSMPM-MAN-SVR、JRF-MAN-SVR、およびWSM-CACHE-SVR

WLS_WSM2

SOAHOST2

7010

いいえ

無効

WSMPM-MAN-SVR、JRF-MAN-SVR、およびWSM-CACHE-SVR

WLS_SOA1

SOAHOST1

8001

いいえ

無効

SOA-MGD-SVRS-ONLY

WLS_SOA2

SOAHOST2

8001

いいえ

無効

SOA-MGD-SVRS-ONLY

タスク11   クラスタの構成

このタスクでは、Oracle SOA Suiteソフトウェアのターゲットとすることができる管理対象サーバーのクラスタを作成します。

クラスタの「フロントエンド・ホスト」プロパティも設定します。これにより、WebLogic Serverは必要に応じてWebサービス・コールバックやその他のリダイレクトを、各リクエストのHOSTヘッダーにあるアドレスではなく、ロード・バランサ上のsoa.example.comにリダイレクトするようになります。

soa.example.com仮想サーバー・アドレスの詳細は、「ハードウェア・ロード・バランサでの仮想ホストの構成」を参照してください。

「クラスタ」画面を使用して、新しいクラスタを作成します。

1. 「追加」ボタンをクリックします。

2. 「クラスタ名」フィールドでSOA_Clusterを指定します。

3. 「フロントエンド・ホスト」フィールドでsoa.example.comを指定します。

4. 「フロントエンドHTTPポート」に80を指定し、「フロントエンドHTTPSポート」に443を指定します。

注意:

デフォルトでは、クラスタ内のサーバー・インスタンスは、ユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』のユニキャストまたはマルチキャストを選択する際の考慮事項に関する項を参照してください。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「クラスタ」に関する項を参照してください。

タスク12   クラスタへの管理対象サーバーの割当て

「サーバーのクラスタへの割当」画面を使用して、WLS_SOA1およびWLS_SOA2を新規クラスタSOA_Clusterに割り当てます。

1. 「クラスタ」ペインで、サーバーを割り当てるクラスタ(ここではSOA_Cluster)を選択します。

2. 「サーバー」ペインで、次のいずれかの操作を実行して、WLS_SOA1をSOA_Clusterに割り当てます。

- WLS_SOA1管理対象サーバーを1回クリックして選択し、右矢印をクリックして「クラスタ」ペインで選択されているクラスタの下に移動します。

- WLS_SOA1をダブルクリックして、クラスタ・ペインで選択されているクラスタの下に移動します。

3. 同じ手順を繰り返して、WLS_SOA2をSOA_Clusterに割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのクラスタへの割当」に関する項を参照してください。

タスク13   Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期Infrastructureドメインの作成中に定義されているため、9991のままにします。

注意:

Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報』のOracle Coherenceに関する項を参照してください。

タスク14 既存のマシンの検証

「次へ」をクリックします。

タスク15   マシンへのサーバーの割当て

「サーバーのマシンへの割当」画面を使用して、作成したばかりのOracle SOA Suite管理対象サーバーを、ドメイン内の対応するマシンに割り当てます。

WLS_SOA1をSOAHOST1に割り当て、WLS_SOA2をSOAHOST2に割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのマシンへの割当」に関する項を参照してください。

タスク16   仮想ターゲット

「次へ」をクリックして次の画面に進みます。

タスク17   パーティション

「次へ」をクリックして次の画面に進みます。

タスク18 JMSファイル・ストアの構成

「JMSファイル・ストア」画面で、UMSおよびBPMのファイル・ストアを含む各SOA永続ストアに次のディレクトリを割り当てます。

ORACLE_RUNTIME/domain_name/SOA_cluster/jms

この例では、ORACLE_RUNTIMEを、ご使用の環境の変数値に置き換えます。domain_nameを、ドメインに割り当てた名前に置き換えます。soa_clusterを、クラスタに割り当てた名前に置き換えます。

タスク19   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

「更新」をクリックするまで、ドメインの作成は開始されません。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

タスク20   ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

- ドメインの場所

- 管理サーバーURL

いずれの項目も後で必要になるため、メモしておいてください。ドメインの場所は管理サーバーの起動に使用するスクリプトへのアクセスに必要で、管理サーバーURLはWebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlへのアクセスに必要です。

「終了」をクリックして、構成ウィザードを閉じます。

タスク21   管理サーバーの起動

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

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

各管理対象サーバーでは、サーバーが調整およびコミットする、完了していない可能性のあるトランザクションに関する情報を格納するトランザクション・ログを使用します。Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、管理対象サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

注意:

トランザクション・リカバリ・サービスの移行機能を有効にするには、クラスタにある他のサーバーで使用可能な永続記憶域ソリューションの場所を指定します。クラスタ内のすべての管理対象サーバーがこのディレクトリにアクセスできる必要があります。また、このディレクトリは、サーバーを再起動する前にも存在している必要があります。

お薦めする場所は、デュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)です。記憶域エラーが発生した場合に確実に保護するには、記憶域レベルで適切な複製およびバックアップ・メカニズムを設定しておくことが重要です。

この情報は、ファイルベースのトランザクション・ログに適用されます。トランザクション・ログに対して、データベース・ベースの永続ストアを構成することもできます。詳細は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用」を参照してください。

デフォルトの永続ストアの場所を設定する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

ADMINVHN:7001/console

2. 「チェンジ・センター」セクションで、「ロックして編集」をクリックします。

3. クラスタ内の管理対象サーバーごとに、次を実行します。

a. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページが表示されます。

b. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

c. 「構成」タブで、「サービス」タブをクリックします。

d. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
エンタープライズ・デプロイメントの場合は、ORACLE_RUNTIMEディレクトリの場所を使用します。このサブディレクトリは、クラスタのトランザクション・ログの中央の共有場所の役割を果します。詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

例:

ORACLE_RUNTIME/domain_name/cluster_name/tlogs

この例では、ORACLE_RUNTIMEを、ご使用の環境の変数値に置き換えます。domain_nameを、ドメインに割り当てた名前に置き換えます。cluster_nameを、先ほど作成したクラスタ名で置き換えます。

e. 「保存」をクリックします。

4. 「保存」をクリックして、「変更のアクティブ化」をクリックします。

5. クラスタ内の他のサーバーで手順1から4を完了します。

注意:

構成手順の後半で、トランザクション・ログの場所と作成について検証します。

13.7 ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

Oracle SOA Suiteインスタンスを含めることでドメインを拡張し、SOAHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリとマシンに伝播する必要があります。

表13-1は、変更をすべてのドメイン・ディレクトリとマシンに伝播するために必要な手順をまとめたものです。

更新済ドメインをWEBHOST1およびWEBHOST2マシンに伝播する必要はありません。それらのホスト・コンピュータ上のOracle HTTP Serverインスタンスに対する変更はないためです。

表13-1 ドメイン変更をドメイン・ディレクトリおよびマシンに伝播するために必要なタスクのサマリー

タスク

説明

詳細情報

SOAHOST1での拡張済ドメインの圧縮

packコマンドを使用して、新しいOracle SOA Suite管理対象サーバー構成が含まれる新しいテンプレートJARファイルを作成します。

ドメインを圧縮する際には、soadomaintemplate.jarというテンプレートJARファイルを作成します。

SOAHOST1での拡張済ドメインの圧縮

SOAHOST1の管理対象サーバー・ディレクトリでのドメインの解凍

SOAHOST1のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

SOAHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍

SOAHOST2でのドメインの解凍

SOAHOST2のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

- SOAHOST1での拡張済ドメインの圧縮

- SOAHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍

- SOAHOST2でのドメインの解凍

13.7.1 SOAHOST1での拡張済ドメインの圧縮

次の手順を使用して、ドメイン構成情報が含まれるテンプレートJARファイルを作成します。

1. SOAHOST1にログインし、次のようにpackコマンドを実行してテンプレートJARファイルを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true
-domain=ASERVER_HOME
-template=full_path/soadomaintemplate.jar
-template_name=soa_domain_template

この例では、次のようになります。

- ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

- full_pathを、テンプレートJARファイルを保存するディレクトリの完全なパスに置き換えます。

- soadomaintemplate.jarは、作成するJARファイルのサンプル名です。これには、Oracle HTTP Serverインスタンスの構成ファイルなどのドメイン構成ファイルが含まれます。

- soa_domain_templateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

2. packコマンドで作成したばかりのテンプレートJARファイルの場所を書き留めます。

ヒント:

packおよびunpackコマンドの詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』のPackおよびUnpackコマンドの概要に関する項を参照してください。

13.7.2 SOAHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍

更新したドメイン構成情報を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播する手順は次のとおりです。

1. SOAHOST1にログインしていない場合は、ログインします。

2. まだ作成していない場合は、SOAHOST1のローカル記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

3. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME  \
-template=full_path/soadomaintemplate.jar \
-overwrite_domain=true \
-app_dir=APPLICATION_HOME

この例では、次のようになります。

- MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

- soadomaintemplate.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。

- 管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍する場合は、-overwrite_domain=true引数が必要です。
上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびEARファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびEARファイルをリストアする必要があります。

- APPLICATION_HOMEを、ローカル記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。

ヒント:

packおよびunpackコマンドの詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』のPackおよびUnpackコマンドの概要に関する項を参照してください。

4. ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがSOAHOST1のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

13.7.3 SOAHOST2でのドメインの解凍

この手順では、以前に作成したファイルを、SOAHOST1とSOAHOST2の両方からアクセスできる場所(たとえば、共有記憶域ファイラ上のASERVER_HOMEディレクトリなど)にコピー済であることを想定しています。

1. SOAHOST2にログインします。

2. まだ作成していない場合は、SOAHOST2の記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

3. SOAHOST2からsoadomaintemplate.jarにアクセスできることを確認します。
たとえば、SOAHOST2に別の共有記憶域ボリュームまたはパーティションを使用している場合は、SOAHOST2にマウントされているボリュームまたはパーティションにテンプレートをコピーします。

4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME
-overwrite_domain=true
-template=complete_path/soadomaintemplate.jar
-log_priority=DEBUG
-log=/tmp/unpack.log
-app_dir=APPLICATION_HOME

この例では、次のようになります。

- MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

- complete_path/soadomaintemplate.jarを、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したドメイン・テンプレートJARファイルの完全なパスとファイル名に置き換えます。

- APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

5. ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがSOAHOST2のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

13.8 WLS_SOA1管理対象サーバーの起動および検証

これでドメインの拡張、管理サーバーの起動、およびドメインの他のホストへの伝播を完了したので、新しく構成したOracle SOA Suite管理対象サーバーを起動できます。

このプロセスには、次の各項で説明する3つのタスクが含まれます。

- WLS_SOA1管理対象サーバーの起動

- AdministratorsグループへのSOAAdminロールの追加

- SOAインフラストラクチャへのログインによる管理対象サーバーの検証

13.8.1 WLS_SOA1管理対象サーバーの起動

WLS_SOA1管理対象サーバーを起動する手順は次のとおりです。

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

http://ADMINVHN:7001/em

2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

3. 「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。

4. WLS_SOA1管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。

注意:

SOAサーバーは、ポリシー・アクセス・サービスに依存して機能します。これは、SOAサーバーが起動する前に、ドメイン内のWSM-PM管理対象サーバーが稼働していてアクセス可能になっている必要があることを意味します。

5. 起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_SOA1管理対象サーバーが稼働中であることを確認します。

13.8.2 AdministratorsグループへのSOAAdminロールの追加

WLS _SOA1管理対象サーバーのOracle SOA Suite構成を検証する前に、SOAAdmin管理ロールをエンタープライズ・デプロイメント管理グループ(SOA Administrators)に追加します。

このタスクを実行するには、「エンタープライズ・デプロイメントの管理用のロールの構成」を参照してください。

13.8.3 SOAインフラストラクチャへのログインによる管理対象サーバーの検証

SOAAdminロールをSOA Administratorsグループに追加した後、次のようにWLS_SOA1管理対象サーバーのOracle SOA Suiteソフトウェアの構成を検証できます。

1. Webブラウザを使用して次のURLに移動します。

http://SOAHOST1:8001/soa-infra/

2. エンタープライズ・デプロイメント管理者ユーザー資格証明(weblogic_soa)を使用してログインします。

次のようなタイトルのWebページが表示されます。

"Welcome to the Oracle SOA Platform on WebLogic"

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

WLS_SOA1管理対象サーバーの正常な構成と起動を検証したら、WLS_SOA2管理対象サーバーを起動して検証できます。

WLS_SOA2管理対象サーバーを起動して検証するには、WLS_SOA2管理対象サーバーに対して「WLS_SOA1管理対象サーバーの起動および検証」の手順を使用します。

検証URLとしてWebブラウザに次のURLを入力し、エンタープライズ・デプロイメント管理者ユーザー資格証明(weblogic_soa)を使用してログインします。

http://SOAHOST2:8001/soa-infra/

13.10 トランザクション・ログの場所と作成の検証

WLS_SOA1およびWLS_SOA2が起動して稼働したら、トランザクション・ログ・ディレクトリを確認し、トランザクション・ログが予期したように作成されたことを確認します。

「トランザクション・リカバリ用のデフォルト永続ストアの構成」で実行した手順に基づいて、次のコマンドを実行し、確認します。

ORACLE_RUNTIME/domain_name/cluster_name/tlogs

- _WLS_WLS_SOA1000000.DAT

- _WLS_WLS_SOA2000000.DAT

13.11 拡張したドメイン用のWeb層の構成

次の項では、Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをルーティングする方法について説明します。

- 拡張したドメイン用のOracle Traffic Directorの構成

- WLS_SOA管理対象サーバー用のOracle HTTP Serverの構成

- WebLogicプロキシ・プラグインの構成

- ロード・バランサを使用したOracle SOA Suite URLの検証

13.11.1 拡張したドメイン用のOracle Traffic Directorの構成

このドメインでOracle Traffic Directorを構成した場合、状況によっては、Oracle Traffic Director構成に別のオリジン・サーバー・プール、仮想サーバーまたはルートを追加する必要があります。各Oracle Fusion Middleware製品のOracle Traffic Directorの要件を理解するには、「オリジン・サーバーおよび仮想ホストのサマリー」を参照してください。

オリジン・サーバー・プール、仮想サーバーおよびルートを追加する手順は、「エンタープライズ・デプロイメント用のOracle Traffic Director仮想サーバーの定義」を参照してください。

13.11.2 WLS_SOA管理対象サーバー用のOracle HTTP Serverの構成

Oracle SOA Suiteクラスタにリクエストを正しくルーティングするようにWeb層のOracle HTTP Serverインスタンスを構成するには、次の手順を使用して、soa.example.com仮想サーバーのパラメータを作成して定義するOracle HTTP Server構成ファイルを追加作成します。

この手順では、「リクエストをアプリケーション層にルーティングするようにOracle HTTP Serverを構成」で説明されているOracle HTTP Server構成タスクが実行済であることを想定しています。

リクエストがOracle SOA Suiteクラスタに正しくルーティングされるように仮想ホスト構成ファイルを作成する手順は次のとおりです。

1. WEBHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(OHS_1)の構成ディレクトリに変更します。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/

2. soa_vh.confファイルを作成し、次のディレクティブを追加します。

<VirtualHost WEBHOST1:7777>
ServerName https://soa.example.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

3. <VirtualHost>タグ内に、次のディレクティブを追加します。

注意:

/workflowのURLエントリは省略可能です。これは、Oracle ADFタスク・フォームと関連付けられたワークフロー・タスク用です。/workflowのURL自体は、フォームに応じた別の値とすることができます。

<Location /soa-infra>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Worklist
<Location /integration>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Workflow
<Location /workflow>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA composer application
<Location /soa/composer>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /frevvo>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
</VirtualHost>

soa_vh.confファイルは、例13-1のように表示されます。

4. soa_vh.confファイルを2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。

OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf/

5. soa_vh.confを編集して、<VirtualHost>ディレクティブ内のWEBHOST1への参照をWEBHOST2への参照に変更します。

6. WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

例13-1 soa_vh.confファイル

<VirtualHost WEBHOST1:7777>
ServerName https://soa.example.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

<Location /soa-infra>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Worklist
<Location /integration>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
WLSRequest ON
WebLogicCluster SSOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Workflow
<Location /workflow>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA composer application
<Location /soa/composer>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /frevvo>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
</VirtualHost>

注意:

システムで内部呼出しを使用する場合は、soainternal仮想ホストに適切なロケーションを追加してください。

13.11.3 WebLogicプロキシ・プラグインの構成

リクエストがOracle HTTP Serverインスタンスを介して正しくルーティングされたことを検証するには、先ほど構成したクラスタに対して「WebLogicプラグインの有効化」パラメータを設定しておく必要があります。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ペインで、「環境」ノードを開きます。

3. 「クラスタ」をクリックします。

4. Oracle HTTP Serverからのリクエストのプロキシ先とするクラスタを選択します。

「構成: 一般」タブが表示されます。

5. 「詳細」セクションまでスクロール・ダウンして、開きます。

6. 「チェンジ・センター」で「ロックして編集」をクリックします。

7. 「WebLogicプラグインの有効化」を「はい」に設定します。

8. 「保存」をクリックし、「変更のアクティブ化」をクリックします。

9. 「チェンジ・センター」の「変更のアクティブ化」をクリックします。

10. この項で変更したすべてのクラスタのすべての管理対象サーバーを再起動します。

13.11.4 ロード・バランサを使用したOracle SOA Suite URLの検証

Oracle HTTP Server仮想ホストの構成を検証し、ハードウェア・ロード・バランサがOracle HTTP Serverインスタンスを経由してアプリケーション層にリクエストをルーティングできることを確認する手順は次のとおりです。

1. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。

サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。

2. 次のURLにアクセスできることを確認します。

- https://soa.example.com:443/soa-infra

- https://soa.example.com:443/integration/worklistapp

- https://soa.example.com:443/sdpmessaging/userprefs-ui

- https://soa.example.com:443/soa/composer

3. 次のロード・バランサURLにアクセスして、アプリケーション層でアイデンティティ・サービスを正常に起動できることを確認します。

https://soa.example.com:443/integration/services/IdentityService/identity?WSDL

13.12 Oracle SOA Suiteの構成後手順

Oracle SOA Suiteをインストールして構成した後、次のような構成後タスクを検討します。

- Oracle SOA Suite用のOracleアダプタの構成

- SOAサーバーとハードウェア・ロード・バランサ間のSSL通信の有効化

- SOAクラスタ内の同期/非同期相互作用に関する考慮事項

13.12.1 Oracle SOA Suite用のOracleアダプタの構成

開発しているOracle SOA Suiteアプリケーションで、Oracle SOA Suite用のOracleアダプタのいずれかを利用する場合、それらのアダプタがエンタープライズ・トポロジで効率的かつセキュアに機能するように構成されていることを確認します。

詳細は、次の各項を参照してください。

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

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

- Oracle Databaseアダプタの高可用性の有効化

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

開発またはデプロイするOracle SOA Suiteアプリケーションで、OracleファイルおよびFTPアダプタを必要とする場合、エンタープライズ・デプロイメント・トポロジで高可用性が得られるようにそれらのアダプタを構成する必要があります。

次の各項を使用してこのタスクを完了します。

- OracleファイルおよびFTPアダプタ構成の理解

- 管理コンソールでのOracleファイル・アダプタの構成

- コンポジット・アプリケーション内でのJCAファイルの編集

- Oracle FTPアダプタの構成

13.12.1.1.1 OracleファイルおよびFTPアダプタ構成の理解

OracleファイルおよびFTPアダプタを使用すると、プライベート・ファイル・システムやリモート・ファイル・システムのファイルをFTP(ファイル転送プロトコル)を使用してBPELプロセスまたはOracle Mediatorで読取りまたは書込みできるようになります。

適切に構成した場合、これらのアダプタは、Oracle BPEL Process ManagerおよびOracle Mediatorサービス・エンジンでのアクティブ/アクティブ・トポロジに対する高可用性機能を、インバウンドおよびアウトバウンドの両方の操作でサポートします。

このタスクの一般情報は、テクノロジ・アダプタの理解のOracleファイルおよびFTPアダプタの構成に関する項を参照してください。ここで説明する手順は、Oracle SOA Suiteエンタープライズ・デプロイメントに固有のものです。

注意:

ファイル・アダプタは、インバウンド・ディレクトリからファイルを取得して処理し、出力ディレクトリにファイルを出力します。ファイル・アダプタでの処理はトランザクション方式ではないので、ファイルは2回処理できます。この結果として、RACバックエンドまたはSOA管理対象サーバーでフェイルオーバーが発生したときに、重複するファイルが得られる可能性があります。

13.12.1.1.2 管理コンソールでのOracleファイル・アダプタの構成

Oracleファイル・アダプタの高可用性を実現するには、最初に、eis/HAFileAdapterに対応するconnection-instanceのOracleファイル・アダプタのデプロイメント・ディスクリプタを変更します。

このタスクは、Oracle WebLogic Serverコンソールから実行できます。

1. Oracle WebLogic Server管理コンソールに移動してログインします。
例:

http://ADMINVHN:7001/console

2. 管理コンソールの左ペインで、「デプロイメント」をクリックします。

3. 「デプロイメントのサマリー」表でFileAdapterリソース・アダプタを見つけます。

4. 「FileAdapter」をクリックし、「FileAdapterの設定」ページを表示します。

5. 「構成」をクリックします。

6. 「アウトバウンド接続プール」をクリックします。

7. javax.resource.cci.ConnectionFactoryを開き、構成済の接続ファクトリを表示します。

8. 「eis/HAFileAdapter」をクリックします。
接続ファクトリの「アウトバウンド接続のプロパティ」が表示されます(図13-1)。

図13-1 Oracle WebLogic Serverコンソール - 「javax.resource.cci.Connectionfactoryの設定」

9. 「ロックして編集」をクリックします。
プロパティ値の列が編集可能になります(「プロパティ値」列の任意の行をクリックしてその値を変更できます)。

10. 表13-2に示されている値を入力します。

注意:

controlDirを更新し、その他の値を、表13-2に示されているデフォルト値と照合します。

表13-2 javax.resource.cci.Connectionfactoryに入力する値

パラメータ

説明

controlDir

制御ファイルを格納するディレクトリを入力します。1つのクラスタ内で複数のWebLogic Serverインスタンスを実行する場合は、共有の場所に設定する必要があります。この共有記憶域のディレクトリは次のような構造にします。

ORACLE_RUNTIME/domain_name/cluster_name/fadapter

inboundDataSource

値をjdbc/SOADataSourceに設定します。

outboundDataSource

値をjdbc/SOADataSourceに設定します。

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の完全修飾クラス名を指定します。

workingDirectory

この値は、デフォルトのままにします。

11. これらのプロパティを更新した後、「保存」をクリックします。「デプロイメント・プランの保存」ページが表示されます。

12. DEPLOY_PLAN_HOMEディレクトリを作成します。

mkdir -p DEPLOY_PLAN_HOME/soaedg_domain

この例では、DEPLOY_PLAN_HOMEを、「このガイドで使用するファイル・システムとディレクトリ変数」で定義されているデプロイメント・プラン・ディレクトリの実際のパスに置き換えます。

13. デプロイメント・プランの共有記憶域場所を入力します。そのディレクトリ構造は次のとおりです。

DEPLOY_PLAN_HOME/soaedg_domain/FileAdapterPlan.xml

14. 保存してアクティブ化をクリックし、変更を保存して適用します。

15. コンソールでデプロイメントを更新します。

a. 「デプロイメント」をクリックします。

b. 「ロックして編集」をクリックします。

c. ファイル・アダプタを選択します。

d. 「更新」をクリックします。

e. 「このアプリケーションを新しいデプロイメント・プランの変更とあわせた場所に更新します(このオプションには、デプロイメント・プランを指定する必要があります)。」を選択し、共有記憶域の場所に保存されたデプロイメント・プランを選択します。クラスタ内のすべてのサーバーは、このプランにアクセスできる必要があります。

f. 「終了」をクリックします。

g. 変更をアクティブ化します。

16. FileAdapterデプロイメントがアクティブ化されて稼働中であることを確認します。

a. 管理コンソールの左ペインで、「デプロイメント」をクリックします。

b. 「デプロイメント」表のFileAdapterデプロイメントを見つけます。

c. それがアクティブな状態ではない場合は、「デプロイメントのサマリー」の下の「FileAdapter」を選択し、「起動」→「すべてのリクエストを処理」を選択します。

13.12.1.1.3 コンポジット・アプリケーション内でのJCAファイルの編集

管理コンソールでFileAdapterデプロイメントを構成したら、例13-2に示すように、デプロイするコンポジット・アプリケーションに含まれている.jcaファイルを編集し、それらが前の手順で構成した接続ファクトリを使用できるようにすることができます。

注意:

接続ファクトリの位置属性は、eis/HAFileAdapterに設定されています。

例13-2 エンタープライズ・デプロイメント用のファイル・アダプタ.JCAファイルの変更の例

<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>

13.12.1.1.4 Oracle FTPアダプタの構成

アプリケーションでFTPアダプタが必要な場合、「管理コンソールでのOracle File Adapterの構成」および「コンポジット・アプリケーション内でのJCAファイルの編集」の各手順を繰り返します(ただし、次の点が異なります)。

- 管理コンソールのデプロイメントのリストで「FtpAdapter」デプロイメントを選択します。

- FTPAdapterデプロイメントのeis/Ftp/HAFtpAdapter接続ファクトリ・インスタンスを変更します。

- デプロイメント・プランの共有記憶域場所を入力します。そのディレクトリ構造は次のとおりです。

DEPLOY_PLAN_HOME/soaedg_domain/FtpAdapterPlan.xml

- 次の場所を指すように、ControlDirプロパティを更新します。

ORACLE_RUNTIME/domain_name/cluster_name/ftadapter

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

Oracle JMSアダプタがクラスタ内の複数のサーバーと通信する場合、アダプタの通信ファクトリのプロパティFactoryPropertiesに使用可能なサーバーがリストされている必要があります。サーバーがリストされない場合、ランダムな1サーバーとの接続が確立されます。そのサーバーが停止しても、追加のメッセージは処理されません。

アダプタのJCA接続ファクトリを確認する手順は次のとおりです。

1. 次のURLを使用して、Oracle WebLogic Server管理コンソールにログインします。

http://ADMINVHN:7001/console

2. 「ドメイン構造」の左ペインで「デプロイメント」をクリックします。

3. 右ペインの「デプロイメントのサマリー」でJmsAdapterをクリックします。

4. 「構成」タブをクリックします。

5. 「アウトバウンド接続プール」タブをクリックしてoracle.tip.adapter.jms.IJmsConnectionFactoryを開き、構成済の接続ファクトリを表示します。

6. 使用中の特定のインスタンス(例: eis/wls/Queue)をクリックします。接続ファクトリの「アウトバウンド接続のプロパティ」が開きます。

7. 「ロックして編集」をクリックします。

8. FactoryPropertiesフィールドで(「プロパティ」値の該当するセルをクリックして)、次を入力します。セミコロンで区切ってすべてを1行に入力してください。

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;
java.naming.provider.url=t3://SOAHOST1:8001,SOAHOST2:8001;
java.naming.security.principal=weblogic;
java.naming.security.credentials=mypassword

9. これらのプロパティを更新した後、「保存」をクリックします。「デプロイメント・プランの保存」ページが表示されます。

10. デプロイメント・プランの共有記憶域場所を入力します。そのディレクトリ構造は次のとおりです。

DEPLOY_PLAN_HOME/soaedg_domain/JMSAdapterPlan.xml

11. 「保存してアクティブ化」をクリックします。

コンソールでデプロイメントを更新します。

1. 「デプロイメント」をクリックします。

2. 「ロックして編集」をクリックします。

3. JMSアダプタを選択します。

4. 「更新」をクリックします。

5. 「このアプリケーションを新しいデプロイメント・プランの変更とあわせた場所に更新します(このオプションには、デプロイメント・プランを指定する必要があります)。」を選択し、共有記憶域の場所に保存されたデプロイメント・プランを選択します。クラスタ内のすべてのサーバーは、このプランにアクセスできる必要があります。

6. 「終了」をクリックします。

7. 変更をアクティブ化します。

13.12.1.3 Oracle Databaseアダプタの高可用性の有効化

Oracle Databaseアダプタを利用しながら高可用性を確保するために、通常は、物理削除より高速な論理削除ポーリング方式が使用されます。しかし、複数のノードが同じデータをポーリングするクラスタ化環境では、1つのレコードが複数回処理されることがあります。この問題を回避するために、Oracle Databaseアダプタでは、「ロックのスキップ」と呼ばれるOracle Database機能を使用する分散ポーリング技術を使用します。

以前に論理削除ポーリング方式のアプローチを使用していた場合は、MarkReservedValueを(db.jcaで)削除するか、または(ウィザードの「論理削除」ページで)消去するだけです。それによってロックが自動的にスキップされるようになります。

予約された値に対してロックのスキップを使用することには、次のような利点があります。

- ロックをスキップすると、クラスタにおいて、また負荷がかかっている状態で、スケーリングが向上します。

- (更新/予約の次にコミットを行ってから新しいトランザクションで選択するのとは反対に)すべての作業が1つのトランザクションで行われるため、高可用性環境でリカバリ不能な状況に直面するリスクが最小に抑えられます。

- 一意のMarkReservedValueを指定する必要がありません。以前は、そのようにするためには、R${weblogic.Name-2}-${IP-2}-${instance}のように、複雑な変数を構成することが必要でした。

論理削除ポーリングを使用していて、MarkReservedValueを設定している場合は、ロックのスキップは使用されません。

詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のスケーラビリティとポーリング戦略に関する項を参照してください。

13.12.2 SOAサーバーとハードウェア・ロード・バランサ間のSSL通信の有効化

Oracle SOA Suiteを含めてドメインを拡張した後、管理サーバーと管理対象サーバーがハードウェア・ロード・バランサのフロントエンドのSSL URLにアクセスできることを確認する必要もあります。

これにより、SOAコンポジット・アプリケーションとWebサービスが、フロントエンドのセキュアURLとのコールバックやその他の通信を起動できるようになります。

詳細は、「中間層とハードウェア・ロード・バランサ間のSSL通信の有効化」を参照してください。

13.12.3 SOAクラスタ内の同期/非同期相互作用に関する考慮事項

SOAクラスタでは、次のシナリオはサポートされていません。

- mid-process receiveを持つ同期BPELプロセス

- 非同期サービスをコールする同期BPELプロセス。

- 同期プロセスからのコールバック。

13.13 Oracle SOA Suiteに対する自動サービス移行およびJDBC永続ストアの有効化

Oracle SOA Suiteが高可用性を実現するように構成するには、自動サービス移行でOracle SOA Suite管理対象サーバーを構成します。

自動サービス移行の有効化の詳細は、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。

可用性を高めるために、データベース内にトランザクション・ログ・ストアとJMSストアを構成することもできます。詳細は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用」を参照してください。

14 トポロジへのOracle Service Busの追加

次の各項では、エンタープライズ・デプロイメント・トポロジにOracle Service Bus (OSB)を追加する手順について説明します。

- トポロジにOracle Service Busを追加する際に使用する変数
この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

- Oracle Serviceの独自のドメインでの構成について
Oracle Service Busをエンタープライズ・トポロジに追加する際、既存のSOAドメインに追加することも、Oracle SOA Suiteドメインとは別にOracle Service Bus用の新たなドメインを作成することもできます。

- トポロジへのOSBの追加の概要
この項では、Oracle Service Busをドメインに追加するために実行する必要のある手順の概要を示します。

- Oracle Service Busを追加するためのドメインの拡張の前提条件
現在のドメインを拡張する前に、既存のデプロイメントが次の前提条件を満たしていることを確認します。

- Oracle Service Busソフトウェアのインストール
次の各項で、エンタープライズ・デプロイメントでOracle Service Busをインストールする方法について説明します。

- Oracle Service Busを追加するためのSOAまたはInfrastructureドメインの拡張
この項では、Oracle Service Busを含めることで既存のエンタープライズ・デプロイメントSOAドメインを拡張する手順について説明します。

- トランザクション・リカバリ用のデフォルト永続ストアの構成
各管理対象サーバーでは、サーバーが調整およびコミットする、完了していない可能性のあるトランザクションに関する情報を格納するトランザクション・ログを使用します。Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、管理対象サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

- ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播
OSBインスタンスを含めることでドメインを拡張し、SOAHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリおよびマシンに伝播する必要があります。

- 拡張したドメイン用のWeb層の構成
次の項では、Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをルーティングする方法について説明します。

- Oracle Service Busの構成後タスク
ドメインにOracle Service Busをインストールして構成した後、次のような構成後タスクを検討します。

- Oracle Service Busに対する自動サービス移行およびJDBC永続ストアの有効化
Oracle Service Busが高可用性を実現するように構成するには、フェイルオーバーおよびゼロ・データ損失を実現する自動サービス移行でOracle Service Bus管理対象サーバーを構成します。

親トピック: エンタープライズ・デプロイメントの構成

14.1 トポロジにOracle Service Busを追加する際に使用する変数

この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

いくつかのディレクトリ変数の値については、「このガイドで使用するファイル・システムとディレクトリ変数」に定義されています。

- ORACLE_HOME

- ASERVER_HOME

- MSERVER_HOME

- JAVA_HOME

- OHS_DOMAIN_HOME

さらに、「エンタープライズ・トポロジによって必要とされる物理および仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスを参照することになります。

- ADMINVHN

この項のアクションは、次のホスト・コンピュータで実行します。

- SOAHOST1

- SOAHOST2

- WEBHOST1

- WEBHOST2

14.2 Oracle Serviceの独自のドメインでの構成について

Oracle Service Busをエンタープライズ・トポロジに追加する際、既存のSOAドメインに追加することも、Oracle SOA Suiteドメインとは別にOracle Service Bus用の新たなドメインを作成することもできます。

詳細は、「Oracle Service Busのトポロジ・オプションの理解」を参照してください。

Oracle Service Busを別個のドメイン内に構成すると決定した場合、トポロジにOracle Serviceを追加する手順を使用する際に、次の点に留意してください。

- SOA管理対象サーバーまたはSOAクラスタへの参照はすべて無視してください。ドメインのこれらの要素が存在するのは、Oracle SOA Suiteを含めることですでに拡張されたドメインを拡張する場合のみです。

- リポジトリ作成ユーティリティ(RCU)を実行して、Oracle Service BusドメインのSOAINFRAスキーマを作成する必要があります。このスキーマは、Oracle Service Busで必要とされます。Oracle Service Busドメインには、一意のSOAINFRAスキーマとスキーマ接頭辞を使用する必要があります。

14.3 トポロジへのOSBの追加の概要

この項では、Oracle Service Busをドメインに追加するために実行する必要のある手順の概要を示します。

表14-1に、Oracle Service Busのために既存のSOAドメインまたは既存のInfrastructureドメインを拡張する手順の概要を示します。これらの手順では、初期Infrastructureドメインの作成に必要な手順をすでに実行し、Oracle SOA Suiteを追加するためにドメインを拡張したことを前提としています。

表14-1 Oracle Service Busを追加するためのSOAドメインの拡張手順

手順

説明

詳細情報

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

ターゲット・システムへのOSBソフトウェアのインストール

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

オプションで、サポートされているデータベースにSOAINFRAスキーマをインストールします。

OSBでは、wlsbjmsrpDataSourceデータ・ソースにSOAINFRAスキーマが必要です。OSBを独自のドメインで実行する場合は、サポートされているデータベースでOSBに別個のSOAINFRAスキーマがインストールされていることを確認する必要があります。

OSBドメインで使用されるSOAINFRAスキーマには一意のスキーマを使用してください。

Oracle SOA Suiteデータベース・スキーマの作成

オプションで、新しいInfrastructureドメインを作成します。

OSBを独自のドメインで実行する場合は、まずInfrastuctureドメインを作成して、OSBを含めることでこのドメインを拡張できるようにする必要があります。

エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成

ドメイン拡張のための構成ウィザードの実行

Oracle Service Busコンポーネントを追加するためにSOAまたはInfrastructureドメインを拡張します

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

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

クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

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

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

Oracle Service Busでは、WebLogic Serverの起動スクリプトに多少の更新が必要です。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。

ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

Oracle Service Busサーバーの起動

Oracle Service Busサーバーは既存のドメインを拡張します。そのため、管理サーバーおよびそれぞれのノード・マネージャはSOAHOST1およびSOAHOST2で稼働しています。

WLS_OSB1管理対象サーバーの起動と検証

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

管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認し、URLにアクセスしてサーバーのステータスを確認します。

WLS_OSB2管理対象サーバーの起動と検証

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

Oracle Service BusコンソールおよびOracle Service BusサービスにOracle HTTP Serverからルーティングできるようにするため、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。

Oracle Service Bus用のOracle HTTP Serverの構成

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

サーバーのステータスが「実行中」であることを確認します。

ロード・バランサを使用したOracle Service Bus URLの検証

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

OracleファイルとFTPアダプタのアウトバウンド操作に対する高可用性を、データベースのmutexロック操作を使用して実現します。

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

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

この後の手順でエラーが発生した場合の即座のリストアを目的として、ドメイン構成をバックアップします。

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

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

現在のドメインを拡張する前に、既存のデプロイメントが次の前提条件を満たしていることを確認します。

- インストールのバックアップ - 既存のFusion Middlewareホームとドメインをバックアップしていない場合は、今すぐバックアップすることをお薦めします。
既存のFusion Middlewareホームとドメインをバックアップするには、「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。

- 共有記憶域のOracleホームにInfrastructureおよびSOAソフトウェア・バイナリがインストールされ、SOAHOST1とSOAHOST2から使用できることを確認します。

- Oracle Service BusがSOAと同じドメイン内に構成されている場合は、適切なSOAINFRAスキーマ(wlsbjmsrpDataSourceによって使用されるもの)がすでに使用可能になっていること。OSBが独自のドメイン内に構成されている場合、RCUを実行し、SOAドメインで使用されているSOAINFRAスキーマとは異なるスキーマ接頭辞を使用して、サポートされているデータベースにSOAINFRAスキーマをインストールする必要があります。

- 前の章の説明どおりに、ノード・マネージャ、管理サーバー、(任意でSOAサーバー)、およびWSMサーバーをすでに構成していること。必要に応じて、サーバー移行、トランザクション・ログ、一貫性など、SOAシステムのその他のすべての構成手順が完了していること。

- 各ホスト・コンピュータのシステム・クロックが同期していることを確認します(まだ、確認していない場合)。これは、各クラスタ内のホストで可能なかぎり同時にdateコマンドを実行することで行えます。
また、そのために使用できるサードパーティおよびオープンソースのユーティリティもあります。

14.5 Oracle Service Busソフトウェアのインストール

次の各項で、エンタープライズ・デプロイメントでOracle Service Busをインストールする方法について説明します。

- Oracle Service Busインストーラの起動

- OSBインストール画面のナビゲート

- 他のホスト・コンピュータへのソフトウェアのインストール

- OSBインストールの検証

14.5.1 Oracle Service Busインストーラの起動

インストール・プログラムを起動するには、次の手順を実行します。

1. ターゲット・システムSOAHOST1にログインします。

2. インストール・プログラムをダウンロードしたディレクトリに移動します。

3. 次のように、Java実行可能ファイルへのパス を入力します。

export JAVA_HOME=JAVA_HOME
export PATH=$JAVA_HOME/bin:$PATH

この例では、「このガイドで使用するファイル・システムとディレクトリ変数」に記載され、エンタープライズ・デプロイメント・ワークブックに入力されている変数の値で、JAVA_HOMEを置き換えます。

4. 次のコマンドを入力して、インストール・プログラムを起動します。

java -d64 -jar fmw_12.2.1.1.0_osb.jar

インストール・プログラムが表示されると、インストールを開始する準備ができています。

14.5.2 OSBインストール画面のナビゲート

表14-2は、インストール・プログラムの各画面の説明です。

表14-2 SOAのインストール画面

画面

説明

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面では、使用可能なパッチを探してMy Oracle Supportを自動的に検索するか、組織にすでにダウンロードしたパッチを探してローカル・ディレクトリを自動的に検索します。

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

既存のSOAドメインを拡張する場合は、OSBソフトウェアをSOAソフトウェアがすでにインストールされている既存のOracleホームにインストールします。

OSBを別のドメイン内に構成する場合は、OSBソフトウェアをInfrastructureのOracleホームにインストールします。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

このトポロジの場合は、「Service Bus」を選択します。

前提条件チェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告メッセージまたはエラー・メッセージが表示された場合は、第1.4項に記載されているドキュメントのいずれかを参照してください。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

インストール完了

インストールが完了すると、この画面が表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

14.5.3 他のホスト・コンピュータへのソフトウェアのインストール

SOAHOST2用に別の共有記憶域ボリュームまたはパーティションを構成している場合は、SOAHOST2にもソフトウェアをインストールする必要があります。詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

Oracleホーム(ソフトウェア・バイナリが含まれている)をインストールする場所は、ホストによって異なることに注意してください。ご使用のOracleホーム・ディレクトリの正しい場所を特定するには、「このガイドで使用するファイル・システムとディレクトリ変数」のガイドラインを参照してください。

14.5.4 OSBインストールの検証

インストールの完了後、次のタスクを正常に実行することでインストールを検証できます。

- インストール・ログ・ファイルの確認

- ディレクトリ構造のチェック

- Oracleホームの内容の表示

14.5.4.1 インストール・ログ・ファイルの確認

インストール・ログ・ファイルの内容を確認し、何も問題が発生していないことを確認します。ログ・ファイルの説明とその場所の詳細は、Oracle Universal Installerを使用したソフトウェアのインストールのインストール・ログ・ファイルの理解に関する項を参照してください。

14.5.4.2 ディレクトリ構造のチェック

インストールの内容は、インストール中に選択したオプションによって異なります。

Oracle Service Busを追加すると、次のディレクトリおよびサブディレクトリが追加されます。

ORACLE_HOME/osb/

bin
common
config
doc
financial
L10N
lib
osb
plugins
tools

インストール後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解の「Oracle Fusion Middlewareの主要ディレクトリとは」を参照してください。

14.5.4.3 Oracleホームの内容の表示

Oracleホームの内容を、viewInventoryスクリプトを使用して表示することもできます。詳細は、Oracle Universal Installerを使用したソフトウェアのインストールのOracleホームの内容の表示に関する項を参照してください。

14.6 Oracle Service Busを追加するためのSOAまたはInfrastructureドメインの拡張

この項では、Oracle Service Busを含めることで既存のエンタープライズ・デプロイメントSOAドメインを拡張する手順について説明します。

ドメインを拡張するには、次の各項で説明するタスクを実行する必要があります。

- 構成ウィザードの起動

- Oracle Service Busの構成ウィザード画面のナビゲート

14.6.1 構成ウィザードの起動

注意:

ドメインで起動スクリプトに直接カスタマイズを追加した場合、それらのカスタマイズは構成ウィザードによって上書きされます。ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverrides.shという名前のファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のjavaコマンド行オプションの指定、追加の環境変数の指定などを行うように構成できます。このファイルに追加したカスタマイズは、ドメインのアップグレード操作時に保持され、packコマンドとunpackコマンドの使用時にリモート・サーバーに継承されます。

ドメインの構成を開始するには:

1. ドメインの構成中に、構成のロック、保存、アクティブ化が行われないように、管理サーバーを停止します。

詳細は、「SOAHOST1での構成ウィザードの起動」でノード・マネージャを使用して管理サーバーを停止する手順を参照してください。

2. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

ORACLE_HOME/oracle_common/common/bin
./config.sh

14.6.2 Oracle Service Busの構成ウィザード画面のナビゲート

この手順では、「Oracle SOA Suiteを含めるドメインの拡張」で作成したドメインを拡張して、Oracle Service Busソフトウェア・コンポーネントと管理対象サーバーを追加します。

Oracle Service Busを追加して管理サーバーとWSM-PMクラスタのみを含むドメインを拡張する場合の手順は、この項で説明する手順とほぼ同じになりますが、画面に表示される一部のオプション、ライブラリ、コンポーネントは異なる場合があります。

ドメインを作成して構成するためのタスクは次のとおりです。

- タスク1「ドメイン・タイプとドメイン・ホームの場所の選択」

- タスク2「構成テンプレートの選択」

- タスク3「データ・ソース構成タイプの指定」

- タスク4「JDBCコンポーネント・スキーマの情報の指定」

- タスク5「GridLink Oracle RACデータベース接続の詳細情報の指定」

- タスク6「JDBC接続のテスト」

- タスク7「拡張構成の選択」

- タスク8「管理対象サーバーの構成」

- タスク9「クラスタの構成」

- タスク10「クラスタへの管理対象サーバーの関連付け」

- タスク11「Coherenceクラスタの構成」

- タスク12「既存のマシンの検証」

- タスク13「マシンへのサーバーの割当て」

- タスク14「JMSファイル・ストアの構成」

- タスク15「構成仕様の確認とドメインの構成」

- タスク16「管理サーバーの起動」

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「構成タイプ」に関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

Oracle Service Bus - 12.2.1.1.0 [osb]

このテンプレートを選択すると、次の項目が依存関係として自動的に選択されます。

- WebLogic Advanced Web Services for JAX-RPC Extension - 12.2.1.1.0 [oracle_common]

- ODSI XQuery 2004 Components - 12.1.3.0 [oracle_common]

注意:

ODSI用の12.2.1.1.0テンプレートはありません。12.1.3テンプレートは12.2.1構成に役立ちます。

また、初期ドメインを作成するために使用したため、次の追加のテンプレートもすでに選択されているはずです。

- Oracle Enterprise Manager - 12.2.1.1.0 [em]

- Oracle WSM Policy Manager - 12.2.1.1.0 [oracle_common]

- Oracle JRF - 12.2.1.1.0 [oracle_common]

- WebLogic Coherenceクラスタの拡張 - 12.2.1.1.0 [wlserver]

タスク3   データ・ソース構成タイプの指定

Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。すべてのフィールドにおける資格証明が、Oracle Fusion Middleware Infrastructureの構成中に指定したものと同じであることを確認します。

データベース接続情報の確認が完了した後で、「RCU構成の取得」をクリックします。「接続結果ログ」の次の出力は、操作が成功したことを示しています。

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK
Successfully Done.

ヒント:

RCUデータのオプションの詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解に関する項を参照してください。

この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のデータ・ソース・デフォルトに関する項を参照してください。

タスク4   JDBCコンポーネント・スキーマ情報の指定

OSB JMSレポート・プロバイダ・コンポーネント・スキーマを選択し、「GridLinkへ変換」オプションをクリックして「次へ」をクリックします。

「次へ」をクリックします。

タスク5   GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

要素

説明と推奨値

SCAN、ホスト名とポート

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドに、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

データベースがFANイベントを受信して処理できるように、「FANの有効化」チェック・ボックスが選択されていることを確認します。

タスク6   JDBC接続のテスト

「JDBCデータ・ソースのテスト」画面で、すべての接続が正常であることを確認します。

接続のテストは自動的に行われます。「ステータス」列に結果が表示されます。正常でない接続がある場合は、「前へ」をクリックして前の画面に戻り、入力を訂正します。

すべての接続に成功したら「次へ」をクリックします。

タスク7   拡張構成の選択

拡張構成の選択画面で、次を選択します。

- トポロジ
サーバー・テンプレート、管理対象サーバー、クラスタ、仮想ターゲットおよびCoherenceの設定の追加、削除または変更。

- JMSファイル・ストア

「次へ」をクリックします。

タスク8   管理対象サーバーの構成

「管理対象サーバー」画面で、Oracle Service Busに必要な管理対象サーバーを追加します。

- 自動的に作成されたサーバーを選択し、「名前の変更」をクリックして、名前をWLS_OSB1に変更します。

- 「追加」をクリックし他の新規サーバーを追加して、サーバー名としてWLS_OSB2と入力します。

- WLS_OSB1およびWLS_OSB2サーバーに、表14-3内の属性を指定します。

- OSBサーバーのサーバー・グループとして「OSB-MGD-SVRS-ONLY」を選択します。デフォルトで選択されているOSB-MGD-SVRS-COMBINEDの選択を解除します。

最後に、追加されたサーバーの構成が表14-3に一致している必要があります。

「次へ」をクリックします。

表14-3 構成ウィザードでのOracle Service Bus管理対象サーバーの構成

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

サーバー・グループ

WLS_SOA1

SOAHOST1

8001

n/a

いいえ

SOA-MGD-SVRS-ONLY

WLS_SOA2

SOAHOST2

8001

n/a

いいえ

SOA-MGD-SVRS-ONLY

WLS_WSM1

SOAHOST1

7010

n/a

いいえ

JRF-MAN-SVR

WSMPM-MAN-SVR

WSM-CACHE-SVR

WLS_WSM2

SOAHOST2

7010

n/a

いいえ

JRF-MAN-SVR

WSMPM-MAN-SVR

WSM-CACHE-SVR

WLS_OSB1

SOAHOST1

8011

n/a

いいえ

OSB-MGD-SVRS-ONLY

WLS_OSB2

SOAHOST2

8011

n/a

いいえ

OSB-MGD-SVRS-ONLY

WLS_SOA管理対象サーバーは、Oracle Service Busを含めて既存のOracle SOA Suiteドメインを拡張する場合に表示されます。

タスク9   クラスタの構成

このタスクでは、Oracle SOA Suiteソフトウェアのターゲットとすることができる管理対象サーバーのクラスタを作成します。

クラスタの「フロントエンド・ホスト」プロパティも設定します。これにより、WebLogic Serverは必要に応じてWebサービス・コールバックやその他のリダイレクトを、各リクエストのHOSTヘッダーにあるアドレスではなく、ロード・バランサ上のosb.example.comにリダイレクトするようになります。

osb.example.com仮想サーバー・アドレスの詳細は、「ハードウェア・ロード・バランサでの仮想ホストの構成」を参照してください。

「クラスタ」画面を使用して、新しいクラスタを作成します。

1. 「追加」ボタンをクリックします。

2. 「クラスタ名」フィールドで、OSB_Clusterを指定します。

3. 「フロントエンド・ホスト」フィールドでosb.example.comを指定します。

4. 「フロントエンドHTTPポート」に80を指定し、「フロントエンドHTTPSポート」に443を指定します。

注意:

デフォルトでは、クラスタ内のサーバー・インスタンスは、ユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』のユニキャストまたはマルチキャストを選択する際の考慮事項に関する項を参照してください。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「クラスタ」に関する項を参照してください。

タスク10   クラスタへの管理対象サーバーの割当て

「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。

WLS_SOA管理対象サーバーは、Oracle Service Busを含めて既存のOracle SOA Suiteドメインを拡張する場合に表示されます。

- SOA_Cluster - SOAドメインを拡張する場合

- WLS_SOA1

- WLS_SOA2

- WSM-PM_Cluster:

- WLS_WSM1

- WLS_WSM2

- OSB_Cluster:

- WLS_OSB1

- WLS_OSB2

「次へ」をクリックします。

タスク11   Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期Infrastructureドメインの作成中に定義されているため、9991のままにします。

タスク12 既存のマシンの検証

次のエントリが表示されることを確認します。

名前

ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINHOST

ADMINVHN

その他のすべてのフィールドはデフォルト値のままにします。

「次へ」をクリックします。

タスク13   マシンへのサーバーの割当て

「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- ADMINHOST:

- AdminServer

- SOAHOST1

- WLS_SOA1 (SOAドメインを拡張する場合)

- WLS_WSM1

- WLS_OSB1

- SOAHOST2:

- WLS_SOA2 (SOAドメインを拡張する場合)

- WLS_WSM2

- WLS_OSB2

「次へ」をクリックします。

タスク14 JMSファイル・ストアの構成

構成セッションで作成したJMSファイル・ストアを構成します(Wsee FileStore、UMS JMS FileStore、およびFileStore)。

「JMSファイル・ストア」画面で、各OSB永続ストアに次のディレクトリを割り当てます。

ORACLE_RUNTIME/domain_name/OSB_Cluster/jms

この例では、ORACLE_RUNTIMEを、ご使用の環境の変数値に置き換えます。OSB_Clusterを、OSBクラスタに割り当てた名前に置き換えます。

表示されるJMS構成警告は無視してください。

タスク15   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

「更新」をクリックします。

「ドメインの拡張」画面で、「完了」をクリックします。

タスク16   管理サーバーの起動

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

14.7 トランザクション・リカバリのためのデフォルトの永続ストアの構成

各管理対象サーバーでは、サーバーが調整およびコミットする、完了していない可能性のあるトランザクションに関する情報を格納するトランザクション・ログを使用します。Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、管理対象サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

注意:

トランザクション・リカバリ・サービスの移行機能を有効にするには、クラスタにある他のサーバーで使用可能な永続記憶域ソリューションの場所を指定します。クラスタ内のすべての管理対象サーバーがこのディレクトリにアクセスできる必要があります。また、このディレクトリは、サーバーを再起動する前にも存在している必要があります。

お薦めする場所は、デュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)です。記憶域エラーが発生した場合に確実に保護するには、記憶域レベルで適切な複製およびバックアップ・メカニズムを設定しておくことが重要です。

この情報は、ファイルベースのトランザクション・ログに適用されます。トランザクション・ログに対して、データベース・ベースの永続ストアを構成することもできます。詳細は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用」を参照してください。

デフォルトの永続ストアの場所を設定する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

ADMINVHN:7001/console

2. 「チェンジ・センター」セクションで、「ロックして編集」をクリックします。

3. クラスタ内の管理対象サーバーごとに、次を実行します。

a. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページが表示されます。

b. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

c. 「構成」タブで、「サービス」タブをクリックします。

d. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
エンタープライズ・デプロイメントの場合は、ORACLE_RUNTIMEディレクトリの場所を使用します。このサブディレクトリは、クラスタのトランザクション・ログの中央の共有場所の役割を果します。詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

例:

ORACLE_RUNTIME/domain_name/cluster_name/tlogs

この例では、ORACLE_RUNTIMEを、ご使用の環境の変数値に置き換えます。domain_nameを、ドメインに割り当てた名前に置き換えます。cluster_nameを、先ほど作成したクラスタ名で置き換えます。

e. 「保存」をクリックします。

4. 「保存」をクリックして、「変更のアクティブ化」をクリックします。

5. クラスタ内の他のサーバーで手順1から4を完了します。

注意:

構成手順の後半で、トランザクション・ログの場所と作成について検証します。

14.8 ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

OSBインスタンスを含めることでドメインを拡張し、SOAHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリおよびマシンに伝播する必要があります。

更新済ドメインをWEBHOST1およびWEBHOST2マシンに伝播する必要はありません。それらのホスト・コンピュータ上のOracle HTTP Serverインスタンスに対する変更はないためです。

詳細は、次の項を参照してください。

- 変更を他のドメイン・ディレクトリおよびマシンに伝播するために必要なタスクのサマリー

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

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

- トランザクション・ログの場所と作成の検証

- OSBシングルトン・サービスのターゲット指定が適切であるかどうかの確認

14.8.1 変更を他のドメイン・ディレクトリおよびマシンに伝播するために必要なタスクのサマリー

表14-4は、変更をすべてのドメイン・ディレクトリとマシンに伝播するために必要な手順をまとめたものです。

表14-4 ドメイン変更をドメイン・ディレクトリおよびマシンに伝播するために必要なタスクのサマリー

タスク

説明

詳細情報

SOAHOST1での拡張済ドメインの圧縮

Packコマンドを使用して、新しいOSBサーバー構成が含まれる新しいテンプレートJARファイルを作成します。

ドメインを圧縮する場合は、soadomaintemplateExtOSB.jarというテンプレートJARファイルを作成します。

SOAHOST1での拡張済ドメインの圧縮

SOAHOST1の管理対象サーバー・ディレクトリでのドメインの解凍

SOAHOST1のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

SOAHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍

SOAHOST2でのドメインの解凍

SOAHOST2のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

SOAHOST2でのドメインの解凍

14.8.2 WLS_OSB1管理対象サーバーの起動と検証

ドメインの拡張、管理サーバーの再起動、および他のホストへのドメインの伝播を完了したら、次の手順を使用して、WLS_OSB1サーバーを起動し、そのサーバーが正常に構成されていることを検証します。

- WLS_OSB1管理対象サーバーの起動

- エンタープライズ・デプロイメント管理グループへのMiddlewareAdministratorsロールの追加

- SOAインフラストラクチャへのログインによる管理対象サーバーの検証

14.8.2.1 WLS_OSB1管理対象サーバーの起動

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

http://ADMINVHN:7001/em

2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

3. 「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。

4. WLS_OSB1管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。

注意:

OSBサーバーは、ポリシー・アクセス・サービスに依存して機能します。これは、OSBサーバーが起動する前に、ドメイン内のWSM-PM管理対象サーバーが稼働していてアクセス可能になっている必要があることを意味します。

5. 起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_OSB1管理対象サーバーが稼働中であることを確認します。

14.8.2.2 エンタープライズ・デプロイメント管理グループへのMiddlewareAdministratorsロールの追加

WLS_OSB1管理対象サーバーのOracle Service Bus構成を検証する前に、Oracle Service BusのMiddlewareAdministrators管理ロールをエンタープライズ・デプロイメント管理グループ(SOA Administrators)に追加して、外部LDAPディレクトリにIntegrationAdministratorsグループを追加します。

このタスクを実行するには、「Oracle SOA Suite製品の管理のためのロールの構成」を参照してください。

14.8.2.3 SOAインフラストラクチャへのログインによる管理対象サーバーの検証

MiddlewareAdministratorロールをSOA Administratorsグループに追加した後、次のようにWLS_OSB1管理対象サーバーのOracle Service Busソフトウェアの構成を検証できます。

1. Webブラウザを使用して次のURLに移動します。

http://SOAHOST1:8011/sbinspection.wsil

SOAHOST1を、Enterprise Deployment Workbookに入力されているこの変数の値に置き換えます。詳細は、「エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス」を参照してください。

2. エンタープライズ・デプロイメント管理ユーザー(SOA Administrators)を使用してログインします。

デフォルトのインストールでは、これにより、Webサービス・コールに対して次のHTTPレスポンスが返されます。

<ins:inspection xmlns:ins="http://schemas.xmlsoap.org/ws/2001/10/inspection/"/>

14.8.3 WLS_OSB2管理対象サーバーの起動と検証

WLS_OSB2でも、前の項と同様の手順を実行します。

1. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

2. 「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。

3. WLS_OSB2管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。

4. 起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_OSB2管理対象サーバーが稼働中であることを確認します。WLS_OSB2用の同等のURLにアクセスします。

http://SOAHOST2:8011/sbinspection.wsil

5. 次のURLにアクセスし、管理サーバーへのOracle Service Busコンソールのデプロイメントが適切であることを確認します。

http://ADMINVHN:7001/servicebus/

14.8.4 トランザクション・ログの場所と作成の検証

WLS_OSB1およびWLS_OSB2管理対象サーバーが稼働したら、「トランザクション・リカバリ用デフォルト永続ストアの構成」で実行した手順に基づいて、トランザクション・ログ・ディレクトリとトランザクション・ログが想定どおりに作成されていることを確認します。

ORACLE_RUNTIME/domain_name/OSB_Cluster/tlogs

- _WLS_WLS_OSB1000000.DAT

- _WLS_WLS_OSB2000000.DAT

14.8.5 OSBシングルトン・サービスのターゲット指定が適切であるかどうかの確認

Oracle Service Busは、OSB_Cluster内のいずれか1つのWLSサーバー上でのみ稼働するシングルトン・サービスをいくつか使用します。

適切なターゲット指定が存在し、WLS_OSB1のみが次のアプリケーションのターゲットとなることを確認します。

- Service Bus Domain Singleton Marker Application

そのためには、次の手順に従ってください。

1. ブラウザで、次のURLにアクセスします。

http://ADMINVHN:7001/console

2. 管理者としてログインします。

3. 左側にある「ドメイン構造」ツリーで、「デプロイメント」をクリックします。

4. Service Bus Domain Singleton Marker Applicationを探します。表の「ターゲット」列にターゲットとしてWLS_OSB1のみが表示されていることを確認します。

14.9 拡張したドメイン用のWeb層の構成

次の項では、Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをルーティングする方法について説明します。

- 拡張したドメイン用のOracle Traffic Directorの構成

- Oracle Service Bus用のOracle HTTP Serverの構成
Oracle Service Busクラスタにリクエストを正しくルーティングするようにWeb層のOracle HTTP Serverインスタンスを構成するには、次の手順を使用して、soa.example.com仮想サーバーのパラメータを作成して定義するOracle HTTP Server構成ファイルを追加作成します。

- WebLogicプロキシ・プラグインの構成
OSBクラスタの「WebLogicプラグインの有効化」パラメータを設定します。

- ロード・バランサを使用したOracle Service Bus URLの検証
Oracle Service Bus URLを検証して、ハードウェア・ロード・バランサからHTTP Serverインスタンスを経由してOracle Service Busコンポーネントに至るルーティングとフェイルオーバーが適切に機能することを確認します。

14.9.1 拡張したドメイン用のOracle Traffic Directorの構成

このドメインでOracle Traffic Directorを構成した場合、状況によっては、Oracle Traffic Director構成に別のオリジン・サーバー・プール、仮想サーバーまたはルートを追加する必要があります。各Oracle Fusion Middleware製品のOracle Traffic Directorの要件を理解するには、「オリジン・サーバーおよび仮想ホストのサマリー」を参照してください。

オリジン・サーバー・プール、仮想サーバーおよびルートを追加する手順は、「エンタープライズ・デプロイメント用のOracle Traffic Director仮想サーバーの定義」を参照してください。

14.9.2 Oracle Service Bus用のOracle HTTP Serverの構成

Oracle Service Busクラスタにリクエストを正しくルーティングするようにWeb層のOracle HTTP Serverインスタンスを構成するには、次の手順を使用して、soa.example.com仮想サーバーのパラメータを作成して定義するOracle HTTP Server構成ファイルを追加作成します。

この手順では、「管理およびOracle Web Services Manager用のOracle HTTP Serverの構成」で説明されているOracle HTTP Server構成タスクが実行済であることを想定しています。

注意:

HTTPプロキシ・サービスを構成する場合は、すべてのプロキシ・サービスのルーティングを容易にするためにプロキシ・サービスのコンテキスト・パスを共通名から始めることができます。例:

/osb/project-name/folder-name/proxy-service-name

パラメータを設定する手順は次のとおりです。

1. WEBHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(ohs1)の構成ディレクトリに変更します。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf

2. 新しい構成ファイル(osb_vh.confという名前のファイル)を作成し、次の<VirtualHost>ディレクティブをそのファイルに追加します。

<VirtualHost WEBHOST1:7777>
ServerName https://osb.example.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

3. <VirtualHost>タグ内に、次のディレクティブを追加します。

<Location /sbinspection.wsil>
WLSRequest ON
WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /sbresource>
WLSRequest ON
WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /osb>
WLSRequest ON
WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /alsb>
WLSRequest ON
WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

osb_vh.confファイルは、例14-1のように表示されます。

4. 次のエントリをadmin_vh.confファイルの<VirtualHost>タグ内に追加します。

<Location /sbconsole >
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /servicebus>
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /lwpfconsole >
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

admin_vh.confファイルは、例14-2のように表示されます。

5. WEBHOST2でosb_vh.confファイルおよびadmin_vh.confファイルを、2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。

OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf

6. osb_vh.confファイルを編集して、<VirtualHost>ディレクティブ内のWEBHOST1への参照をWEBHOST2への参照に変更します。

7. WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

例14-1 osb_vh.confファイル

<VirtualHost WEBHOST1:7777>
ServerName https://osb.example.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

<Location /sbinspection.wsil >
WLSRequest ON
WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /sbresource >
WLSRequest ON
WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /osb >
WLSRequest ON
WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /alsb >
WLSRequest ON
WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

例14-2 admin_vh.confファイル

# The admin URLs should only be accessible via the admin virtual host

<VirtualHost WEBHOST1:7777>
ServerName admin.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# Admin Server and EM
<Location /console>
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /consolehelp>
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /em>
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /sbconsole >
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /servicebus>
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
</VirtualHost>

<Location /lwpfconsole >
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
</VirtualHost>

14.9.3 WebLogicプロキシ・プラグインの構成

OSBクラスタの「WebLogicプラグインの有効化」パラメータを設定します。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ペインで、「環境」ノードを開きます。

3. 「クラスタ」をクリックします。

4. Oracle HTTP Serverからのリクエストのプロキシ先とするOSB_Clusterクラスタを選択します。

「構成: 一般」タブが表示されます。

5. 「詳細」セクションまでスクロール・ダウンして、開きます。

6. 「ロックして編集」をクリックします。

7. 「WebLogicプラグインの有効化」を「はい」に設定します。

8. 変更を保存してアクティブ化をクリックします。OSBサーバーを再起動して、変更を有効にします。

14.9.4 ロード・バランサを使用したOracle Service Bus URLの検証

Oracle Service Bus URLを検証して、ハードウェア・ロード・バランサからHTTP Serverインスタンスを経由してOracle Service Busコンポーネントに至るルーティングとフェイルオーバーが適切に機能することを確認します。

URLを検証する手順は次のとおりです。

1. WLS_OSB1が稼動している状態で、Oracle WebLogic Server管理コンソールを使用してWLS_OSB2を停止します。

2. 次のURLにアクセスし、HTTPレスポンスが「WLS_OSB2管理対象サーバーの起動と検証」のとおりであることを確認します。

https://osb.example.com/

3. Oracle WebLogic Server管理コンソールでWLS_OSB2を起動します。

4. Oracle WebLogic Server管理コンソールでWLS_OSB1を停止します。

5. 同じURLにアクセスし、HTTPレスポンスが「WLS_OSB2管理対象サーバーの起動と検証」のとおりであることを確認します。

注意:

OSB_ClusterにフロントエンドURLが設定されているため、URLへのリクエストはLBRへの再ルーティングになりますが、どのようなケースでも、Oracle HTTP Server内のマウント・ポイントおよびフェイルオーバーの検証には十分です。

6. ロード・バランサのアドレスを使用して、このURLを検証します。

http://osb.example.com:443/sbinspection.wsil

http://osb.example.com:80/servicebusも検証できます。

14.10 Oracle Service Busの構成後タスク

ドメインにOracle Service Busをインストールして構成した後、次のような構成後タスクを検討します。

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

- エンタープライズ・デプロイメント用の個別のOracle Service Busサービスの構成

- Oracle Service Busサーバーとハードウェア・ロード・バランサ間のSSL通信の有効化

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

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

Oracle SOA SuiteとOracle Service Busは、同じデータベース、ファイルおよびFTP JCAアダプタを使用します。

Oracle SOA Suiteを構成する前にOracle リポジトリ作成ユーティリティを使用するときに、これらのアダプタに必要なデータベース・スキーマを作成します。データベース・アダプタの構成は、WebLogic Serverのリソース・レベルでは必要ありません。

その他のアダプタに必要な構成は、「OracleファイルとFTPアダプタの高可用性化」に記載されています。

SOAドメインの拡張としてOracle Service Busを構成する場合は、アダプタに対する構成はすでに行われているため構成に加える必要はありません。

Oracle Service BusをOracle Fusion Middleware Infrastructureドメインの拡張としてデプロイする(Oracle SOA Suiteを含まない)場合は、次の操作を実行する必要があります。

- RCUを実行し、Oracle Service Busデータベースに必要なアダプタ・スキーマをシードします(RCUで「SOAインフラストラクチャ」スキーマを選択)。

- 「OracleファイルとFTPアダプタの高可用性化」の手順を実行します。

14.10.2 エンタープライズ・デプロイメント用の個別のOracle Service Busサービスの構成

IBM WebSphereのMQ接続リソースとMQトランスポートをOracle Service Bus内で使用するには、MQクライアント・ライブラリをクラスパスに追加する必要があります。

必要なMQライブラリをドメイン・ホーム・ディレクトリの次の場所にコピーするのも1つの方法です。

DOMAIN_HOME/lib

これは、カスタム・アサーションおよびJBoss統合サービスの場合にもあてはまります。

- JBoss初期コンテキスト・ファクトリ・クラスを使用している場合は、クラスおよび依存クラスをDOMAIN_HOME/libディレクトリに含めてください。

- 同様に、カスタム・アサーションの場合は、アサーションに必要なJARファイルを作成し、DOMAIN_HOME/libディレクトリにそのJARファイルを追加します。

さらに、エンタープライズ・デプロイメントでこれらのサービスを使用するには、必要なライブラリを管理サーバー・ドメイン・ホーム(ASERVER_HOME/lib)と管理対象サーバー・ドメイン・ホーム(MSERVER_HOME/lib)に追加する必要があります。

Oracle Service Busのサービスの構成およびデプロイの詳細は、『Oracle Service Busでのサービスの開発』を参照してください。

14.10.3 Oracle Service Busサーバーとハードウェア・ロード・バランサ間のSSL通信の有効化

Oracle Service Busを含めてドメインを拡張した後、管理サーバーと管理対象サーバーがハードウェア・ロード・バランサのフロントエンドのSSL URLにアクセスできることを確認する必要もあります。

これにより、Oracle Service BusのWebサービスとその他のサービスが、フロントエンドのセキュアURLとのコールバックやその他の通信を起動できるようになります。

詳細は、「中間層とハードウェア・ロード・バランサ間のSSL通信の有効化」を参照してください。

14.10.4 Oracle Service Bus構成のバックアップ

Oracleのベスト・プラクティスとしては、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。

バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

構成をバックアップする方法の詳細は、「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。

14.11 Oracle Service Busに対する自動サービス移行およびJDBC永続ストアの有効化

Oracle Service Busが高可用性を実現するように構成するには、フェイルオーバーおよびゼロ・データ損失を実現する自動サービス移行でOracle Service Bus管理対象サーバーを構成します。

サーバー移行の有効化の詳細は、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。

可用性を高めるために、データベース内にトランザクション・ログ・ストアとJMSストアを構成することもできます。詳細は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用」を参照してください。

15 Business Process Managementを含めるドメインの拡張

次の各項では、Business Process Managementを追加するためのドメイン拡張の手順を説明します。

- この章で使用される変数
この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

- Oracle BPMを追加するためのSOAドメイン拡張の前提条件
現在のドメインを拡張する前に、既存のデプロイメントが次の前提条件を満たしていることを確認します。

- エンタープライズ・デプロイメント用のOracle Business Process Managementのインストール
次の各項では、エンタープライズ・デプロイメント用のOracle SOA Foundation and Business Process Managementソフトウェアのインストール方法を説明します。

- SOAHOST1での構成ウィザードを使用したBPMを追加するためのSOAドメインの拡張
ORACLE_COMMON_HOMEディレクトリで構成ウィザードを実行して、管理サーバー、Oracle Web Services ManagerおよびSOAを含むドメインを拡張し、BPMのコンポーネントをサポートするようにします。

- ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播
Oracle BPM Suiteでは、WebLogic Serverの起動スクリプトに多少の更新が必要です。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。

- WebフォームのSOA BPMサーバーの更新

- Business Process ManagementによるWLS_SOA管理対象サーバーの再起動
構成変更および起動スクリプトを有効にするには、BPMが追加されたWLS_SOAnサーバーを再起動する必要があります。

- Oracle BPM Administratorsグループへのエンタープライズ・デプロイメント管理ユーザーの追加
管理対象サーバーのOracle Business Process Management構成を検証する前に、エンタープライズ・デプロイメント管理ユーザー(weblogic_soa)をLDAPディレクトリ内のBusiness Process Management Administratorsグループに追加します。

- 拡張したドメイン用のWeb層の構成
次の項では、Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをルーティングする方法について説明します。

- Business Process Managementサーバーとハードウェア・ロード・バランサ間のSSL通信の有効化
Business Process Managementを含めてドメインを拡張した後、管理サーバーと管理対象サーバーがハードウェア・ロード・バランサのフロントエンドのSSL URLにアクセスできることを確認する必要もあります。

- ハードウェア・ロード・バランサを使用したBusiness Process Managementへのアクセスの検証
SOA_Clusterのクラスタ・アドレスは前の章ですでに設定されているので、Business Process ManagementコンテキストURLをWebLogic ServerにルーティングするようにOracle HTTP Server構成ファイルを変更した後にのみBusiness Process Managementシステムを検証できます。

- Oracle BPM Cluster用のBPMJMSModuleの構成
BPMJMSModule JMSモジュールを構成するには、モジュール内の一部のデフォルト値をこの項に示すように変更する必要があります。

- Oracle BPM構成のバックアップ
Oracleのベスト・プラクティスとしては、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。

- Oracle Business Process Managementに対する自動サービス移行およびJDBC永続ストアの有効化
Oracle Business Process Managementが高可用性を実現するように構成するには、フェイルオーバーおよびゼロ・データ損失を実現する自動サービス移行で管理対象サーバーを構成します。

親トピック: エンタープライズ・デプロイメントの構成

15.1 この章で使用される変数

この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

いくつかのディレクトリ変数の値については、「このガイドで使用するファイル・システムとディレクトリ変数」に定義されています。

- ORACLE_HOME

- ASERVER_HOME

- MSERVER_HOME

- OHS_DOMAIN_HOME

- JAVA_HOME

さらに、「エンタープライズ・トポロジによって必要とされる物理および仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスを参照することになります。

- ADMINVHN

この章のアクションは、次のホスト・コンピュータで実行します。

- SOAHOST1

- SOAHOST2

- WEBHOST1

- WEBHOST2

15.2 Oracle BPMを追加するためのSOAドメイン拡張の前提条件

現在のドメインを拡張する前に、既存のデプロイメントが次の前提条件を満たしていることを確認します。

- インストールのバックアップ - 既存のFusion Middlewareホームとドメインをバックアップしていない場合は、今すぐバックアップすることをお薦めします。
既存のFusion Middlewareホームとドメインをバックアップするには、「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。

- 既存のWL_HOMEおよびSOA ORACLE_HOME (バイナリ)は、共有記憶域に関する章でインストールされており、SOAHOST1およびSOAHOST2にあります。

- ノード・マネージャ、管理サーバー、SOAサーバーおよびWSMサーバーが存在し、前の章の説明のように、SOAシステムを実行するように構成されていること。

- RCUを実行して、BPM用の追加のスキーマをロードする必要はありません。これらは、SOAリポジトリの一部であり、SOAに関する章でDBにロードされています。

15.3 エンタープライズ・デプロイメント用のOracle Business Process Managementのインストール

次の各項では、エンタープライズ・デプロイメント用のOracle SOA Foundation and Business Process Managementソフトウェアのインストール方法を説明します。

- インストール・プログラムの起動

- Oracle BPMのインストール画面のナビゲート

- インストールの確認

15.3.1 インストール・プログラムの起動

インストール・プログラムを起動するには、次の手順を実行します。

1. ターゲットのシステムにログインします。

2. 動作保証されたJDKがシステムに存在していることを確認します。

詳細は、「サポートされているJDKのインストール」を参照してください。

3. インストール・プログラムがダウンロードされたディレクトリに移動します。

4. 次の例に示すとおり、ご使用のシステムのJDKディレクトリからjava実行可能ファイルを実行し、インストール・プログラムを起動します。

JAVA_HOME/bin/java -d64 -jar fmw_12.2.1.0.0_soa.jar

これらの例にあるJDKの場所は、ご使用のシステムの実際のJDKの場所に読み替えてください。

インストール・プログラムが表示されると、インストールを開始する準備ができています。

15.3.2 Oracle BPMのインストール画面のナビゲート

インストール・プログラムでは、表15-1に記載された順番で一連の画面が表示されます。

インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。

表15-1 Oracle Business Process Managementのインストール画面

画面

説明

インストール・インベントリの設定

この画面は、UNIXオペレーティング・システムで、このホストに初めてOracle製品をインストールする場合に表示されます。中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名には、中央インベントリの場所への書込み権限があることを確認してください。

中央インベントリの詳細は、Oracle Universal InstallerによるソフトウェアのインストールでOracle中央インベントリの理解に関する項を参照してください。

自動更新

この画面では、使用可能なパッチを探してMy Oracle Supportを自動的に検索するか、組織にすでにダウンロードしたパッチを探してローカル・ディレクトリを自動的に検索します。

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。Oracleホームの場合は、/u01/oracle/products/fmwnnnnを指定します。

Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middlewareのインストールのプランニングでインストールと構成のディレクトリの選択に関する項を参照してください。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

- 「BPM」を選択します

注意: このドキュメントのトポロジには、例は含まれていません。例を本番環境にインストールしないことを強くお薦めします。

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告メッセージまたはエラー・メッセージが表示された場合は、第1.4項に記載されているドキュメントのいずれかを参照してください。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを確認します。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。レスポンス・ファイルは、今後、サイレント・インストールを実行する場合に使用できます。

サイレント・インストールやコマンド行インストールの詳細は、Oracle Universal Installerによるソフトウェアのインストールでサイレント・モードにおけるOracle Universal Installerの使用方法に関する項を参照してください。

「インストール」をクリックしてインストールを開始します。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

進捗バーが100%完了になった後で、「次へ」をクリックします。

インストール完了

この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

15.3.3 インストールの確認

インストールの完了後、次のタスクを正常に実行することでインストールを検証できます。

- インストール・ログ・ファイルの確認

- ディレクトリ構造のチェック

- Oracleホームの内容の表示

15.3.3.1 インストール・ログ・ファイルの確認

インストール・ログ・ファイルの内容を確認し、何も問題が発生していないことを確認します。ログ・ファイルの説明とその場所の詳細は、Oracle Universal Installerを使用したソフトウェアのインストールのインストール・ログ・ファイルの理解に関する項を参照してください。

15.3.3.2 ディレクトリ構造のチェック

インストールの内容は、インストール中に選択したオプションによって異なります。

BPMを追加すると、ORACLE_HOME/soa/bpmディレクトリに次のディレクトリとサブディレクトリが追加されます。

composites
helpsets
lib
modules

インストール後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解の「Oracle Fusion Middlewareの主要ディレクトリとは」を参照してください。ls -lart

15.3.3.3 Oracleホームの内容の表示

Oracleホームの内容を、viewInventoryスクリプトを使用して表示することもできます。詳細は、Oracle Universal Installerを使用したソフトウェアのインストールのOracleホームの内容の表示に関する項を参照してください。

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

ORACLE_COMMON_HOMEディレクトリで構成ウィザードを実行して、管理サーバー、Oracle Web Services ManagerおよびSOAを含むドメインを拡張し、BPMのコンポーネントをサポートするようにします。

- 構成ウィザードの起動

- ドメインを拡張するために構成ウィザード画面へ移動

15.4.1 構成ウィザードの起動

注意:

ドメインで起動スクリプトに直接カスタマイズを追加した場合、それらのカスタマイズは構成ウィザードによって上書きされます。ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverrides.shという名前のファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のjavaコマンド行オプションの指定、追加の環境変数の指定などを行うように構成できます。このファイルに追加されたカスタマイズはドメインのアップグレード操作中に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。

構成ウィザードを起動する手順は次のとおりです。

1. WebLogic Serverコンソールで、このドメイン拡張によって変更されるすべての管理対象サーバーを停止します。影響を受けない管理対象サーバーは、オンラインのままにすることができます。

注意:
Oracle Business Process Managementコンポーネントのこの特定のドメイン拡張では、WLS_SOAn管理対象サーバーを変更します。これらの管理対象サーバーを確実に停止します。

2. 管理対象サーバーのステータスを確認してから、管理サーバーを停止します。

詳細は、「SOAHOST1での構成ウィザードの起動」でノード・マネージャを使用して管理サーバーを停止する手順を参照してください。

3. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

cd ORACLE_HOME/oracle_common/common/bin
./config.sh

15.4.2 ドメインを拡張するために構成ウィザード画面へ移動

この項の手順に従って、BPM用にドメインを拡張します。

注意:

この手順では、既存のドメインを拡張することを想定しています。この手順の説明では要件が満たされない場合は、その要件に応じた選択を行うか、サポート・ドキュメントで追加の詳細を参照してください。

ドメインを作成して構成するためのタスクは次のとおりです。

- タスク1「ドメイン・タイプとドメイン・ホームの場所の選択」

- タスク2「構成テンプレートの選択」

- タスク3「データ・ソース構成タイプの指定」

- タスク4「拡張構成の選択」

- タスク5「構成仕様の確認とドメインの構成」

- タスク6「ドメイン・ホームと管理サーバーのURLの書込み」

- タスク7「管理サーバーの起動」

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください

ヒント:

この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

- Oracle BPM Suite - 12.2.1.1.0 [soa]

また、次の追加のテンプレートも、初期ドメインの作成と初期ドメインのSOAへの拡張に使用されているため、すでに選択されているはずです。

- Basic Weblogic Server Domain - 12.2.1.1.0 [wlserver]

- Oracle SOA Suite 12.2.1.1.0 [soa]

- Oracle Enterprise Manager - 12.2.1.1.0 [em]

- Oracle WSM Policy Manager - 12.2.1.1.0 [oracle_common]

- Oracle JRF - 12.2.1.1.0 [oracle_common]

- WebLogic Coherenceクラスタの拡張 - 12.2.1.1.0 [wlserver]

前にOracle Service Busを含めることでドメインを拡張した場合は、次のテンプレートも選択されています。

- WebLogic Advanced Web Services for JAX-RPC Extension - 12.2.1.1.0 [oracle_common]

- ODSI XQuery 2004 Components - 12.1.3.0 [oracle_common]

注意:

ODSI用の12.2.1.1.0テンプレートはありません。12.1.3テンプレートは12.2.1.1.0構成に役立ちます。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のテンプレートに関する項を参照してください。

タスク3   データ・ソース構成タイプの指定

Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。BPMは既存のSOAのデータソースを使用するため、新しいデータソースをドメインに追加する必要はありません。

注意:

拡張前に作成されたカスタム・データソース(リース・データソースなど)は、この画面の前に表示されます。「データソース」行を確認し、「次へ」をクリックします。テスト・データソース画面で、その妥当性が確認されます。「次へ」をクリックします。

タスク4   拡張構成の選択

トポロジのドメイン構成を完了するには、「拡張構成」画面で追加のオプションを選択しないで、「次へ(N)」をクリックします。BPMアプリケーションと必要なアーティファクトは、自動的に既存のSOAサーバーをターゲットとします。

タスク5   構成仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することによって前のいずれかの画面に戻ることができます。

「更新」をクリックするまで、ドメインの作成は開始されません。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

タスク6   ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

- ドメインの場所

- 管理サーバーURL

いずれの項目も後で必要になるため、メモしておいてください。ドメインの場所は管理サーバーを開始するために使用するスクリプトへのアクセスに必要で、URLは管理サーバーへのアクセスに必要です。

「終了」をクリックして、構成ウィザードを閉じます。

タスク7   管理サーバーの起動

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

15.5 ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

Oracle BPM Suiteでは、WebLogic Serverの起動スクリプトに多少の更新が必要です。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。

表15-2は、変更をすべてのドメイン・ディレクトリとマシンに伝播するために必要な手順をまとめたものです。

更新済ドメインをWEBHOST1およびWEBHOST2マシンに伝播する必要はありません。それらのホスト・コンピュータ上のOracle HTTP Serverインスタンスに対する変更はないためです。

表15-2 ドメイン変更をドメイン・ディレクトリおよびマシンに伝播するために必要なタスクのサマリー

タスク

説明

詳細情報

SOAHOST1での拡張済ドメインの圧縮

Packコマンドを使用して、新しいOracle BPM Suite管理対象サーバー構成が含まれる新しいテンプレートJARファイルを作成します。

ドメインを圧縮する場合は、soadomaintemplateExtSOABPM.jarというテンプレートJARファイルを作成します。

SOAHOST1での拡張済ドメインの圧縮

SOAHOST1の管理対象サーバー・ディレクトリでのドメインの解凍

SOAHOST1のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

SOAHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍

SOAHOST2でのドメインの解凍

SOAHOST2のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

SOAHOST2でのドメインの解凍

15.6 WebフォームのSOA BPMサーバーの更新

Oracle BPM Webフォームは、ユーザーがアプリケーションと対話できるインタフェースを定義します。Oracle BPMで作成されるビジネス・アプリケーションでは、これらのフォームはOracle Business Process Management Workspaceに表示されます。Webフォームを高可用性環境で適切に動作させるには、次の手順を実行します。

MSERVER/bin/startManagedWebLogic.shファイルを編集します。

次のコードをstartManagedWeblogic.shファイルに挿入します。

if [ "$1" = "WLS_SOA1" ] ; then
export cache_port=8001
export host_bind=SOAHOST1
fi
if [ "$1" = "WLS_SOA2" ] ; then
export cache_port=8001
export host_bind=SOAHOST2
fi

注意:
スケール・シナリオでは、サーバー、ホストおよびポートを更新する必要があります。

JAVA_OPTIONS= -Djgroups.tcpping.bind_port="${cache_port}" -Djgroups.tcpping.initial_hosts=SOAHOST1[8001],SOAHOST2[8001] -Dfrevvo.metadata.cache-config=/WEB-INF/cache-clustered.xml
-Dfrevvo.cache.config.file=cache-tcp.xml
-Dfrevvo.cluster=SOA_Cluster
-Djgroups.tcpping.num_members=2
-Djgroups.bind_addr=host_bind
-Djava.net.preferIP4Stack=true

JAVA_OPTIONSセクションの残りの部分は、元の内容のままとする必要があります。

15.7 Business Process ManagementによるWLS_SOA管理対象サーバーの再起動

構成変更および起動スクリプトを有効にするには、BPMが追加されたWLS_SOAnサーバーを再起動する必要があります。

BPMでは既存のSOAシステムが拡張されているので、管理サーバーおよびそれぞれのノード・マネージャはSOAHOST1およびSOAHOST2で稼働しています。

WLS_SOA1管理対象サーバーを再起動する手順は次のとおりです。

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

http://ADMINVHN:7001/em

2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

3. 「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。

4. WLS_SOA1管理対象サーバーを選択し、Oracle WebLogic Serverツールバーで「停止」をクリックします。

注意:

SOAサーバーは機能しているポリシー・アクセス・サービスに依存するため、SOAサーバーが起動する前に、ドメイン内のWSM-PM管理対象サーバーが稼働していてアクセス可能になっている必要があります。

5. 停止操作が完了したら、サーバーが引き続き選択されていることを確認し、ツールバーで「起動」をクリックします。

6. WLS_SOA2管理対象サーバーについて手順4と5を繰り返します。

7. 起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_SOA1およびWLS_SOA2管理対象サーバーが稼働中であることを確認します。

15.8 Oracle BAM Administrationグループへのエンタープライズ・デプロイメント管理ユーザーの追加

管理対象サーバーのOracle Business Process Management構成を検証する前に、エンタープライズ・デプロイメント管理ユーザー(weblogic_soa)をLDAPディレクトリ内のBusiness Process Management Administratorsグループに追加します。

このタスクを実行するには、「Oracle SOA Suite製品の管理のためのロールの構成」を参照してください。

Business Process Management ComposerまたはBusiness Process Management Worklistアプリケーションに初めてログインするときは、Administratorsグループのメンバーであるユーザーとしてログインする必要があります。初回ログイン後、ユーザーは次のロールが付与されていれば管理ユーザーになることができます。

OracleBPMComposerRolesApp/BPMComposerAdmin

また、初回ログイン後、認証済ユーザーであれば、Business Process Managementアプリケーションにアクセスできるようになります。

15.9 拡張したドメイン用のWeb層の構成

次の項では、Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをルーティングする方法について説明します。

- 拡張したドメイン用のOracle Traffic Directorの構成

- Oracle Business Process Management用のOracle HTTP Serverの構成
Oracle HTTP Serverインスタンス構成ファイルに次の変更を行って、Web層のOracle HTTP ServerインスタンスがOracle Business Process ManagementリクエストをOracle Business Process Managementソフトウェアに正しくルーティングできるようにします。

15.9.1 拡張したドメイン用のOracle Traffic Directorの構成

このドメインでOracle Traffic Directorを構成した場合、状況によっては、Oracle Traffic Director構成に別のオリジン・サーバー・プール、仮想サーバーまたはルートを追加する必要があります。各Oracle Fusion Middleware製品のOracle Traffic Directorの要件を理解するには、「オリジン・サーバーおよび仮想ホストのサマリー」を参照してください。

オリジン・サーバー・プール、仮想サーバーおよびルートを追加する手順は、「エンタープライズ・デプロイメント用のOracle Traffic Director仮想サーバーの定義」を参照してください。

15.9.2 Oracle Business Process Management用のOracle HTTP Serverの構成

Oracle HTTP Serverインスタンス構成ファイルに次の変更を行って、Web層のOracle HTTP ServerインスタンスがOracle Business Process ManagementリクエストをOracle Business Process Managementソフトウェアに正しくルーティングできるようにします。

Oracle HTTP ServerがBPM ComposerまたはBPM Workspaceコンソールにリクエストをルーティングできるようにする手順は次のとおりです。

1. WEBHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(ohs1)の構成ディレクトリに変更します。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf

2. 次のディレクティブを、soa_vh.confファイルの<VirtualHost>タグ内に追加します。

# BPM
<Location /bpm/composer>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# BPM
<Location /bpm/workspace>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

3. ディレクトリを次の場所に変更して、2番目のOracle HTTP Serverインスタンス(ohs2)の構成ファイルを更新できるようにします。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf

4. soa_vh.confファイルを開き、<VirualHost>タグにOracle Business Process Managementディレクティブを追加します。

5. WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

15.10 Business Process Managementサーバーとハードウェア・ロード・バランサ間のSSL通信の有効化

Business Process Managementを含めてドメインを拡張した後、管理サーバーと管理対象サーバーがハードウェア・ロード・バランサのフロントエンドのSSL URLにアクセスできることを確認する必要もあります。

これにより、Business Process Managementが、Webサービスを使用してフロントエンドのセキュアURLとのコールバックやその他の通信を起動できるようになります。

Oracle SOA Suite (WLS_SOA)管理対象サーバーに対してすでにこの通信を構成している場合は、「ハードウェア・ロード・バランサを使用したBusiness Process Managementへのアクセスの検証」の検証手順を使用し、この構成を検証できます。

ハードウェア・ロード・バランサとのSSL通信をまだ構成していない場合は、検証手順に進む前に「中間層とハードウェア・ロード・バランサ間のSSL通信の有効化」を参照してください。

15.11 ハードウェア・ロード・バランサを使用したBusiness Process Managementへのアクセスの検証

SOA_Clusterのクラスタ・アドレスは前の章ですでに設定されているので、Business Process ManagementコンテキストURLをWebLogic ServerにルーティングするようにOracle HTTP Server構成ファイルを変更した後にのみBusiness Process Managementシステムを検証できます。

次の手順を使用して、Business Process Management URLを検証し、ハードウェア・ロード・バランサからOracle HTTP Serverインスタンスを経由してBusiness Process Management管理対象サーバーに至るルーティングとフェイルオーバーが適切に機能することを確認します。

1. WLS_SOA2管理対象サーバーが稼働している間に、Oracle WebLogic Server管理コンソールを使用してWLS_SOA1管理対象サーバーを停止します。

2. Webブラウザを使用して次のURLにアクセスします。

https://soa.example.com/bpm/composer/
https://soa.example.com/bpm/workspace/

3. weblogic_soa管理資格証明を使用してログインします。

BPM ComposerおよびBPM Workspaceアプリケーション(図15-1と図15-2)が表示されます

4. Oracle WebLogic Server管理コンソールからWLS_SOA1を起動します。

5. Oracle WebLogic Server管理コンソールでWLS_SOA2を停止します。

6. 同じURLにアクセスして、ロード・バランサとOracle HTTP Serverインスタンスがリクエストを他の管理対象サーバーにルーティングできることを確認します。

図15-1 Oracle BPM Composer

図15-2 Oracle BPM Workspace

15.12 Oracle BPM Cluster用のBPMJMSModuleの構成

BPMJMSModule JMSモジュールを構成するには、モジュール内の一部のデフォルト値をこの項に示すように変更する必要があります。

BPMJMSModule JMSモジュールは、Oracle Business Process ManagementをOracle WebLogic Serverドメインに構成すると自動的にデプロイされます。

ただし、Oracle Business Process ManagementサーバーをOracle WebLogic Serverクラスタの一部としてデプロイした場合は、BPMJMSModule JMSモジュール内の個々のJMSリソースについて割当および再配信の制限のデフォルト値を変更する必要があります。

具体的には、次の表に示されているJMSトピック・リソースを変更する必要があります。

JMSリソース

プロパティ

説明

推奨設定

クラスタ構成内の「測定」分散トピック:

dist_MeasurementTopic_auto

割当

大量のメッセージが「測定」jmsトピックにパブリッシュされ、メッセージの消費が比較的遅い場合に、この設定が原因で問題が発生することがあります。

JMSの最大メッセージサイズのデフォルトのしきい値に到達すると、それ以上メッセージをパブリッシュできなくなり、一切のパブリッシュの試みは次の例外を受信して失敗します。

ResourceAllocationException

「割当」をMeasurementQuotaに設定します。

クラスタ構成内の「測定」分散トピック:

dist_MeasurementTopic_auto

再配信の制限

クラスタ構成では、このプロパティはデフォルトで「-1」に設定されます。

この設定が原因で、JMSが確認応答を受信するまでメッセージの送信を再試行することがあります。

トランザクションのロールバックを引き起こすシステム・エラーが発生したために、「測定」トピックのコンシューマがメッセージを処理できない場合、システムでパフォーマンスの問題が発生したり、繰り返される例外でログが一杯になったりすることがあります。

再配信の制限を3に設定します。

クラスタ構成内の「測定」分散トピック:

dist_MeasurementTopic_auto

転送ポリシー

クラスタ・インストール内の分散測定トピックは、デフォルトでは転送ポリシーが「レプリケート」に設定されて構成されていますが、これはBPM分析の最善のパフォーマンス・オプションではありません。

詳細は、パフォーマンスのチューニングのOracle Business Process Managementのチューニングに関する項を参照してください。

転送ポリシーを「パーティション化」に変更します。

BPMJMSModuleリソースの設定を変更する手順:

1. Oracle WebLogic Server管理コンソールにログインします。

2. 左のナビゲーション・ページで「サービス」→「メッセージング」→「JMSモジュール」を選択します。

3. JMSモジュールのリストで「BPMJMSModule」をクリックします。

4. 「リソースのサマリー」表で「dist_MeasurementTopic_auto」を選択します。

5. 「しきい値と割当」タブをクリックします。

6. 「ロックして編集」をクリックします。

7. 「割当」ドロップダウン・メニューで「MeasurementQuota」を選択し「保存」をクリックします。

8. 「配信の失敗」タブをクリックします。

9. 次のフィールドが3に設定されていることを確認します。

- 再配信遅延のオーバーライド

- 再配信の制限

10. 「保存」をクリックします。

11. 「一般」タブをクリックします。

12. 「転送ポリシー」メニューで「パーティション化」を選択します。

13. 「保存」をクリックします。

14. 「変更のアクティブ化」をクリックします。

15.13 Oracle BPM構成のバックアップ

Oracleのベスト・プラクティスとしては、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。

バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

構成をバックアップする方法の詳細は、「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。

15.14 Oracle Business Process Managementに対する自動サービス移行およびJDBC永続ストアの有効化

Oracle Business Process Managementが高可用性を実現するように構成するには、フェイルオーバーおよびゼロ・データ損失を実現する自動サービス移行で管理対象サーバーを構成します。

サーバー移行の有効化の詳細は、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。

WLS_SOA管理対象サーバーに対してすでに自動サービス移行が構成されている場合、この手順は不要です。

可用性を高めるために、データベース内にトランザクション・ログ・ストアとJMSストアを構成することもできます。詳細は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用」を参照してください。

16 Oracle Enterprise Schedulerを含めるドメインの拡張

次の各項では、Oracle Enterprise Schedulerソフトウェアを含めることでエンタープライズ・デプロイメント・ドメインを拡張する方法について説明します。

- この章で使用される変数
この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

- SOAドメインへのOracle Enterprise Schedulerの追加の概要
この項では、SOAドメインへのOracle Enterprise Schedulerの追加について概説します。

- ESS用のデータベース・スキーマの作成
Oracle ESSサーバーを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに必要なスキーマをインストールする必要があります。

- Oracle Enterprise Schedulerを追加するためのSOAドメインの拡張
この項では、Oracle Enterprise Schedulerを含める既存のエンタープライズ・デプロイメントのSOAドメインの拡張手順について説明します。

- トランザクション・リカバリ用のデフォルト永続ストアの構成
各管理対象サーバーでは、サーバーが調整およびコミットする、完了していない可能性のあるトランザクションに関する情報を格納するトランザクション・ログを使用します。Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、管理対象サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

- ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播
ESSインスタンスを含めることでドメインを拡張し、SOAHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリおよびマシンに伝播する必要があります。

- SOA管理者グループへのESSAdminロールの追加
WLS_ESS1管理対象サーバーのOracle Enterprise Scheduler構成を検証する前に、ESSAdminロールをエンタープライズ・デプロイメントの管理グループ(SOA Administrators)に追加します。

- WLS_ESS1管理対象サーバーの起動
これでドメインの拡張、管理サーバーの再起動、およびドメインの他のホストへの伝播を完了したので、新しく構成したESSサーバーを起動できます。

- WLS_ESS2管理対象サーバーの起動と検証
この項の手順に従って、WLS_ESS2管理対象サーバーを起動および検証します。

- トランザクション・ログの場所と作成の検証
WLS_ESS1およびWLS_ESS2が起動して稼働したら、トランザクション・ログ・ディレクトリを確認し、トランザクション・ログが予期したように作成されたことを確認します。

- 拡張したドメイン用のWeb層の構成
次の項では、Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをルーティングする方法について説明します。

- ハードウェア・ロード・バランサを介したOracle Enterprise Schedulerへのアクセスの検証
URLを検証して、HTTP ServerからOracle ESSコンポーネントへのルーティングとフェイルオーバーが適切に機能することを確認します。

- Oracle Enterprise Scheduler構成のバックアップ
Oracleのベスト・プラクティスとしては、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。

親トピック: エンタープライズ・デプロイメントの構成

16.1 この章で使用される変数

この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

いくつかのディレクトリ変数の値については、「このガイドで使用するファイル・システムとディレクトリ変数」に定義されています。

- ORACLE_HOME

- ASERVER_HOME

- MSERVER_HOME

- OHS_DOMAIN_HOME

さらに、「エンタープライズ・トポロジによって必要とされる物理および仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスを参照することになります。

- ADMINVHN

この章のアクションは、次のホスト・コンピュータで実行します。

- SOAHOST1

- SOAHOST2

- WEBHOST1

- WEBHOST2

16.2 SOAドメインへのOracle Enterprise Schedulerの追加の概要

この項では、SOAドメインへのOracle Enterprise Schedulerの追加について概説します。

表16-1は、Oracle Enterprise Schedulerを追加するためのSOAドメイン拡張の大まかな手順と説明を示しています。

表16-1 Oracle Enterprise Schedulerを追加するためのSOAドメインの拡張手順

手順

説明

詳細情報

ESS用のデータベース・スキーマの作成

RCU画面に移動し、データベース・スキーマを作成します。

ESS用のデータベース・スキーマの作成

ドメイン拡張のための構成ウィザードの実行

Oracle Enterprise Schedulerコンポーネントを追加するために、SOA/OSBドメイン拡張します。

Oracle Enterprise Schedulerを追加するためのSOAドメインの拡張

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

クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

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

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

Oracle Enterprise Schedulerは、WebLogic Server起動スクリプトに対するいくつかの更新を必要とします。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。

ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

Oracle Enterprise Schedulerサーバーの起動

Oracle Enterprise Schedulerサーバーは、既存のドメインを拡張します。そのため、管理サーバーおよびそれぞれのノード・マネージャはSOAHOST1およびSOAHOST2で稼働しています。

WLS_ESS1管理対象サーバーの起動

WLS_ESS管理対象サーバーの検証

管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認し、URLにアクセスしてサーバーのステータスを確認します。

WLS_ESS2管理対象サーバーの起動と検証

WLS_ESSn管理対象サーバーに対するOracle HTTP Serverの構成

Oracle HTTP ServerがOracle Enterprise Schedulerコンソールおよびサービスにルーティングできるようにするには、WebLogicClusterパラメータを、クラスタ内のノードのリストに設定します。

WLS_ESS管理対象サーバーに対するOracle HTTP Serverの構成

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

サーバーのステータスが「実行中」であることを確認します。

ハードウェア・ロード・バランサを介したOracle Enterprise Schedulerへのアクセスの検証

Oracle Enterprise Schedulerのバックアップ

この後の手順でエラーが発生した場合の即座のリストアを目的として、ドメイン構成をバックアップします。

Oracle Enterprise Scheduler構成のバックアップ

16.3 ESS用のデータベース・スキーマの作成

Oracle ESSサーバーを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに必要なスキーマをインストールする必要があります。

次の各項の手順に従ってスキーマをインストールします。

- リポジトリ作成ユーティリティ(RCU)の起動

- エンタープライズ・スケジューラ・スキーマを作成するためのRCU画面のナビゲート

16.3.1 リポジトリ作成ユーティリティ(RCU)の起動

リポジトリ作成ユーティリティ(RCU)を起動するには:

1. 対象のシステムで、ORACLE_HOME/oracle_common/binディレクトリに移動します。

2. 対象のシステムで、JAVA_HOME環境変数に、動作保証されたJDKの場所が設定されていることを確認します。この場所は、binディレクトリより上の階層にする必要があります。たとえば、JDKが/u01/oracle/products/jdkに存在する場合は、次のようになります。

UNIXオペレーティング・システムの場合:

export JAVA_HOME=/u01/oracle/products/jdk

3. RCUを起動します。

UNIXオペレーティング・システムの場合:

./rcu

16.3.2 エンタープライズ・スケジューラ・スキーマを作成するためのRCU画面のナビゲート

スキーマ作成に必要なタスクは、次のとおりです。

- タスク1「RCUの導入」

- タスク2「スキーマ作成の方法の選択」

- タスク3「データベース接続の詳細の指定」

- タスク4「カスタム接頭辞の指定とスキーマの選択」

- タスク5「スキーマのパスワードの指定」

- タスク6「カスタム変数の指定」

- タスク7「スキーマ作成の完了」

タスク1   RCUの導入

「次へ」をクリックします。

タスク2   スキーマ作成の方法の選択

データベースでDBAアクティビティを実行するために必要な権限を持っている場合は、「システム・ロードおよび製品ロードの同時実行」を選択します。この手順は、必要な権限が付与されていることを前提としています。

データベースに対するDBAアクティビティの実行に必要なパーミッションまたは権限が付与されていない場合は、この画面で、「システム・ロードに対するスクリプトの準備」を選択する必要があります。これによってSQLスクリプトが生成され、これをデータベース管理者が利用できます。『リポジトリ作成ユーティリティによるスキーマの作成』でシステム・ロードと製品ロードの理解に関する項を参照してください。

タスク3   データベース接続の詳細の指定

RCUがデータベースに接続できるようにするために、データベース接続の詳細を指定します。「ホスト名」に、ご使用のRAC DBのSCANアドレスを入力します。

「次へ」をクリックして続行し、データベースへの接続が成功したことを通知するダイアログ・ウィンドウで「OK」をクリックします。

タスク4   カスタム接頭辞の指定とスキーマの選択

「既存の接頭辞の選択」を選択して、元のドメイン作成スキーマで使用した接頭辞を指定します。

Oracle AS共通スキーマを開き、コンポーネント・リストで「Oracle Enterprise Scheduler」を選択します。

カスタム接頭辞は、これらのスキーマを論理的にグループ化して、このドメイン内でのみ使用することを目的としています。複数のドメイン間でのスキーマの共有はサポートされていないため、ドメインごとに固有のスキーマのセットを作成する必要があります。

ヒント:

カスタム接頭辞の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のカスタム接頭辞の理解に関する項を参照してください。

マルチドメイン環境のスキーマを編成する方法の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のスキーマの作成計画に関する項を参照してください。

ヒント:

ここに入力するカスタム接頭辞は、メモしておく必要があります。このカスタム接頭辞は、後述するドメイン作成のプロセスで必要になります。

「次へ」をクリックして先に進み、スキーマ作成の前提条件チェックが成功したことを確認するダイアログ・ウィンドウの「OK」をクリックします。

タスク5   スキーマのパスワードの指定

スキーマのパスワードをデータベースに設定する方法を指定してから、パスワードの指定と確認を行います。

ヒント:

この画面で設定するパスワードは、メモしておく必要があります。このパスワードは、後述するドメイン作成のプロセスで必要になります。

タスク6   カスタム変数の指定

デフォルトおよび一時表領域の選択で「次へ」をクリックし(デフォルトを受け入れ)、作成する表領域に関する警告を表示する「確認」ポップアップ・ウィンドウをクリックします。

タスク7   スキーマ作成の完了

RCU画面の残りの部分を先に進めて、スキーマ作成を完了します。「完了サマリー」画面が表示されたら、「閉じる」をクリックしてRCUを終了します。

16.4 Oracle Enterprise Schedulerを追加するためのSOAドメインの拡張

この項では、Oracle Enterprise Schedulerを含める既存のエンタープライズ・デプロイメントのSOAドメインの拡張手順について説明します。

ドメインを拡張するには、次のタスクを実行する必要があります。

- 構成ウィザードの起動

- Oracle Enterprise Schedulerを含めるドメイン拡張を行うための構成ウィザード画面への移動

16.4.1 構成ウィザードの起動

注意:

ドメインで起動スクリプトに直接カスタマイズを追加した場合、それらのカスタマイズは構成ウィザードによって上書きされます。ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverrides.shという名前のファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のjavaコマンド行オプションの指定、追加の環境変数の指定などを行うように構成できます。このファイルに追加したカスタマイズは、ドメインのアップグレード操作時に保持され、packコマンドとunpackコマンドの使用時にリモート・サーバーに継承されます。

ドメインの構成を開始するには:

1. ドメインの構成中に、構成のロック、保存、アクティブ化が行われないように、管理サーバーを停止します。

詳細は、「SOAHOST1での構成ウィザードの起動」でノード・マネージャを使用して管理サーバーを停止する手順を参照してください。

2. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

ORACLE_HOME/oracle_common/common/bin
./config.sh

16.4.2 Oracle Enterprise Schedulerを含めるドメイン拡張を行うための構成ウィザード画面への移動

この手順では、「Oracle SOA Suiteを含めるドメインの拡張」で作成したドメインを拡張して、Oracle Enterprise Schedulerコンポーネントを含めます。

この項の手順は、Oracle Fusion Middleware Infrastructureドメインを直接拡張するために必要な手順とほぼ同じになりますが、画面に表示される一部のオプション、ライブラリ、コンポーネントは異なります。

ドメインを作成して構成するためのタスクは次のとおりです。

- タスク1「ドメイン・タイプとドメイン・ホームの場所の選択」

- タスク2「構成テンプレートの選択」

- タスク3「データ・ソース構成タイプの指定」

- タスク4「JDBCコンポーネント・スキーマの情報の指定」

- タスク5「GridLink Oracle RACデータベース接続の詳細情報の指定」

- タスク6「拡張構成の選択」

- タスク7「管理対象サーバーの構成」

- タスク8「クラスタの構成」

- タスク9「クラスタへの管理対象サーバーの関連付け」

- タスク10「Coherenceクラスタの構成」

- タスク11「既存のマシンの検証」

- タスク12「マシンへのサーバーの割当て」

- タスク13「構成仕様の確認とドメインの構成」

- タスク14「管理サーバーの起動」

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「構成タイプ」に関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

Oracle Enterprise Scheduler Service Basic - 12.2.1.1.0 [oracle_common]

Oracle Enterprise Manager Plugin for ESS - 12.2.1.1.0 [em]

「次へ」をクリックします。

タスク3   データ・ソース構成タイプの指定

注意:

拡張前に作成されたカスタム・データソース(リース・データソースなど)は、この画面の前に表示されます。「データソース」行を確認し、「次へ」をクリックします。テスト・データソース画面で、その妥当性が確認されます。「次へ」をクリックします。

Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。すべてのフィールドにおける資格証明が、Oracle Fusion Middleware Infrastructureの構成中に指定したものと同じであることを確認します。

データベース接続情報の確認が完了した後で、「RCU構成の取得」をクリックします。「接続結果ログ」の次の出力は、操作が成功したことを示しています。

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK
Successfully Done.

ヒント:

RCUデータのオプションの詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解に関する項を参照してください。

この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のデータ・ソース・デフォルトに関する項を参照してください。

タスク4   JDBCコンポーネント・スキーマ情報の指定

ESSスキーマおよびESS MDSスキーマを選択します。

スキーマを選択すると、ページ上のフィールドがアクティブ化され、データベース接続フィールドに自動的に値が移入されます。

「GridLinkへ変換」をクリックし、「次へ」をクリックします。

タスク5   GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

要素

説明と推奨値

SCAN、ホスト名とポート

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドに、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

データベースがFANイベントを受信して処理できるように、「FANの有効化」チェック・ボックスが選択されていることを確認します。

タスク6   拡張構成の選択

拡張構成の選択画面で、次を選択します。

管理対象サーバー、クラスタおよびCoherence

「次へ」をクリックします。

タスク7   管理対象サーバーの構成

「管理対象サーバー」画面で、エンタープライズ・スケジューラに必要な管理対象サーバーを追加します。

- 自動的に作成されたサーバーを選択し、「名前の変更」をクリックして、名前をWLS_ESS1に変更します。

- 「追加」をクリックして別の新規サーバーを追加し、サーバー名としてWLS_ESS2と入力します。

- WLS_ESS1およびWLS_ESS2サーバーに、表16-2内の属性を指定します。

「次へ」をクリックします。

表16-2 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

サーバー・グループ

WLS_SOA1

SOAHOST1

8001

n/a

いいえ

SOA-MGD-SVRS-ONLY

WLS_SOA2

SOAHOST2

8001

n/a

いいえ

SOA-MGD-SVRS-ONLY

WLS_WSM1

SOAHOST1

7010

n/a

いいえ

JRF-MAN-SVR

WSMPM-MAN-SVR

WSM-CACHE-SVR

WLS_WSM2

SOAHOST2

7010

n/a

いいえ

JRF-MAN-SVR

WSMPM-MAN-SVR

WSM-CACHE-SVR

WLS_OSB1

SOAHOST1

8011

n/a

いいえ

OSB-MGD-SVRS-ONLY

WLS_OSB2

SOAHOST2

8011

n/a

いいえ

OSB-MGD-SVRS-ONLY

WLS_ESS1

SOAHOST1

8021

n/a

いいえ

ESS-MGD-SVRS

WLS_ESS2

SOAHOST2

8021

n/a

いいえ

ESS-MGD-SVRS

Oracle SOA Suiteが構成されているドメインを拡張する場合にかぎり、WLS_SOA管理対象サーバーが表示されます。

Oracle Service Busが構成されているドメインを拡張する場合にかぎり、WLS_OSB管理対象サーバーが表示されます。

タスク8   クラスタの構成

「クラスタの構成」画面で、次の表に示される各プロパティの値を使用して、エンタープライズ・スケジューラ・クラスタを追加します。

「次へ」をクリックします。

名前

クラスタ・アドレス

フロントエンド・ホストADMIN.mycompany.com

フロントエンドHTTPポート

フロントエンドHTTPS

SOA_Cluster

空白のままにします。

soa.example.com

80

443

WSM-PM_Cluster

空白のままにします

空白のままにします

空白のままにします

空白のままにします

OSB_Cluster

空白のままにします

osb.example.com

80

443

ESS_Cluster

空白のままにします

soa.example.com

80

443

Oracle SOA Suiteが構成されているドメインを拡張する場合にかぎり、SOA_Clusterクラスタが表示されます。

Oracle Service Busが構成されているドメインを拡張する場合にかぎり、OSB_Clusterクラスタが表示されます。

タスク9   クラスタへの管理対象サーバーの割当て

「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。

- SOA_Cluster - SOAドメインを拡張する場合

- WLS_SOA1

- WLS_SOA2

- WSM-PM_Cluster:

- WLS_WSM1

- WLS_WSM2

- OSB_Cluster - OSBドメインを拡張する場合:

- WLS_OSB1

- WLS_OSB2

- ESS_Cluster:

- WLS_ESS1

- WLS_ESS2

「次へ」をクリックします。

タスク10   Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期Infrastructureドメインの作成中に定義されているため、9991のままにします。

タスク11 既存のマシンの検証

「Unixマシン」タブで、次のエントリが表示されることを確認します。

名前

ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINHOST

ADMINVHN

その他のすべてのフィールドはデフォルト値のままにします。

「次へ」をクリックします。

タスク12   マシンへのサーバーの割当て

「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- ADMINHOST:

- AdminServer

- SOAHOST1

- WLS_SOA1 (SOAドメインを拡張する場合)

- WLS_WSM1

- WLS_OSB1 (OSBドメインを拡張する場合)

- WLS_ESS1

- SOAHOST2

- WLS_SOA2 (SOAドメインを拡張する場合)

- WLS_WSM2

- WLS_OSB2 (OSBドメインを拡張する場合)

- WLS_ESS2

「次へ」をクリックします。

タスク13   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

「更新」をクリックします。

「ドメインの拡張」画面で、「完了」をクリックします。

タスク14   管理サーバーの起動

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

16.5 トランザクション・リカバリのためのデフォルトの永続ストアの構成

各管理対象サーバーでは、サーバーが調整およびコミットする、完了していない可能性のあるトランザクションに関する情報を格納するトランザクション・ログを使用します。Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、管理対象サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

注意:

トランザクション・リカバリ・サービスの移行機能を有効にするには、クラスタにある他のサーバーで使用可能な永続記憶域ソリューションの場所を指定します。クラスタ内のすべての管理対象サーバーがこのディレクトリにアクセスできる必要があります。また、このディレクトリは、サーバーを再起動する前にも存在している必要があります。

お薦めする場所は、デュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)です。記憶域エラーが発生した場合に確実に保護するには、記憶域レベルで適切な複製およびバックアップ・メカニズムを設定しておくことが重要です。

この情報は、ファイルベースのトランザクション・ログに適用されます。トランザクション・ログに対して、データベース・ベースの永続ストアを構成することもできます。詳細は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用」を参照してください。

デフォルトの永続ストアの場所を設定する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

ADMINVHN:7001/console

2. 「チェンジ・センター」セクションで、「ロックして編集」をクリックします。

3. クラスタ内の管理対象サーバーごとに、次を実行します。

a. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページが表示されます。

b. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

c. 「構成」タブで、「サービス」タブをクリックします。

d. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
エンタープライズ・デプロイメントの場合は、ORACLE_RUNTIMEディレクトリの場所を使用します。このサブディレクトリは、クラスタのトランザクション・ログの中央の共有場所の役割を果します。詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

例:

ORACLE_RUNTIME/domain_name/cluster_name/tlogs

この例では、ORACLE_RUNTIMEを、ご使用の環境の変数値に置き換えます。domain_nameを、ドメインに割り当てた名前に置き換えます。cluster_nameを、先ほど作成したクラスタ名で置き換えます。

e. 「保存」をクリックします。

4. 「保存」をクリックして、「変更のアクティブ化」をクリックします。

5. クラスタ内の他のサーバーで手順1から4を完了します。

注意:

構成手順の後半で、トランザクション・ログの場所と作成について検証します。

16.6 ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

ESSインスタンスを含めることでドメインを拡張し、SOAHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリおよびマシンに伝播する必要があります。

次の表は、変更をすべてのドメイン・ディレクトリとマシンに伝播するために必要な手順をまとめたものです。

タスク

説明

詳細情報

SOAHOST1での拡張済ドメインの圧縮

Packコマンドを使用して、新しいESSサーバー構成が含まれる新しいテンプレートJARファイルを作成します。

ドメインを圧縮する場合は、soadomaintemplateExtESS.jarというテンプレートJARファイルを作成します。

SOAHOST1での拡張済ドメインの圧縮

SOAHOST1の管理対象サーバー・ディレクトリでのドメインの解凍

SOAHOST1のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

SOAHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍

SOAHOST2でのドメインの解凍

SOAHOST2のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

SOAHOST2でのドメインの解凍

16.7 SOA管理者グループへのESSAdminロールの追加

WLS_ESS1管理対象サーバーのOracle Enterprise Scheduler構成を検証する前に、ESSAdminロールをエンタープライズ・デプロイメントの管理グループ(SOA Administrators)に追加します。

このタスクを実行するには、「Oracle SOA Suite製品の管理のためのロールの構成」を参照してください。

16.8 WLS_ESS1管理対象サーバーの起動

これでドメインの拡張、管理サーバーの再起動、およびドメインの他のホストへの伝播を完了したので、新しく構成したESSサーバーを起動できます。

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

http://ADMINVHN:7001/em

この例では、次のようになります。

- ADMINVHNを、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」でADMINVHN仮想IPアドレスに割り当てたホスト名に置き換えます。

- ポート7001は、管理サーバー・コンソールおよびFusion Middleware Controlで一般的に使用されるポートです。ただし、ドメインを作成したときに構成ウィザードのセッションの終わりに表示された実際のURLを使用する必要があります。

2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

3. 「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。

図16-1 WLS_ESS1管理対象サーバー

4. WLS_ESS1管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。

注意:

SOAサーバーは、ポリシー・アクセス・サービスに依存して機能します。つまり、SOAサーバーが起動される前に、ドメイン内のWSM-PMサーバーがアクセス可能な状態になっている必要があります。

5. 起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_ESS1管理対象サーバーが稼働中であることを確認します。

6. ESSソフトウェアが構成されていることを検証するには、ブラウザに次のURLを入力します。

http://SOAHOST1:8021/EssHealthCheck

デフォルトのインストールでは、次の図に示すように、これはHTTPレスポンスです。

ヘルス・チェック・ボタンをクリックし、welogic_soa管理資格証明を使用してログインします。

次の図に示すように、返信で、Oracle Enterprise Schedule (ESS)が稼働中であることが報告されます。

16.9 WLS_ESS2管理対象サーバーの起動と検証

この項の手順に従って、WLS_ESS2管理対象サーバーを起動および検証します。

WLS_ESS2でも、前の項と同様の手順を実行します。

1. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

2. 「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。

3. WLS_ESS2管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。

4. 起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_ESS2管理対象サーバーが稼働中であることを確認し、次のようにWLS_ESS2用の同等のURLにアクセスします。

http://SOAHOST2:8021/EssHealthCheck

ヘルス・チェック・ボタンをクリックし、welogic_soa管理資格証明を使用してログインします。

図16-*に示すように、返信で、Oracle Enterprise Schedulerが稼働中であることが報告されます。

16.10 トランザクション・ログの場所と作成の検証

WLS_ESS1およびWLS_ESS2が起動して稼働したら、トランザクション・ログ・ディレクトリを確認し、トランザクション・ログが予期したように作成されたことを確認します。

「トランザクション・リカバリ用のデフォルト永続ストアの構成」で実行した手順に基づいて、次のコマンドを実行し、確認します。

ORACLE_RUNTIME/domain_name/ESS_Cluster/tlogs

- _WLS_WLS_ESS1000000.DAT

- _WLS_WLS_ESS2000000.DAT

16.11 拡張したドメイン用のWeb層の構成

次の項では、Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをルーティングする方法について説明します。

- 拡張したドメイン用のOracle Traffic Directorの構成

- WLS_ESS管理対象サーバーに対するOracle HTTP Serverの構成
Oracle HTTP Serverインスタンスの構成ファイルに対して次の変更を行い、Web層のOracle HTTP Serverインスタンスが、SOAHOST1およびSOAHOST2上のWLS_ESS管理対象サーバーにOracle Enterprise Schedulerのリクエストを正しくルーティングできるようにします。

- WebLogicプロキシ・プラグインの構成
ESSクラスタの「WebLogicプラグインの有効化」パラメータを設定します。

16.11.1 拡張したドメイン用のOracle Traffic Directorの構成

このドメインでOracle Traffic Directorを構成した場合、状況によっては、Oracle Traffic Director構成に別のオリジン・サーバー・プール、仮想サーバーまたはルートを追加する必要があります。各Oracle Fusion Middleware製品のOracle Traffic Directorの要件を理解するには、「オリジン・サーバーおよび仮想ホストのサマリー」を参照してください。

オリジン・サーバー・プール、仮想サーバーおよびルートを追加する手順は、「エンタープライズ・デプロイメント用のOracle Traffic Director仮想サーバーの定義」を参照してください。

16.11.2 WLS_ESS管理対象サーバーに対するOracle HTTP Serverの構成

Oracle HTTP Serverインスタンスの構成ファイルに対して次の変更を行い、Web層のOracle HTTP Serverインスタンスが、SOAHOST1およびSOAHOST2上のWLS_ESS管理対象サーバーにOracle Enterprise Schedulerのリクエストを正しくルーティングできるようにします。

Oracle HTTP Serverが、アプリケーション層にOracle Enterprise Schedulerのリクエストをルーティングできるようにするには:

1. SOAHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(ohs1)の構成ディレクトリに変更します。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf

2. 次のディレクティブを、soa_vh.confファイルの<VirtualHost>タグ内に追加します。

<Location /ess >
WLSRequest ON
WebLogicCluster SOAHOST1:8021,SOAHOST2:8021
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /EssHealthCheck >
WLSRequest ON
WebLogicCluster SOAHOST1:8021,SOAHOST2:8021
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /ess-async >
WLSRequest ON
WebLogicCluster SOAHOST1:8021,SOAHOST2:8022
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /ess-wsjob >
WLSRequest ON
WebLogicCluster SOAHOST1:8021,SOAHOST2:8022
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

3. ディレクトリを次の場所に変更して、2番目のOracle HTTP Serverインスタンス(ohs2)の構成ファイルを更新できるようにします。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf

4. soa_vh.confファイルを開き、<VirualHost>タグにOracle Business Process Managementディレクティブを追加します。

5. WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

16.11.3 WebLogicプロキシ・プラグインの構成

ESSクラスタの「WebLogicプラグインの有効化」パラメータを設定します。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ペインで、「環境」ノードを開きます。

3. 「クラスタ」をクリックします。

4. Oracle HTTP Serverからのリクエストをプロキシ設定する、ESS_Clusterクラスタを選択します。

「構成: 一般」タブが表示されます。

5. 「詳細」セクションまでスクロール・ダウンして、開きます。

6. 「ロックして編集」をクリックします。

7. 「WebLogicプラグインの有効化」を「はい」に設定します。

8. 変更を保存してアクティブ化をクリックします。

9. ESSサーバーを再起動して、変更内容を有効にします。

16.12 ハードウェア・ロード・バランサを介したOracle Enterprise Schedulerへのアクセスの検証

URLを検証して、HTTP ServerからOracle ESSコンポーネントへのルーティングとフェイルオーバーが適切に機能することを確認します。

ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。

URLを検証する手順は次のとおりです。

1. WLS_ESS1が稼動している状態で、Oracle WebLogic Server管理コンソールを使用してWLS_ESS2を停止します。

2. 「WLS_ESS2管理対象サーバーの起動と検証」で示すように、Webブラウザから次のURLにアクセスして、HTTPレスポンスを確認します。

https://soa.example.com/EssHealthCheck

3. Oracle WebLogic Server管理コンソールでWLS_ESS2を起動します。

4. Oracle WebLogic Server管理コンソールでWLS_ESS1を停止します。

5. ロード・バランサのアドレスを使用して、これらのURLを検証します。

https://soa.example.com:443/EssHealthCheck
https://soa.example.com/ess

16.13 Oracle Enterprise Scheduler構成のバックアップ

Oracleのベスト・プラクティスとしては、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。

バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

構成をバックアップする方法の詳細は、「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。

17 Business Activity Monitoringを含めるドメインの拡張

次の各項では、Oracle Business Activity Monitoringを追加するためのドメイン拡張の方法について説明します。

- この章で使用される変数
この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

- Oracle BAMをドメインに追加するための前提条件
Oracle BAMを既存のOracle SOA Suiteドメインに追加する前に、次の情報と前提条件を確認してください。

- 個別のホスト上でOracle BAMを構成する場合の特別な指示
Oracle BAMを独自のハードウェアで構成する場合は、次の項の情報も考慮しながら、この章の手順を実行します。

- Oracle BAMをドメインに追加するためのロードマップ
この項の表に、Oracle Business Activity MonitoringのためにSOAドメインを拡張する、大まかな手順を示します。

- Oracle Business Activity Monitoringを追加するためのSOAドメインの拡張
この項では、Oracle Business Activity Monitoringを追加して、既存のエンタープライズ・デプロイメントのSOAドメインを拡張する手順について説明します。

- トランザクション・リカバリ用のデフォルト永続ストアの構成
各管理対象サーバーでは、サーバーが調整およびコミットする、完了していない可能性のあるトランザクションに関する情報を格納するトランザクション・ログを使用します。Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、管理対象サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

- ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播
BAMインスタンスを追加してドメインを拡張し、SOAHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリおよびマシンに伝播する必要があります。

- Oracle BAM管理グループへのエンタープライズ・デプロイメント管理ユーザーの追加
管理対象サーバーのOracle BAM構成を検証する前に、エンタープライズ・デプロイメント管理ユーザー(weblogic_soa)をBAMAdministratorsグループに追加します。

- WLS_BAM1管理対象サーバーの起動
ドメインの拡張、管理サーバーの再起動、およびドメインの他のホストへの伝播を完了したら、新しく構成したBAMサーバーを起動します。

- WLS_BAM2管理対象サーバーの起動と検証
この項の手順に従って、WLS_BAM2を起動および検証します。

- 拡張したドメイン用のWeb層の構成
次の項では、Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをルーティングする方法について説明します。

- ハードウェア・ロード・バランサを介したOracle BAMへのアクセスの検証
Oracle BAM URLが、ハードウェア・ロード・バランサからのリクエストを、Oracle HTTP Serverインスタンスを経て中間層のOracle BAMソフトウェアに、正常にルーティングしていることを確認します。

- Oracle BAMサーバーに対する自動サービス移行およびJDBC永続ストアの有効化
ソフトウェアが高可用性を実現するように構成するには、自動サービス移行でOracle Business Activity Monitoring管理対象サーバーを構成します。

- Oracle BAM構成のバックアップ
Oracleのベスト・プラクティスとしては、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。

親トピック: エンタープライズ・デプロイメントの構成

17.1 この章で使用される変数

この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

いくつかのディレクトリ変数の値については、「このガイドで使用するファイル・システムとディレクトリ変数」に定義されています。

- ORACLE_HOME

- ASERVER_HOME

- MSERVER_HOME

- ORACLE_RUNTIME

- OHS_DOMAIN_HOME

さらに、「エンタープライズ・トポロジによって必要とされる物理および仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスを参照することになります。

- ADMINVHN

この章のアクションは、次のホスト・コンピュータで実行します。

- SOAHOST1

- SOAHOST2

- WEBHOST1

- WEBHOST2

17.2 Oracle BAMをドメインに追加するための前提条件

Oracle BAMを既存のOracle SOA Suiteドメインに追加する前に、次の情報と前提条件を確認してください。

注意:

Oracle BAMを個別のホスト・コンピュータにインストールする場合は、ここに記載されている前提条件の他に、「個別のホスト上でOracle BAMを構成する場合の特別な指示」を参照してください。

- Oracle BAMをドメインに追加するためのインストール要件の理解

- Oracle BAMのデータベース・スキーマ要件の理解

- 既存のインストールのバックアップ

17.2.1 Oracle BAMをドメインに追加するためのインストール要件の理解

この章では、図3-2に示すように、Oracle SOA Suiteと同じホスト・コンピュータ上にOracle Business Activity Monitoringを構成することを前提としています。

デフォルトのOracle SOA SuiteとOracle Business Activity Monitoringのトポロジでは、Oracle BAMを独自の管理対象サーバーとクラスタにターゲット指定しますが、Oracle BAMでは、SOAHOST1およびSOAHOST2上の他のOracle SOA Suite製品とシステム・リソースを共有します。このようなシステム・リソースには、Oracle SOA Suiteソフトウェアが既存のOracleホーム・ディレクトリにインストールされている共有記憶域デバイスが含まれます。

Oracle BAMは、Oracle SOA SuiteおよびOracle Business Process Managementのディストリビューションに含まれ、「Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジの理解」でOracle SOA SuiteをインストールするときにOracleホーム・ディレクトリにインストールされるため、デフォルトのトポロジでは、Oracle BAMをインストールする必要はありません。

17.2.2 Oracle BAMのデータベース・スキーマ要件の理解

リポジトリ作成ユーティリティ(RCU)を実行して、必要なOracle SOA Suiteスキーマを作成したときに、Oracle BAMに必要なスキーマがデータベースに作成されます。

そのため、Oracle BAMを対象にRCUを実行する必要はありません。

BAMシステムが他のOracle SOA Suite製品を含めずに作成され、SOAスキーマの作成がまだ実行されていない場合は、「Oracle SOA Suiteを含めるドメインの拡張」で説明したRCUインストール手順を実行する必要があります。

17.2.3 既存のインストールのバックアップ

既存のFusion Middlewareホームとドメインをバックアップしていない場合は、今すぐバックアップします。

既存のFusion Middlewareホームとドメインをバックアップするには、「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。

17.3 個別のホスト上でOracle BAMを構成する場合の特別な指示

Oracle BAMを独自のハードウェアで構成する場合は、次の項の情報も考慮しながら、この章の手順を実行します。

組織によっては、Oracle BAMソフトウェアが専用のハードウェア・リソースを使用でき、他のOracle SOA Suite製品から独立できるように、Oracle BAMを個別のホスト・コンピュータにインストールして構成するとよい場合があります。

- Oracle BAM用の追加ホスト・コンピュータの入手

- 個別のホスト上でOracle BAMを構成するときのインストール要件

- 個別のホスト上でOracle BAMを構成するときの構成ウィザードの手順

- 個別のホスト上でOracle BAMを構成するときのドメイン構成の伝播

17.3.1 Oracle BAM用の追加ホスト・コンピュータの入手

独自のホスト・コンピュータにOracle BAMを構成する場合は、追加のハードウェアを入手し、そのハードウェアが「ホスト・コンピュータのハードウェア要件」と「エンタープライズ・デプロイメント・トポロジのオペレーティング・システム要件」に記載されているシステム要件を満たしていることを確認する必要があります。

また、「エンタープライズ・デプロイメント・ワークブックの使用」で説明しているように、必要なエントリをエンタープライズ・デプロイメント・ワークブックに追加する必要があります。このガイドでは、これらのホスト・コンピュータをBAMHOST1およびBAMHOST2と呼びます。

17.3.2 個別のホスト上でOracle BAMを構成するときのインストール要件

独自のホスト・コンピュータでOracle BAMを構成する場合は、他のOracle SOA Suite製品がインストールされているホスト・コンピュータで従っているものと同じ共有記憶域戦略に従う必要があります。

注意:

BAMHOST1とBAMHOST2で使用するOracleホームには、ドメイン内のSOAHOST1ホストとSOAHOST2ホストで使用するソフトウェア・バイナリの正確なセットが含まれている必要があります。 含まれていない場合は、バイナリの実行時に予測できない動作が発生する可能性があります。

Oracle BAMソフトウェア用に個別のホスト・ハードウェアを使用する場合は、従っている共有記憶域戦略に応じて、次の項のいずれかが該当します。

- 個別のボリュームまたはパーティションを使用するときのインストール要件

- 共有Oracleホームを使用するときのインストール要件

17.3.2.1 個別のボリュームまたはパーティションを使用するときのインストール要件

BAMHOST1およびBAMHOST2で個別の共有記憶域のボリュームまたはパーティションを使用する場合は、そのホストに、Infrastructureと、必要に応じてOracle SOA Suiteをインストールする必要があります。詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

Oracleホーム(ソフトウェア・バイナリが含まれている)をインストールする場所は、ホストによって異なることに注意してください。ご使用のOracleホーム・ディレクトリの正しい場所を特定するには、「このガイドで使用するファイル・システムとディレクトリ変数」のガイドラインを参照してください。

BAMHOST1とBAMHOST2にソフトウェアをインストールするには、各ホストにログインして、次のタスクを実行します。

- 「エンタープライズ・デプロイメントの準備におけるOracle Fusion Middleware Infrastructureのインストール」の手順に従って、適切な記憶域デバイスにOracleホームを作成して、Oracle Fusion Middleware Infrastructureをインストールします。

- 「エンタープライズ・デプロイメント用のOracle SOA Suiteのインストール」の手順に従って、Oracle SOA Suiteソフトウェアをインストールします(任意)。

17.3.2.2 共有Oracleホームを使用するときのインストール要件

BAMHOST1とBAMHOST2で、Oracle Fusion Middleware InfrastructureまたはOracle SOA Suiteがすでにインストールされている既存のボリュームまたはパーティションを使用する場合は、ボリュームをBAMHOST1とBAMHOST2に適切にマウントする必要があります。詳細は、「各ホストへの必要な共有ファイル・システムのマウント」を参照してください。BAMHOST1とBAMHOST2が、ドメイン内の他のホストと同様に、このOracleホームにアクセスできることを確認します。

これは、エンタープライズ・デプロイメントで共有記憶域を使用するための推奨方法です。詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

既存のOracleホームを含む既存のボリュームまたはパーティションをマウントしたら、Oracleホームを、BAMHOST1またはBAMHOST2にあるローカルのOracleインベントリに追加する必要があります。

共有記憶域内のOracleホームをローカルのOracleインベントリに追加するには、BAMHOSTで次のコマンドを実行します。

cd ORACLE_HOME/oui/bin/attachHome.sh

./attachHome.sh -jreLoc JAVA_HOME

packユーティリティおよびunpackユーティリティを使用して、WLS_BAM1サーバーおよびWLS_BAM2サーバーのドメイン構成をブートストラップします。そのため、必要なソフトウェアがすでにインストールされている既存のOracleホームをマウントした場合は、これらの2つのホストにソフトウェアをインストールする必要はありません。

17.3.3 個別のホスト上でOracle BAMを構成するときの構成ウィザードの手順

個別のホスト・コンピュータでOracle BAMを構成する場合は、この章に記載されている、構成ウィザードを使用したドメインの構成方法が少し変更されます。

具体的には、必ず、BAMHOST1とBAMHOST2に対して追加のOracle WebLogic Serverマシンを作成し、WLS_BAM1およびWLS_BAM2管理対象サーバーを、SOAHOST1およびSOAHOST2ではなく、これらのマシンにターゲット指定するようにします。

詳細は、タスク12「既存のマシンの検証」とタスク13「サーバーのマシンへの割当て」を参照してください。

17.3.4 個別のホスト上でOracle BAMを構成するときのドメイン構成の伝播

個別のホスト・コンピュータでOracle BAMを構成する場合は、この章に記載されている、他のドメイン・ディレクトリにドメインを伝播する方法を変更する必要があります。

具体的には、SOAHOST1およびSOAHOST2上の管理対象サーバーのドメイン・ディレクトリにドメインを伝播することに加え、BAMHOST1およびBAMHOST2のローカルな管理対象サーバー・ディレクトリでドメインを解凍する必要があります。

つまり、各BAMHOSTコンピュータでノード・マネージャ・ソフトウェアを起動しなければ、これらのホスト上でWLS_BAM管理対象サーバーをリモートで起動することはできません。

17.4 Oracle BAMをドメインに追加するためのロードマップ

この項の表に、Oracle Business Activity MonitoringのためにSOAドメインを拡張する、大まかな手順を示します。

手順

説明

詳細情報

構成ウィザードによる、管理サーバー・ドメイン・ホーム内のドメインの拡張

Oracle BAMコンポーネントを追加するために、SOAドメイン拡張します。

Oracle Business Activity Monitoringを追加するためのSOAドメインの拡張

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

クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

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

管理対象サーバーのドメイン・ディレクトリへのドメイン構成の伝播

Oracle BAMでは、WebLogic Serverの起動スクリプトに多少の更新が必要です。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。

ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

Oracle BAM管理グループへのSOA管理者ロールの追加

この手順により、一連の資格証明を使用して、様々な製品固有の管理ユーティリティにアクセスできます。

Oracle BAM管理グループへのエンタープライズ・デプロイメント管理ユーザーの追加

Oracle BAMサーバーの起動

Oracle BAMサーバーにより、既存のドメインが拡張されます。そのため、管理サーバーおよびそれぞれのノード・マネージャはSOAHOST1およびSOAHOST2で稼働しています。

WLS_BAM1管理対象サーバーの起動

WLS_BAM管理対象サーバーの検証

管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認し、URLにアクセスしてサーバーのステータスを確認します。

WLS_BAM2管理対象サーバーの起動と検証

WLS_BAMn管理対象サーバーに対するOracle HTTP Serverの構成

Oracle HTTP ServerがOracle BAMにルーティングできるようにするには、必要なディレクティブをOracle HTTP Serverの構成ファイルに追加して、 WebLogicClusterパラメータをクラスタ内のノードの一覧に設定します。

WLS_BAM管理対象サーバーに対するOracle HTTP Serverの構成

WebLogic Serverプロキシ・プラグインの構成

Oracle BAMに対してWebLogic Serverプロキシ・プラグインを有効にします。

WebLogicプロキシ・プラグインの構成

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

サーバーのステータスが「実行中」であることを確認します。

ハードウェア・ロード・バランサを介したOracle BAMへのアクセスの検証

Oracle BAMサーバーの自動サービス移行の構成

管理対象サーバーまたはホスト・コンピュータのいずれかで障害が発生した場合に、サービスの移行により、主要な固定サービスがクラスタ内の別の管理対象サーバーに自動的に移行されます。サービス移行の詳細は、「エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用」を参照してください。

Oracle BAMサーバーの自動サービス移行の構成

Oracle BAM構成のバックアップ

この後の手順でエラーが発生した場合の即座のリストアを目的として、ドメイン構成をバックアップします。

Oracle BAM構成のバックアップ

17.5 Oracle Business Activity Monitoringを追加するためのSOAドメインの拡張

この項では、Oracle Business Activity Monitoringを追加して、既存のエンタープライズ・デプロイメントのSOAドメインを拡張する手順について説明します。

ドメインを拡張するには、次のタスクを実行する必要があります。

- 構成ウィザードの起動

- Oracle BAMの構成ウィザード画面のナビゲート

17.5.1 構成ウィザードの起動

注意:

ドメインで起動スクリプトに直接カスタマイズを追加した場合、それらのカスタマイズは構成ウィザードによって上書きされます。ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverrides.shという名前のファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のjavaコマンド行オプションの指定、追加の環境変数の指定などを行うように構成できます。このファイルに追加したカスタマイズは、ドメインのアップグレード操作時に保持され、packコマンドとunpackコマンドの使用時にリモート・サーバーに継承されます。

ドメインの構成を開始するには:

1. ドメインの構成中に、構成のロック、保存、アクティブ化が行われないように、管理サーバーを停止します。

詳細は、「SOAHOST1での構成ウィザードの起動」でノード・マネージャを使用して管理サーバーを停止する手順を参照してください。

2. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

ORACLE_HOME/oracle_common/common/bin
./config.sh

17.5.2 Oracle BAMの構成ウィザード画面のナビゲート

この手順では、「Oracle SOA Suiteを含めるドメインの拡張」で作成したドメインを拡張して、Oracle Business Activity Monitoringコンポーネントを追加します。

Oracle Business Activity Monitoringを追加して、管理サーバーとWSM-PMクラスタのみを含むドメインを拡張する場合の手順は、この項で説明する手順とほぼ同じになりますが、画面に表示される一部のオプション、ライブラリ、コンポーネントは異なる場合があります。

ドメインを作成して構成するためのタスクは次のとおりです。

- タスク1「ドメイン・タイプとドメイン・ホームの場所の選択」

- タスク2「構成テンプレートの選択」

- タスク3「データ・ソース構成タイプの指定」

- タスク4「JDBCコンポーネント・スキーマの情報の指定」

- タスク5「GridLink Oracle RACデータベース接続の詳細情報の指定」

- タスク6「JDBC接続のテスト」

- タスク7「拡張構成の選択」

- タスク8「管理対象サーバーの構成」

- タスク9「クラスタの構成」

- タスク10「クラスタへの管理対象サーバーの関連付け」

- タスク11「Coherenceクラスタの構成」

- タスク12「既存のマシンの検証」

- タスク13「マシンへのサーバーの割当て」

- タスク14「JMSファイル・ストアの構成」

- タスク15「構成仕様の確認とドメインの構成」

- タスク16「管理サーバーの起動」

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「構成タイプ」に関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

Oracle Business Activity Monitoring- 12.2.1.1.0 [soa]

「次へ」をクリックします。

タスク3   データ・ソース構成タイプの指定

注意:

拡張前に作成されたカスタム・データ・ソース(LEASINGデータ・ソースなど)が、この画面の前に表示されます。「データソース」行を確認し、「次へ」をクリックします。データ・ソースのテスト画面で、その有効性が検証されます。「次へ」をクリックします。

Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。すべてのフィールドにおける資格証明が、Oracle Fusion Middleware Infrastructureの構成中に指定したものと同じであることを確認します。

データベース接続情報の確認が完了した後で、「RCU構成の取得」をクリックします。「接続結果ログ」の次の出力は、操作が成功したことを示しています。

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK
Successfully Done.

タスク4   JDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」ページで、次のスキーマを選択します。

- BAMスキーマ

- BAM Job Schedスキーマ

- BAM Leasingスキーマ

- BAM Non JTAスキーマ

- BAM MDSスキーマ

「GridLinkへ変換」を選択して、「次へ」をクリックします。

タスク5   GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

要素

説明と推奨値

SCAN、ホスト名とポート

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドに、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

データベースがFANイベントを受信して処理できるように、「FANの有効化」チェック・ボックスが選択されていることを確認します。

タスク6   JDBC接続のテスト

「JDBCデータ・ソースのテスト」画面で、すべての接続が正常であることを確認します。

接続のテストは自動的に行われます。「ステータス」列に結果が表示されます。正常でない接続がある場合は、「前へ」をクリックして前の画面に戻り、入力を訂正します。

すべての接続に成功したら「次へ」をクリックします。

タスク7   拡張構成の選択

拡張構成の選択画面で、次を選択します。

- 管理対象サーバー、クラスタおよびCoherence

- JMSファイル・ストア

「次へ」をクリックします。

タスク8   管理対象サーバーの構成

「管理対象サーバー」画面で、Oracle BAMに必要な管理対象サーバーを追加します。

- 自動的に作成されたサーバーを選択して、その名前をWLS_BAM1に変更します。

- 「追加」をクリックし他の新規サーバーを追加して、サーバー名としてWLS_BAM2と入力します。

- BAMサーバーのサーバー・グループとして「BAM12-MGD-SVRS-ONLY」を選択します。リストから、「BAM12-MGD-SVRS」を選択解除します。

追加したサーバーの構成は、次の表に示す構成と一致する必要があります。

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

サーバー・グループ

WLS_SOA1*

SOAHOST1

8001

n/a

いいえ

SOA-MGD-SVRS-ONLY

WLS_SOA2*

SOAHOST2

8001

n/a

いいえ

SOA-MGD-SVRS-ONLY

WLS_WSM1

SOAHOST1

7010

n/a

いいえ

JRF-MAN-SVR

WSMPM-MAN-SVR

WSM-CACHE-SVR

WLS_WSM2

SOAHOST2

7010

n/a

いいえ

JRF-MAN-SVR

WSMPM-MAN-SVR

WSM-CACHE-SVR

WLS_BAM1

SOAHOST1

9001

n/a

いいえ

BAM12-MGD-SVRS-ONLY

WLS_BAM2

SOAHOST2

9001

n/a

いいえ

BAM12-MGD-SVRS-ONLY

*Oracle SOA Suiteがすでに構成されているドメインを拡張する場合は、WLS_SOA1およびWLS_SOA2管理対象サーバーが表示されます。

*WLS_BAM1およびWLS_BAM2のリスニング・アドレスを指定するときは、それぞれSOAHOST1およびSOAHOST2のIPアドレスを入力します。ただし、個別のホスト・コンピュータ(BAMHOST1およびBAMHOST2)でOracle BAMを構成する場合は、このかぎりではありません。個別のホストでOracle BAMを構成する場合は、BAMHOST1およびBAMHOST2のリスニング・アドレスを入力します。

タスク9   クラスタの構成

「クラスタの構成」画面で、「追加」をクリックして、BAM_Clusterを追加します(既存のクラスタはそのままにしておきます)。

表17-1 Oracle BAM用にドメインを拡張するときのクラスタのリスト

名前

クラスタ・アドレス

SOA_Cluster*

空白のままにします

WSM-PM_Cluster

空白のままにします

BAM_Cluster

空白のままにします

*ドメインにすでにOracle SOA Suiteを構成している場合にかぎり、SOAクラスタが表示されます。

「次へ」をクリックします。

タスク10   クラスタへの管理対象サーバーの割当て

「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。

- BAM_Cluster:

- WLS_BAM1

- WLS_BAM2

「次へ」をクリックします。

タスク11   Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期Infrastructureドメインの作成中に定義されているため、9991のままにします。

タスク12 既存のマシンの検証

ドメインに作成されているマシンを検証します。デフォルトでは、新しいOracle BAM管理対象サーバーを、それぞれSOAHOST1マシンとSOAHOST2マシンにターゲット指定することになります。

ただし、個別のホスト・コンピュータでOracle BAMを構成する場合は、対応するBAMHOST1およびBAMHOST2ホスト・コンピュータ用に2台のマシンを新しく作成する必要があります。

1. 「Unixマシン」タブを選択します。

2. 「追加」ボタンを使用して、BAMHOST1およびBAMHOST2用に2台のUnixマシンを新しく作成します。
BAMHOST1およびBAMHOST2の物理IPアドレスに対するノード・マネージャ・リスニング・アドレス。

3. 「ノード・マネージャ・リスニング・ポート」フィールドのポート番号を確認します。
この例に示されているポート番号5556は、このドキュメントの他の例にも使用されています。このポート番号は、必要に応じて各自のポート番号に置換してください。

その他のすべてのフィールドはデフォルト値のままにします。

「次へ」をクリックします。

タスク13   マシンへのサーバーの割当て

「サーバーのマシンへの割当」画面で、新しいWLS_BAM1およびWLS_BAM2サーバーを、それぞれSOAHOST1およびSOAHOST2マシンに割り当てます。

ただし個別のホスト・コンピュータでOracle BAMを構成する場合は、新しいOracle BAMサーバーを、新しく作成されたBAMHOST1およびBAMHOST2マシンにそれぞれ割り当てます。

「次へ」をクリックします。

タスク14 JMSファイル・ストアの構成

「JMSファイル・ストア」画面で、次のディレクトリをOracle BAMの各永続ストア(このセッションで作成された2つのUMS JMSファイル・ストアを含む)に割り当てます。

ORACLE_RUNTIME/domain_name/BAM_Cluster/jms

既存のJMSファイル・ストアに割り当てられている値は変更しないでください。これらの値は、事前に構成されている製品に対して作成したクラスタに対応しています。

タスク15   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

「更新」をクリックします。

「ドメインの拡張」画面で、「完了」をクリックします。

タスク16   管理サーバーの起動

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

17.6 トランザクション・リカバリのためのデフォルトの永続ストアの構成

各管理対象サーバーでは、サーバーが調整およびコミットする、完了していない可能性のあるトランザクションに関する情報を格納するトランザクション・ログを使用します。Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、管理対象サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

注意:

トランザクション・リカバリ・サービスの移行機能を有効にするには、クラスタにある他のサーバーで使用可能な永続記憶域ソリューションの場所を指定します。クラスタ内のすべての管理対象サーバーがこのディレクトリにアクセスできる必要があります。また、このディレクトリは、サーバーを再起動する前にも存在している必要があります。

お薦めする場所は、デュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)です。記憶域エラーが発生した場合に確実に保護するには、記憶域レベルで適切な複製およびバックアップ・メカニズムを設定しておくことが重要です。

この情報は、ファイルベースのトランザクション・ログに適用されます。トランザクション・ログに対して、データベース・ベースの永続ストアを構成することもできます。詳細は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用」を参照してください。

デフォルトの永続ストアの場所を設定する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

ADMINVHN:7001/console

2. 「チェンジ・センター」セクションで、「ロックして編集」をクリックします。

3. クラスタ内の管理対象サーバーごとに、次を実行します。

a. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページが表示されます。

b. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

c. 「構成」タブで、「サービス」タブをクリックします。

d. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
エンタープライズ・デプロイメントの場合は、ORACLE_RUNTIMEディレクトリの場所を使用します。このサブディレクトリは、クラスタのトランザクション・ログの中央の共有場所の役割を果します。詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

例:

ORACLE_RUNTIME/domain_name/cluster_name/tlogs

この例では、ORACLE_RUNTIMEを、ご使用の環境の変数値に置き換えます。domain_nameを、ドメインに割り当てた名前に置き換えます。cluster_nameを、先ほど作成したクラスタ名で置き換えます。

e. 「保存」をクリックします。

4. 「保存」をクリックして、「変更のアクティブ化」をクリックします。

5. クラスタ内の他のサーバーで手順1から4を完了します。

注意:

構成手順の後半で、トランザクション・ログの場所と作成について検証します。

17.7 ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

BAMインスタンスを追加してドメインを拡張し、SOAHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリおよびマシンに伝播する必要があります。

次の表は、変更をすべてのドメイン・ディレクトリとマシンに伝播するために必要な手順をまとめたものです。

タスク

説明

詳細情報

SOAHOST1での拡張済ドメインの圧縮

Packコマンドを使用して、新しいBAMサーバー構成が含まれる新しいテンプレートJARファイルを作成します。

ドメインを圧縮する場合は、soadomaintemplateExtBAM.jarというテンプレートJARファイルを作成します。

SOAHOST1での拡張済ドメインの圧縮

SOAHOST1の管理対象サーバー・ディレクトリでのドメインの解凍*

SOAHOST1のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

SOAHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍

SOAHOST2でのドメインの解凍

SOAHOST2のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

SOAHOST2でのドメインの解凍

*個別のホストでOracle BAMを構成する場合は、SOAHOST1およびSOAHOST2ではなく、BAMHOST1およびBAMHOST2でドメインを解凍します。

17.8 Oracle BAM管理グループへのエンタープライズ・デプロイメント管理ユーザーの追加

管理対象サーバーのOracle BAM構成を検証する前に、エンタープライズ・デプロイメント管理ユーザー(weblogic_soa)をBAMAdministratorsグループに追加します。

このタスクを実行するには、「Oracle SOA Suite製品の管理のためのロールの構成」を参照してください。

17.9 WLS_BAM1管理対象サーバーの起動

ドメインの拡張、管理サーバーの再起動、およびドメインの他のホストへの伝播を完了したら、新しく構成したBAMサーバーを起動します。

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

http://ADMINVHN:7001/em

2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

3. 「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。

4. WLS_BAM1管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。

注意:

BAMサーバーは、ポリシー・アクセス・サービスに依存して機能するため、BAMサーバーが起動する前に、ドメイン内のWSM-PM管理対象サーバーが稼働し、アクセス可能な状態になっている必要があります。

5. 起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_BAM1管理対象サーバーが稼働中であることを確認します。

6. BAMソフトウェアが適切に構成されていることを確認するには:

a. ブラウザに次のURLを入力します。

http://SOAHOST1:9001/bam/composer

BAMのコンポーザのログイン画面が表示されます。

個別のホスト・コンピュータでOracle BAMを構成した場合は、SOAHOST1ではなく、BAMHOST1をURLに入力します。

b. weblogic_soaログイン資格証明を入力します。
BAMコンポーザ画面が表示されます。

7. 次のURLを入力します。

http://SOAHOST1:9001/inspection.wsil/

個別のホスト・コンピュータでOracle BAMを構成した場合は、SOAHOST1ではなく、BAMHOST1をURLに入力します。

次のリンクのリストが含まれるレスポンスが表示されます。

8. ブラウザに次のURLを入力します。

http://SOAHOST1:9001/bam/cqservice/

個別のホスト・コンピュータでOracle BAMを構成した場合は、SOAHOST1ではなく、BAMHOST1をURLに入力します。

BAM CQServiceが稼働中であることを示すメッセージが、ブラウザに表示されます。

17.10 WLS_BAM2管理対象サーバーの起動と検証

この項の手順に従って、WLS_BAM2を起動および検証します。

1. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

2. 「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。

3. WLS_BAM2管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。

4. 起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_BAM2管理対象サーバーが稼働中であることを確認し、次のようにWLS_BAM2用の同等のURLにアクセスします。

http://SOAHOST2:9001/bam/composer

BAMのコンポーザのログイン画面が表示されます。ログイン資格証明を入力します。BAM Composerのメニューが表示されます。

5. 次のURLを入力します。

http://SOAHOST2:9001/inspection.wsil/

リンクのリストが含まれるレスポンスが表示されます。

6. ブラウザに次のURLを入力します。

http://SOAHOST2:9001/bam/cqservice/

BAM Serviceが稼働中であることを示すメッセージが、ブラウザに表示されます。

注意:

個別のホスト・コンピュータでOracle BAMを構成した場合は、SOAHOST2ではなく、BAMHOST2をURLに入力します。

17.11 拡張したドメイン用のWeb層の構成

次の項では、Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをルーティングする方法について説明します。

- 拡張したドメイン用のOracle Traffic Directorの構成

- WLS_BAM管理対象サーバーに対するOracle HTTP Serverの構成
Oracle HTTP Serverインスタンスの構成ファイルに対して次の変更を行い、Web層のOracle HTTP Serverインスタンスが、Oracle SOA Suiteクラスタ上のOracle BAMソフトウェアにOracle BAMリクエストを正しくルーティングできるようにします。

- WebLogicプロキシ・プラグインの構成
BAMクラスタの「WebLogicプラグインの有効化」パラメータを設定します。

17.11.1 拡張したドメイン用のOracle Traffic Directorの構成

このドメインでOracle Traffic Directorを構成した場合、状況によっては、Oracle Traffic Director構成に別のオリジン・サーバー・プール、仮想サーバーまたはルートを追加する必要があります。各Oracle Fusion Middleware製品のOracle Traffic Directorの要件を理解するには、「オリジン・サーバーおよび仮想ホストのサマリー」を参照してください。

オリジン・サーバー・プール、仮想サーバーおよびルートを追加する手順は、「エンタープライズ・デプロイメント用のOracle Traffic Director仮想サーバーの定義」を参照してください。

17.11.2 WLS_BAM管理対象サーバーに対するOracle HTTP Serverの構成

Oracle HTTP Serverインスタンスの構成ファイルに対して次の変更を行い、Web層のOracle HTTP Serverインスタンスが、 Oracle SOA Suiteクラスタ上のOracle BAMソフトウェアにOracle BAMリクエストを正しくルーティングできるようにします。

この手順は、Oracle SOA Suiteと同じホストでOracle BAMを構成することを前提にしています。Oracle BAM用に個別のホストを使用する場合は、SOAHOSTコンピュータではなくBAMHOSTコンピュータを参照するように、Oracle HTTP Server構成ファイルのWebLogicClusterパラメータを変更する必要があります。

Oracle HTTP ServerがOracle BAMにリクエストをルーティングできるようにする手順:

1. WEBHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(ohs1)の構成ディレクトリに変更します。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf

2. 次のディレクティブを、soa_vh.confファイルの<VirtualHost>タグ内に追加します。

<Location /bam/composer >
WLSRequest ON
WebLogicCluster SOAHOST1:9001,SOAHOST2:9001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /OracleBAMWS>
WLSRequest ON
WebLogicCluster SOAHOST1:9001,SOAHOST2:9001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /oracle/bam/server>
WLSRequest ON
WebLogicCluster SOAHOST1:9001,SOAHOST2:9001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

3. ディレクトリを次の場所に変更して、2番目のOracle HTTP Serverインスタンス(ohs1)の構成ファイルを更新できるようにします。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf

4. soa_vh.confファイルを開き、B2Bディレクティブを<VirualHost>タグに追加します。

5. WEBHOST1とWEBHOST2上のOracle HTTP Serverインスタンスを再起動します。

17.11.3 WebLogicプロキシ・プラグインの構成

BAMクラスタの「WebLogicプラグインの有効化」パラメータを設定します。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ペインで、「環境」ノードを開きます。

3. 「クラスタ」をクリックします。

4. Oracle HTTP Serverからのリクエストをプロキシ設定する、BAM_Clusterクラスタを選択します。

「構成: 一般」タブが表示されます。

5. 「詳細」セクションまでスクロール・ダウンして、開きます。

6. 「ロックして編集」をクリックします。

7. 「WebLogicプラグインの有効化」を「はい」に設定します。

8. 変更を保存してアクティブ化をクリックします。BAMサーバーを再起動して、変更を有効にします。

17.12 ハードウェア・ロード・バランサを介したOracle BAMへのアクセスの検証

Oracle BAM URLが、ハードウェア・ロード・バランサからのリクエストを、Oracle HTTP Serverインスタンスを経て中間層のOracle BAMソフトウェアに、正常にルーティングしていることを確認します。

この手順では、Oracle BAMが構成されている管理対象サーバーのフェイルオーバーをテストすることもできます。

URLを検証する手順は次のとおりです。

1. WLS_BAM1管理対象サーバーが稼働中は、Oracle WebLogic Server管理コンソールを使用して、WLS_BAM2管理対象サーバーを停止します。

2. 次のURLにアクセスし、「WLS_BAM1管理対象サーバーの起動」で示すように、HTTPレスポンスを検証します。

https://soa.example.com/bam/composer

3. 次のURLにアクセスして、ソフトウェアが予想どおりに実行されていることを確認します。
https://soa.example.com/oracle/bam/server

4. Oracle WebLogic Server管理コンソールでWLS_BAM2を起動します。

5. Oracle WebLogic Server管理コンソールでWLS_BAM1を停止します。

6. URLに再度アクセスし、「WLS_BAM2管理対象サーバーの起動と検証」に示すように、HTTPレスポンスが有効であることを確認します。

17.13 Oracle BAMサーバーに対する自動サービス移行およびJDBC永続ストアの有効化

ソフトウェアが高可用性を実現するように構成するには、自動サービス移行でOracle Business Activity Monitoring管理対象サーバーを構成します。

自動サービス移行の有効化の詳細は、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。

注意:

Oracle BAMを独自のドメイン内に構成する場合は、Oracle BAMに対して自動サービス移行を構成する際に、デフォルトのリース・データ・ソース(BamLeasingDatasource)を使用できます。

ただし、Oracle BAMとOracle SOA SuiteまたはOracle Service Busの両方を構成する一般的な環境では、LeasingDSのような中央の自動サービス移行データ・ソースを使用することが推奨されます(「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照)。

可用性を高めるために、データベース内にトランザクション・ログ・ストアとJMSストアを構成することもできます。詳細は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用」を参照してください。

17.14 Oracle BAM構成のバックアップ

Oracleのベスト・プラクティスとしては、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。

バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

構成をバックアップする方法の詳細は、「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。

18 Oracle B2Bを含めるドメインの拡張

この章では、Oracle B2Bを追加するためのドメイン拡張の手順を説明します。

Oracle B2BおよびHealthcareのディストリビューションには、Oracle B2BまたはOracle SOA for Healthcareの構成に必要なソフトウェアが含まれます。

注意:

X12 HIPAAユースケースの場合、この章で説明するOracle B2Bドメイン拡張手順を使用できます。ただし、HL7ドキュメントを使用するヘルスケア・プロバイダの場合は、「Oracle SOA Suite for Healthcare Integrationを含めるドメインの拡張」を参照して、Oracle SOA Suite for Healthcare Integrationソフトウェアを含めることでドメインを拡張します。

- この章で使用される変数
この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

- Oracle B2Bを追加するためのSOAドメイン拡張の前提条件
現在のドメインを拡張する前に、既存のデプロイメントがこの項に示す前提条件を満たしていることを確認します。

- エンタープライズ・デプロイメントのOracle B2Bのインストール
エンタープライズ・デプロイメント用の新規ドメインを構成する準備として、次の各項を参照してOracle Fusion Middleware Infrastructureソフトウェアをインストールします。

- 構成ウィザードを使用したOracle B2Bのための拡張
Oracle B2Bが含まれるようにドメインを拡張するには、次の項を参照してください。

- B2B Suiteコンポーネントの起動
構成の変更および起動スクリプトを有効にするには、B2Bが追加されたWLS_SOAサーバーを再起動する必要があります。B2Bでは既存のSOAシステムが拡張されているので、管理サーバーおよびそれぞれのノード・マネージャはSOAHOST1およびSOAHOST2で稼働しています。

- トランスポートのためのB2Bインスタンス識別子の更新
ファイル、FTPまたは電子メール・トランスポートを高可用性環境で設定するには、「b2b.HAInstance」プロパティを「true」に設定します。

- 拡張したドメイン用のWeb層の構成
次の項では、Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをルーティングする方法について説明します。

- SOA管理者グループへのB2BAdminロールの追加
管理対象サーバーのOracle B2B構成を検証する前に、B2BAdmin管理ロールをエンタープライズ・デプロイメントの管理グループ(SOA Administrators)に追加します。

- ロード・バランサを介したOracle B2Bへのアクセスの検証
次の手順を使用して、ロード・バランサからHTTP Serverインスタンスを経て、Oracle SOA Suite管理対象サーバー上のB2B Suiteコンポーネントに対して行われるルーティングとフェイルオーバーが、適切に機能することを確認します。

- 構成のバックアップ
Oracleのベスト・プラクティスとしては、ドメインの構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。

- Oracle B2Bに対する自動サービス移行およびJDBC永続ストアの有効化
エンタープライズ・トポロジでは、Oracle B2Bは、既存のOracle SOA Suite管理対象サーバー上で構成されています。SOA_Clusterに自動サービス移行がすでに構成されている場合、Oracle B2Bソフトウェアは自動サービス移行によってすでに保護されています。

親トピック: エンタープライズ・デプロイメントの構成

18.1 この章で使用される変数

この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

いくつかのディレクトリ変数の値については、「このガイドで使用するファイル・システムとディレクトリ変数」に定義されています。

- ORACLE_HOME

- ASERVER_HOME

- MSERVER_HOME

- OHS_DOMAIN_HOME

- JAVA_HOME

さらに、「エンタープライズ・トポロジによって必要とされる物理および仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスを参照することになります。

- ADMINVHN

この章のアクションは、次のホスト・コンピュータで実行します。

- SOAHOST1

- SOAHOST2

- WEBHOST1

- WEBHOST2

18.2 Oracle B2Bを追加するためのSOAドメイン拡張の前提条件

現在のドメインを拡張する前に、既存のデプロイメントがこの項に示す前提条件を満たしていることを確認します。

- インストールのバックアップ - 既存のFusion Middlewareホームとドメインをバックアップしていない場合は、今すぐバックアップすることをお薦めします。
既存のFusion Middlewareホームとドメインをバックアップするには、「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。

- 前の章でインストールしたWL_HOMEおよびSOA ORACLE_HOME(バイナリ)が共有記憶域にあり、SOAHOST1とSOAHOST2から利用できること。

- ノード・マネージャ、管理サーバー、SOAサーバーおよびWSMサーバーが存在し、前の章の説明のように、SOAシステムを実行するように構成されていること。

- RCUを実行して、B2Bの追加のスキーマをロードする必要はありません。このスキーマは、SOAリポジトリの一部であり、SOAに関する章で、DBにロードされています。

18.3 エンタープライズ・デプロイメントのOracle B2Bのインストール

エンタープライズ・デプロイメント用の新規ドメインを構成する準備として、次の各項を参照してOracle Fusion Middleware Infrastructureソフトウェアをインストールします。

- SOAHOST1でのOracle B2BおよびHealthcareインストーラの起動

- Oracle B2Bのインストール画面のナビゲート

- B2BまたはHealthcareインストールの確認

18.3.1 SOAHOST1でのOracle B2BおよびHealthcareインストーラの起動

インストール・プログラムを起動するには、次の手順を実行します。

1. SOAHOST1にログインします。

2. インストール・プログラムがダウンロードされたディレクトリに移動します。

3. 次の例に示すとおり、ご使用のシステムのJDKディレクトリからjava実行可能ファイルを実行し、インストール・プログラムを起動します。

JAVA_HOME/bin/java -d64 -jar distribution_file_name.jar

この例では、次のようになります。

- JAVA_HOMEを、ご使用のシステムの環境変数または実際のJDKの場所に置き換えます。

- distribution_file_nameを、ディストリビューションJARファイルの実際の名前に置き換えます。
ディストリビューションをOracle Technology Network (OTN)からダウンロードする場合、通常、JARファイルはダウンロード可能なZIPファイル内にパッケージされています。

初期Infrastructureドメインに必要なソフトウェアをインストールする場合は、インストールするディストリビューションはfmw_12.2.1.1.0_b2bhealthcare.jarです。

各ディストリビューションの実際のファイル名の詳細は、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」を参照してください。

インストール・プログラムが表示されると、インストールを開始する準備ができています。各インストール・プログラム画面の説明については、「インストール画面のナビゲート」を参照してください。

18.3.2 Oracle B2Bのインストール画面のナビゲート

表18-1は、インストール・プログラムの各画面の説明です。

表18-1 Oracle B2Bのインストール画面

画面

説明

インストール・インベントリの設定

この画面は、UNIXオペレーティング・システムで、このホストに初めてOracle製品をインストールする場合に表示されます。中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名には、中央インベントリの場所への書込み権限があることを確認してください。

中央インベントリの詳細は、Oracle Universal InstallerによるソフトウェアのインストールでOracle中央インベントリの理解に関する項を参照してください。

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面では、使用可能なパッチを探してMy Oracle Supportを自動的に検索するか、組織にすでにダウンロードしたパッチを探してローカル・ディレクトリを自動的に検索します。

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middlewareのインストールのプランニングでインストールと構成のディレクトリの選択に関する項を参照してください。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

- B2Bを選択します

注意: このドキュメントのトポロジには、例は含まれていません。例を本番環境にインストールしないことを強くお薦めします。

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告メッセージまたはエラー・メッセージが表示された場合は、第1.4項に記載されているドキュメントのいずれかを参照してください。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを確認します。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。レスポンス・ファイルは、今後、サイレント・インストールを実行する場合に使用できます。

サイレント・インストールやコマンド行インストールの詳細は、Oracle Universal Installerによるソフトウェアのインストールでサイレント・モードにおけるOracle Universal Installerの使用方法に関する項を参照してください。

「インストール」をクリックしてインストールを開始します。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

進捗バーが100%完了になった後で、「次へ」をクリックします。

インストール完了

この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

18.3.3 B2BまたはHealthcareインストールの確認

インストールの完了後、次のタスクを正常に実行することでインストールを検証できます。

- インストール・ログ・ファイルの確認

- ディレクトリ構造のチェック

- Oracleホームの内容の表示

18.3.3.1 インストール・ログ・ファイルの確認

インストール・ログ・ファイルの内容を確認し、何も問題が発生していないことを確認します。ログ・ファイルの説明とその場所の詳細は、Oracle Universal Installerを使用したソフトウェアのインストールのインストール・ログ・ファイルの理解に関する項を参照してください。

18.3.3.2 ディレクトリ構造のチェック

インストールの内容は、インストール中に選択したオプションによって異なります。

Oracle Healthcareを追加すると、次のディレクトリとサブディレクトリが追加されます。

ls  /u01/oracle/products/fmw/soa/soa/thirdparty/edifecs/

Common
STANDARDS
XEngine

インストール後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解の「Oracle Fusion Middlewareの主要ディレクトリとは」を参照してください。

18.3.3.3 Oracleホームの内容の表示

Oracleホームの内容を、viewInventoryスクリプトを使用して表示することもできます。詳細は、Oracle Universal Installerを使用したソフトウェアのインストールのOracleホームの内容の表示に関する項を参照してください。

18.4 構成ウィザードを使用したOracle B2Bのための拡張

Oracle B2Bが含まれるようにドメインを拡張するには、次の項を参照してください。

- 構成ウィザードの起動

- Oracle B2Bの構成ウィザード画面のナビゲート

18.4.1 構成ウィザードの起動

注意:

ドメインで起動スクリプトに直接カスタマイズを追加した場合、それらのカスタマイズは構成ウィザードによって上書きされます。ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverrides.shという名前のファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のjavaコマンド行オプションの指定、追加の環境変数の指定などを行うように構成できます。このファイルに追加したカスタマイズは、ドメインのアップグレード操作時に保持され、packコマンドとunpackコマンドの使用時にリモート・サーバーに継承されます。

構成ウィザードを起動する手順は次のとおりです。

1. WebLogic Serverコンソールで、このドメイン拡張によって変更されるすべての管理対象サーバーを停止します。影響を受けない管理対象サーバーは、オンラインのままにすることができます。

注意:
Oracle B2Bコンポーネントのこの特定のドメイン拡張では、WLS_SOAn管理対象サーバーを変更します。これらの管理対象サーバーを確実に停止します。

2. 管理対象サーバーのステータスを確認してから、管理サーバーを停止します。

詳細は、「SOAHOST1での構成ウィザードの起動」でノード・マネージャを使用して管理サーバーを停止する手順を参照してください。

3. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

cd ORACLE_HOME/oracle_common/common/bin
./config.sh

18.4.2 Oracle B2Bの構成ウィザード画面のナビゲート

この項の手順に従って、B2B用にドメインを拡張します。

注意:

この項で説明する手順を使用して、既存のドメインを拡張することもできます。この手順の説明では要件が満たされない場合は、その要件に応じた選択を行うか、サポート・ドキュメントで追加の詳細を参照してください。

ドメインを作成して構成するためのタスクは次のとおりです。

- タスク1「ドメイン・タイプとドメイン・ホームの場所の選択」

- タスク2「構成テンプレートの選択」

- タスク3「データ・ソース構成タイプの指定」

- タスク4「拡張構成の選択」

- タスク5「構成仕様の確認とドメインの構成」

- タスク6「ドメイン・ホームと管理サーバーのURLの書込み」

- タスク7「管理サーバーの起動」

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください

ヒント:

この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

- Oracle B2B - 12.2.1.1.0 [soa]

また、次の追加のテンプレートも、初期ドメインの作成と初期ドメインのSOAへの拡張に使用されているため、すでに選択されているはずです。

- Basic Weblogic Server Domain - 12.2.1.1.0 [wlserver]

- Oracle SOA Suite 12.2.1.1.0 [soa]

- Oracle Enterprise Manager - 12.2.1.1.0 [em]

- Oracle WSM Policy Manager - 12.2.1.1.0 [oracle_common]

- Oracle JRF - 12.2.1.1.0 [oracle_common]

- WebLogic Coherenceクラスタの拡張 - 12.2.1.1.0 [wlserver]

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のテンプレートに関する項を参照してください。

タスク3   データ・ソース構成タイプの指定

Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。B2Bでは、SOAの既存のデータ・ソースを使用するため、新しいデータ・ソースをドメインに追加する必要はありません。

注意:

拡張前に作成されたカスタム・データ・ソース(LEASINGデータ・ソースなど)が、この画面の前に表示されます。「データソース」行を確認し、「次へ」をクリックします。データ・ソースのテスト画面で、その有効性が検証されます。「次へ」をクリックします。

タスク4   拡張構成の選択

トポロジのドメイン構成を完了するには、「拡張構成」画面で追加オプションを選択せずに、「次へ」をクリックします。B2Bアプリケーションと必要なアーティファクトが、自動的に、既存のSOAサーバーにターゲット指定されます。

タスク5   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

「ドメイン更新」をクリックするまで、ドメインの作成は開始されません。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

タスク6   ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

- ドメインの場所

- 管理サーバーURL

どちらの項目も後で必要になるため、メモしておく必要があります。ドメインの場所は、管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、URLは管理サーバーへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

タスク7   管理サーバーの起動

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

18.5 B2B Suiteコンポーネントの起動

構成の変更および起動スクリプトを有効にするには、B2Bが追加されたWLS_SOAサーバーを再起動する必要があります。B2Bでは既存のSOAシステムが拡張されているので、管理サーバーおよびそれぞれのノード・マネージャはSOAHOST1およびSOAHOST2で稼働しています。

追加したB2Bコンポーネントを起動するには、管理対象サーバーを再起動します。

1. 次の場所にあるOracle WebLogic Server管理コンソールにログインします。

http://ADMINVHN:7001/em

この例では、次のようになります。

ADMINVHNを、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」でADMINVHN仮想IPアドレスに割り当てたホスト名に置き換えます。

ポート7001は、管理サーバー・コンソールおよびFusion Middleware Controlで一般的に使用されるポートです。ただし、ドメインを作成したときに構成ウィザードのセッションの終わりに表示された実際のURLを使用する必要があります。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。
「サーバーのサマリー」ページが表示されます。

3. 「制御」タブをクリックします。

4. 表の「サーバー」列から「WLS_SOA1」を選択します。

5. 「停止」をクリックします。停止が完了するのを待ちます(WebLogic Serverコンソールのページを更新して、ステータスが「停止」になったことを確認します)。

6. 「起動」をクリックします。

7. WLS_SOA2について手順2から6を繰り返します。

18.6 トランスポートのためのB2Bインスタンス識別子の更新

ファイル、FTPまたは電子メール・トランスポートを高可用性環境で設定するには、「b2b.HAInstance」プロパティを「true」に設定します。

そのためには、次の手順に従ってください。

1. ドメイン管理で指定したユーザー名とパスワードを使用して、Oracle Enterprise Manager Fusion Middleware Controlにログインします。

2. 画面左上にあるターゲット・ナビゲーション・アイコンをクリックして、「ターゲット・ナビゲーション」ペインを表示します。

3. ナビゲーション・ツリーでSOAを開き、「soa-infra(server_name)」を右クリックし、コンテキスト・メニューから「SOA管理」、「B2Bサーバー・プロパティ」の順に選択します。

「soa-infra (server_name)」が複数存在する場合は、プロパティを一度だけ追加します。

4. 「詳細B2B構成プロパティ」をクリックします。
B2BConfig b2bがすでに選択されているはずです。

5. 「操作」タブをクリックします。

6. 右側のリストの「addProperty」をクリックします。

7. 「キー」フィールドに「b2b.HAInstance」を入力します。

8. 「値」フィールドに、trueと入力します。

このプロパティは、MDSに格納され、クラスタ用に一度だけ作成される必要があります。

9. 「起動」をクリックします。

高可用性プロパティを定義した後は、「属性」タブでそれらを表示できます。プロパティを表示するには、「属性」タブをクリックし、「プロパティ」をクリックします。「値」表の「要素」ノードを開いて、プロパティの名前と値を確認します。

18.7 拡張したドメイン用のWeb層の構成

次の項では、Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをルーティングする方法について説明します。

- 拡張したドメイン用のOracle Traffic Directorの構成

- Oracle B2Bに対するOracle HTTP Serverの構成
Oracle HTTP Serverインスタンスの構成ファイルに対して次の変更を行い、Web層のOracle HTTP Serverインスタンスが、Oracle SOA Suiteクラスタ上のOracle B2BソフトウェアにOracle B2Bリクエストを正しくルーティングできるようにします。

18.7.1 拡張したドメイン用のOracle Traffic Directorの構成

このドメインでOracle Traffic Directorを構成した場合、状況によっては、Oracle Traffic Director構成に別のオリジン・サーバー・プール、仮想サーバーまたはルートを追加する必要があります。各Oracle Fusion Middleware製品のOracle Traffic Directorの要件を理解するには、「オリジン・サーバーおよび仮想ホストのサマリー」を参照してください。

オリジン・サーバー・プール、仮想サーバーおよびルートを追加する手順は、「エンタープライズ・デプロイメント用のOracle Traffic Director仮想サーバーの定義」を参照してください。

18.7.2 Oracle B2Bに対するOracle HTTP Serverの構成

Oracle HTTP Serverインスタンスの構成ファイルに対して次の変更を行い、Web層のOracle HTTP Serverインスタンスが、 Oracle SOA Suiteクラスタ上のOracle B2BソフトウェアにOracle B2Bリクエストを正しくルーティングできるようにします。

Oracle HTTP Serverが、Oracle B2BコンソールとOracle B2Bサービスにリクエストをルーティングできるようにするには:

1. WEBHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(ohs1)の構成ディレクトリに変更します。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf

2. 次のディレクティブを、soa_vh.confファイルの<VirtualHost>タグ内に追加します。

# B2B
<Location /b2bconsole>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
</Location>

# B2B
<Location /b2b>
WLSRequest ON
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
</Location>

3. ohs1インスタンスを再起動します。

a. ディレクトリを次の場所に変更します。

cd OHS_DOMAIN_HOME/bin

b. 次のコマンドを入力し、インスタンスを停止して起動します。

./stopComponent.sh ohs1
./startComponent.sh ohs1

4. WEBHOST2にログインして、soa_vh.confファイルを2つ目のOracle HTTP Serverインスタンス(ohs_2)の構成ディレクトリにコピーします。

OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf

5. soa_vh.confファイルを編集して、WEBHOST1への参照をWEBHOST2への参照に変更します。

6. ohs2インスタンスを再起動します。

a. ディレクトリを次の場所に変更します。

cd OHS_DOMAIN_HOME/bin

b. 次のコマンドを入力し、インスタンスを停止して起動します。

./stopComponent.sh ohs2
./startComponent.sh ohs2

18.8 SOA管理者グループへのB2BAdminロールの追加

管理対象サーバーのOracle B2B構成を検証する前に、B2BAdmin管理ロールをエンタープライズ・デプロイメントの管理グループ(SOA Administrators)に追加します。

このタスクを実行するには、「Oracle SOA Suite製品の管理のためのロールの構成」を参照してください。

18.9 ロード・バランサを介したOracle B2Bへのアクセスの検証

次の手順を使用して、ロード・バランサからHTTP Serverインスタンスを経て、Oracle SOA Suite管理対象サーバー上のB2B Suiteコンポーネントに対して行われるルーティングとフェイルオーバーが、適切に機能することを確認します。

1. 次のURLを入力して、ロード・バランサ経由でOracle B2B Consoleにアクセスします。

https://soa.example.com/b2bconsole

2. weblogic_soaユーザーでログインします。図18-1に示す、Oracle B2Bの「パートナ」、「アグリーメント」、「プロファイル」画面が表示されます。

図18-1 Oracle B2Bの「パートナ」、「アグリーメント」、「プロファイル」画面

3. 次のURLを入力して、Oracle B2B Webサービスのエンドポイントにアクセスします。

https://soa.example.com/b2b/services

別のB2Bエンドポイントのテストへのリンクが表示されます。

図18-2 Oracle B2Bサービス

18.10 構成のバックアップ

Oracleのベスト・プラクティスとしては、ドメインの構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。

バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

構成をバックアップする方法の詳細は、「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。

18.11 Oracle B2Bに対する自動サービス移行およびJDBC永続ストアの有効化

エンタープライズ・トポロジでは、Oracle B2Bは、既存のOracle SOA Suite管理対象サーバー上で構成されています。SOA_Clusterに自動サービス移行がすでに構成されている場合、Oracle B2Bソフトウェアは自動サービス移行によってすでに保護されています。

Oracle B2Bが構成されている管理対象サーバーに自動サービス移行が構成されていない場合は、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。

さらに、オプションでOracle B2Bにデータベース・ベースの永続ストアを構成することもできます。詳細は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用」を参照してください。

19 Oracle SOA Suite for Healthcare Integrationを含めるドメインの拡張

次の各項では、Oracle SOA Suite for healthcare integration (Oracle Healthcare)を追加するためのドメイン拡張の手順を説明します。

- Oracle Healthcare用にドメインを拡張する際に使用される変数
この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

- エンタープライズ・デプロイメントでのOracle SOA Suite for Healthcare Integrationについて
Oracle SOA Suite for Healthcare Integrationでは、Oracle SOA Suiteの複数の機能を使用して、医療データを処理するアプリケーションの設計、作成、管理ができます。

- Oracle Healthcareを追加するためのドメイン拡張の前提条件
Oracle Healthcareを含めることでドメインを拡張する前に、Oracle Healthcareに固有の次の重要な前提条件に留意してください。

- エンタープライズ・デプロイメントのOracle Healthcareのインストール
エンタープライズ・デプロイメント用の新規ドメインを構成する準備として、次の各項を参照してOracle Fusion Middleware Infrastructureソフトウェアをインストールします。

- Oracle Healthcareの構成ウィザードの実行
Oracle Healthcareを追加するためにドメインを拡張するには、次の項を参照してください。

- Healthcareコンポーネントの起動
この項では、ドメイン内に構成したOracle Healthcareコンポーネントを起動する方法について説明します。この手順では、Oracle Healthcareが構成されている管理対象サーバーを再起動する必要があります。これにより、構成変更および起動スクリプトが適切に更新され、検証されます。既存のドメインを拡張するため、管理サーバーおよびそれぞれのノード・マネージャは、両方のアプリケーション・サーバー・ホストですでに稼働しています。

- B2Bインスタンス識別子およびMLLP高可用性モードの更新
ファイル、FTPまたは電子メール・トランスポートを高可用性環境で設定するには、b2b.HAInstanceプロパティをtrueに設定します。

- 最適なロード・バランシングのための接続ファクトリ・アフィニティの無効化
Oracle Healthcareサーバーに影響を与えるすべての負荷を避けるために、次の手順を実行することをお薦めします。

- 拡張したドメイン用のWeb層の構成
次の項では、Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをルーティングする方法について説明します。

- SOA管理者グループへのB2BAdminロールの追加
管理対象サーバーのOracle B2B構成を検証する前に、B2BAdmin管理ロールをエンタープライズ・デプロイメントの管理グループ(SOA Administrators)に追加します。

- ロード・バランサを介したOracle Healthcareへのアクセスの検証
次の手順を使用して、ロード・バランサからHTTP Serverインスタンスを経て、Oracle SOA Suite管理対象サーバー上のOracle Healthcareコンポーネントに対して行われるルーティングとフェイルオーバーが、適切に機能することを確認します。

- 構成のバックアップ
Oracleのベスト・プラクティスとしては、ドメインの構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。

- Oracle Healthcareに対する自動サービス移行の有効化
エンタープライズ・トポロジでは、Oracle Healthcareは、既存のOracle SOA Suite管理対象サーバー上で構成されています。SOA_Clusterに自動サービス移行がすでに構成されている場合、Oracle Healthcareソフトウェアは自動サービス移行によってすでに保護されています。

親トピック: エンタープライズ・デプロイメントの構成

19.1 Oracle Healthcare用にドメインを拡張する際に使用される変数

この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

いくつかのディレクトリ変数の値については、「このガイドで使用するファイル・システムとディレクトリ変数」に定義されています。

- ORACLE_HOME

- ASERVER_HOME

- MSERVER_HOME

- OHS_DOMAIN_HOME

- JAVA_HOME

さらに、「エンタープライズ・トポロジによって必要とされる物理および仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスを参照することになります。

- ADMINVHN

この章のアクションは、次のホスト・コンピュータで実行します。

- SOAHOST1

- SOAHOST2

- WEBHOST1

- WEBHOST2

19.2 エンタープライズ・デプロイメントでのOracle SOA Suite for Healthcare Integrationについて

Oracle SOA Suite for Healthcare Integrationでは、Oracle SOA Suiteの複数の機能を使用して、医療データを処理するアプリケーションの設計、作成、管理ができます。

Oracle SOA Suite for Healthcare Integrationの詳細は、Oracle SOA Suite Healthcare Integrationユーザーズ・ガイドのOracle SOA Suite for Healthcare Integrationの概要に関する項を参照してください。

エンタープライズ・デプロイメントでOracle SOA Suite for Healthcare Integrationを構成する場合、Healthcareを独自のドメイン内に構成することが推奨されます。この推奨事項の詳細は、Oracle SOA Suite Healthcare Integrationユーザーズ・ガイドのB2BおよびHealthcareドメイン・トポロジのベスト・プラクティスに関する項を参照してください。

一般に、Oracle SOA Suite for Healthcare Integrationに単一のドメイン、およびOracle B2Bに別個のドメインを構成します。これらのドメイン・トポロジは両方とも、このエンタープライズ・デプロイメント・ガイドで説明およびサポートされています。詳細は、次を参照してください。

- プライマリOracle SOA Suiteエンタープライズ・トポロジの実装のフロー・チャートとロードマップ

- 独自のOracle SOA Suiteエンタープライズ・トポロジの構築

19.3 Oracle Healthcareを追加するためのドメイン拡張の前提条件

Oracle Healthcareを含めることでドメインを拡張する前に、Oracle Healthcareに固有の次の重要な前提条件に留意してください。

- Oracle Healthcareソフトウェアを含めることで既存のドメインを拡張できるのは、Oracle SOA Suiteドメイン構成テンプレートを使用してドメインが構成された場合のみです。Oracle Healthcareを含めることでOracle BPM、Oracle BAMまたはOracle OSBドメインを拡張することはできません。
この章では、「Oracle SOA Suiteを含めるドメインの拡張」の各手順が実行されていることを前提としています。

- Oracle SOA InfrastructureスキーマをOracle SOA Suiteのインストールおよび構成の一部としてインストールした場合は、Healthcare Integration RCUカスタム変数をYESに設定する必要があります。Healthcare Integrationカスタム変数の値として「YES」を入力すると、RCUは、データベース内に追加のマテリアライズド・ビューを作成します。Healthcare Integrationユーザー・インタフェースには、このビューが必要になります。
「NO」を入力した場合は、次に示すSQLスクリプトをデータベースで実行することで、これに該当する追加のスキーマ構成タスクを後から実行できます。このスクリプトは、B2Bインストール・タイプにHealthcareを選択すると、Oracle Fusion MiddlewareのOracleホームにインストールされます。

ORACLE_HOME/soa/common/sql/soainfra/sql/oracle/b2b_mv.sql

さらに、既存のデプロイメントが、ドメインを拡張するための次の一般的な前提条件を満たしていることを確認します

- インストールのバックアップ - 既存のFusion Middlewareホームとドメインをバックアップしていない場合は、今すぐバックアップすることをお薦めします。
既存のFusion Middlewareホームとドメインをバックアップするには、「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。

- 共有記憶域のOracleホームにInfrastructureおよびSOAソフトウェア・バイナリがインストールされ、SOAHOST1とSOAHOST2から使用できることを確認します。

- 前の章の説明のとおり、SOAシステムを実行するために、ノード・マネージャ、管理サーバー、SOAサーバーおよびWSMサーバーがすでに構成されていること。必要に応じて、サーバー移行、トランザクション・ログ、一貫性など、SOAシステムのその他のすべての構成手順が完了していること。

- 各ホスト・コンピュータのシステム・クロックが同期していることを確認します(まだ、確認していない場合)。これは、各クラスタ内のホストで可能なかぎり同時にdateコマンドを実行することで行えます。
また、そのために使用できるサードパーティおよびオープンソースのユーティリティもあります。

19.4 エンタープライズ・デプロイメントのOracle Healthcareのインストール

エンタープライズ・デプロイメント用の新規ドメインを構成する準備として、次の各項を参照してOracle Fusion Middleware Infrastructureソフトウェアをインストールします。

- SOAHOST1でのOracle B2BおよびHealthcareインストーラの起動

- Oracle Healthcareインストール用のインストール画面のナビゲート

- B2BまたはHealthcareインストールの確認

19.4.1 SOAHOST1でのOracle B2BおよびHealthcareインストーラの起動

インストール・プログラムを起動するには、次の手順を実行します。

1. SOAHOST1にログインします。

2. インストール・プログラムがダウンロードされたディレクトリに移動します。

3. 次の例に示すとおり、ご使用のシステムのJDKディレクトリからjava実行可能ファイルを実行し、インストール・プログラムを起動します。

JAVA_HOME/bin/java -d64 -jar distribution_file_name.jar

この例では、次のようになります。

- JAVA_HOMEを、ご使用のシステムの環境変数または実際のJDKの場所に置き換えます。

- distribution_file_nameを、ディストリビューションJARファイルの実際の名前に置き換えます。
ディストリビューションをOracle Technology Network (OTN)からダウンロードする場合、通常、JARファイルはダウンロード可能なZIPファイル内にパッケージされています。

初期Infrastructureドメインに必要なソフトウェアをインストールする場合は、インストールするディストリビューションはfmw_12.2.1.1.0_b2bhealthcare.jarです。

各ディストリビューションの実際のファイル名の詳細は、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」を参照してください。

インストール・プログラムが表示されると、インストールを開始する準備ができています。各インストール・プログラム画面の説明については、「インストール画面のナビゲート」を参照してください。

19.4.2 Oracle Healthcareインストール用のインストール画面のナビゲート

表18-1は、インストール・プログラムの各画面の説明です。

表19-1 Oracle B2BおよびHealthcareのインストール画面

画面

説明

インストール・インベントリの設定

この画面は、UNIXオペレーティング・システムで、このホストに初めてOracle製品をインストールする場合に表示されます。中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名には、中央インベントリの場所への書込み権限があることを確認してください。

中央インベントリの詳細は、Oracle Universal InstallerによるソフトウェアのインストールでOracle中央インベントリの理解に関する項を参照してください。

自動更新

この画面では、使用可能なパッチを探してMy Oracle Supportを自動的に検索するか、組織にすでにダウンロードしたパッチを探してローカル・ディレクトリを自動的に検索します。

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middlewareのインストールのプランニングでインストールと構成のディレクトリの選択に関する項を参照してください。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

- 「Healthcare」を選択します

注意: このドキュメントのトポロジには、例は含まれていません。例を本番環境にインストールしないことを強くお薦めします。

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを確認します。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。レスポンス・ファイルは、今後、サイレント・インストールを実行する場合に使用できます。

サイレント・インストールやコマンド行インストールの詳細は、Oracle Universal Installerによるソフトウェアのインストールでサイレント・モードにおけるOracle Universal Installerの使用方法に関する項を参照してください。

「インストール」をクリックしてインストールを開始します。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

進捗バーが100%完了になった後で、「次へ」をクリックします。

インストール完了

この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

19.4.3 B2BまたはHealthcareインストールの確認

インストールの完了後、次のタスクを正常に実行することでインストールを検証できます。

- インストール・ログ・ファイルの確認

- ディレクトリ構造のチェック

- Oracleホームの内容の表示

19.4.3.1 インストール・ログ・ファイルの確認

インストール・ログ・ファイルの内容を確認し、何も問題が発生していないことを確認します。ログ・ファイルの説明とその場所の詳細は、Oracle Universal Installerを使用したソフトウェアのインストールのインストール・ログ・ファイルの理解に関する項を参照してください。

19.4.3.2 ディレクトリ構造のチェック

インストールの内容は、インストール中に選択したオプションによって異なります。

Oracle Healthcareを追加すると、次のディレクトリとサブディレクトリが追加されます。

ls  /u01/oracle/products/fmw/soa/soa/thirdparty/edifecs/

Common
STANDARDS
XEngine

インストール後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解の「Oracle Fusion Middlewareの主要ディレクトリとは」を参照してください。

19.4.3.3 Oracleホームの内容の表示

Oracleホームの内容を、viewInventoryスクリプトを使用して表示することもできます。詳細は、Oracle Universal Installerを使用したソフトウェアのインストールのOracleホームの内容の表示に関する項を参照してください。

19.5 Oracle Healthcareの構成ウィザードの実行

Oracle Healthcareを追加するためにドメインを拡張するには、次の項を参照してください。

- 構成ウィザードの起動

- Oracle Healthcareの構成ウィザード画面のナビゲート

19.5.1 構成ウィザードの起動

注意:

ドメインで起動スクリプトに直接カスタマイズを追加した場合、それらのカスタマイズは構成ウィザードによって上書きされます。ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverrides.shという名前のファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のjavaコマンド行オプションの指定、追加の環境変数の指定などを行うように構成できます。このファイルに追加したカスタマイズは、ドメインのアップグレード操作時に保持され、packコマンドとunpackコマンドの使用時にリモート・サーバーに継承されます。

構成ウィザードを起動する手順は次のとおりです。

1. WebLogic Serverコンソールで、このドメイン拡張によって変更されるすべての管理対象サーバーを停止します。影響を受けない管理対象サーバーは、オンラインのままにすることができます。

注意:
Oracle Healthcareコンポーネントのこの特定のドメイン拡張では、WLS_SOAn管理対象サーバーを変更します。これらの管理対象サーバーを確実に停止します。

2. 管理対象サーバーのステータスを確認してから、管理サーバーを停止します。

詳細は、「SOAHOST1での構成ウィザードの起動」でノード・マネージャを使用して管理サーバーを停止する手順を参照してください。

3. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

cd ORACLE_HOME/oracle_common/common/bin
./config.sh

19.5.2 Oracle Healthcareの構成ウィザード画面のナビゲート

この項の手順に従って、Oracle Healthcare用にドメインを拡張します。

注意:

この項で説明する手順を使用して、既存のドメインを拡張することもできます。この手順の説明では要件が満たされない場合は、その要件に応じた選択を行うか、サポート・ドキュメントで追加の詳細を参照してください。

ドメインを作成して構成するためのタスクは次のとおりです。

- タスク1「ドメイン・タイプとドメイン・ホームの場所の選択」

- タスク2「構成テンプレートの選択」

- タスク3「データ・ソース構成タイプの指定」

- タスク4「拡張構成の選択」

- タスク5「構成仕様の確認とドメインの構成」

- タスク6「ドメイン・ホームと管理サーバーのURLの書込み」

- タスク7「管理サーバーの起動」

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください

ヒント:

この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

- Oracle SOA Suite for healthcare integration — 12.2.1.1.0 [soa]
このテンプレートを選択すると、次が依存関係として自動的に選択されます。

Oracle B2B — 12.2.1.1.0 [soa]

また、次の追加のテンプレートも、初期ドメインの作成と初期ドメインのSOAへの拡張に使用されているため、すでに選択されているはずです。

- Basic Weblogic Server Domain - 12.2.1.1.0 [wlserver]

- Oracle SOA Suite 12.2.1.1.0 [soa]

- Oracle Enterprise Manager - 12.2.1.1.0 [em]

- Oracle WSM Policy Manager - 12.2.1.1.0 [oracle_common]

- Oracle JRF - 12.2.1.1.0 [oracle_common]

- WebLogic Coherenceクラスタの拡張 - 12.2.1.1.0 [wlserver]

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のテンプレートに関する項を参照してください。

タスク3   データ・ソース構成タイプの指定

Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。Oracle HealthcareではSOAに既存のデータ・ソースが使用され、ドメインに新しいデータ・ソースを追加する必要はありません。

注意:

拡張前に作成されたカスタム・データ・ソース(LEASINGデータ・ソースなど)が、この画面の前に表示されます。「データソース」行を確認し、「次へ」をクリックします。データ・ソースのテスト画面で、その有効性が検証されます。「次へ」をクリックします。

タスク4   拡張構成の選択

トポロジのドメイン構成を完了するには、「拡張構成」画面で追加オプションを選択せずに、「次へ」をクリックします。Oracle Healthcareアプリケーションと必要なアーティファクトが、自動的に、既存のSOAサーバーにターゲット指定されます

タスク5   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

「ドメイン更新」をクリックするまで、ドメインの作成は開始されません。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

タスク6   ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

- ドメインの場所

- 管理サーバーURL

どちらの項目も後で必要になるため、メモしておく必要があります。ドメインの場所は、管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、URLは管理サーバーへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

タスク7   管理サーバーの起動

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

19.6 Healthcareコンポーネントの起動

この項では、ドメイン内に構成したOracle Healthcareコンポーネントを起動する方法について説明します。この手順では、Oracle Healthcareが構成されている管理対象サーバーを再起動する必要があります。これにより、構成変更および起動スクリプトが適切に更新され、検証されます。既存のドメインを拡張するため、管理サーバーおよびそれぞれのノード・マネージャは、両方のアプリケーション・サーバー・ホストですでに稼働しています。

Healthcareコンポーネントを起動するには、管理対象サーバーを再起動します。

1. 次の場所にあるOracle WebLogic Server管理コンソールにログインします。
http://ADMINVHN:7001/em

この例では、次のようになります。

- ADMINVHNを、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」でADMINVHN仮想IPアドレスに割り当てたホスト名に置き換えます。

- ポート7001は、管理サーバー・コンソールおよびFusion Middleware Controlで一般的に使用されるポートです。ただし、ドメインを作成したときに構成ウィザードのセッションの終わりに表示された実際のURLを使用する必要があります。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。
「サーバーのサマリー」ページが表示されます。

3. 「制御」タブをクリックします。

4. 表の「サーバー」列から「WLS_SOA1」を選択します。

5. 「停止」をクリックします。
停止が完了するまで待機します。「コンソール」ページをリフレッシュして、停止ステータスを確認します。

6. 表の「サーバー」列から「WLS_SOA1」を選択します。

7. 「起動」をクリックします。

8. WLS_SOA2管理対象サーバーについて手順4から7を繰り返します。

19.7 B2Bインスタンス識別子およびMLLP高可用性モードの更新

ファイル、FTPまたは電子メール・トランスポートを高可用性環境で設定するには、b2b.HAInstanceプロパティをtrueに設定します。

1. ドメイン管理で指定したユーザー名とパスワードを使用して、Oracle Enterprise Manager Fusion Middleware Controlにログインします。

2. 表示されていない場合は、ページの左上にある「ターゲット・ナビゲーション」アイコンをクリックして、「ターゲット・ナビゲーション」ペインを表示します。

3. SOAを開き、soa-infra(server_name)を右クリックして、「SOA管理」、「B2Bサーバー・プロパティ」の順に選択します。
soa-infraインスタンスが複数存在する場合は、プロパティを1回だけ追加します。

4. 詳細B2B構成プロパティ...をクリックします。
このリンクをクリックすると、Fusion Middleware ControlでMBeanブラウザが表示され、特定のB2B MBeanプロパティを変更できます。

5. 「b2b」MBeanをクリックします。
B2BConfig b2bが、すでに選択されているはずです。

6. 「操作」タブをクリックします。

7. 操作リストのaddPropertyをクリックします。

8. 「キー」フィールドにb2b.HAInstanceと入力します。

9. 「値」フィールドに、trueと入力します。
このプロパティはMDSリポジトリに格納され、クラスタ用に1回だけ作成される必要があります。

10. 「起動」をクリックします。
プロパティが追加されたことを確認するメッセージが表示されます。

11. 「戻る」をクリックしてB2Bプロパティ・リストに戻ります。

12. 「操作」タブをクリックします。

13. addPropertyをクリックして、別のプロパティを追加します。

14. 「キー」フィールドにb2b.MLLP_HA_Modeと入力します。

15. 「値」フィールドに、trueと入力します。

16. 「起動」をクリックします。

高可用性プロパティを定義した後は、「属性」タブでそれらを表示できます。プロパティを表示するには、「属性」タブをクリックし、「プロパティ」をクリックします。「値」表の「要素」ノードを開いて、プロパティの名前と値を確認します。

19.8 最適なロード・バランシングのための接続ファクトリ・アフィニティの無効化

Oracle Healthcareサーバーに影響を与えるすべての負荷を避けるために、次の手順を実行することをお薦めします。

1. ドメイン管理で指定したユーザー名とパスワードを使用して、WebLogic Administration Console Controlにログインします。

2. 左のナビゲーション・ツリーで「サービス」、「メッセージング」の順に開きます。

3. 「JMSモジュール」をクリックします。

4. 表でSOAJMSModuleをクリックします。

5. B2BEventQueueConnectionFactoryをクリックします。

6. 「ロード・バランシング」タブをクリックします。

7. 「チェンジ・センター」メニューで「ロックして編集」をクリックします。

8. 「サーバー・アフィニティの有効化」チェック・ボックスを選択解除します。

9. 「保存」をクリックして、「変更をアクティブ化します。」をクリックします。

19.9 拡張したドメイン用のWeb層の構成

次の項では、Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをルーティングする方法について説明します。

- 拡張したドメイン用のOracle Traffic Directorの構成

- Oracle Healthcare用のOracle HTTP Serverの構成
Oracle HTTP Serverインスタンスの構成ファイルに対して次の変更を行い、Web層のOracle HTTP Serverインスタンスが、Oracle HealthcareリクエストをOracle SOA Suiteクラスタに正しくルーティングできるようにします。

19.9.1 拡張したドメイン用のOracle Traffic Directorの構成

このドメインでOracle Traffic Directorを構成した場合、状況によっては、Oracle Traffic Director構成に別のオリジン・サーバー・プール、仮想サーバーまたはルートを追加する必要があります。各Oracle Fusion Middleware製品のOracle Traffic Directorの要件を理解するには、「オリジン・サーバーおよび仮想ホストのサマリー」を参照してください。

オリジン・サーバー・プール、仮想サーバーおよびルートを追加する手順は、「エンタープライズ・デプロイメント用のOracle Traffic Director仮想サーバーの定義」を参照してください。

19.9.2 Oracle Healthcare用のOracle HTTP Serverの構成

Oracle HTTP Serverインスタンスの構成ファイルに対して次の変更を行い、Web層のOracle HTTP Serverインスタンスが、Oracle HealthcareリクエストをOracle SOA Suiteクラスタに正しくルーティングできるようにします。

Oracle HTTP ServerがOracle Healthcareにリクエストをルーティングできるようにする手順:

1. WEBHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(ohs1)の構成ディレクトリに変更します。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf

2. 次のディレクティブを、soa_vh.confファイルの<VirtualHost>タグ内に追加します。

<Location /healthcare>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

3. 次のディレクティブでsoainternal_vh.confファイルを更新します。

<Location /healthcare>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1:8001,SOAHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

4. ohs1インスタンスを再起動します。

a. ディレクトリを次の場所に変更します。

cd OHS_DOMAIN_HOME/bin

b. 次のコマンドを入力し、インスタンスを停止して起動します。

./stopComponent.sh ohs1
./startComponent.sh ohs1

5. WEBHOST2にログインして、soa_vh.confファイルとsoainternal_vh.confファイルを2つ目のOracle HTTP Serverインスタンス(ohs_2)の構成ディレクトリにコピーします。

OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf

6. soa_vh.confファイルとsoainternal_vh.confファイルを編集して、WEBHOST1への参照をWEBHOST2への参照に変更します。

7. ohs2インスタンスを再起動します。

a. ディレクトリを次の場所に変更します。

cd OHS_DOMAIN_HOME/bin

b. 次のコマンドを入力し、インスタンスを停止して起動します。

./stopComponent.sh ohs2
./startComponent.sh ohs2

19.10 SOA管理者グループへのB2BAdminロールの追加

管理対象サーバーのOracle B2B構成を検証する前に、B2BAdmin管理ロールをエンタープライズ・デプロイメントの管理グループ(SOA Administrators)に追加します。

このタスクを実行するには、「Oracle SOA Suite製品の管理のためのロールの構成」を参照してください。

19.11 ロード・バランサを介したOracle Healthcareへのアクセスの検証

次の手順を使用して、ロード・バランサからHTTP Serverインスタンスを経て、Oracle SOA Suite管理対象サーバー上のOracle Healthcareコンポーネントに対して行われるルーティングとフェイルオーバーが、適切に機能することを確認します。

注意:

前にOracle SOA Suite管理対象サーバーを構成した場合、WebLogicプラグインが有効化されているはずです。このタスクを実行していない場合は、「WebLogicプロキシ・プラグインの構成」を参照してください。

1. ロード・バランサを介してOracle Healthcareユーザー・インタフェースにアクセスするには、次のURLを入力します。

https://soa.example.com/healthcare

Oracle Healthcareユーザー・インタフェース画面が表示されます。

2. weblogic_soaユーザーでログインします。

詳細は、Oracle SOA Suite Healthcare Integrationユーザーズ・ガイドの“Oracle SOA Suite for Healthcare Integrationユーザー・インタフェースの使用方法に関する項を参照してください。

19.12 構成のバックアップ

Oracleのベスト・プラクティスとしては、ドメインの構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。

バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

構成をバックアップする方法の詳細は、「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。

19.13 Oracle Healthcareに対する自動サービス移行の有効化

エンタープライズ・トポロジでは、Oracle Healthcareは、既存のOracle SOA Suite管理対象サーバー上で構成されています。SOA_Clusterに自動サービス移行がすでに構成されている場合、Oracle Healthcareソフトウェアは自動サービス移行によってすでに保護されています。

Oracle Healthcareが構成されている管理対象サーバーに自動サービス移行が構成されていない場合は、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。

可用性を高めるために、データベース内にトランザクション・ログ・ストアとJMSストアを構成することもできます。詳細は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用」を参照してください。

20 エンタープライズ・デプロイメントでのOracle Managed File Transferの構成

次の各項では、エンタープライズ・デプロイメントにOracle Managed File Transferを追加する手順について説明します。

- Oracle Managed File Transferについて
Oracle Managed File Transfer (MFT)は、標準ベースのファイル・ゲートウェイを提供します。転送の優先付け、ファイルの暗号化、スケジューリング、埋込みFTPサーバーと埋込みsFTPサーバーなどの機能を備えたWebベースのデザインタイム・コンソールで、ファイル転送の設計、デプロイメントおよび監視を実行できます。

- エンタープライズ・デプロイメントでOracle Traffic Directorの構成時に使用される変数
Oracle Traffic Diretor参照をインストールして構成する手順では、環境内で使用される実際の値に置換できる一連の変数を使用します。

- システム・クロックの同期
Oracle SOA Suiteを含むようにドメインを拡張する前に、各ホスト・コンピュータのシステム・クロックが同期していることを確認します。これは、各クラスタ内のホストで可能なかぎり同時にdateコマンドを実行することで行えます。

- Managed File Transferドメインを作成するための前提条件
Managed File Transferドメインを作成する前に、既存のデプロイメントが次の前提条件を満たしていることを確認します。

- エンタープライズ・デプロイメント用のソフトウェアのインストール
次の各項では、エンタープライズ・デプロイメント用のソフトウェアのインストール方法を説明します。

- Managed File Transferデータベース・スキーマの作成
Managed File Transferドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに必要なスキーマをインストールする必要があります。

- エンタープライズ・デプロイメント用のManaged File Transferドメインの作成
Fusion Middleware構成ウィザードを使用して別個のManaged File Transferドメインを作成します。

- Managed File Transferドメイン用のノード・マネージャの構成
Managed File Transferドメインでは、ノード・マネージャで同じホスト上の複数のドメインを制御できるように、ホストごとのノード・マネージャを使用します。

- ドメイン・ディレクトリの構成とMFTHOST1上のサーバーの起動
ドメインを作成し、ノード・マネージャを構成したら、MFTHOST1で追加のドメイン・ディレクトリを構成し、管理サーバーおよび管理対象サーバーを起動できます。

- ドメインの伝播とMFTHOST2上のサーバーの起動
MFTHOST1で管理サーバーとWLS_WSM1管理対象サーバーを起動して検証したら、MFTHOST2で次のタスクを実行できます。

- uploadおよびstageディレクトリの絶対パスへの変更
ドメインを構成し、すべてのホスト上の管理対象サーバーのドメイン・ディレクトリにそのドメインを解凍した後、新しい管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

- Managed File TransferのSSH-FTPサービスの構成および有効化
Oracle Managed File Transferのエンタープライズ・デプロイメント・トポロジは、ファイル転送用のSecure File Transfer Protocol (SFTP)に基づきます。SFTPは、別個のプロトコルで、SSHとともにパッケージされ、FTPのように動作しますが、セキュアな接続を使用します。

- Managed File Transfer用のOracle Traffic Directorの構成
Oracle Traffic Directorは、Web層のOracle HTTP Serverのかわりとして使用できます。Oracle HTTP Serverと同様に、これはHTTPリクエストをフロントエンド・ロード・バランサからアプリケーション層のWebLogic管理対象サーバーにルーティングできます。ただし、TCPロード・バランシングおよびフェイルオーバーを提供できるのは、Oracle Traffic Directorのみです。そのため、Oracle Traffic Directorは、セキュアなFTPリクエストのルーティングのためにTCPを必要とするOracle Managed File Transferによって必要とされます。

- 新しいLDAPオーセンティケータの作成とManaged File Transferのユーザーのプロビジョニング
Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダ(DefaultAuthenticator)を使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用することをお薦めします。

- Managed File Transferに対する自動サービス移行およびJDBC永続ストアの有効化
ソフトウェアが高可用性を実現するように構成するには、自動サービス移行でOracle Managed File Transfer管理対象サーバーを構成します。

上位トピック: 「エンタープライズ・ドメインの構成」

20.1 Oracle Managed File Transferについて

Oracle Managed File Transfer (MFT)は、標準ベースのファイル・ゲートウェイを提供します。転送の優先付け、ファイルの暗号化、スケジューリング、埋込みFTPサーバーと埋込みsFTPサーバーなどの機能を備えたWebベースのデザインタイム・コンソールで、ファイル転送の設計、デプロイメントおよび監視を実行できます。

Oracle MFTの詳細は、MFTのユーザーズ・ガイドのOracle Managed File Transferの理解に関する項を参照してください。

- エンタープライズ・デプロイメントでのManaged File Transferについて

- Managed File Transferドメインの特徴

20.1.1 エンタープライズ・デプロイメントでのManaged File Transferについて

Managed File Transferは、Oracle SOA Suite、Oracle Service Bus、Business Activity Monitoringなどの他のコンポーネントとは別に、独自のドメイン内で実行されます。通常、単一の構成ウィザード・セッションで、ドメインを作成してManaged File Transferの管理対象サーバーを構成します。

Managed File Transferは、Oracle Web Services Manager (OWSM)を使用して、Managed File Transferアプリケーションと同じサーバー上でOWSMサービスを実行します。

Web層を構成する場合、Managed File Transferでは、Managed File TransferのSFTPリクエストのTCP通信をロード・バランシングするために、Oracle Traffic Directorが必要です。

Managed File Transferドメインは、他のFMWコンポーネントと同じホスト上に構成できます。このため、ホストごとのノード・マネージャ構成を使用することをお薦めします。この構成で、単一のノード・マネージャは、同じマシン上の異なるドメインを制御できます。詳細は、「エンタープライズ・デプロイメントに対するホストごとのノード・マネージャの構成」を参照してください。

20.1.2 Managed File Transferドメインの特徴

次の表に、作成するドメインの主な特徴を示します。これらの特徴を確認して理解することで、ドメインの構成手順の目的やコンテキストに対する理解が深まります。

これらの特徴の多くは、「標準的なエンタープライズ・デプロイメントの理解」で詳しく説明しています。

ドメインの特徴

詳細情報

管理サーバーに別個の仮想IP (VIP)アドレスを使用。

管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成

ドメイン内の管理サーバーと管理対象サーバーに別個のドメイン・ディレクトリを使用。

管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成

Managed File Transferと同じサーバーにデプロイされるOracle Web Services Managerを使用

アプリケーション層でのOracle Web Services Managerの使用

Web層からSFTリクエストをルーティングするためにOracle Traffic Directorが必要。

エンタープライズ・デプロイメントでのOracle Traffic Directorについて

単一の構成ウィザード・セッションを使用して、Managed File Transfer管理対象サーバーでInfrastructureおよびManaged File Transferソフトウェアを構成。ドメインは、後でOracle Traffic Directorを含めるように拡張されます。

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

ホストごとのノード・マネージャ構成を使用します。

標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について

別途インストールされたLDAPベースの認証プロバイダが必要。

OPSSおよび認証ストアと認可ストアへのリクエストの理解

20.2 エンタープライズ・デプロイメントでOracle Traffic Directorの構成時に使用される変数

Oracle Traffic Diretor参照をインストールして構成する手順では、環境内で使用される実際の値に置換できる一連の変数を使用します。

これらの手順では、次のディレクトリの場所の変数が使用されます。

- WEB_ORACLE_HOME

- ASERVER_HOME

- MSERVER_HOME

- WEB_DOMAIN_HOME

- JAVA_HOME

- NM_HOME

詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

さらに、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」で定義されている次の仮想IP (VIP)アドレスを参照することになります。

- ADMINVHN

この章のアクションは、次のホスト・コンピュータで実行します。

- APPHOST1

- APPHOST2

- WEBHOST1

- WEBHOST2

注意:

この章では、APPHOST1とAPPHOST2は、アプリケーション層ホストのより汎用的な変数を示すことに注意してください。この理由は、作成されるドメインに応じて、ホスト名変数が異なるためです。

たとえば、Oracle SOA Suiteドメイン用にOracle Traffic Directorを構成する場合、APPHOST1はSOAHOST1と同じです。ただし、通常は独自のドメイン内に構成されるOracle Managed File Transferドメイン用にOracle Traffic Directorを構成する場合、APPHOST1はMFTHOST1と同じです。

20.3 システム・クロックの同期

Oracle SOA Suiteを含むようにドメインを拡張する前に、各ホスト・コンピュータのシステム・クロックが同期していることを確認します。これは、各クラスタ内のホストで可能なかぎり同時にdateコマンドを実行することで行えます。

また、そのために使用できるサードパーティおよびオープンソースのユーティリティもあります。

20.4 Managed File Transferドメインを作成するための前提条件

Managed File Transferドメインを作成する前に、既存のデプロイメントが次の前提条件を満たしていることを確認します。

- サポートされているJDKをインストールしたことを確認します。

- Oracle Fusion Middleware Infrastructureソフトウェア・バイナリをインストールした既存のOracleホームが存在する必要があります。これは、Managed File Transferドメイン用の専用のOracleホームである必要があります。Oracleホームは、通常、共有記憶域上にあり、MFTHOST1およびMFTHOST2から使用できます。詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。
Infrastructureドメインを構成するのではなく、Oracle Fusion Middleware Infrastructureソフトウェアのインストールのみを行ってください。

InfrastructureのOracleホームを作成するには、「エンタープライズ・デプロイメントの準備におけるOracle Fusion Middleware Infrastructureのインストール」を参照してください。

- インストールのバックアップ - 既存のFusion Middlewareホームをバックアップしていない場合は、今すぐバックアップすることをお薦めします。
既存のFusion Middlewareホームとドメインをバックアップするには、「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。

- 各ホスト・コンピュータのシステム・クロックが同期していることを確認します(まだ、確認していない場合)。これは、各クラスタ内のホストで可能なかぎり同時にdateコマンドを実行することで行えます。
また、そのために使用できるサードパーティおよびオープンソースのユーティリティもあります。

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

次の各項では、エンタープライズ・デプロイメント用のソフトウェアのインストール方法を説明します。

- MFTHOST1でのManaged File Transferインストーラの起動

- Managed File Transferをインストールする場合のインストール画面のナビゲート

- インストールの確認

20.5.1 MFTHOST1でのManaged File Transferインストーラの起動

インストール・プログラムを起動する手順は次のとおりです。

1. MFTHOST1にログインします。

2. インストール・プログラムがダウンロードされたディレクトリに移動します。

3. 次の例に示すとおり、ご使用のシステムのJDKディレクトリからjava実行可能ファイルを実行し、インストール・プログラムを起動します。

JAVA_HOME/bin/java -d64 -jar Installer File Name

これらの例にあるJDKの場所は、ご使用のシステムの実際のJDKの場所に読み替えてください。

Installer File Nameは、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」にリストされているご使用の製品の実際のインストーラ・ファイルの名前に読み替えてください。

インストール・プログラムが表示されると、インストールを開始する準備ができています。

20.5.2 Managed File Transferをインストールする場合のインストール画面のナビゲート

インストール・プログラムでは次の表に記載された順番で一連の画面が表示されます。

インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。

画面

説明

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面を使用して、使用可能なパッチをMy Oracle Supportで自動的に検索するか、組織のためにすでにダウンロードしたパッチをローカル・ディレクトリで自動的に検索します。

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。このOracleホームには、Oracle Fusion Middleware Infrastructureが含まれている必要があります。

Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middlewareのインストールのプランニングでインストールと構成のディレクトリの選択に関する項を参照してください。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

- 「Managed File Transfer」を選択します

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告メッセージまたはエラー・メッセージが表示された場合は、Oracle Fusion Middleware Infrastructureのインストール計画のシステム環境の検証ロードマップに関する項でいずれかのドキュメントを参照してください。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを確認します。

「インストール」をクリックしてインストールを開始します。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

進捗バーが100%完了になった後で、「次へ」をクリックします。

インストール完了

この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

20.5.3 インストールの確認

インストールの完了後、次のタスクを正常に実行することでインストールを検証できます。

- インストール・ログ・ファイルの確認

- Managed File Transferのディレクトリ構造のチェック

20.5.3.1 インストール・ログ・ファイルの確認

インストール・ログ・ファイルの内容を確認し、何も問題が発生していないことを確認します。ログ・ファイルの説明とその場所の詳細は、Oracle Universal Installerを使用したソフトウェアのインストールのインストール・ログ・ファイルの理解に関する項を参照してください。

20.5.3.2 Managed File Transferのディレクトリ構造のチェック

インストールの内容は、インストール中に選択したオプションによって異なります。

Managed File Transferを追加すると、次のディレクトリおよびサブディレクトリが追加されます。

/u01/oracle/products/fmw

cfgtoollogs
coherence
em
install
inventory
mft
OPatch
oracle_common
oraInst.loc
osb
oui
soa
wlserver

インストール後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解の「Oracle Fusion Middlewareの主要ディレクトリとは」を参照してください。

20.6 Managed File Transferデータベース・スキーマの作成

Managed File Transferドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに必要なスキーマをインストールする必要があります。

- リポジトリ作成ユーティリティ(RCU)の起動

- Managed File Transferスキーマを作成するためのRCU画面のナビゲート

20.6.1 リポジトリ作成ユーティリティ(RCU)の起動

リポジトリ作成ユーティリティ(RCU)を起動するには:

1. 対象のシステムで、ORACLE_HOME/oracle_common/binディレクトリに移動します。

2. 対象のシステムで、JAVA_HOME環境変数に、動作保証されたJDKの場所が設定されていることを確認します。この場所は、binディレクトリより上の階層にする必要があります。たとえば、JDKが/u01/oracle/products/jdkに存在する場合は、次のようになります。

UNIXオペレーティング・システムの場合:

export JAVA_HOME=/u01/oracle/products/jdk

3. RCUを起動します。

UNIXオペレーティング・システムの場合:

./rcu

20.6.2 Managed File Transferスキーマを作成するためのRCU画面のナビゲート

スキーマ作成に必要なタスクは、次のとおりです。

- タスク1「RCUの導入」

- タスク2「スキーマ作成の方法の選択」

- タスク3「データベース接続の詳細の指定」

- タスク4「カスタム接頭辞の指定とスキーマの選択」

- タスク5「スキーマのパスワードの指定」

- タスク6「カスタム変数の指定」

- タスク7「必須スキーマの表領域の検証」

- タスク8「スキーマ作成の実行」

- タスク9「スキーマの作成の検証」

タスク1   RCUの導入

「次へ」をクリックします。

タスク2   スキーマ作成の方法の選択

対象のデータベースに対するDBAアクティビティの実行に必要なパーミッションと権限が付与されている場合は、「システム・ロードおよび製品ロード」を選択します。この手順は、必要な権限が付与されていることを前提としています。

データベースに対するDBAアクティビティの実行に必要なパーミッションまたは権限が付与されていない場合は、この画面で、「システム・ロードに対するスクリプトの準備」を選択する必要があります。このオプションによってSQLスクリプトが生成され、必要なスキーマを作成するためにデータベース管理者が利用できます。リポジトリ作成ユーティリティを使用したスキーマの作成のシステム・ロードおよび製品ロードの理解に関する項を参照してください。

タスク3   データベース接続の詳細の指定

RCUがデータベースに接続できるようにするために、データベース接続の詳細を指定します。

「ホスト名」フィールドに、Oracle RACデータベースのSCANアドレスを入力します。

「DBMS/サービス」詳細を入力します。

「スキーマ所有者」および「スキーマ・パスワード」詳細を入力します。

「次へ」をクリックして先に進み、データベースへの接続が成功したことを確認するダイアログ・ウィンドウで、「OK」をクリックします。

タスク4   カスタム接頭辞の指定とスキーマの選択

このページで、次を行います:

1. 「新規接頭辞の作成」を選択し、Managed File Transferスキーマに使用する接頭辞を入力します。Managed File Transferの新しいドメインを作成するため、一意のスキーマ接頭辞が必要です。

2. スキーマのリストから、「Managed File Transfer」スキーマを選択します。
これにより、次の依存スキーマが自動的に選択されます。

- ユーザー・メッセージング・サービス

- メタデータ・サービス

- Oracle Platform Security Services

- 監査サービス

- 監査サービスへの追加

- 監査サービス・ビューア

- Oracle Enterprise Scheduler

3. 「WebLogicサービス」を選択します。

注意:
WebLogicサービス・スキーマは自動的に選択されないため、必ず手動で選択してください。

カスタム接頭辞は、これらのスキーマを論理的にグループ化して、このドメイン内でのみ使用することを目的としています。複数のドメイン間でのスキーマの共有はサポートされていないため、ドメインごとに固有のスキーマのセットを作成する必要があります。

ヒント:

カスタム接頭辞の詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のカスタム接頭辞の理解に関する項を参照してください。

マルチドメイン環境でスキーマを編成する方法の詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のスキーマ作成の計画に関する項を参照してください。

「次へ」をクリックして先に進み、スキーマ作成の前提条件チェックが成功したことを確認するダイアログ・ウィンドウの「OK」をクリックします。

タスク5   スキーマのパスワードの指定

スキーマのパスワードをデータベースに設定する方法を指定してから、パスワードの指定と確認を行います。

ヒント:

この画面で設定するパスワードは、メモしておく必要があります。このパスワードは、後述するドメイン作成のプロセスで必要になります。

タスク6   カスタム変数の指定

SOAインフラストラクチャ・スキーマのカスタム変数を指定します。

エンタープライズ・デプロイメント・トポロジの場合、Database Profileのカスタム変数としてLARGEを入力し、Oracle Healthcareの使用を予定している場合は、Healthcare Integrationの変数としてYESを入力します。

タスク7   必須スキーマの表領域の検証

「表領域のマップ」画面で情報を確認し、「次へ」をクリックして、デフォルト値を受け入れます。

確認ダイアログ・ボックスで「OK」をクリックします。

タスク8   スキーマ作成の完了

RCU画面の残りの部分を先に進めて、スキーマ作成を完了します。「完了サマリー」画面に到達したら、「閉じる」をクリックしてRCUを終了します。

タスク9   スキーマの作成の検証

スキーマが正常に作成されたことと、データベース接続詳細を確認するためには、SQL*Plusまたは別のユーティリティで、Managed File Transferスキーマ名および指定したパスワードを使用してデータベースに接続します。

例:

./sqlplus

SQL*Plus: Release 11.2.0.4.0 Production on Fri Nov 1 08:44:18 2013

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Enter user-name: FMW12211_MFT
Enter password: mft_schema_password

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

20.7 エンタープライズ・デプロイメント用のManaged File Transferドメインの作成

Fusion Middleware構成ウィザードを使用して別個のManaged File Transferドメインを作成します。

- 構成ウィザードの起動

- ドメインを作成および構成するための構成ウィザード画面のナビゲート
トポロジ用のドメインを作成および構成するには、構成ウィザードを使用します。

20.7.1 構成ウィザードの起動

構成ウィザードを起動する手順は次のとおりです。

1. WebLogic Serverコンソールで、このドメイン拡張によって変更されるすべての管理対象サーバーを停止します。影響を受けない管理対象サーバーは、オンラインのままにすることができます。

2. 管理対象サーバーのステータスを確認してから、管理サーバーを停止します。

3. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

cd ORACLE_HOME/oracle_common/common/bin
./config.sh

20.7.2 ドメインを作成および構成するための構成ウィザード画面のナビゲート

トポロジ用のドメインを作成および構成するには、構成ウィザードを使用します。

注意:

この手順を使用して既存のドメインを拡張できます。この手順の説明では要件が満たされない場合は、その要件に応じた選択を行うか、サポート・ドキュメントで追加の詳細を参照してください。

次の各項では、構成ウィザードの各手順を説明します。

1. ドメイン・タイプおよびドメイン・ホームの場所の選択
ドメイン・ホーム・ディレクトリの場所(Oracleホーム・ディレクトリの外部が最適)を選択する必要があります。

2. Oracle Managed File Transferの構成テンプレートの選択
「テンプレート」画面で、必要なテンプレートを選択します。

3. エンタープライズ・デプロイメント・ドメインのアプリケーション・ホームの場所の選択

4. 管理者アカウントの構成
「管理者アカウント」画面を使用して、ドメインのデフォルトWebLogic管理者アカウント用のユーザー名とパスワードを指定します。

5. エンタープライズ・デプロイメントのドメイン・モードとJDKの指定
「ドメイン・モードおよびJDK」画面を使用して、ドメイン・モードおよびJava Development Kit (JDK)を指定します。

6. エンタープライズ・デプロイメントのデータベース構成タイプの指定
「データベース構成タイプ」画面を使用して、データベースとデータベース・スキーマの詳細を指定します。

7. エンタープライズ・デプロイメントのJDBCコンポーネント・スキーマ情報の指定
「JDBCコンポーネント・スキーマ」画面を使用して、データベース・スキーマの詳細を確認または指定します。

8. GridLink Oracle RACデータベース接続の詳細情報の指定

9. JDBC接続のテスト
「JDBCコンポーネント・スキーマ・テスト」画面を使用してデータ・ソース接続をテストします。

10. ドメインのキーストアの指定

11. エンタープライズ・デプロイメントの拡張構成の選択
「拡張構成」画面を使用して、ドメイン構成を完了します。

12. エンタープライズ・デプロイメントでの管理サーバーのリスニング・アドレスの構成

13. ノード・マネージャ・タイプ(ホストごと)の構成

14. エンタープライズ・デプロイメントでのManaged File Transferの管理対象サーバーの構成

15. エンタープライズ・デプロイメントでのManaged File Transferクラスタの構成

16. クラスタへのManaged File Transferサーバーの割当て

17. エンタープライズ・デプロイメントでのCoherenceクラスタの構成

18. Managed File Transfer用のマシンの作成

19. エンタープライズ・デプロイメントでのマシンへのサーバーの割当て

20. エンタープライズ・デプロイメントでのJMSファイル・ストアの構成

21. 構成の指定内容の確認とドメインの構成
「構成サマリー」画面に、作成しているドメインの詳細な構成情報が表示されます。

22. ドメイン・ホームと管理サーバーURLの記録
「構成に成功しました」画面に、構成したばかりのドメインに関する情報が表示されます。

20.7.2.1 ドメイン・タイプとドメイン・ホームの場所の選択

ドメイン・ホーム・ディレクトリの場所(Oracleホーム・ディレクトリの外部が最適)を選択する必要があります。

ドメイン・ホームの場所は、Oracle Fusion Middlewareの理解のOracle Fusion Middlewareの主要ディレクトリに関する項のディレクトリ構造に従って、Oracleホーム・ディレクトリの外に配置することをお薦めします。このディレクトリ構造は、ソフトウェアのアップグレードや再インストールが必要になった場合に問題が発生しないようにするのに役立ちます。

ドメイン・タイプおよびドメインのホーム・ディレクトリを指定する手順:

1. 「構成タイプ」画面で、「新規ドメインの作成」を選択します。

2. 「ドメインの場所」フィールドで、使用するドメイン・ホーム・ディレクトリを指定します。

この画面上のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。

20.7.2.2 Templates for Oracle Managed File Transferの構成テンプレートの選択

「テンプレート」画面で、必要なテンプレートを選択します。

「テンプレート」画面で、「製品テンプレートを使用してドメインを作成」が選択されていることを確認し、次のテンプレートを選択します。

- Oracle Managed File Transfer - 12.1.1.1.0 [mft]
このテンプレートを選択すると、次の項目が依存関係として自動的に選択されます。

- Oracle B2B Client

- Oracle Enterprise Manager

- Oracle WSM Policy Manager

- Oracle JRF

- WebLogic Coherenceクラスタ拡張

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のテンプレートに関する項を参照してください。

20.7.2.3 エンタープライズ・デプロイメント・ドメインのアプリケーション・ホームの場所の選択

「アプリケーションの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、APPLICATION_HOME変数の値を指定します。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「アプリケーションの場所」に関する項を参照してください。

20.7.2.4 管理者アカウントの構成

「管理者アカウント」画面では、ドメインに対するデフォルトのWebLogic管理者アカウントのユーザー名とパスワードを指定します。

この画面に入力するユーザー名とパスワードは、メモしておいてください。これらの資格証明は、このドメインの管理サーバーの起動とそのサーバーへの接続で、後で必要になります。

20.7.2.5 エンタープライズ・デプロイメントのドメイン・モードとJDKの指定

「ドメイン・モードおよびJDK」画面を使用して、ドメイン・モードおよびJava Development Kit (JDK)を指定します。

「ドメイン・モードおよびJDK」画面では、次の操作を実行します。

- 「ドメイン・モード」フィールドで、「本番」を選択します。

- 「JDK」フィールドで、Oracle HotSpot JDKを選択します。

ヒント:

この画面上のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のドメイン・モードとJDKに関する項を参照してください。

本番モードでは、起動アイデンティティ・ファイルを作成することで、管理サーバーの起動時に必要なユーザー名とパスワードの指定を省略できます。詳細は、「boot.propertiesファイルの作成」を参照してください。

20.7.2.6 エンタープライズ・デプロイメントのデータベース構成タイプの指定

「データベース構成タイプ」画面を使用して、データベースとデータベース・スキーマの詳細を指定します。

「データベース構成タイプ」画面で、「RCUデータ」を選択します。このオプションでは、構成ウィザードに対して、データベースおよびサービス表(STB)スキーマに接続し、ドメインの構成に必要なスキーマのスキーマ情報を自動的に取得するように指示します。

注意:

この画面で「手動構成」を選択した場合は、「JDBCコンポーネント・スキーマ」画面でスキーマのパラメータを手動で入力する必要があります。

「RCUデータ」を選択してから、次の各フィールドに入力します。

フィールド

説明

DBMS/サービス

製品スキーマをインストールするOracle RACデータベースのサービス名を入力します。例:

orcl.example.com

必ずOracle RACデータベース内のすべてのインスタンスの識別に使用される共通サービス名を指定してください。ホスト固有のサービス名は使用しないでください。

ホスト名

Enterprise Deployment Workbookに入力したOracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

ポート

データベースがリスニングするポート番号を入力します。例: 1521。

スキーマ所有者

スキーマ・パスワード

データベースのサービス表スキーマに接続するためのユーザー名とパスワードを入力します。

これは、リポジトリ作成ユーティリティの「スキーマ・パスワード」画面でサービス表コンポーネントに指定されたスキーマのユーザー名およびパスワードです。

デフォルトのユーザー名はprefix_STBであり、この場合prefixはRCUで定義したカスタム接頭辞です。

データベース接続情報の指定を完了したら、「RCU構成の取得」をクリックします。「接続結果ログ」の次の出力は、操作が成功したことを示しています。

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

ヒント:

「RCUデータ」オプションの詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解に関する項を参照してください。

この画面上のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のデータソースのデフォルトに関する項を参照してください。

20.7.2.7 エンタープライズ・デプロイメントのJDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」画面を使用して、データベース・スキーマの詳細を確認または指定します。

前の画面でRCUデータの取得を選択したため、スキーマ表は移入されています。

この時点では、これらの値は単一インスタンスのデータベースに接続するように構成されています。ただし、エンタープライズ・デプロイメントの場合、「エンタープライズ・デプロイメント用のデータベースの準備」の説明のように、可用性の高いReal Application Clusters (RAC)データベースを使用する必要があります。

さらに、各コンポーネント・スキーマでアクティブなGridLinkデータ・ソースを使用することをお薦めします。GridLinkデータ・ソースを使用してRACデータベースに接続する利点の詳細は、高可用性ガイドのデータベースの考慮事項に関する項を参照してください。

1. スキーマ表の最初のヘッダー行にあるチェック・ボックスを選択することですべてのスキーマを選択します。

2. 「GridLinkへ変換」をクリックし、「次へ」をクリックします。

20.7.2.8 GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

要素

説明と推奨値

「SCAN」、「ホスト名」および「ポート」

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドには、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのSCANリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

「FANの有効化」チェック・ボックスが選択され、データベースがFANイベントを受信および処理できることを確認します。

この画面で情報を指定する方法の詳細および適切なSCANアドレスの特定方法については、『高可用性ガイド』のOracle RACでのアクティブなGridLinkデータ・ソースの構成に関する項を参照してください。

また、「ヘルプ」をクリックすると、画面の各フィールドの簡単な説明を表示できます。

20.7.2.9 JDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用してデータ・ソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

デフォルトでは、スキーマの作成時に指定したパスワードが、各スキーマ・コンポーネントのスキーマ・パスワードです。スキーマ・コンポーネントに応じて異なるパスワードを使用する場合は、各行の「スキーマ・パスワード」列に使用するパスワードを入力して、前の画面(JDBCコンポーネント・スキーマ)でそれらを手動で編集します。パスワードを指定した後、パスワードを変更したスキーマに対応するチェック・ボックスを選択し、再度接続をテストします。

ヒント:

この画面上のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のJDBCコンポーネント・スキーマのテストに関する項を参照してください。

20.7.2.10 ドメインのキーストアの指定

構成ウィザードの「キーストア」画面を使用して、ドメインで使用されるキーストアの詳細を指定します。

標準的なエンタープライズ・デプロイメントの場合は、デフォルト値を残すことができます。

詳細は、『構成ウィザードによるWebLogicドメインの作成』のキーストアに関する項を参照してください。

20.7.2.11 エンタープライズ・デプロイメントの拡張構成の選択

「拡張構成」画面を使用して、ドメイン構成を完了します。

「拡張構成」画面で、次を選択します。

- 管理サーバー
管理サーバーのリスニング・アドレスを適切に構成するために必要です。

- ノード・マネージャ
ノード・マネージャを構成するために必要です。

- サーバー・テンプレート、管理対象サーバー、クラスタ、動的サーバー、仮想ターゲットおよびCoherence
MFT管理対象サーバーを構成するために必要です。

- ファイル・ストア
エンタープライズ・デプロイメント・ドメインの永続ファイル・ストアを設定するために必要です。

注意:

構成ウィザードの「拡張構成」画面を使用するときは、次のようにします。

- この画面で前述のオプションのいずれかが使用可能でない場合は、「テンプレート」画面に戻り、このトポロジに必要なテンプレートが選択されていることを確認します。

20.7.2.12 エンタープライズ・デプロイメントでの管理サーバーのリスニング・アドレスの構成

「管理サーバー」画面を使用して、ホストのIPアドレスを選択します。

「管理サーバー」画面で、「リスニング・アドレス」の横にあるドロップダウン・リストを選択し、管理サーバーが存在するホストの名前を選択します。「すべてのローカル・アドレス」を使用しないでください。

管理サーバーにサーバー・グループは指定しないでください。

1. 「サーバー名」フィールドで、デフォルト値(AdminServer. )を維持します

2. 「リスニング・アドレス」フィールドに、「エンタープライズ・デプロイメント用のリソースの取得」で取得し、「エンタープライズ・デプロイメント用のホスト・コンピュータの準備」で有効化したADMINVHNのVIPに対応する仮想ホスト名を入力します。

ADMINVHN仮想ホストを使用する理由の詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。

3. 他のフィールドでは、デフォルト値をそのまま使用します。

特に、管理サーバーにサーバー・グループが割り当てられていないことを確認してください。

20.7.2.13 ノード・マネージャ・タイプ(ホストごと)の構成

「ノード・マネージャ」画面を使用して、構成するノード・マネージャのタイプおよびノード・マネージャ資格証明を選択します。

ノード・マネージャ・タイプとして「手動ノード・マネージャ・セットアップ」を選択します。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のノード・マネージャに関する項を参照してください。

ドメインごとのノード・マネージャおよびホストごとのノード・マネージャの実装の詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

その他の情報は、『Oracle WebLogic Serverノード・マネージャの管理』の複数マシンでのノード・マネージャの構成に関する項を参照してください。

20.7.2.14 エンタープライズ・デプロイメントでのManaged File Transferの管理対象サーバーの構成

構成ウィザードの「管理対象サーバー」画面を使用して、Managed File Transferドメインで必要な管理対象サーバーを作成します。

1. 「追加」ボタンをクリックして、1台の管理対象サーバーを新規作成します。

2. 「サーバー名」列でWLS_MFT1を指定します。

3. 「リスニング・アドレス」列にMFTHOST1を入力します。

MFTHOST1に対応するホスト名を必ず入力して、IPアドレスは使用しないでください。

4. 「リスニング・ポート」列に7500と入力します。

5. 「サーバー・グループ」ドロップダウン・リストで、MFT-MGD-SVRSを選択します。

選択したサーバー・グループによって、Managed File TransferとOracle Web Services Manager (OWSM)ソフトウェアが、管理対象サーバーにターゲット設定されます。

サーバーに対してOracle Web Services Manager (OWSM)ではなくMFTのみを対象とするMFT-MGD-SVRS-ONLYと呼ばれる別のサーバー・グループがあります。これは、通常、Oracle Web Services Manager (OWSM)がMFTサーバーとは異なるサーバーにある場合に使用されます。

サーバー・グループは、定義済アプリケーション・サービス・グループを各定義済サーバー・グループにマップすることにより、Fusion Middlewareアプリケーションおよびサービスを1つ以上のサーバーにターゲット指定します。必要に応じて、特定のアプリケーション・サービス・グループを複数のサーバー・グループにマップできます。特定のサーバー・グループにマップされた任意のアプリケーション・サービスは、そのグループに割り当てられたすべてのサーバーに自動的にターゲット指定されます。詳細は、『ドメイン・テンプレート・リファレンス』のアプリケーション・サービス・グループ、サーバー・グループおよびアプリケーション・サービス・マッピングに関する項を参照してください。

6. 「追加」をクリックし、このプロセスを繰り返して、WLS_MFT2という名前の2つ目の管理対象サーバーを作成します。

「リスニング・アドレス」にMFTHOST2と入力します。「リスニング・ポート」に7500と入力します。最初の管理対象サーバーに適用したものと同じサーバー・グループをWLS_MFT2管理対象サーバーに適用します。

この手順で推奨する管理対象サーバー名(WLS_MFT1およびWLS_MFT2)はこのドキュメント全体で参照します。別の名前を選択した場合は、必要に応じてそれらの名前に置き換えてください。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の管理対象サーバーに関する項を参照してください。

20.7.2.15 エンタープライズ・デプロイメントでのManaged File Transferクラスタの構成

「クラスタ」画面を使用して、新規クラスタを作成します。

1. 「追加」をクリックします。

2. 「クラスタ名」フィールドにMFT_Clusterを指定します。

3. 「クラスタ・アドレス」フィールドは、空白のままにしておきます。

4. 「フロントエンド・ホスト」フィールドにmft.example.comを指定します。

5. 「フロントエンドHTTPポート」に80を指定し、「フロントエンドHTTPSポート」に443を指定します。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項を参照してください。

20.7.2.16 クラスタへのManaged File Transferサーバーの割当て

「サーバーのクラスタへの割当」画面を使用して、管理対象サーバーを新しいクラスタに割り当てます。

1. 「クラスタ」ペインで、管理対象サーバーを割り当てるクラスタ(ここではMFT_Cluster)を選択します。

2. 「サーバー」ペインで、次のいずれかの操作を実行して、WLS_MFT1をMFT_Clusterに割り当てます。

- 「WLS_MFT1」を1回クリックして選択し、右矢印をクリックして「クラスタ」ペインの選択されているクラスタ(MFT_Cluster)の下に移動します。
または

- 「WLS_MFT1」をダブルクリックして、「クラスタ」ペインの選択されているクラスタ(MFT_Cluster)の下に移動します。

3. これらの手順を繰り返して、WLS_MFT2をクラスタに割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのクラスタへの割当」に関する項を参照してください。

20.7.2.17 エンタープライズ・デプロイメントでのCoherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。

「クラスタ・リスニング・ポート」に9991と入力します。

注意:

Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報』のOracle Coherenceに関する項を参照してください。

20.7.2.18 Managed File Transfer用のマシンの作成

「マシン」画面を使用して、ドメイン内に3つの新規マシンを作成します。マシンは、ノード・マネージャでサーバーを起動または停止できるようにするために必要です。

1. 「Unixマシン」タブを選択します。

2. 「追加」ボタンをクリックし、3つの新しいUnixマシンを作成します。

次の表の値を使用して、各マシンの名前およびノード・マネージャ・リスニング・アドレスを定義します。

3. 「ノード・マネージャ・リスニング・ポート」フィールドのポート番号を確認します。

この例に示されているポート番号5556は、このドキュメントの別の例でも引用されることがあります。このポート番号は、必要に応じて各自のポート番号に置換してください。

注意:

追加のドメインがすでに構成されているホスト上にインストールする場合で、ホストごとのノード・マネージャをすでに構成済の場合、この画面で構成されるアドレスおよびポートは、既存のホストごとのノード・マネージャが対象となります。

名前

ノード・マネージャのリスニング・アドレス

ノード・マネージャのリスニング・ポート

MFTHOST1

MFTHOST1ホスト名変数の値。例: MFTHOST1.example.com。

5556

MFTHOST2

MFTHOST2ホスト名変数の値。例: MFTHOST2.example.com。

5556

ADMINHOST

ADMINVHN変数の値を入力します。

5556

ヒント:

画面上のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のマシンに関する項を参照してください。

20.7.2.19 エンタープライズ・デプロイメントでのマシンへのサーバーの割当て

「サーバーのマシンへの割当」画面を使用して、管理サーバーと2つの管理対象サーバーを適切なマシンに割り当てます。

「サーバーのマシンへの割当」画面は、管理対象サーバーのクラスタへの割当て画面に似ています。「マシン」列でターゲット・マシンを選択し、左の列で管理対象サーバーを選択した後、右矢印をクリックしてそのサーバーを適切なマシンに割り当てます。

次のように、サーバーを割り当てます。

- AdminServerをADMINHOSTマシンに割り当てます。

- WLS-MFT1管理対象サーバーをMFTHOST1マシンに割り当てます。

- WLS-MFT2管理対象サーバーをMFTHOST2マシンに割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのマシンへの割当」に関する項を参照してください。

20.7.2.20 エンタープライズ・デプロイメントでのJMSファイル・ストアの構成

エンタープライズ・デプロイメントのドメインを構成する場合、JMSファイル・ストアの適切な場所を選択する必要があります。

「JMSファイル・ストア」画面の「ディレクトリ」列に次の場所を入力します。

ORACLE_RUNTIME/domain_name/cluster_name

「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、ORACLE_RUNTIMEを変数の実際の値に置き換えます。

domain_nameを作成しているドメインの名前に置き換えます。

cluster_nameをこのドメイン用に構成したクラスタの名前に置き換えます。

20.7.2.21 構成の指定内容の確認とドメインの構成

「構成サマリー」画面に、作成しているドメインの詳細な構成情報が表示されます。

画面上の各項目を検討し、情報が正しいことを確認します。変更するには、「戻る」ボタンをクリックするか、ナビゲーション・ペインの画面を選択していずれかの画面に戻ります。ドメインの作成は、「作成」をクリックするまで開始されません。

ヒント:

この画面上のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

20.7.2.22 ドメイン・ホームと管理サーバーURLの記録

「構成に成功しました」画面に、構成したばかりのドメインに関する情報が表示されます。

後で必要になるので、次の項目を書きとめます。

- ドメインの場所

- 管理サーバーURL

ドメインの場所はノード・マネージャおよび管理サーバーを起動するスクリプトにアクセスするため、URLは管理サーバーにアクセスするために必要です。

「終了」をクリックして、構成ウィザードを閉じます。

20.8 Managed File Transferドメイン用のノード・マネージャの構成

Managed File Transferドメインでは、ノード・マネージャで同じホスト上の複数のドメインを制御できるように、ホストごとのノード・マネージャを使用します。

MFTHOST1で最初にノード・マネージャを構成する場合、「エンタープライズ・デプロイメントに対するホストごとのノード・マネージャの構成」に記載されている手順に従ってください。ドメイン名とディレクトリは、Managed File Transferドメインの値に一致している必要があります。

MFTHOST1でホストごとのノード・マネージャをすでに構成している場合、新しいドメインを既存のノード・マネージャ構成に追加できます。

1. MFTHOST1で、ディレクトリをホストごとのノード・マネージャ・ホーム・ディレクトリに変更します。
cd NM_HOME

2. テキスト・エディタを使用してnodemanager.domainsファイルを開きます。

3. 管理サーバー・ドメイン・ホームと管理対象サーバー・ドメイン・ホームへのパスをnodemanager.domainsファイルに追加します。

ドメイン・パスはセミコロンで区切ります。例:

mftedg_domain=/u02/oracle/config/domains/mftedg_domain; /u01/oracle/config/domains/mftedg_domain

4. ホストごとのノード・マネージャを再起動します。

(オプション)この手順の結果をここで入力します。

20.9 ドメイン・ディレクトリの構成とMFTHOST1上のサーバーの起動

ドメインを作成し、ノード・マネージャを構成したら、MFTHOST1で追加のドメイン・ディレクトリを構成し、管理サーバーおよび管理対象サーバーを起動できます。

- ノード・マネージャを使用した管理サーバーの起動
ドメインを構成し、ノード・マネージャを構成したら、ノード・マネージャを使用して管理サーバーを起動できます。エンタープライズ・デプロイメントでは、ドメイン内の管理サーバーおよびすべての管理対象サーバーの起動および停止にノード・マネージャが使用されます。

- 管理サーバーの検証
構成手順に進む前に、管理サーバーにインストールおよび構成されているOracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認し、管理サーバーが正常に起動したことを確認します。

- Derbyデータベースの無効化

- MFTHOST1での管理対象サーバーの個別ドメイン・ディレクトリの作成
エンタープライズ・デプロイメント用にドメインを初期作成すると、ドメイン・ディレクトリは共有ディスクにあります。このデフォルト・ドメイン・ディレクトリは、管理サーバーの実行に使用されます。これで、MFTHOST1とMFTHOST2の両方で、ローカル記憶域にドメインのコピーを作成できるようになりました。ローカル(またはプライベート)記憶域上のドメイン・ディレクトリは、管理対象サーバーの実行に使用されます。

- MFTHOST1でのWLS_MFT1管理対象サーバーの起動と検証
ノード・マネージャを構成して管理対象サーバー・ドメイン・ディレクトリを作成したら、Oracle Enterprise Manager Fusion Middleware Controlを使用してMFTHOST1でWLS_MFT1管理対象サーバーを起動できます。

20.9.1 ノード・マネージャを使用した管理サーバーの起動

ドメインを構成し、ノード・マネージャを構成したら、ノード・マネージャを使用して管理サーバーを起動できます。エンタープライズ・デプロイメントでは、ドメイン内の管理サーバーおよびすべての管理対象サーバーの起動および停止にノード・マネージャが使用されます。

ノード・マネージャを使用して管理サーバーを起動する手順は次のとおりです。

1. WebLogic Scripting Tool (WLST)を起動します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

2. ノード・マネージャ資格証明を使用してノード・マネージャに接続します。

wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
'ADMINVHN','5556','domain_name',
'ASERVER_HOME','PLAIN')

注意:

このユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバー管理者IDおよびパスワードとは無関係であり、次のディレクトリにあるnm_password.propertiesファイルに格納されます。

ASERVER_HOME/config/nodemanager

3. 管理サーバーを起動します。

nmStart('AdminServer')

注意:

管理サーバーを起動すると、WebServicesポリシーを取得するためにOracle Web Services Managerに接続しようとします。WSM-PM管理対象サーバーはまだ起動されていないため、次のメッセージが管理サーバー・ログに出力されます。

<Warning><oracle.wsm.resources.policymanager>
<WSM-02141><Unable to connect to the policy access service due to Oracle WSM policy manager host server being down.>

4. WLSTを終了します。

exit()

20.9.2 管理サーバーの検証

構成手順に進む前に、管理サーバーにインストールおよび構成されているOracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認し、管理サーバーが正常に起動したことを確認します。

Fusion Middleware Controlに移動するには、次のURLを入力し、Oracle WebLogic Server管理者の資格証明を使用してログインします。

ADMINVHN:7001/em

Oracle WebLogic Server管理コンソールに移動するには、次のURLを入力し、同じ管理者資格証明を使用してログインします。

ADMINVHN:7001/console

20.9.3 Derbyデータベースの無効化

管理対象サーバー・ディレクトリを作成して、管理対象サーバーを起動する前に、組込みDerbyデータベース(Oracle WebLogic Serverに含まれているファイルベースのデータベース)を無効にします。Derbyデータベースは、主に開発環境で使用されます。結果として、本番として使用可能なエンタープライズ・デプロイメント環境を構成する場合、それを無効にする必要があります。そうしないと、管理対象サーバーを起動するときに、Derbyデータベース・プロセスが自動的に開始されます。

Derbyデータベースを無効にする手順は次のとおりです。

1. Oracleホームの次のディレクトリに移動します。
WL_HOME/common/derby/lib

2. Derberライブラリjarファイルの名前を変更します。
mv derby.jar disable_derby.jar

3. SOAHOST1およびSOAHOST2の各ORACLE_HOMEで手順1から2を完了します(別個の共有ファイル・システムを使用している場合)。

20.9.4 MFTHOST1での管理対象サーバーの個別ドメイン・ディレクトリの作成

エンタープライズ・デプロイメント用にドメインを初期作成すると、ドメイン・ディレクトリは共有ディスクにあります。このデフォルト・ドメイン・ディレクトリは、管理サーバーの実行に使用されます。これで、MFTHOST1とMFTHOST2の両方で、ローカル記憶域にドメインのコピーを作成できるようになりました。ローカル(またはプライベート)記憶域上のドメイン・ディレクトリは、管理対象サーバーの実行に使用されます。

サーバーが共有記憶域にログを書き込むことによって発生する潜在的な競合とオーバーヘッドを排除するために、MSERVER_HOMEをローカル記憶域に配置することをお薦めします。また、必要なクラスおよびjarをドメイン・ディレクトリからロードするほうが高速であるため、管理対象サーバーがドメイン・ディレクトリから使用するtmpまたはキャッシュのデータのほうがより迅速に処理されます。

「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のように、管理サーバー・ドメイン・ホームのパスはASERVER_HOME変数によって表され、管理対象サーバー・ドメイン・ホームのパスはMSERVER_HOME変数によって表されます。

管理対象サーバーのドメイン・ディレクトリを作成する手順は次のとおりです。

1. MFTHOST1にログインし、次のようにpackコマンドを実行してテンプレートを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true
-domain=ASERVER_HOME
-template=complete_path/mftdomaintemplate.jar
-template_name=soa_domain_template

この例では、次のようになります。

- ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

- complete_pathを、ドメイン・テンプレートJARファイルを作成する場所の完全なパスに置き換えます。ドメイン・テンプレートJARファイルをコピーまたは解凍する際に、この場所を参照する必要があります。

- mftdomaintemplateは作成するJARファイルのサンプル名であり、これにはドメイン構成ファイルが含まれます。

- mft_domain_templateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

2. packコマンドで作成したテンプレートJARファイルの場所を書き留めます。

テンプレートJARファイルの完全なパスを、packコマンドの-template引数の一部として指定する必要があります。

ORACLE_COMMON_HOME/common/bin/

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

3. まだ作成していない場合は、MFTHOST1のローカル記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME \
-overwrite_domain=true \
-template=complete_path/mftdomaintemplate.jar \
-log_priority=DEBUG \
-log=/tmp/unpack.log \
-app_dir=APPLICATION_HOME \

注意:

unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

また、ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverrides.shというファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のjavaコマンド行オプションの指定、追加の環境変数の指定などを行うよう構成できます。このファイルに追加されたカスタマイズはドメインのアップグレード操作中に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。

この例では、次のようになります。

- MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

- complete_pathを、テンプレートJARファイルを作成またはコピーした場所の完全なパスに置き換えます。

- mftdomaintemplate.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートJARファイルの名前です。

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

5. ディレクトリを、新しく作成した管理対象サーバー・ディレクトリに変更して、ドメイン構成ファイルがMFTHOST1のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

20.9.5 MFTHOST1でのWLS_MFT1管理対象サーバーの起動と検証

ノード・マネージャを構成して管理対象サーバー・ドメイン・ディレクトリを作成したら、Oracle Enterprise Manager Fusion Middleware Controlを使用してMFTHOST1でWLS_MFT1管理対象サーバーを起動できます。

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

http://ADMINVHN:7001/em

この例では、次のようになります。

- ADMINVHNを、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」でADMINVHN仮想IPアドレスに割り当てたホスト名に置き換えます。

- ポート7001は、管理サーバー・コンソールおよびFusion Middleware Controlで一般的に使用されるポートです。ただし、ドメインを作成したときに構成ウィザードのセッションの終わりに表示された実際のURLを使用する必要があります。

ヒント:

Oracle Enterprise Manager Fusion Middlewareを使用したOracle Fusion Middlewareの管理の詳細は、Oracle Fusion Middlewareの管理のOracle Enterprise Manager Fusion Middleware Controlの使用のスタート・ガイドを参照してください。

2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

3. 「サーバー」ペインを選択して、ドメイン内の管理対象サーバーを表示します。

4. WLS_MFT1管理対象サーバーのみを選択して、ツールバーで「コントロール」→「起動」をクリックします。

5. 管理対象サーバーが正しく機能していることを検証するには、ブラウザを開き、次のURLを入力します。

MFTHOST1:7500/wsm-pm/
MFTHOST1:7500/mftconsole/

要求に従って、ドメイン管理ユーザー名とパスワードを入力します。

20.10 ドメインの伝播とMFTHOST2上のサーバーの起動

MFTHOST1で管理サーバーとWLS_WSM1管理対象サーバーを起動して検証したら、MFTHOST2で次のタスクを実行できます。

- MFTHOST2でのドメイン構成の解凍

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

- MFTHOST2でのWLS_MFT2管理対象サーバーの起動と検証

20.10.1 MFTHOST2でのドメイン構成の解凍

MFTHOST1で管理サーバーと最初のWLS_WSM1管理対象サーバーを実行した後、MFTHOST2でドメインを構成できます。

1. MFTHOST2にログインします。

2. まだ作成していない場合は、MFTHOST2の記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

3. MFTHOST2からmftdomaintemplate.jarにアクセスできることを確認します。
たとえば、MFTHOST2に別の共有記憶域ボリュームまたはパーティションを使用している場合は、MFTHOST2にマウントされているボリュームまたはパーティションにテンプレートをコピーします。

4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME
-overwrite_domain=true
-template=complete_path/mftdomaintemplate.jar
-log_priority=DEBUG
-log=/tmp/unpack.log
-app_dir=APPLICATION_HOME

この例では、次のようになります。

- MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

- complete_path/mftdomaintemplate.jarを、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したドメイン・テンプレートJARファイルの完全なパスとファイル名に置き換えます。

- APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

5. ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがMFTHOST2のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

20.10.2 MFTHOST2でのノード・マネージャの起動

ホストごとのノード・マネージャ構成を使用するようにノード・マネージャを手動で設定したら、MFTHOST2で次のコマンドを使用してノード・マネージャを起動できます。

1. ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。

cd NM_HOME

2. 次のコマンドを実行してノード・マネージャを起動し、コマンドの出力を現在のターミナル・シェルではなく出力ファイルに送信します。

nohup ./startNodeManager.sh > nodemanager.out 2>&1 &

20.10.3 MFTHOST2でのWLS_MFT2管理対象サーバーの起動と検証

「MFTHOST1でのWLS_MFT1管理対象サーバーの起動と検証」の手順を使用して、MFTHOST2上のWLS_WSM2管理対象サーバーを起動および検証します。

20.11 uploadおよびstageディレクトリの絶対パスへの変更

ドメインを構成し、すべてのホスト上の管理対象サーバーのドメイン・ディレクトリにそのドメインを解凍した後、新しい管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

この手順は、リモート・デプロイメントの実行時の潜在的な問題の回避とステージ・モードが必要なデプロイメントのために必要です。

管理対象サーバー・ドメイン・ホーム・ディレクトリ内のすべての管理対象サーバーについてこれらのディレクトリ・パスを更新する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 左側のナビゲーション・ツリーで、「ドメイン」→「環境」を開きます。

3. 「ロックして編集」をクリックします。

4. 「サーバー」をクリックします。

5. 管理対象サーバー・ドメイン・ホーム・ディレクトリ内の新しい管理対象サーバーごとに次の操作を実行します。

a. 管理対象サーバーの名前をクリックします。

b. 「構成」タブをクリックし、「デプロイメント」タブをクリックします。

c. 「ステージング・ディレクトリ名」が次のように設定されていることを確認します。

MSERVER_HOME/servers/server_name/stage

MSERVER_HOMEをMSERVER_HOMEディレクトリのディレクトリ・パスに置き換え、server_nameを編集しているサーバーの名前に置き換えます。

d. 「アップロード・ディレクトリ名」を次の値に更新します。

ASERVER_HOME/servers/AdminServer/upload

ASERVER_HOMEをASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。

e. 「保存」をクリックします。

f. 「サーバーのサマリー」画面に戻ります。

6. 各管理対象サーバーについてこれらの値を変更したら、「変更のアクティブ化」をクリックします。

7. すべての管理対象サーバーを再起動します。

20.12 Managed File TransferのSSH-FTPサービスの構成および有効化

Oracle Managed File Transferのエンタープライズ・デプロイメント・トポロジは、ファイル転送用のSecure File Transfer Protocol (SFTP)に基づきます。SFTPは、別個のプロトコルで、SSHとともにパッケージされ、FTPのように動作しますが、セキュアな接続を使用します。

SFTPでは、ファイル転送接続に使用するポート数を制限できます。これは、その基礎となるセキュリティ機能の存在と標準のSSH接続の使用が可能であることから、FTPより推奨されます。

- SFTPポートの構成
Oracle Managed File TransferでSecure File Transfer Protocol (SFTP)を使用する前に、SFTPポートを構成する必要があります。

- 必要なSSHキーの生成
SFTPを有効化するには、SSHキーを生成する必要があります。Managed File Transferではクラスタ内のすべてのサーバーで同じSFTPキーが共有されるため、管理対象サーバーの1つで1回のみこの手順を実行する必要があります。

- Managed File Transferの追加のSFTP構成手順
Managed File TransferでSFTPを使用する場合に実行する必要のある追加の構成手順がいくつかあります。

20.12.1 SFTPポートの構成

Oracle Managed File TransferでSecure File Transfer Protocol (SFTP)を使用する前に、SFTPポートを構成する必要があります。

1. ドメイン管理ユーザー名とパスワードを使用して、Managed File Transferコンソールに接続します。
mft.example.com:80/mftconsole

2. 「管理」タブを選択します。

3. 左側のナビゲーション・ペインで、「埋込みサーバー」を開きます。

4. 「ポート」をクリックします。

5. Managed File Transferサーバーの「構成済ポート」として7501を入力します。

6. 「保存」をクリックします。

7. 「再起動」をクリックしてサービスを再起動します。

20.12.2 必要なSSHキーの生成

SFTPを有効化するには、SSHキーを生成する必要があります。Managed File Transferではクラスタ内のすべてのサーバーで同じSFTPキーが共有されるため、管理対象サーバーの1つで1回のみこの手順を実行する必要があります。

有効な秘密鍵がないと、SSH-FTPサーバーは起動しません。セキュリティのベスト・プラクティスに準拠するには、常にパスワードで保護された秘密鍵を使用する必要があります。使用するパスワードは、Managed File Transferコンソールで指定したパスワードに一致している必要があります。コンソールでパスワードを特定するには、「キーストア」→「SSHキーストア」→「秘密鍵のパスワード」を選択します。

1. a.ssh-keygenコマンドを実行してキーを生成します。

例:

ssh —keygen \-t rsa \-b 2048

ssh-keygenは標準のUnix/Linuxコマンドです。詳細は、オペレーティング・システムのドキュメントを参照してください。

生成されたキーの場所を書き留めます。この情報は後で必要になります。

2. キーをManaged File Transferキーストアにインポートします。

a. Managed File Transfer管理対象サーバーが稼働中であることを確認します。

b. ディレクトリを次の場所に変更します。
ORACLE_COMMON_HOME/common/bin

c. WebLogic Server Scripting Tool (WLST)を起動します。
./wlst.sh

d. 次のコマンド構文を使用して最初の管理対象サーバーに接続します。
connect('admin_user','admin_password','server_url')
例:

connect('weblogic','mypassword','t3://MFTHOST1:7500')

e. 次のWLSTコマンドを実行してキーをインポートします。
importCSFKey('SSH', 'PRIVATE', 'alias', 'pvt_key_file_path')

aliasは、管理対象サーバーを識別するために使用できる名前に置き換えます。

pvt_key_file_pathは、この手順で前に生成したキーの名前およびディレクトリの場所に置き換えます。

詳細は、『SOA Suite WLSTコマンド・リファレンス』のimportCSFKeyに関する項を参照してください。

3. SSHキーのインポートに成功したら、SSH-FTPを有効化して秘密鍵の別名を選択します。

a. ドメイン管理ユーザーとパスワードを使用して、次のURLのManaged File Transferコンソールに接続します。
mft.mycompany.com:80/mftconsole

b. 「SSHキーストア」フィールドに、この手順で前に作成したキーストア・パスワードを入力します。

c. 変更内容を保存します。

d. 「管理」タブを選択し、ナビゲーション・ツリーで「埋込みサーバー」を開きます。

e. SSH-FTPタブで、「有効」を選択します。

f. 「ホスト・キー・エイリアス」ドロップダウン・メニューから、この手順で前に作成した秘密鍵の別名を選択します。

g. 変更内容を保存します。

h. MFTサーバーを起動します。

i. 「起動」をクリックしてSSH-FTPサービスを起動します。

4. 任意の標準的なSFTPクライアント・アプリケーションを使用して、SFTPを介してManaged File Transferサーバーにアクセスできることを確認します。

20.12.3 Managed File Transferの追加のSFTP構成手順

Managed File TransferでSFTPを使用する場合に実行する必要のある追加の構成手順がいくつかあります。

1. 次のURLのManaged File Transferコンソールに接続します。
mft.example.com:80/mftconsole

2. 「管理」を選択し、ナビゲーション・ツリーで「サーバー・プロパティ」を選択します。

3. 高可用性プロパティを更新します。

a. クラスタ内の異なるサーバーからアクセスできる共有記憶域の場所を指すように、ペイロードおよびコールアウト・ディレクトリを更新します。

例:

ORACLE_RUNTIME/mftedg_domain/MFT_Cluster/storage

ORACLE_RUNTIME/mftedg_domain/MFT_Cluster/callouts

b. 「制御ディレクトリ」を共有の場所に設定します。

例:

ORACLE_RUNTIME/mftedg_domain/MFT_Cluster/control_dir

制御ディレクトリは、高可用性のユース・ケースを処理するためにManaged File TransferのファイルおよびFTPアダプタによって使用されるディレクトリ・パスです。MFTがHA環境で実行している場合、このフィールドは必須です。クラスタ内で複数のOracle WebLogic Serverインスタンスが稼働している場合は、共有の場所に設定する必要があります。

c. 制御ディレクトリを指定しない場合、「インバウンド・データソース」および「アウトバウンド・データソース」フィールドの値を確認する必要があります。

「インバウンド・データソース」の有効なデフォルト値は、jdbc/MFTLocalTxDataSourceです。

「アウトバウンド・データソース」の有効なデフォルト値は、jdbc/MFTDataSourceです。

d. これまでの変更内容を保存します。

e. ナビゲーション・ツリーで「拡張配信プロパティ」を開きます。

拡張配信プロパティにより、ロード・バランサで使用される内部アドレスと外部アドレス(IPアドレス)に加え、FTP、FTPSおよびSFTPポートを取得します。

これらの設定を使用するのは、Oracle Managed File TransferからペイロードがFTPまたはSFTP参照として送信されるときです。値が設定されている場合は、その値を使用してFTP参照(FTP/SFTPホスト・アドレスとポート)が構築されます。

Managed File Transferが内部および外部プロキシの背後で稼働している場合、内部および外部IPアドレスは必須です。

- 内部アドレス: SFTPに内部ロード・バランサを使用していないかぎり、このフィールドは空白のままにします。デフォルトのエンタープライズ・デプロイメントでは、内部ロード・バランサではなく外部ロード・バランサを使用します。

- 外部アドレス: 外部ロード・バランサを通じたSFTリクエストのエントリ・ポイントとして使用するアドレスを入力します。
たとえば、アドレスとしてsftp.example.comを、SFTPポートとして7503を入力します。

sftp.mycompany.com

f. 変更内容を保存し、コンソールを終了します。

4. WLS_MFT管理対象サーバーを再起動します。

5. 任意の標準的なSFTPクライアント・アプリケーションを使用して、SFTPを介してManaged File Transferサーバーにアクセスできることを確認します。

20.13 Managed File Transfer用のOracle Traffic Directorの構成

Oracle Traffic Directorは、Web層のOracle HTTP Serverのかわりとして使用できます。Oracle HTTP Serverと同様に、これはHTTPリクエストをフロントエンド・ロード・バランサからアプリケーション層のWebLogic管理対象サーバーにルーティングできます。ただし、TCPロード・バランシングおよびフェイルオーバーを提供できるのは、Oracle Traffic Directorのみです。そのため、Oracle Traffic Directorは、セキュアなFTPリクエストのルーティングのためにTCPを必要とするOracle Managed File Transferによって必要とされます。

Oracle Traffic Directorを構成する完全な手順は、「Oracle Traffic Directorを含めるドメインの拡張」を参照してください。

20.14 新しいLDAPオーセンティケータの作成とManaged File Transferのユーザーのプロビジョニング

Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダ(DefaultAuthenticator)を使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用することをお薦めします。

新しいOracle Fusion Middlewareドメインごとにこの手順が必要です。Oracle Managed File Transferドメインでは、次のようにこのタスクを実行できます。

1. 「新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング」を確認して、必要な概念を理解し、新しいLDAPオーセンティケータを作成します。

2. ユーザーとグループをプロビジョニングする場合、Managed File Transfer管理認証では次のユーザー名およびグループ名を使用します。
管理ユーザー: weblogic_mft

管理グループ: MFT Administrators

20.15 Managed File Transferに対する自動サービス移行およびJDBC永続ストアの有効化

ソフトウェアが高可用性を実現するように構成するには、自動サービス移行でOracle Managed File Transfer管理対象サーバーを構成します。

サーバー移行の有効化の詳細は、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。

可用性をさらに高めるために、トランザクション・ログ・ストアおよびJMSストアをデータベースに構成することもできます。詳細は、「エンタープライズ・デプロイメントのTLOGおよびJMSでのJDBC永続ストアの使用」を参照してください。

第IV部 エンタープライズ・デプロイメントの共通の構成および管理手順

ここでは、一般的なエンタープライズ・デプロイメントに必須または推奨される構成および管理手順について説明します。

- エンタープライズ・デプロイメントの共通の構成および管理手順
次の各項では、エンタープライズ・デプロイメント環境で実行する必要性が高い、構成および管理タスクについて説明します。

- エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用
次の各項では、Oracle WebLogic Serverのサーバー全体の移行およびOracle WebLogic Serverの自動サービス移行について説明します。Oracle Fusion Middlewareエンタープライズ・トポロジでこれらの機能を使用する方法についても説明します。

- エンタープライズ・デプロイメントに対するシングル・サインオンの構成
この章では、Oracle Access Managerを使用したシングル・サインオンが有効になるようOracle HTTP Server Webゲートを構成する方法について説明します。

21 エンタープライズ・デプロイメントの共通の構成および管理タスク

次の各項では、エンタープライズ・デプロイメント環境で実行する必要性が高い、構成および管理タスクについて説明します。

- すべてのエンタープライズ・デプロイメントの構成および管理タスク
この項では、Oracle Fusion Middlewareエンタープライズ・デプロイメントで実行する必要性が高い、いくつかの一般的な構成および管理タスクについて説明します。

- Oracle SOA Suiteエンタープライズ・デプロイメントの構成および管理タスク
この項では、Oracle SOA Suiteエンタープライズ・デプロイメントで実行する必要性が高い、いくつかの主要な構成および管理タスクについて説明します。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理手順

21.1 すべてのエンタープライズ・デプロイメントの構成および管理タスク

この項では、Oracle Fusion Middlewareエンタープライズ・デプロイメントで実行する必要性が高い、いくつかの一般的な構成および管理タスクについて説明します。

- 管理サーバーの手動フェイルオーバーの確認
ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。次に、SOAHOST1およびSOAHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証する方法を示します。

- 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化
この項では、中間層とハードウェア・ロード・バランサとの間のSSL通信を有効にする方法を説明します。

- エンタープライズ・デプロイメントの管理用のロールの構成
この項では、固有の管理ロールを使用する製品のサマリーを示し、製品固有の管理ロールをエンタープライズ・デプロイメント管理グループに追加する手順を示します。

- エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用
次の項では、トランザクション・ログ(TLOG)およびJMSにJDBC永続ストアを使用する方法のガイドラインを示します。サポートされているデータベースで永続ストアを構成するための手順も示します。

- エンタープライズ・デプロイメントのバックアップとリカバリの実行
この項では、Oracle SOA Suiteエンタープライズ・デプロイメントの必要なディレクトリと構成データを確実にバックアップするためのガイドラインを示します。

21.1.1 管理サーバーの手動フェイルオーバーの確認

ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。次に、SOAHOST1およびSOAHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証する方法を示します。

前提条件:

- 管理サーバーを、localhostまたは任意のアドレスではなく、ADMINVHN上でリスニングするように構成します。
ADMINVHN仮想IPアドレスの詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。

- この手順では、管理サーバーのドメイン・ホーム(ASERVER_HOME)が両方のホスト・コンピュータにマウントされていることを前提にしています。これにより、管理サーバーのドメイン構成ファイルと永続ストアが、共有記憶域デバイスに保存されるようになります。

- 管理サーバーはSOAHOST1からSOAHOST2アプリケーションにフェイルオーバーし、これら2つのノードには次のIPが割り当てられています。

- SOAHOST1: 100.200.140.165

- SOAHOST2: 100.200.140.205

- ADMINVHN : 100.200.140.206。これは管理サーバーを実行している場所の仮想IPであり、ethX:Yに割り当てられており、SOAHOST1とSOAHOST2からアクセスできます。

- Oracle WebLogic ServerとOracle Fusion Middlewareのコンポーネントが、このガイドの個々の構成の章で示すように、SOAHOST2にインストールされています。
具体的には、両方のホスト・コンピュータは、まったく同じパスを使用してOracleホームのバイナリ・ファイルを参照します。

次の項では、管理サーバーのフェイルオーバー手順のテストを実行する方法について詳しく説明します。

- ホストごとのノード・マネージャを使用している場合の管理サーバーのフェイルオーバー
次の手順は、管理サーバーを別のノード(SOAHOST2)にフェイルオーバーする方法を示します。フェイルオーバー後でも、管理サーバーは引き続き同じOracle WebLogic Serverマシン(物理マシンではなく論理マシン)を使用することに注意してください。

- Oracle HTTP Serverを介したSOAHOST2上の管理サーバーへのアクセスの検証
管理サーバーの手動フェイルオーバーを実行したら、標準の管理URLを使用して管理サーバーにアクセスできるかを確認することが重要です。

- ホストごとのノード・マネージャを使用する場合の管理サーバーのSOAHOST1へのフェイルバック
管理サーバーの手動フェイルオーバーをテストし、フェイルオーバー後に管理URLにアクセスできることを確認したら、管理サーバーを元のホストに戻すことができます。

21.1.1.1 ホストごとのノード・マネージャを使用している場合の管理サーバーのフェイルオーバー

次の手順は、管理サーバーを別のノード(SOAHOST2)にフェイルオーバーする方法を示します。フェイルオーバー後でも、管理サーバーは引き続き同じOracle WebLogic Serverマシン(物理マシンではなく論理マシン)を使用することに注意してください。

この手順では、「ホストごとのノード・マネージャ構成の作成」の説明に従って、エンタープライズ・トポロジにホストごとのノード・マネージャが構成されていることを前提としています。詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

管理サーバーを別のホストにフェイルオーバーするには:

1. SOAHOST1で管理サーバーを停止します。

2. SOAHOST1でノード・マネージャを停止します。
このガイドの前半で示した手順を使用してホストごとのノード・マネージャを起動した場合、ノード・マネージャを起動したターミナル・ウィンドウに戻り、[Ctrl]キーを押しながら[C]キーを押してプロセスを停止します。

3. ADMINVHN仮想IPアドレスを第2ホストに移行します。

a. SOAHOST1で次のコマンドをroot権限で実行します(X:YはADMINVHNで現在使用しているインタフェース)。

/sbin/ifconfig ethX:Y down

b. 次のコマンドをSOAHOST2でrootとして実行します。

/sbin/ifconfig <interface:index> ADMINVHN netmask <netmask>

例:

/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0

注意:

使用するネットマスクとインタフェースは、SOAHOST2で使用可能なネットワーク構成と一致している必要があります。

4. 次の例のように、arpingを使用してルーティング表を更新します。

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

5. SOAHOST1で、ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。

cd NM_HOME

6. nodemanager.domainsファイルを編集し、ASERVER_HOMEへの参照を削除します。
SOAHOST1 nodemanager.domainsファイルで次のようなエントリが生成されます。

soaedg_domain=MSERVER_HOME;

7. SOAHOST2で、ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。

cd NM_HOME

8. nodemanager.domainsファイルを編集し、MSERVER_HOMEへの参照を追加します。
SOAHOST2 nodemanager.domainsファイルで次のようなエントリが生成されます。

soaedg_domain=MSERVER_HOME;ASERVER_HOME

9. SOAHOST1でノード・マネージャを起動し、SOAHOST2でノード・マネージャを再起動します。

10. SOAHOST2で管理サーバーを起動します。

11. 次の方法でSOAHOST2上の管理サーバーにアクセスできることをテストします。

a. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。

http://ADMINVHN:7001/console

b. 次のURLを使用して、Fusion Middleware Controlのコンポーネントにアクセスできることを確認し、そのステータスを検証します。

http://ADMINVHN:7001/em

21.1.1.2 Oracle HTTP Serverを介したSOAHOST2上の管理サーバーへのアクセスの検証

管理サーバーの手動フェイルオーバーを実行したら、標準の管理URLを使用して管理サーバーにアクセスできるかを確認することが重要です。

ロード・バランサから次のURLにアクセスして、SOAHOST2で稼働中の管理サーバーにアクセスできることを確認します。

- http://admin.example.com/console
このURLはWebLogic Server管理コンソールを表示するはずです。

- http://admin.example.com/em
このURLはOracle Enterprise Manager Fusion Middleware Controlを表示するはずです。

21.1.1.3 ホストごとのノード・マネージャを使用する場合の管理サーバーのSOAHOST1へのフェイルバック

管理サーバーの手動フェイルオーバーをテストし、フェイルオーバー後に管理URLにアクセスできることを確認したら、管理サーバーを元のホストに戻すことができます。

この手順では、「ホストごとのノード・マネージャ構成の作成」の説明に従って、エンタープライズ・トポロジにホストごとのノード・マネージャが構成されていることを前提としています。詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

1. SOAHOST2で管理サーバーを停止します。

2. SOAHOST2でノード・マネージャを停止します。

3. 次のコマンドをSOAHOST2上でrootとして実行します。

/sbin/ifconfig ethZ:N down

4. 次のコマンドをSOAHOST1上でrootとして実行します。

/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0

注意:

使用するネットマスクとインタフェースは、SOAHOST1で使用可能なネットワーク構成と一致している必要があります

5. SOAHOST1上でarpingを使用して、ルーティング表を更新します。

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

6. SOAHOST2で、ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。

cd NM_HOME

7. nodemanager.domainsファイルを編集し、MSERVER_HOMEへの参照を削除します。

8. SOAHOST1で、ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。

cd NM_HOME

9. nodemanager.domainsファイルを編集し、MSERVER_HOMEへの参照を追加します。

10. SOAHOST2でノード・マネージャを起動し、SOAHOST1でノード・マネージャを再起動します。

11. SOAHOST1で管理サーバーを起動します。

12. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることをテストします。

http://ADMINVHN:7001/console

13. 次のURLを使用してOracle Enterprise Managerにアクセスおよびコンポーネントのステータスを確認できることを確認します。

http://ADMINVHN:7001/em

21.1.2 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

この項では、中間層とハードウェア・ロード・バランサとの間のSSL通信を有効にする方法を説明します。

注意:

次の手順は、ハードウェア・ロード・バランサにSSLが構成されており、その結果システムのフロント・エンド・アドレスが保護されている場合に使用できます。

- 中間層とロード・バランサ間のSSL通信が必要になるとき

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

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

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

- トラスト・ストアへのロード・バランサ証明書のインポート

- Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加

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

- SSLエンドポイントを使用したコンポジットのテスト

21.1.2.1 中間層とロード・バランサ間のSSL通信が必要になるとき

エンタープライズ・デプロイメントには、中間層で実行されているソフトウェアが、ハードウェア・ロード・バランサのフロントエンドSSLアドレスにアクセスしなければならないシナリオがあります。このシナリオでは、ロード・バランサと起動サーバー間で、適切なSSLハンドシェイクが行われる必要があります。中間層の管理サーバーと管理対象サーバーが適切なSSL構成を使用して起動されていない場合は、このハンドシェイクを実行できません。

たとえば、Oracle SOA Suiteエンタープライズ・デプロイメントでは、次のような例が該当します。

- Oracle Business Process Managementは、特定のWebサービス経由でロール情報を取得しようとするときに、フロントエンド・ロード・バランサのURLにアクセスする必要がある。

- Oracle Service Busは、ロード・バランサのSSL仮想サーバーで公開されているエンドポイントに対する呼出しを実行する。

- Oracle SOA Suiteのコンポジット・アプリケーションとサービスは、ロード・バランサで公開されているSSLアドレスを使用して呼出しを実行する必要のあるコールバックを、頻繁に生成する。

- Oracle Enterprise Manager Fusion Middleware ControlでSOA Webサービスのエンドポイントをテストするとき、管理サーバーで実行されているFusion Middleware Controlソフトウェアは、ロード・バランサのフロントエンドにアクセスして、エンドポイントを検証する必要がある。

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

この項では、SOAHOST1に自己署名証明書を作成する手順を説明します。これらの証明書は、ネットワーク名またはホストの別名を使用して作成します。

キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。様々な目的(HTTPを起動するためのSSL設定など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。詳細は、「エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解」に記載されているKEYSTORE_HOMEの場所に対するファイル・システムの指定に関する情報を参照してください。

かわりに信頼できるCA証明書を使用する方法は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する情報を参照してください。

パスワードについて

このマニュアルで使用するパスワードは、あくまでも例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字を含むパスワードを使用します。

自己署名証明書を作成する手順は次のとおりです。

1. 一時的に環境を設定するためにWL_HOME/server/bin/setWLSEnv.shスクリプト・コマンドを実行します。

. WL_HOME/server/bin/setWLSEnv.sh

現在のシェルでシェル・スクリプトを参照するために、スクリプト名の前にドット(.)と空白( )があることに注意してください。

2. CLASSPATH環境変数が設定されていることを確認します。

echo $CLASSPATH

3. 共有構成ディレクトリ・フォルダが作成され、「エンタープライズ・デプロイメント用のファイル・システムの準備」で説明されているように共有記憶域に正しくマウントされていることを確認します。

たとえば、次のコマンドを使用して、各ホストで共有構成ディレクトリが使用できることを確認します。

df -h | grep -B1 SHARED_CONFIG_DIR

SHARED_CONFIG_DIRを、共有構成ディレクトリへの実際のパスに置き換えます。

ディレクトリを表示して、ホストで使用できることを確認することもできます。

ls -al SHARED_CONFIG_DIR

4. キーストア・ホーム・フォルダ構造が存在しない場合は、作成します。

例:

cd SHARED_CONFIG_DIR
mkdir keystores
chown oracle:oinstall keystores
chmod 750 keystores
export KEYSTORE_HOME=$SHARED_CONFIG_DIR/keystores

5. ディレクトリを、キーストア・ホームに変更します。

cd KEYSTORE_HOME

6. utils.CertGenツールを実行し、ノード内のサーバーで使用される物理ホスト名と仮想ホスト名の両方の証明書を作成します。

構文:

java utils.CertGen key_passphrase cert_file_name key_file_name [export | domestic] [hostname]

例:

java utils.CertGen password ADMINVHN.example.com_cert \
ADMINVHN.example.com_key domestic ADMINVHN.example.com

java utils.CertGen password SOAHOST1.example.com_cert \
SOAHOST1.example.com_key domestic SOAHOST1.example.com

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

この項では、SOAHOST1.example.comでアイデンティティ・キーストアを作成する方法について説明します。

前の項では、証明書とキーを作成して、それを共有記憶域に配置しました。この項では、SOAHOST1とADMINVHN両方の証明書と秘密鍵が新しいアイデンティティ・ストアにインポートされます。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

注意:

アイデンティティ・ストアは、utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をインポートすることで作成されます(存在していない場合)。

1. ADMINVHNおよびSOAHOST1の証明書と秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

構文:

java utils.ImportPrivateKey
-certfile cert_file
-keyfile private_key_file
[-keyfilepass private_key_password]
-keystore keystore
-storepass storepass
[-storetype storetype]
-alias alias
[-keypass keypass]

注意:

デフォルトのkeystore_typeはjksです。

例:

java utils.ImportPrivateKey
-certfile KEYSTORE_HOME/ADMINVHN.example.com_cert.pem
-keyfile KEYSTORE_HOME/ADMINVHN.example.com_key.pem
-keyfilepass password
-keystore appIdentityKeyStore.jks
-storepass password
-alias ADMINVHN
-keypass password

java utils.ImportPrivateKey
-certfile KEYSTORE_HOME/SOAHOST1.example.com_cert.pem
-keyfile KEYSTORE_HOME/SOAHOST1.example.com_key.pem
-keyfilepass password
-keystore appIdentityKeyStore.jks
-storepass password
-alias SOAHOST1
-keypass password

2. システムで使用される残りのすべてのホスト(SOAHOST2など)について、上述の手順を繰り返します。

21.1.2.4 Keytoolユーティリティを使用した信頼キーストアの作成

SOAHOST1.example.comに信頼キーストアを作成するには:

1. 新しい信頼キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。

標準のJava信頼キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリにある標準のJavaキーストアのCA証明書を、証明書のあるディレクトリにコピーします。例:

cp WL_HOME/server/lib/cacerts KEYSTORE_HOME/appTrustKeyStore.jks

2. キーツール・ユーティリティを使用してデフォルト・パスワードを変更します。

標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは、常に次のように変更することをお薦めします。

keytool -storepasswd -new NewPassword -keystore TrustKeyStore -storepass Original_Password

例:

keytool -storepasswd -new password -keystore appTrustKeyStore.jks -storepass changeit

3. キーツール・ユーティリティを使用してCA証明書をappTrustKeyStoreにインポートします。

CA証明書CertGenCA.derは、utils.CertGenツールによって生成されるすべての証明書の署名に使用され、WL_HOME/server/libディレクトリに置かれています。

次の構文を使用して、証明書をインポートします。

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

21.1.2.5 トラスト・ストアへのロード・バランサ証明書のインポート

SSLハンドシェイクが適切に行われるには、ロード・バランサの証明書をWLSサーバーのトラスト・ストアに追加する必要があります。追加するには、次の手順を実行します。

1. ブラウザでSSLのサイトにアクセスします(これにより、サーバーの証明書がブラウザのリポジトリに追加されます)。

2. ブラウザの証明書管理ツールから、証明書を、サーバーのファイル・システムにある(soa.example.comのようなファイル名を持つ)ファイルにエクスポートします。

3. keytoolを使用して、ロード・バランサの証明書をトラスト・ストアにインポートします。

keytool -import -file soa.example.com -v -keystore appTrustKeyStore.jks

21.1.2.6 Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加

各サーバーが更新済のトラスト・ストアにアクセスできるようにするには、エンタープライズ・デプロイメント内の各ドメイン・ホーム・ディレクトリにsetUserOverrides.shスクリプトを作成して編集します。

1. SOAHOST1にログインして、テキスト・エディタで次のファイルを開きます。

ASERVER_HOME/bin/setUserOverrides.sh

2. 2行を追加してEXTRA_JAVA_PROPERTIES環境変数を設定およびエクスポートし、カスタマイズされたSSLトラスト・ストア・パラメータを挿入します。

EXTRA_JAVA_PROPERTIESのすべての値をファイル内に1行で記述し、その後の新規行にexportコマンドを記述する必要があります。例:

EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Djavax.net.ssl.trustStore=KEYSTORE_HOME/appTrustKeyStore.jks"
export EXTRA_JAVA_PROPERTIES

3. setUserOverrides.shをASERVER_HOME/binディレクトリから、このドメインで使用されるすべてのホスト上のMSERVER_HOME/binディレクトリにコピーします。

注意:
これにはWEBHOSTnホストは含まれません。

setUserOrverrides.shの使用は、従来setDomainEnv.shを編集して実装されてきたドメイン・レベルでの変更を構成するために推奨されるベスト・プラクティスです。setDomainEnv.shを編集することは、ドメインのスクリプトが構成ウィザードで拡張されたり解凍操作で更新されたりすると、そのファイルに対する手動変更が上書きされるため、推奨されません。詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のドメイン全体のサーバー・パラメータのカスタマイズに関する項を参照してください。

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

Oracle WebLogic Server管理コンソールを使用して、カスタム・キーストアを使用するためにWebLogic Serverを構成します。SSL上のフロント・エンドLBRへのアクセスが必要な管理サーバーおよび管理対象サーバーに対して、次の手順を実行します。

IDキーストアおよび信頼キーストアを構成するには:

1. 管理コンソールにログインして「ロックして編集」をクリックします。

2. 左ペインで「環境」を開き、「サーバー」を選択します。

3. IDキーストアおよび信頼キーストアを構成するサーバーの名前をクリックします。

4. 「構成」を選択して、「キーストア」を選択します。

5. 「キーストア」フィールドで、「変更」をクリックし、秘密鍵/デジタル証明書のペアおよび信頼できるCA証明書の格納および管理に使用するための「カスタムIDとカスタム信頼」方法を選択して、「保存」をクリックします。

6. 「ID」セクションで、アイデンティティ・キーストアの属性を定義します。

- カスタムIDキーストア: アイデンティティ・キーストアの完全修飾パスを入力します。

KEYSTORE_HOME/appIdentityKeyStore.jks

- カスタムIDキーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

- カスタムIDキーストアのパスフレーズ: 「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で指定したパスワードKeystore_Passwordを入力します
この属性はオプションの場合も必須の場合もあります。どちらになるかはキーストアのタイプによって決まります。すべてのキーストアで、キーストアに書き込むためにはパスワードが必須です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

7. 「信頼」セクションで、トラスト・キーストアの次のプロパティを定義します。

- カスタム信頼キーストア: トラスト・キーストアの完全修飾パスを入力します。

KEYSTORE_HOME/appTrustKeyStore.jks

- カスタム信頼キーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

- カスタム信頼キーストアのパスフレーズ: 「keytoolユーティリティを使用した信頼キーストアの作成」で、新規パスワードとして指定したパスワード。
前の手順で説明したとおり、この属性はオプションの場合も必須の場合もあり、どちらになるかはキーストアのタイプによって決まります。

8. 「保存」をクリックします。

9. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

10. 「ロックして編集」をクリックします。

11. 「構成」をクリックし、「SSL」をクリックします。

12. 「秘密鍵の別名」フィールドで、管理対象サーバーがリスニングを実行するホスト名に使用した別名を入力します。

「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」で作成したキーストアのパスワードを入力します

13. 「保存」をクリックします。

14. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

15. 管理サーバーを再起動します。

16. キーストアが更新された管理対象サーバーを再起動します。

注意:

管理コンソール/ノード・マネージャを使用してサーバーを再起動できるということは、ノード・マネージャ、管理サーバーおよび管理対象サーバー間の通信が正常であるということです。

21.1.2.8 SSLエンドポイントを使用したコンポジットのテスト

SSLが有効になると、Oracle Enterprise Manager FMW Controlから、SSL上のコンポジット・エンドポイントを検証できます。SSLエンドポイントをテストするには、次の手順に従います。

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

http://ADMINVHN:7001/em

この例では、次のようになります。

- ADMINVHNを、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」でADMINVHN仮想IPアドレスに割り当てたホスト名に置き換えます。

- ポート7001は、管理サーバー・コンソールおよびFusion Middleware Controlで一般的に使用されるポートです。ただし、ドメインを作成したときに構成ウィザードのセッションの終わりに表示された実際のURLを使用する必要があります。

2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

3. 左側のツリーから、SOAを開きます。「soa-infra」(WLS_SOAn)をクリックして、コンポジットがデプロイされたパーティションを選択します。

4. コンポジットを選択します。

5. 右側のペインで、「テスト」タブをクリックします。

6. WSDLまたはWADLアドレスで、http://soa.example.com:80をsoa.example.comに置き換えます。

7. 「WSDLまたはWADLの解析」をクリックします。

8. 表示されるエンドポイントURLがSSLであることを確認します。

9. コンポジットをテストします。Webサービスのレスポンスが期待どおりであれば、管理サーバーとロード・バランサ間のSSL通信は正常に構成されています。

21.1.3 エンタープライズ・デプロイメントの管理用のロールの構成

この項では、固有の管理ロールを使用する製品のサマリーを示し、製品固有の管理ロールをエンタープライズ・デプロイメント管理グループに追加する手順を示します。

各エンタープライズ・デプロイメントは複数の製品で構成されています。製品の一部には、各製品への管理アクセスの制御に使用される、特定の管理ユーザー、ロールまたはグループが存在します。

ただし、複数の製品で構成されているエンタープライズ・デプロイメントでは、単一のLDAPベースの認可プロバイダと、単一の管理ユーザーおよびグループを使用して、デプロイメントのあらゆる側面に対するアクセスを制御できます。認可プロバイダの作成と、エンタープライズ・デプロイメントの管理ユーザーおよびグループのプロビジョニングの詳細は、「新しいLDAPオーセンティケータの作成と新しいエンタープライズ・デプロイメント管理者ユーザーおよびグループのプロビジョニング」を参照してください。

単一のエンタープライズ・デプロイメント・ドメイン内で各製品を効率的に管理できるようにするには、特定の管理ロールまたはグループを必要とする製品を理解すること、単一の共通エンタープライズ・デプロイメントの管理グループに特定の製品管理ロールを追加する方法を知ること、さらに必要な場合は、必須の製品固有の管理グループにエンタープライズ・デプロイメントの管理ユーザーを追加する方法を知ることが必要になります。

詳細な情報は、次のトピックを参照してください

- 特定の管理ロールを持つ製品のサマリー

- 特定の管理グループを持つOracle SOA Suite製品のサマリー

- エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加

- 製品固有の管理グループへのエンタープライズ・デプロイメントの管理ユーザーの追加

21.1.3.1 特定の管理ロールを持つ製品のサマリー

次の表に、エンタープライズ・デプロイメント用にLDAP認可プロバイダで定義した、エンタープライズ・デプロイメントの管理グループ(SOA Administrators)に追加する必要のある特定の管理ロールを持つ、Fusion Middleware製品のリストを示します。

次の表の情報と「エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加」の手順を使用して、必要な管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。

製品

アプリケーション・ストライプ

割り当てられる管理ロール

Oracle Web Services Manager。

wsm-pm

policy.updater

SOAインフラストラクチャ

soa-infra

SOAAdmin

Oracle Service Bus

Service_Bus_Console

MiddlewareAdministrator

エンタープライズ・スケジューラ・サービス

ESSAPP

ESSAdmin

Oracle B2B

b2bui

B2BAdmin

Oracle MFT

mftapp

Oracle MFT

mftess

21.1.3.2 特定の管理グループを持つOracle SOA Suite製品のサマリー

表21-1には、特定の管理グループを使用する必要のあるOracle SOA Suite製品のリストを示します。

これらのコンポーネントごとに、共通エンタープライズ・デプロイメントの管理ユーザーを製品固有の管理グループに追加する必要があります。追加しなければ、「エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング」で作成したEnterprise Managerの管理ユーザーを使用して製品リソースを管理できません。

表21-1の情報と「製品固有の管理グループへのエンタープライズ・デプロイメントの管理ユーザーの追加」の手順を使用して、必要な管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。

表21-1 製品固有の管理グループを持つOracle SOA Suite製品

製品

製品固有の管理グループ

Oracle Business Activity Monitoring

BAMAdministrators

Oracle Business Process Management

Administrators

Oracle Service Bus統合

IntegrationAdministrators

MFT

OracleSystemGroup

注意:
MFTでは、集中LDAPに特定のユーザー(OracleSystemUser)を追加する必要があります。このユーザーは、OracleSystemGroupグループに属している必要があります。MFTジョブの作成および削除が適切に動作するように、ユーザー名とユーザー・グループの両方を集中LDAPに追加する必要があります。

21.1.3.3 エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加

製品固有の管理ロールを必要とする製品では、次の手順を使用して、その管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。

1. Oracle WebLogic Server管理サーバーの資格証明を使用して、Oracle Enterprise Manager Fusion Middleware Controlにログインします。

これらは、最初にドメインを構成し、Oracle WebLogic Server管理ユーザー名(通常weblogic_soa)とパスワードを作成したときに作成した資格証明です。

2. 「WebLogicドメイン」メニューから、「セキュリティ」→「アプリケーション・ロール」を選択します。

3. 製品固有のアプリケーション・ロールごとに、「アプリケーション・ストライプ」ドロップダウン・メニューから対応するアプリケーション・ストライプを選択します。

4. 「アプリケーション・ロールの検索」アイコンをクリックして、ドメインで利用できるすべてのアプリケーション・ロールを表示します。

5. エンタープライズ・デプロイメントの管理グループに追加するアプリケーション・ロールの行を選択します。

6. 「編集」アイコンをクリックして、ロールを編集します。

7. 「アプリケーション・ロールの編集」ページの「追加」アイコンをクリックします。

8. 「プリンシパルの追加」ダイアログ・ボックスで、「タイプ」ドロップダウン・メニューから「グループ」を選択します。

9. 「プリンシパル名」の「次で始まる」フィールドにグループ名(SOA Administratorsなど)を入力し、右矢印をクリックして検索を開始して、エンタープライズ・デプロイメントの管理者グループを検索します。

10. 検索結果で管理者グループを選択して「OK」をクリックします。

11. 「アプリケーション・ロールの編集」ページで、「OK」をクリックします。

21.1.3.4 製品固有の管理グループへのエンタープライズ・デプロイメントの管理ユーザーの追加

製品固有の管理グループを持つ製品では、次の手順を使用して、エンタープライズ・デプロイメントの管理ユーザー(weblogic_soa)をグループに追加します。これにより、Enterprise Managerの管理者ユーザーを使用して製品を管理できるようになります。

1. 以下に示すような、product_admin_group.ldifというLDIFファイルを作成します。

dn: cn=product-specific_group_name, cn=groups, dc=us, dc=oracle, dc=com
displayname: product-specific_group_display_name
objectclass: top
objectclass: groupOfUniqueNames
objectclass: orclGroup
uniquemember: cn=weblogic_soa,cn=users,dc=us,dc=oracle,dc=com
cn: product-specific_group_name
description: Administrators Group for the Domain

この例では、product-specific_group_nameを、表21-1で示す製品管理者グループの実際の名前と置き換えます。

product-specific_group_display_nameを、LDAPサーバーの管理コンソールとOracle WebLogic Server管理コンソールに表示されるグループの表示名と置き換えます。

2. LDIFファイルを使用して、エンタープライズ・デプロイメントの管理者ユーザーを製品固有の管理グループに追加します。

Oracle Unified Directoryの場合:

OUD_INSTANCE_HOME/bin/ldapmodify -a
-D "cn=Administrator"
-X
-p 1389
-f product_admin_group.ldif

Oracle Internet Directoryの場合:

OID_ORACLE_HOME/bin/ldapadd -h oid.example.com
-p 389
-D cn="orcladmin"
-w <password>
-c
-v
-f product_admin_group.ldif

21.1.4 エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用

次の項では、トランザクション・ログ(TLOG)およびJMSにJDBC永続ストアを使用する方法のガイドラインを示します。サポートされているデータベースで永続ストアを構成するための手順も示します。

- TLOGおよびJMSのJDBC永続ストアについて
Oracle Fusion MiddlewareではOracle WebLogic Serverトランザクション・ログ(TLOG)とJMSに対して、データベース・ベースとファイル・ベース両方の永続ストアをサポートしています。お使いの環境の永続ストア戦略を決定する前に、各方法の長所と短所を検討してください。

- JMS永続ストアとTLOGを使用する製品およびコンポーネント

- TLOGおよびJMS永続ストアのパフォーマンスへの影響
トランザクション・ログのストレージ方法およびJMS永続ストアを選択する際の考慮事項の1つとして、パフォーマンスへの影響があげられます。この項では、TLOGおよびJMSにJDBC永続ストアを使用する場合のパフォーマンスへの影響を明らかにするのに役立つ、ガイドラインや詳細をいくつか示します。

- TLOGに対するJDBC永続ストアの構成のロードマップ
次の項では、トランザクション・ログにデータベース・ベースの永続ストアを構成する方法について説明します。

- JMSに対するJDBC永続ストアの構成のロードマップ
次の項では、JMSにデータベース・ベースの永続ストアを構成する方法について説明します。

- TLOG用のユーザーおよび表領域の作成
トランザクション・ログにデータベース・ベースの永続ストアを作成する前に、サポートされているデータベースでユーザーと表領域を作成する必要があります。

- JMS用のユーザーおよび表領域の作成
JMSにデータベース・ベースの永続ストアを作成する前に、サポートされているデータベースでユーザーと表領域を作成する必要があります。

- TLOGおよびJMSストアのGridLinkデータ・ソースの作成
JMSおよびTLOGにデータベース・ベースの永続ストアを構成する前に、TLOG永続ストアとJMS永続ストアにそれぞれ1つずつ、2つのデータ・ソースを作成する必要があります。

- 管理対象サーバーへのTLOG JDBCストアの割当て
データベースでユーザーと表領域を作成し、データ・ソースを作成したら、必要な各管理対象サーバーにTLOG永続ストアを割り当てることができます。

- JDBC JMSストアの作成
データベースでJMS永続ストア・ユーザーと表領域を作成し、JMS永続ストアのデータ・ソースを作成したら、管理コンソールを使用してストアを作成できます。

- JMSサーバーへのJMS JDBCストアの割当て
データベースでJMS表領域とユーザーを作成し、JMSデータ・ソースを作成し、JMSストアを作成したら、必要な各JMSサーバーにJMS永続ストアを割り当てることができます。

- JMS JDBCストアに必要な表の作成
JMSにJDBC永続ストアを使用する最後の手順は、必要なJDBCストア表を作成することです。このタスクは、ドメインで管理対象サーバーを再起動する前に実行します。

21.1.4.1 TLOGおよびJMSのJDBC永続ストアについて

Oracle Fusion MiddlewareではOracle WebLogic Serverトランザクション・ログ(TLOG)とJMSに対して、データベース・ベースとファイル・ベース両方の永続ストアをサポートしています。お使いの環境の永続ストア戦略を決定する前に、各方法の長所と短所を検討してください。

注意:

選択するストレージ方法に関係なく、トランザクションの整合性および一貫性を確保するために、JMSとTLOGの両方に同じタイプのストアを使用することをお薦めします。

TLOGおよびJMSデータをOracleデータベースに格納する場合、データベースの複製機能と高可用性機能を利用できます。たとえば、OracleData Guardを使用してサイト間の同期を簡易化できます。これは、Oracle Fusion Middlewareを障害回復構成でデプロイする場合に特に重要です。

また、TLOGおよびJMSデータをデータベースに格納するということは、このデータ専用の共有記憶域の場所を識別する必要がないことを意味します。ただし、エンタープライズ・デプロイメントの他の局面では、共有記憶域は依然として必要です。たとえば、管理サーバー構成(管理サーバーのフェイルオーバーをサポートするため)、デプロイメント・プラン、ファイル/FTPアダプタ制御や処理ファイルなどのアダプタ・アーティファクトには必要です。

TLOGおよびJMSストアを共有記憶域デバイスに格納する場合、適切な複製およびバックアップ戦略を使用してデータ損失ゼロを保証することで、このデータを保護できます。また、システム・パフォーマンスも向上する可能性があります。ただし、ファイル・システム保護は常に、Oracle Databaseによって提供される保護よりも弱くなります。

データベース・ベースのTLOGおよびJMSストアを使用する場合のパフォーマンスへの影響の詳細は、「TLOGおよびJMS永続ストアへのパフォーマンスの影響」を参照してください。

21.1.4.2 JMS永続ストアとTLOGを使用する製品およびコンポーネント

どのインストール済製品およびコンポーネントが永続ストアを利用しているかは、WebLogic Serverコンソールの「ドメイン構造」ナビゲーションのドメイン名→「サービス」→「永続ストア」で判別できます。このリストには、ストア名、ストア・タイプ(通常はFileStore)、ターゲットの管理対象サーバー、およびターゲットを移行できるかどうかが示されます。

移行可能なターゲットを持つ永続ストアは、JDBC永続ストアの使用を考慮するうえで適切な候補となります。リストされたMDS関連のストアは、この章の範囲外であり、ここでは検討しません。

21.1.4.3 TLOGおよびJMS永続ストアのパフォーマンスへの影響

トランザクション・ログのストレージ方法およびJMS永続ストアを選択する際の考慮事項の1つとして、パフォーマンスへの影響があげられます。この項では、TLOGおよびJMSにJDBC永続ストアを使用する場合のパフォーマンスへの影響を明らかにするのに役立つ、ガイドラインや詳細をいくつか示します。

トランザクション・ログとJMSストアのパフォーマンスへの影響

トランザクション・ログの場合、ログは本質的に一時的であるため、JDBCストアの使用による影響は比較的小さくて済みます。通常、システム内の他のデータベース操作と比較した場合、影響はほとんどありません。

他方、アプリケーションがJMS集約型である場合、JMSデータベース・ストアはパフォーマンスに大きな影響を及ぼす可能性があります。たとえば、SOA Fusion Order Demo (Oracle SOA Suite環境をテストするために使用されるサンプル・アプリケーション)を使用している場合、JMSデータベース操作はより重い他の多くのSOAデータベース起動によってマスクされるため、ファイル・ベースからデータベース・ベースの永続ストアへの切替えの影響は非常に小さくなります。

パフォーマンスに影響を与える要素

カスタム宛先にJMS DBストアを使用する場合、複数の要素がパフォーマンスに影響を与えます。主なものは、次のとおりです。

- 関与するカスタム宛先とそのタイプ

- 永続化されるペイロード

- SOAシステムの同時実行性(宛先のコンシューマおよびプロデューサ)

上述のいずれかの影響に応じて、次の領域に様々な設定を構成し、パフォーマンスを向上させることができます。

- JMS表に使用されるデータ型のタイプ(RAWの使用対LOBの使用)

- JMS表のセグメント定義(索引および表レベルでのパーティション)

JMSトピックの影響

システムでトピックが集中的に使用されている場合、同時実行性が高まるにつれて、Oracle RACデータベースのパフォーマンス低下はキューの場合よりも大きくなります。OracleがJMSに対して実施したテストでは、様々なペイロード・サイズおよび様々な同時実行性での平均パフォーマンス低下率は、キューの場合は30%未満でした。トピックの場合、影響は40%を超えていました。データベース・ストアを使用するかどうかを決定する際、リカバリの観点からこれらの宛先の重要性を検討してください。

データ型およびペイロード・サイズの影響

ペイロードにRAWデータ型を使用するかSecureFiles LOBデータ型を使用するかを選択する場合、永続化されるペイロードのサイズを考慮してください。たとえば、ペイロード・サイズの範囲が100bから20kの場合、SecureFiles LOBデータ型で必要とされるデータベース時間の量はRAWデータ型よりも若干多くなります。

具体的に言うと、ペイロード・サイズが約4kに達すると、SecureFilesはより多くのデータベース時間を必要とするようになります。これは、4kでは書込みが行外になるためです。約20kのペイロード・サイズで、SecureFilesデータはより効率的になり始めます。ペイロード・サイズが20kを超えると、RAWデータ型に設定されたペイロードのデータベース時間は悪化します。

SecureFilesのもう1つの利点は、500kを超えた時点からペイロードが増加してもデータベース時間が安定化し始める点です。すなわち、その時点で、(SecureFilesにとって)データが500k、1MBまたは2MBのいずれのペイロードを格納しているかは関係なくなります。書込みが非同期化され、すべてのケースで競合が同じになるためです。

ペイロード・サイズが50kに達するまで、キューのスループットに対する同時実行性(プロデューサおよびコンシューマ)の影響はRAWでもSecureFilesでも同じです。ペイロードが小さい場合、同時実行性が変化してもその影響はほぼ同じですが、RAWの方がスケーラビリティがやや優れています。ペイロードが50kを超える場合、SecureFilesの方がスケーラビリティが優れています。

同時実行性、ワーカー・スレッド、データベースのパーティション化の影響

永続ストアに定義された同時実行性とワーカー・スレッドは、索引レベルおよびグローバル・キャッシュ・レベルでRACデータベースの競合の原因になることがあります。1つの単一サーバーで複数のワーカー・スレッドを有効にする場合、または複数のOracle WebLogic Serverクラスタを使用する場合、リバース索引を使用することで様々なことを改善できます。ただし、Oracle Databaseのパーティション化オプションを使用できる場合、かわりにグローバル・ハッシュ・パーティション索引を使用する必要があります。これにより、索引の競合およびグローバル・キャッシュ・バッファ待機が減少し、アプリケーションのレスポンス時間が改善されます。パーティション化はどのケースでも適切に機能しますが、リバース索引で大幅な改善が認められない場合もあります。

21.1.4.4 TLOGに対するJDBC永続ストアの構成のロードマップ

次の項では、トランザクション・ログにデータベース・ベースの永続ストアを構成する方法について説明します。

1. TLOG用のユーザーおよび表領域の作成

2. TLOGおよびJMSストアのGridLinkデータ・ソースの作成

3. 管理対象サーバーへのTLOG JDBCストアの割当て

21.1.4.5 JMSに対するJDBC永続ストアの構成のロードマップ

次の項では、JMSにデータベース・ベースの永続ストアを構成する方法について説明します。

1. JMS用のユーザーおよび表領域の作成

2. TLOGおよびJMSストアのGridLinkデータ・ソースの作成

3. JDBC JMSストアの作成

4. JMSサーバーへのJMS JDBCストアの割当て

5. JMS JDBCストアに必要な表の作成

21.1.4.6 TLOG用のユーザーおよび表領域の作成

トランザクション・ログにデータベース・ベースの永続ストアを作成する前に、サポートされているデータベースでユーザーと表領域を作成する必要があります。

1. tlogsという表領域を作成します。

たとえば、sysdbaユーザーとしてSQL*Plusにログインし、次のコマンドを実行します。

SQL> create tablespace tlogs
logging datafile 'path-to-data-file-or-+asmvolume'
size 32m autoextend on next 32m maxsize 2048m extent management local;

2. TLOGSという名前のユーザーを作成し、そのユーザーにtlogs表領域を割り当てます。

例:

SQL> create user TLOGS identified by password;

SQL> grant create table to TLOGS;

SQL> grant create session to TLOGS;

SQL> alter user TLOGS default tablespace tlogs;

SQL> alter user TLOGS quota unlimited on tlogs;

21.1.4.7 JMS用のユーザーおよび表領域の作成

JMSにデータベース・ベースの永続ストアを作成する前に、サポートされているデータベースでユーザーと表領域を作成する必要があります。

1. jmsという表領域を作成します。

たとえば、sysdbaユーザーとしてSQL*Plusにログインし、次のコマンドを実行します。

SQL> create tablespace jms
logging datafile 'path-to-data-file-or-+asmvolume'
size 32m autoextend on next 32m maxsize 2048m extent management local;

2. JMSという名前のユーザーを作成し、そのユーザーにjms表領域を割り当てます。

例:

SQL> create user JMS identified by password;

SQL> grant create table to JMS;

SQL> grant create session to JMS;

SQL> alter user JMS default tablespace jms;

SQL> alter user JMS quota unlimited on jms;

21.1.4.8 TLOGおよびJMSストアのGridLinkデータ・ソースの作成

JMSおよびTLOGにデータベース・ベースの永続ストアを構成する前に、TLOG永続ストアとJMS永続ストアにそれぞれ1つずつ、2つのデータ・ソースを作成する必要があります。

エンタープライズ・デプロイメントでは、TLOGおよびJMSストアにGridLinkデータ・ソースを使用する必要があります。GridLinkデータ・ソースを作成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。

3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

4. データ・ソースの概要ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次の内容を入力します。

- 「名前」フィールドに、データ・ソースの論理名を入力します。
TLOGストアの場合はTLOGを入力し、JMSストアの場合はJMSを入力します。

- JNDIの名前を入力します。
TLOGストアの場合はjdbc/tlogsを入力し、JMSストアの場合はjdbc/jmsを入力します。

- 「データベース・ドライバ」には、Oracle Driver (Thin) for GridLink Connections Versions: Anyを選択します。

- 「次へ」をクリックします。

5. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」チェック・ボックスを選択解除して「次へ」をクリックします。

6. 「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。

7. 次の接続プロパティを入力します。

- サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。例:
soaedg.example.com

- ホスト名とポート: RACデータベースのSCANアドレスとポートを、コロンで区切って入力します。例:

db-scan.example.com:1521

「追加」をクリックして、フィールドの下のリスト・ボックスにホスト名とポートを追加します。

SCANアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せると、確認できます。

SQL>show parameter remote_listener;

NAME                 TYPE        VALUE

--------------------------------------------------

remote_listener     string      db-scan.example.com

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。例:

dbhost1-vip.mycompany.com (port 1521)

および

dbhost2-vip.mycompany.com (1521)

- データベース・ユーザー名: 次を入力します。
TLOGストアの場合はTLOGSを入力し、JMS永続ストアの場合はJMSを入力します。

- パスワード: データベースでユーザーを作成した際に使用したパスワードを入力します。

- パスワードの確認: もう一度パスワードを入力し、「次へ」をクリックします。

8. 「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。

接続が成功したときに表示される通知の一例を示します。

Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=db-scan.example.com)
(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=soaedg.example.com))) succeeded.

「次へ」をクリックします。

9. 「ONSクライアント構成」ページで、次の手順を実行します。

- 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

- ここにも、次のように、SCANアドレス: RACデータベースのONSリモート・ポート、データベースから報告された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.example.com (port 6200)

および

custdbhost2.example.com (6200)

10. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。

接続が成功したときに表示される通知の一例を示します。

Connection test for db-scan.example.com:6200 succeeded.

「次へ」をクリックします。

11. 「ターゲットの選択」ページで、永続ストアを使用するクラスタを選択し、「クラスタのすべてのサーバー」を選択します。

12. 「終了」をクリックします。

13. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

14. 手順4から手順13を繰り返し、JMSファイル・ストアのGridLinkデータ・ソースを作成します。

21.1.4.9 管理対象サーバーへのTLOG JDBCストアの割当て

データベースでユーザーと表領域を作成し、データ・ソースを作成したら、必要な各管理対象サーバーにTLOG永続ストアを割り当てることができます。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ツリーで「環境」を展開し、「サーバー」を展開します。

4. TLOGストアを使用する管理対象サーバーの名前をクリックします。

5. 「構成」>「サービス」 タブを選択します。

6. 「トランザクション・ログ・ストア」で、「タイプ」メニューから「JDBC」を選択します。

7. 「データ・ソース」メニューで、TLOG永続ストアに作成したデータ・ソースを選択します。

8. 「接頭辞名」フィールドで、構成された各JDBC TLOGストアに一意のJDBC TLOGストア名を生成するための接頭辞名を指定します。

9. 「保存」をクリックします。

10. クラスタ内の追加の管理対象サーバーごとに、手順3から7を繰り返します。

11. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

21.1.4.10 JDBC JMSストアの作成

データベースでJMS永続ストア・ユーザーと表領域を作成し、JMS永続ストアのデータ・ソースを作成したら、管理コンソールを使用してストアを作成できます。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。

3. 「ドメイン構造」ツリーで「サービス」を開き、「永続ストア」を選択します。

4. 「新規」をクリックしてから「JDBCストア」をクリックします。

5. 使用している永続化するJMSサーバーに容易に結び付けられる永続ストア名を入力します。

6. インストールとクラスタを修飾する一意の接頭辞を指定し、JMS永続ストアに作成したデータ・ソースに関連付けます。

7. ストアをJTAサービスをホストするエンティティにターゲット指定します。
サービス移行を使用するサーバーの場合、これはJMSサーバーが属する移行可能なターゲットになります。

8. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

21.1.4.11 JMSサーバーへのJMS JDBCストアの割当て

データベースでJMS表領域とユーザーを作成し、JMSデータ・ソースを作成し、JMSストアを作成したら、必要な各JMSサーバーにJMS永続ストアを割り当てることができます。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ツリーで、「サービス」、「メッセージング」、「JMSサーバー」の順に開きます。

4. 永続ストアを使用するJMSサーバーの名前をクリックします。

5. 「永続ストア」メニューで、前に作成したJMS永続ストアを選択します。

6. 「保存」をクリックします。

7. クラスタ内の追加のJMSサーバーごとに、手順3から6を繰り返します。

8. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

21.1.4.12 JMS JDBCストアに必要な表の作成

JMSにJDBC永続ストアを使用する最後の手順は、必要なJDBCストア表を作成することです。このタスクは、ドメインで管理対象サーバーを再起動する前に実行します。

1. findコマンドを使用してWLSコアJDBCストア・ライブラリの場所を特定し、JDKに付属するjarユーティリティを使用してDDLファイルを一時ディレクトリに抽出します。

mkdir /tmp/edgddl
cd /tmp/edgddl
JAVA_HOME/bin/jar xvf WL_HOME/modules/com.bea.core.store.jdbc.jar weblogic/store/io/jdbc/ddl/

注意:
これにより、サポートされる様々なデータベース・プラットフォーム用およびOracle DB用の複数のDDLファイルが抽出され、必要な機能に基づいて選択できます。

注意:

weblogic/store/io/jdbc/ddlパラメータを省略すると、jarファイル全体が抽出されます。

2. 「TLOGおよびJMS永続ストアのパフォーマンスへの影響」の情報を確認し、現在の環境に適切な表の機能を決定します。

このリリースで提供されるOracle DBスキーマ定義は3つあり、前の手順で確認用に抽出されています。基本定義には、索引のためのパーティションのないRAWデータ型が含まれます。2番目のものはBLOBデータ型を使用し、3番目のものはBLOBデータ型とセキュア・ファイルを使用します。

3. 共有記憶域上にカスタムDDLファイル用として、ドメイン固有の適切に名前付けされたフォルダ構造を作成します。すべてのサーバーで使用できるように、ORACLE_RUNTIME共有ボリュームをお薦めします。

例:

mkdir -p ORACLE_RUNTIME/domain_name/ddl

4. 要件分析に基づいて新しい共有DDLフォルダにjms_custom.ddlファイルを作成します。
たとえば、セキュア・ファイルとハッシュ・パーティション化の両方を使用する最適化されたスキーマ定義を実装するには、次の内容を含むjms_custom.ddlファイルを作成します。

CREATE TABLE $TABLE (
id     int  not null,
type   int  not null,
handle int  not null,
record blob not null,
PRIMARY KEY (ID) USING INDEX GLOBAL PARTITION BY HASH (ID) PARTITIONS 8)
LOB (RECORD) STORE AS SECUREFILE (ENABLE STORAGE IN ROW);

この例を、索引パーティションなしでRAWデータ型が使用される、JMSストアのデフォルトのスキーマ定義と比較することができます。

パーティションの数は2の累乗にする必要があります。これにより、各パーティションがほぼ同じサイズになります。推奨されるパーティションの数は、表または索引の予想増加率によって異なります。データベース管理者(DBA)に一定期間における表の増加率を分析させて、それに応じて表を調整する必要があります。詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

5. 前の手順1でtmpディレクトリに抽出したカスタム・ディレクトリおよびファイルをクリーンアップします。

6. 管理コンソールを使用して、前に作成した既存のJDBCストアを編集し、JMSデータに使用する表を作成します。

a. Oracle WebLogic Server管理コンソールにログインします。

b. 「チェンジ・センター」で、「ロックして編集」をクリックします。

c. 「ドメイン構造」ツリーで「サービス」、「永続ストア」の順に開きます。

d. 前に作成した永続ストアをクリックします。

e. 「詳細」オプションの下で、「DDLファイルからの表の作成」フィールドにORACLE_RUNTIME/domain_name/ddl/jms_custom.ddlと入力します。

f. 「保存」をクリックします。

g. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

7. 管理対象サーバーを再起動します。

21.1.5 エンタープライズ・デプロイメントのバックアップとリカバリの実行

この項では、Oracle SOA Suiteエンタープライズ・デプロイメントの必要なディレクトリと構成データを確実にバックアップするためのガイドラインを示します。

注意:

この項で示す静的なランタイム・アーティファクトの一部は、Network Attached Storage (NAS)からホストされています。可能であれば、これらのボリュームはアプリケーション・サーバーからでなく、NASファイラから直接バックアップおよびリカバリしてください。

Oracle Fusion Middleware製品のバックアップとリカバリの一般情報は、『Oracle Fusion Middlewareの管理』の次の項を参照してください。

- 「環境のバックアップ」

- 「環境のリカバリ」

表21-2は、一般的なOracle SOA Suiteエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。

表21－2 Oracle SOA Suiteエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト

タイプ

ホスト

層

データベースのOracleホーム

DBHOST1およびDBHOST2

データ層

Oracle Fusion Middleware Oracleホーム

WEBHOST1およびWEBHOST2

Web層

Oracle Fusion Middleware Oracleホーム

SOAHOST1およびSOAHOST2

アプリケーション層

インストール関連ファイル

WEBHOST1、WEHOST2および共有記憶域

なし

表21-3は、一般的なOracle SOA Suiteエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。

表21－3 Oracle SOA Suiteエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクト

タイプ

ホスト

層

管理サーバーのドメイン・ホーム(ASERVER_HOME)

SOAHOST1およびSOAHOST2

アプリケーション層

アプリケーション・ホーム(APPLICATION_HOME)

SOAHOST1およびSOAHOST2

アプリケーション層

Oracle RACデータベース

DBHOST1およびDBHOST2

データ層

スクリプトとカスタマイズ

SOAHOST1およびSOAHOST2

アプリケーション層

デプロイメント・プラン・ホーム(DEPLOY_PLAN_HOME)

SOAHOST1およびSOAHOST2

アプリケーション層

OHS構成ディレクトリ

WEBHOST1およびWEBHOST2

Web層

21.2 Oracle SOA Suiteエンタープライズ・デプロイメントの構成および管理タスク

この項では、Oracle SOA Suiteエンタープライズ・デプロイメントで実行する必要性が高い、いくつかの主要な構成および管理タスクについて説明します。

- エンタープライズ・デプロイメントへのOracle SOA Suiteコンポジット・アプリケーションのデプロイ

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

- Oracle SOA Suiteエンタープライズ・デプロイメントでのデータベース増分の管理

21.2.1 エンタープライズ・デプロイメントへのOracle SOA Suiteコンポジット・アプリケーションのデプロイ

Oracle SOA Suiteアプリケーションは、様々な種類のOracle SOA Suiteコンポーネントから構成されるコンポジットとしてデプロイされます。SOAコンポジット・アプリケーションには次が含まれます。

- サービス・コンポーネント。ルーティングのためのOracle Mediator、オーケストレーションのためのBPELプロセス、オーケストレーションのためのBAMプロセス(Oracle BAM Suiteがインストールされている場合)、ワークフロー承認のためのヒューマン・タスク、SOAコンポジット・アプリケーションにJavaインタフェースを統合するためのSpring、ビジネス・ルールを使用するためのデシジョン・サービスなどがあります。

- 外部のサービス、アプリケーションおよびテクノロジに対してSOAコンポジット・アプリケーションを接続するバインディング・コンポーネント(サービスと参照)

これらのコンポーネントが、1つのSOAコンポジット・アプリケーションに組み込まれています。

Oracle SOA Suiteコンポジット・アプリケーションをOracle SOA Suiteエンタープライズ・デプロイメントにデプロイするときは、必ず各コンポジットを、ロード・バランサ・アドレス(soa.example.com)ではなく、特定のサーバーまたはクラスタ・アドレスにデプロイしてください。

ロード・バランサ・アドレスにコンポジットをデプロイするには、多くの場合、デプロイヤ・ノードから外部のロード・バランサ・アドレスへの直接接続が必要になります。そのため、ファイアウォールに追加のポートを開く必要があります。

Oracle SOA Suiteコンポジット・アプリケーションの詳細は、Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理の次の項を参照してください。

- SOAコンポジット・アプリケーションのデプロイ

- SOAコンポジット・アプリケーションの監視

- SOAコンポジット・アプリケーションの管理

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

SOAクラスタ内のSOAインフラストラクチャ・アプリケーションまたはリソース・アダプタを再デプロイするときは、デプロイメント・プランとアプリケーション・ビットに、クラスタ内の全サーバーからアクセスできる必要があります。

SOAのアプリケーションおよびリソース・アダプタは、nostageデプロイメント・モードを使用してインストールされます。nostageデプロイメント・モードを選択した場合、管理サーバーはアーカイブ・ファイルをソースの場所からコピーしないため、各サーバーが同じデプロイメント・プランにアクセスできるようにしておく必要があります。

デプロイメント・プランの場所がドメイン内のすべてのサーバーで利用できるようにするには、「このガイドで使用するファイル・システムとディレクトリ変数」で示され、エンタープライズ・デプロイメント・ワークブック内のDEPLOY_PLAN_HOME変数で表される、デプロイメント・プランのホームの場所を使用します。

21.2.3 Oracle SOA Suiteエンタープライズ・デプロイメントでのデータベース増分の管理

Oracle SOA Suiteデータベースのデータ量が非常に多くなると、特に多くのコンポジット・アプリケーションがデプロイされている可能性のあるOracle SOA Suiteエンタープライズ・デプロイメントでは、データベースの保守が難しくなることがあります。

詳細は、Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理の次の項を参照してください。

- データベース増分管理戦略の策定に関する項

- データベース増分の管理に関する項

22 エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用

次の各項では、Oracle WebLogic Serverのサーバー全体の移行およびOracle WebLogic Serverの自動サービス移行について説明します。Oracle Fusion Middlewareエンタープライズ・トポロジでこれらの機能を使用する方法についても説明します。

- エンタープライズ・デプロイメントでのサーバー全体の移行と自動サービス移行について
Oracle WebLogic Serverは、可用性の高い環境にとって不可欠な要素である移行フレームワークを備えています。次の項では、エンタープライズ・デプロイメントでこのフレームワークを効果的に使用する方法を詳しく説明します。

- リース用のGridLinkデータ・ソースの作成
サーバー全体の移行と自動サービス移動の両方とも、リポジトリ作成ユーティリティ(RCU)によってOracle WebLogic Serverスキーマの一部として自動的に作成される表領域であるリース表のデータ・ソースが必要です。

- エンタープライズ・デプロイメント用のサーバー全体の移行の構成
サーバー全体の移行または自動サービス移行用にドメインを準備した後、クラスタ内の特定の管理対象サーバーに対してサーバー全体の移行を構成できます。詳細は、次の各項を参照してください。

- エンタープライズ・デプロイメントでの自動サービス移行の構成
エンタープライズ・デプロイメント内の特定のサービスに自動サービス移行を構成するには、この項のトピックを参照してください。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理手順

22.1 エンタープライズ・デプロイメントでのサーバー全体の移行と自動サービス移行について

Oracle WebLogic Serverは、可用性の高い環境にとって不可欠な要素である移行フレームワークを備えています。次の項では、エンタープライズ・デプロイメントでこのフレームワークを効果的に使用する方法を詳しく説明します。

- サーバー全体の移行とサービスの移行の違いの理解

- エンタープライズ・デプロイメントでサーバー全体の移行またはサービスの移行を使用する意味

- サーバー全体の移行とサービスの移行が必要となる製品およびコンポーネントの理解

22.1.1 サーバー全体の移行とサービスの移行の違いの理解

Oracle WebLogic Serverの移行フレームワークでは、次の2つの種類の自動移行をサポートしています。

- サーバー全体の移行。障害発生時に、管理対象サーバー・インスタンスが別の物理システムに移行されます。
サーバー全体の移行では、別の物理マシン上で、サーバー・インスタンスとそのすべてのサービスが自動的に再起動されます。サーバー移行が構成されているクラスタに属するサーバーで問題が発生すると、そのサーバーは、クラスタのメンバーをホストする他のマシンで再起動されます。

このためには、サーバーはリスニング・アドレスとして浮動IPを使用する必要があり、必要なリソース(トランザクション・ログとJMS永続ストア)が候補マシンで利用できなければなりません。

詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。

- サービスの移行。特定のサービスが、クラスタ内の別の管理対象サーバーに移行されます。
サービスの移行を理解するには、固定サービスを理解することが重要です。

WebLogic Serverクラスタでは、ほとんどのサブシステム・サービスがクラスタ内のすべてのサーバー・インスタンスで均一にホストされます。これにより、サーバー間の透過的なフェイルオーバーが可能になります。対照的に、JMS関連サービスやJTAトランザクション・リカバリ・サービス、ユーザー定義のシングルトン・サービスなどの固定サービスは、クラスタ内の個々のサーバー・インスタンスにホストされます。WebLogic Serverの移行フレームワークは、これらのサービスに対して、フェイルオーバーではなく、サービスの移行による障害回復をサポートしています。

詳細は、『Oracle WebLogic Serverクラスタの管理』の「サービスの移行フレームワークの理解」を参照してください。

22.1.2 エンタープライズ・デプロイメントでサーバー全体の移行またはサービスの移行を使用する意味

サーバーまたはサービスが別のシステムで再起動されるときは、必要なリソース(サービス・データ、ログなど)が元のシステムとフェイルオーバー・システムの両方で利用できなければなりません。利用できなければ、サービスは、同じ操作をフェイルオーバー・システムで正常に再開できません。

このような理由から、サーバー全体の移行とサービスの移行の両方で、クラスタのすべてのメンバーが、同一のトランザクションとJMS永続ストア(ファイルベースかデータベースベースかを問わない)にアクセスできる必要があります。

これが、エンタープライズ・デプロイメントで共有記憶域が重要となる、もう1つの理由です。共有記憶域を適切に構成すると、手動フェイルオーバー(管理サーバーのフェイルオーバー)または自動フェイルオーバー(サーバー全体の移行またはサービスの移行)が発生したときに、元のマシンとフェイルオーバー・マシンの両方が、サービスを変更しなくても、確実に同一のファイル・ストアにアクセスできるようになります。

自動サービス移行の場合、固定サービスの再開が必要になったときは、フェイルオーバー前に固定サービスによって使用されていたJMSとJTAのログにアクセスできる必要があります。

サーバー全体の移行の場合、共有記憶域のほかに、仮想IPアドレス(VIP)の入手と割当ても必要になります。管理対象サーバーが別のマシンにフェイルオーバーされると、VIPは新しいマシンに自動的に再割り当てされます。

サービスの移行には、VIPは必要ありません。

22.1.3 サーバー全体の移行とサービスの移行が必要となる製品およびコンポーネントの理解

表には、推奨されるベスト・プラクティスがリストされています。サーバー全体の移行または自動サーバー移行をサポートするコンポーネントで、これらを使用することはかまいません。

コンポーネント

サーバー全体の移行(WSM)

自動サービス移行(ASM)

Oracle Web Services Manager(OWSM)

いいえ

いいえ

Oracle SOA Suite

いいえ

はい

Oracle Service Bus

いいえ

はい

Oracle Business Process Management

いいえ

はい

Enterprise Enterprise Scheduler

いいえ

いいえ

Oracle Business Activity Monitoring

いいえ

はい

Oracle B2B

いいえ

はい

22.2 リース用のGridLinkデータ・ソースの作成

サーバー全体の移行と自動サービス移動の両方とも、リポジトリ作成ユーティリティ(RCU)によってOracle WebLogic Serverスキーマの一部として自動的に作成される表領域であるリース表のデータ・ソースが必要です。

エンタープライズ・デプロイメントでは、GridLinkデータ・ソースを作成する必要があります。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。

3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

4. データ・ソースの概要ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次の内容を入力します。

- 「名前」フィールドに、データ・ソースの論理名を入力します。たとえば、Leasingと入力します。

- JNDIの名前を入力します。たとえば、jdbc/leasingです。

- 「データベース・ドライバ」には、Oracle Driver (Thin) for GridLink Connections Versions: Anyを選択します。

- 「次へ」をクリックします。

5. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」チェック・ボックスを選択解除して「次へ」をクリックします。

6. 「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。

7. 次の接続プロパティを入力します。

- サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。例:
soaedg.example.com

- ホスト名とポート: RACデータベースのSCANアドレスとポートを、コロンで区切って入力します。例:

db-scan.example.com:1521

「追加」をクリックして、フィールドの下のリスト・ボックスにホスト名とポートを追加します。

SCANアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せると、確認できます。

SQL>show parameter remote_listener;

NAME                 TYPE        VALUE

--------------------------------------------------

remote_listener     string      db-scan.example.com

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。例:

dbhost1-vip.mycompany.com (port 1521)

および

dbhost2-vip.mycompany.com (1521)

Oracle Database 10gの場合は、マルチ・データ・ソースを使用してOracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- データベース・ユーザー名: 次を入力します。

FMW1221_WLS_RUNTIME

この例では、FMW1221は、最初のエンタープライズ・マネージャ・ドメインを構成する際、スキーマの作成時に使用した接頭辞です。

Oracle Fusion Middlewareの前のバージョンでは、移行リース表のために手動でユーザーと表領域を作成する必要がありました。Fusion Middleware 12c (12.2.1)では、リース表はリポジトリ作成ユーティリティ(RCU)でWLSスキーマを作成する際に自動的に作成されます。

- パスワード: RCUでWLSスキーマを作成した際に使用したパスワードを入力します。

- パスワードの確認: もう一度パスワードを入力し、「次へ」をクリックします。

8. 「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。

接続が成功したときに表示される通知の一例を示します。

Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=db-scan.example.com)
(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=soaedg.example.com))) succeeded.

「次へ」をクリックします。

9. 「ONSクライアント構成」ページで、次の手順を実行します。

- 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

- ONSホストとポート・フィールドにSCANアドレスを入力し、「追加」をクリックしてから「追加」をクリックします。
この値は、RACデータベースのONSホストとONSリモート・ポートである必要があります。データベースの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.example.com (port 6200)

および

custdbhost2.example.com (6200)

10. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。

接続が成功したときに表示される通知の一例を示します。

Connection test for db-scan.example.com:6200 succeeded.

「次へ」をクリックします。

11. 「ターゲットの選択」ページで、サーバー全体の移行または自動サービス移行を構成するクラスタ選択し、「クラスタのすべてのサーバー」を選択します。

12. 「終了」をクリックします。

13. 「変更のアクティブ化」をクリックします。

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

サーバー全体の移行または自動サービス移行用にドメインを準備した後、クラスタ内の特定の管理対象サーバーに対してサーバー全体の移行を構成できます。詳細は、次の各項を参照してください。

- ノード・マネージャのプロパティ・ファイルを編集してサーバー全体の移行を有効化

- wlsifconfig.shスクリプトの環境とスーパーユーザー権限の設定

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

- サーバー全体の移行のテスト

22.3.1 ノード・マネージャのプロパティ・ファイルを編集してサーバー全体の移行を有効化

この項では、サーバーが実行されている2つのノード上のノード・マネージャのプロパティ・ファイルを編集します。

1. 次のファイルを探してテキスト・エディタで開きます。

MSERVER_HOME/nodemanager/nodmeanager.properties

2. nodemanager.propertiesファイルのStartScriptEnabledプロパティをtrueに設定していない場合はtrueに設定します。

これは、ノード・マネージャが管理対象サーバーを起動するために必要です。

3. 次のプロパティをnodemanager.propertiesファイルに追加して、サーバー移行が正常に動作するようにします。

- 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フラグを使用するかどうかを指定します。

4. ノード・マネージャを再起動します。

5. これらのプロパティが適用されていることをノード・マネージャの出力(ノード・マネージャが起動したシェル)で確認します。それ以外の場合、移行中に問題が発生する可能性があります。出力は次のようになります。

...
SecureListener=true
LogCount=1
eth0=*,NetMask=255.255.255.0
...

22.3.2 wlsifconfig.shスクリプトの環境とスーパーユーザー権限の設定

この項では、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定します。このスクリプトは、移行中に、IPアドレスをマシンからマシンに転送するために使用します。通常スーパーユーザーのみが利用可能なifconfigの実行が可能でなければなりません。

wlsifconfig.shスクリプトの詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の自動移行の構成に関する項を参照してください。

wlsifconfig.shスクリプトを実行するためにシステムを準備する手順は、次の項を参照してください。

- wlsifconfig.shスクリプトのPATH環境変数の設定

- wlsifconfig.shスクリプトに対する権限の付与

22.3.2.1 wlsifconfig.shスクリプトのPATH環境変数の設定

次の表に記載されているコマンドは、各ホスト・コンピュータのPATH環境変数に必ず含めてください。

ファイル

ディレクトリの場所

wlsifconfig.sh

MSERVER_HOME/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domains

MSERVER_HOME/nodemanager

22.3.2.2 wlsifconfig.shスクリプトに対する権限の付与

パスワードによる制限を設けずにsudo権限をオペレーティング・システム・ユーザー(oracleなど)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

注意:

セキュリティ上の理由から、sudoを、wlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定する必要があります。

この必須の構成タスクを実行するためのsudo権限とsystem権限については、必要に応じてシステム管理者に問い合せてください。

/etc/sudoers内の次のエントリ例では、ifconfigとarpingを実行するために、oracleに対してsudo実行権限を付与しています。

Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

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

クラスタ内の移行を構成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。

3. 移行を構成するクラスタを、表の「名前」列でクリックします。

4. 「移行」タブをクリックします。

5. 「ロックして編集」をクリックします。

6. 「移行基盤」として「データベース」を選択します。ドロップダウン・リストから、「自動移行に使用するデータ・ソース」として「リース」を選択します。

7. 「移行可能サーバーの候補マシン」の「使用可能」フィールドでクラスタ内の管理対象サーバーを選択し、右矢印をクリックして「選択済み」に移動します。

8. 「リース用のGridLinkデータ・ソースの作成」で作成したリース・データ・ソースを選択します。

9. 「保存」をクリックします。

10. サーバー移行の候補となるマシンを設定します。管理対象サーバーすべてについてこのタスクを次のように実行する必要があります。

a. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。

b. 移行を構成するサーバーを選択します。

c. 「移行」タブをクリックします。

d. 「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。

アプリケーションとリソースのターゲット設定の詳細は、「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

e. 「移行の構成」セクションにある「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。
この手順では、現在のホストを使用できなくなったときの、管理対象サーバーのフェイルオーバー先のホストを識別します。たとえば、HOST1上の管理対象サーバーにはHOST2を選択し、HOST2の管理対象サーバーにはHOST1を選択します。

ヒント:

「サーバーの概要」ページの「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動すると、サーバーを実行しているマシンを確認できます。このサーバーが自動的に移行すると、構成と異なる内容になります。

11. 「変更のアクティブ化」をクリックします。

12. 管理サーバーと、サーバー移行が構成されたサーバーを再起動します。

22.3.4 サーバー全体の移行のテスト

この項の手順を実行して、サーバー全体の自動移行が適切に機能していることを確認します。

ノード1からテストする手順は次のとおりです。

1. 管理対象サーバーのプロセスを停止します。

kill -9 pid

pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。

ps -ef | grep WLS_SOA1

2. ノード・マネージャのコンソール(killコマンドを実行したターミナル・ウィンドウ)を確認します。管理対象サーバーの浮動IPが無効になっていることを示すメッセージが表示されているはずです。

3. ノード・マネージャが管理対象サーバーの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャがサーバーを再起動し、サーバーが「実行中」状態になる前に、関連するプロセスを再度強制終了します。
サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:

必要な再起動回数は、次の構成ファイルのRestartMaxパラメータで設定されます。

MSERVER_HOME/servers/WLS_SOA1/data/nodemanager/startup.properties

デフォルト値はRestartMax=2です。

ノード2からテストする手順は次のとおりです。

1. ローカルのノード・マネージャのコンソールを確認します。ノード1で最後に管理対象サーバーの再起動が試行されてから30秒経過した後、ノード2のノード・マネージャによって、管理対象サーバーの浮動IPが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。

2. 同じIPアドレスを使用して製品URLにアクセスします。URLが正常な場合、移行は成功です。

管理コンソールからの検証

Oracle WebLogic Server管理コンソールを使用して、移行を検証することもできます。

1. 管理コンソールにログインします。

2. 左側のコンソールで、「ドメイン」をクリックします。

3. 「監視」タブをクリックし、「移行」サブタブをクリックします。

「移行の状態」の表に、移行の状態に関する情報が表示されます。

注意:

サーバーの移行後、そのサーバーを元のマシンにフェイルバックするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

22.4 エンタープライズ・デプロイメントでの自動サービス移行の構成

エンタープライズ・デプロイメント内の特定のサービスに自動サービス移行を構成するには、この項のトピックを参照してください。

注意:

このSOA Suite機能は、Oracle Integration Continuous Availabilityの一部です。Oracle SOA Suite for Middlewareオプションの詳細は、『Oracle Fusion Middlewareライセンス情報』を参照してください。

- エンタープライズ・デプロイメント・クラスタに対するリース・メカニズムおよびデータ・ソースの設定

- クラスタ内の管理対象サーバーの移行設定の変更

- サービス移行ポリシーの選択について

- クラスタ内の各管理対象サーバーに対するサービス移行ポリシーの設定

- 管理対象サーバーの再起動および自動サービス移行の検証

- 自動サービス移行後のサービスのフェイルバック

22.4.1 エンタープライズ・デプロイメント・クラスタに対するリース・メカニズムおよびデータ・ソースの設定

自動サービス移行を構成する前に、自動サービス移行機能で使用されるリース・メカニズムとデータ・ソースを確認する必要があります。

注意:

次の手順は、「リース用のGridLinkデータ・ソースの作成」に説明されているとおりに、リース・データ・ソースがすでに作成されていることを前提としています。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。
「クラスタのサマリー」ページが表示されます。

4. 表の「名前」列で、移行を構成するクラスタをクリックします。

5. 「移行」タブをクリックします。

6. 「移行基盤」ドロップダウン・メニューでデータベースが選択されていることを確認します。

7. 「自動移行に使用するデータ・ソース」ドロップダウン・メニューから「リース用のGridLinkデータ・ソースの作成」で作成したリース・データ・ソースを選択します。

8. 「保存」をクリックします。

9. 変更のアクティブ化

10. 管理対象サーバーを再起動します。

22.4.2 クラスタ内の管理対象サーバーの移行設定の変更

クラスタにリース・メカニズムとデータ・ソースを設定した後、サービス移行を構成する管理対象サーバーに対して、自動JTA移行を有効化できます。この項は、JTAサービスをエンタープライズ・デプロイメントの一部としてデプロイする場合にのみ該当します。

各クラスタで管理対象サーバーの移行設定を変更するには:

1. まだ行っていない場合、管理コンソールにログインして「ロックして編集」をクリックします。

2. 「ドメイン構造」ペインで「環境」ノードを開き、「サーバー」をクリックします。
「サーバーのサマリー」ページが表示されます。

3. 表の「名前」列で、変更するサーバーの名前をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

4. 「移行」タブをクリックします。

5. 「JTA移行ポリシー」ドロップダウン・メニューで「障害リカバリ」を選択します。

6. ページの「JTA候補サーバー」セクションの「使用可能」リスト・ボックスで管理対象サーバーを選択し、移動ボタンをクリックして「選択済み」リストに移動します。

7. ページの「JMSサービスの候補サーバー」セクションの「使用可能」リスト・ボックスで管理対象サーバーを選択し、移動ボタンをクリックして「選択済み」リスト・ボックスに移動します。

8. 「保存」をクリックします。

9. すべての管理対象サーバーと管理サーバーを再起動します。

22.4.3 サービス移行ポリシーの選択について

自動サービス移行を構成する際は、クラスタごとにサービス移行ポリシーを選択します。この項では、サービス移行ポリシーを選択する際のガイドラインと考慮事項を示します。

たとえば、シングルトンを実行するまたはパス・サービスを使用する製品またはコンポーネントは、必ず1回自動移行ポリシーのメリットを享受することができます。このポリシーにより、候補サーバーのリストにある管理ターゲット・サーバーが1つ以上動作している場合、この移行可能ターゲットでホストされるサービスは、サーバーが失敗するか管理者によって(正常または強制的に)シャットダウンされた場合に、クラスタ内のいずれかの場所でアクティブ化されます。これにより、複数の同種のサービスが起動時に1つのサーバー上で終了することがあります。

このポリシーを使用している場合は、クラスタの起動を監視して、各サーバー上でどのサーバーが実行されているかを特定する必要があります。その後、必要に応じて手動フェイルバックを実行し、システムをバランスのとれた構成にすることができます。

他のFusion Middlewareコンポーネントは、自動移行障害リカバリ・サービス・ポリシーに適しています。このポリシーでは、移行可能ターゲットのユーザー優先サーバー(UPS)が起動している場合にのみ、移行可能ターゲットでホストされているサービスが起動できます。

これらのガイドラインに基づき、Oracle SOA Suiteエンタープライズ・トポロジには次のポリシーが推奨されます。

- SOA_Cluster: 自動移行障害リカバリ・サービス

- OSB_Cluster: 必ず1回のサービスを自動移行

- BAM_Cluster: 必ず1回のサービスを自動移行

詳細は、『Oracle WebLogic Serverクラスタの管理』の手動および自動サービス移行のポリシーに関する項を参照してください。

22.4.4 クラスタ内の各管理対象サーバーに対するサービス移行ポリシーの設定

クラスタ内の各サーバーの移行設定を変更したら、WebLogic管理コンソールを使用してサービスを識別し、クラスタ内の各管理対象サーバーの移行ポリシーを設定できます。

1. まだ行っていない場合、管理コンソールにログインして「ロックして編集」をクリックします。

2. 「ドメイン構造」ペインで、「環境」、「クラスタ」の順に展開して「移行可能なターゲット」を選択します。

3. クラスタ内の最初の管理対象サーバーの名前をクリックします。

4. 「移行」タブをクリックします。

5. 「サービス移行ポリシー」ドロップダウン・メニューで、クラスタに適したポリシーを選択します。
詳細は、「サービス移行ポリシーの選択について」を参照してください。

6. 「保存」をクリックします。

7. クラスタ内の追加の管理対象サーバーごとに、手順2から6を繰り返します。

8. 変更をアクティブ化します。

9. クラスタ内の管理対象サーバーを再起動します。

22.4.5 管理対象サーバーの再起動および自動サービス移行の検証

クラスタおよび管理対象サーバーの自動サービス移行を構成後、次のように構成を検証します。

1. まだ行っていない場合、管理コンソールにログインします。

2. 「ドメイン構造」ペインで、「環境」、「クラスタ」の順に展開して、先ほど自動サービス移行用に構成したクラスタを再起動します。

3. 「ドメイン構造」ペインで、「環境」、「クラスタ」の順に開きます。

4. 「移行可能なターゲット」をクリックします。

5. 「制御」タブをクリックします。
コンソールに、移行可能なターゲットとその現在のホスト・サーバーがリストされます。

6. 「移行可能なターゲット」表で、いずれかの移行可能なターゲットの行を選択します。

7. 「現在のホスト・サーバー」列の値を書き留めます。

8. オペレーティング・システムのコマンドラインを使用して、最初の管理対象サーバーを停止します。

次のコマンドを使用して管理対象サーバーのプロセスを強制終了し、クラッシュ・シナリオをシミュレートします。

kill -9 pid

この例では、pidを、管理対象サーバーのプロセスID (PID)に置き換えます。次のUNIXコマンドを実行すると、PIDを確認できます。

ps -ef | grep managed_server_name

プロセスの強制終了後、管理対象サーバーが、プロセスを最初に強制終了した後に自動的に起動するように構成されている可能性があることに注意してください。この場合、再度kill –9コマンドを使用して、2番目のプロセスを強制終了する必要があります。

9. ノード・マネージャが動作しているターミナル・ウィンドウ(コンソール)を確認します。

選択した管理対象サーバーでエラーが発生したことを示すメッセージが表示されます。次のようなメッセージが表示されます。

<INFO> <domain_name> <server_name>
<The server 'server_name' with process id 4668 is no longer alive; waiting for the process to die.>
<INFO> <domain_name> <server_name>
<Server failed so attempting to restart (restart count = 1)>.

10. Oracle WebLogic Server管理コンソールに戻って、移行可能なターゲットの表をリフレッシュします。移行可能なターゲットが、残りの実行中のクラスタ内の管理対象サーバーに転送されることを確認します。

- 強制終了したプロセスの現在のホスト・サーバーが更新され、別のホストに移行されたことを示すことを確認します。

- プロセスの「最後の移行のステータス」列の値が「成功」であることを確認します。

11. 現在サービスをホストしている管理対象サーバーのログ・ファイルを開いて確認し、JTAまたはJMSエラーがないかどうか探します。

注意:

JMSテストの場合、宛先からメッセージ・カウントを取得し、移行可能なターゲットにスタック・メッセージがないことを確認することが推奨されます。

たとえば、共通分散送り先(UDD)の場合:

a. 管理コンソールでJMSサブデプロイメント・モジュールにアクセスします。
「ドメイン構造」ペインで、「サービス」、「メッセージング」、「JMSモジュール」の順に選択します。

b. 「JMSモジュール」をクリックします。

c. 「リソースのサマリー」表で宛先をクリックします。「モニタリング」を選択し、メッセージ総数と保留メッセージ数を取得します

d. 「モニタリング」タブを選択し、「宛先」表で「メッセージ総数」および「保留メッセージ数」の値を確認します。

22.4.6 自動サービス移行後のサービスのフェイルバック

自動サービス移行が発生した場合、Oracle WebLogic Serverでは、サーバーがオンラインに戻りクラスタに再度参加するときに、サービスが元のサーバーにフェイルバックすることはサポートされません。

そのため、フェイルオーバー中に、自動サービス移行によって特定のJMSサービスがバックアップ・サーバーに移行されたあとは、元のサーバーがオンラインに戻っても、サービスが元のサーバーに移行されることはありません。かわりに、サービスを元のサーバーに手動で移行する必要があります。

サービスを元のサーバーにフェイルバックするには、次の手順を実行します。

1. まだ行っていない場合は、管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。

2. 「ドメイン構造」ツリーで、「環境」、「クラスタ」の順に開き、「移行可能なターゲット」を選択します。

3. 1つ以上の移行可能なターゲットを一度に移行するには、「移行可能なターゲットのサマリー」ページで次を実行します。

a. 「制御」タブをクリックします。

b. チェック・ボックスを使用して、移行する1つまたは複数の移行可能なターゲットを選択します。

c. 「移行」をクリックします。

d. 「新しいホスト・サーバー」ドロップダウンを使用して、元の管理対象サーバーを選択します。

e. 「OK」をクリックします。
JMS関連サービスを移行するためのリクエストが発行され、構成編集ロックが解除されます。「移行可能なターゲット」表の「最後の移行のステータス」列に、リクエストされた移行が成功したのか、失敗したのかが示されます。

4. 特定の移行可能なターゲットを移行するには、「移行可能なターゲットの概要」ページで、次の手順を実行します。

a. 移行する移行可能なターゲットを選択します。

b. 「制御」タブをクリックします。

c. 再度、移行する移行可能なターゲットを選択します。

d. 「移行」をクリックします。

e. 「新しいホスト・サーバー」ドロップダウンを使用して、移行可能なターゲットのための新しいサーバーを選択します。

f. 「OK」をクリックします。

23 エンタープライズ・デプロイメントに対するシングル・サインオンの構成

この章では、Oracle Access Managerを使用したシングル・サインオンが有効になるようOracle HTTP Server Webゲートを構成する方法について説明します。

- Oracle HTTP Server Webゲートについて
Oracle HTTP Server Webゲートは、HTTPリクエストを捕捉して認証と認可を行うために既存のOracle Access Managerインスタンスに転送するWebサーバー・プラグインです。

- Oracle HTTP Server Webゲートの構成の一般的な前提条件
Oracle HTTP Server Webゲートを構成するには、事前に認定バージョンのOracle Access Managerをインストールおよび構成しておく必要があります。

- OHS 12c Webゲートを構成するためのエンタープライズ・デプロイメントの前提条件
エンタープライズ・デプロイメントに対してシングル・サインオンが有効になるようOracle HTTP Server Webゲートを構成する場合、この項に示す前提条件を確認してください。

- エンタープライズ・デプロイメント用にOracle HTTP Server 12c Webゲートを構成
WEBHOST1とWEBHOST2の両方でOracle Access Manager用Oracle HTTP Server 12c Webゲートを構成するには、次の手順に従います。

- Oracle Access ManagerへのOracle HTTP Server Webゲートの登録
Oracle Access Manager管理コンソールを使用すると、Oracle Access ManagerにWebゲート・エージェントを登録できます。

- WebLogic Server認証プロバイダの設定
WebLogic Server認証プロバイダを設定するには、構成ファイルのバックアップ、Oracle Access Manager IDアサーション・プロバイダの設定およびプロバイダの順序の設定を行います。

- Oracle Access ManagerでのOracle ADFおよびOPSSセキュリティの構成
一部のOracle Fusion Middleware管理コンソールでは、Oracle Access Managerシングル・サインオン(SSO)と統合できるOracle Application Development Framework(Oracle ADF)セキュリティを使用しています。これらのアプリケーションではユーザー認証にOracle Platform Security Services (OPSS) SSOを利用できますが、まずドメイン・レベルのjps-config.xmlファイルを構成して、これらの機能を有効にする必要があります。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理手順

23.1 Oracle HTTP Server Webゲートについて

Oracle HTTP Server Webゲートは、HTTPリクエストを捕捉して認証と認可を行うために既存のOracle Access Managerインスタンスに転送するWebサーバー・プラグインです。

Oracle Fusion Middleware 12cでは、Webゲート・ソフトウェアはOracle HTTP Server 12cソフトウェア・インストールの一部としてインストールされます。

Webゲートの詳細は、『Oracle Access Management管理者ガイド』のOAM 11gエージェントの登録および管理に関する項を参照してください。

23.2 Oracle HTTP Server Webゲートの構成の一般的な前提条件

Oracle HTTP Server Webゲートを構成するには、事前に認定バージョンのOracle Access Managerをインストールおよび構成しておく必要があります。

このドキュメントの公開時点でサポートされているOracle Access Managerのバージョンは、11gリリース2 (11.1.2.2)および11gリリース2 (11.1.2.3)です。最新情報は、Oracle Fusion Middlewareのサポートされるシステム構成ページで、ご使用のリリース向けの動作保証情報のドキュメントを参照してください。

注意:

本番環境では、Oracle Access Managerを、エンタープライズ・デプロイメントをホストしているマシンではなく独自の環境にインストールすることを強くお薦めします。

Oracle Access Managerの詳細は、Oracleヘルプ・センターのMiddlewareドキュメントにあるOracle Identity and Access Managementの最新ドキュメントを参照してください。

23.3 OHS 12c Webゲートを構成するためのエンタープライズ・デプロイメントの前提条件

エンタープライズ・デプロイメントに対してシングル・サインオンが有効になるようOracle HTTP Server Webゲートを構成する場合、この項に示す前提条件を確認してください。

- Oracle Access Managerを可用性の高い安全な本番環境にデプロイすることをお薦めします。エンタープライズ環境へのOracle Access Managerのデプロイの詳細は、お使いのOracle Identity and Access Mangementバージョン向けのエンタープライズ・デプロイメント・ガイドを参照してください。

- WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlに対するシングル・サインオンを有効にするには、Oracle Access Managerが使用している(Oracle Internet DirectoryやOracle Unified Directoryなど)ディレクトリ・サービスに中心的なLDAPプロビジョニング管理ユーザーを追加する必要があります。LDAPディレクトリに追加する必要のあるユーザーとグループの詳細は、「新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング」の手順に従ってください。

23.4 エンタープライズ・デプロイメント用にOracle HTTP Server 12c Webゲートを構成

WEBHOST1とWEBHOST2の両方でOracle Access Manager用Oracle HTTP Server 12c Webゲートを構成するには、次の手順に従います。

次の手順では、OHS_ORACLE_HOMEやOHS_CONFIG_DIRなどのディレクトリ変数を「このガイドで使用するファイル・システムとディレクトリ変数」で定義された値に置き換えてください。

1. Web層ドメインの完全なバックアップを実行します。

2. ディレクトリをOracle HTTP ServerのOracleホームの次の場所に変更します。
cd OHS_ORACLE_HOME/webgate/ohs/tools/deployWebGate/

3. 次のコマンドを実行して、Webゲート・インスタンス・ディレクトリを作成し、OHSインスタンスでのWebゲート・ロギングを有効にします。

./deployWebGateInstance.sh -w OHS_CONFIG_DIR -oh OHS_ORACLE_HOME

4. deployWebGateInstanceコマンドでwebgateディレクトリおよびサブディレクトリが作成されたことを確認します。

ls -lart OHS_CONFIG_DIR/webgate/
total 16
drwxr-x---+ 8 orcl oinstall 20 Oct  2 07:14 ..
drwxr-xr-x+ 4 orcl oinstall  4 Oct  2 07:14 .
drwxr-xr-x+ 3 orcl oinstall  3 Oct  2 07:14 tools
drwxr-xr-x+ 3 orcl oinstall  4 Oct  2 07:14 config

5. 次のコマンドを実行し、LD_LIBRARY_PATH変数にOHS_ORACLE_HOME/libディレクトリ・パスが含まれるようにします。
export LD_LIBRARY_PATH=OHS_ORACLE_HOME/lib

LD_LIBRARY_PATHがすでに設定されている場合、次のコマンドを実行します。

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:OHS_ORACLE_HOME/lib

6. ディレクトリを次のディレクトリに変更します。
OHS_ORACLE_HOME/webgate/ohs/tools/setup/InstallTools

7. InstallToolsディレクトリから次のコマンドを実行します。
./EditHttpConf -w OHS_CONFIG_DIR -oh OHS_ORACLE_HOME -o output_file_name

注意:

-oh OHS_ORACLE_HOMEおよび-o output_file_nameパラメータはオプションです。

このコマンドは次の処理を実行します。

- apache_webgate.templateファイルをOracle HTTP ServerのOracleホームからOracle HTTP Server構成ディレクトリの新しいwebgate.confファイルにコピーします。

- httpd.confファイルを更新して1行を追加し、webgate.confが含まれるようにします。

- Webゲート構成ファイルを生成します。ファイルのデフォルト名はwebgate.confですが、コマンドに対してoutput_file引数を使用してカスタム名を使用できます。

23.5 Oracle Access ManagerへのOracle HTTP Server Webゲートの登録

Oracle Access Manager管理コンソールを使用すると、Oracle Access ManagerにWebゲート・エージェントを登録できます。

詳細は、『Oracle Access Management管理者ガイド』のコンソールを使用したOAMエージェントの登録に関する項を参照してください。

詳細は、以下のトピックを参照してください。

- RREGインバンドおよびアウトオブバンド・モードについて

- OAM11gRequest.xmlファイルでの標準プロパティの更新

- エンタープライズ・デプロイメント用の保護されたリソース、パブリック・リソースおよび除外されたリソースの更新

- RREGツールの実行

- RREGによって生成されるファイルおよびアーティファクト

- 生成済アーティファクトのOracle HTTP Server WebGateインスタンスの場所へのコピー

- Oracle HTTP Serverインスタンスの再起動

23.5.1 RREGインバンドおよびアウトオブバンド・モードについて

RREGツールは、インバンドとアウトオブバンドという2つのモードのいずれかで実行できます。

Oracle Access Managerサーバーへのアクセス権を持っている場合は、インバンド・モードを使用して、Oracle Access ManagerのOracleホームからRREGツールを実行します。RREGツールの実行後、生成されたアーティファクトとファイルをWebサーバー構成ディレクトリにコピーできます。

Oracle Access Managerサーバーに対する権限またはアクセス権がない場合は、アウトオブバンド・モードを使用します。たとえば、組織によっては、Oracle Access Managerサーバー管理者のみがサーバー・ディレクトリにアクセスしてサーバー上で管理タスクを実行する権限を持ちます。アウトオブバンド・モードでは、プロセスは次のようになります。

1. Oracle Access Managerサーバー管理者からユーザーにRREGアーカイブ・ファイル(RREG.tar.gz)のコピーが提供されます。

2. サーバー管理者から提供されたRREG.tar.gzファイルを展開します。
例:

gunzip RREG.tar.gz

tar -xvf RREG.tar

RREGアーカイブを展開したら、次の場所でエージェントを登録するためのツールを見つけることができます。

RREG_HOME/bin/oamreg.sh

この例では、RREG_Homeは、RREGアーカイブの内容を展開したディレクトリです。

3. 「OAM11gRequest.xmlファイルでの標準プロパティの更新」の手順を使用してOAM11GRequest.xmlファイルを更新し、完成したOAM11GRequest.xmlファイルをOracle Access Managerサーバー管理者に送信します。

4. 次に、Oracle Access Managerサーバー管理者は「アウトオブバンド・モードでのRREGツールの実行」の手順を使用してRREGツールを実行し、AgentID_response.xmlファイルを生成します。

5. Oracle Access Managerサーバー管理者はユーザーにAgentID_response.xmlファイルを送信します。

6. 「アウトオブバンド・モードでのRREGツールの実行」の手順を使用してAgentID_response.xmlファイルでRREGツールを実行し、クライアント・システムに必要なアーティファクトとファイルを生成します。

23.5.2 OAM11gRequest.xmlファイルでの標準プロパティの更新

Webゲート・エージェントをOracle Access Managerに登録するには、事前にOAM11gRequest.xmlファイルで必須プロパティを更新する必要があります。

注意:

提供されているXMLファイルのほとんどのパラメータにデフォルト値を使用する場合は、リストされていないすべてのフィールドがデフォルト値をとる短いバージョン(OAM11gRequest_short.xmlを使用できます。

注意:
プライマリ・サーバー・リストで、デフォルト名は、OAMサーバーに対してOAM_SERVER1およびOAM_SERVER2として示されます。現在の環境でサーバー名が変更される場合、リスト内のこれらの名前を変更してください。

このタスクを実行するには、次のようにします。

1. インバンド・モードを使用する場合は、ディレクトリをディレクトリ内の次の場所に変更します。

OAM_ORACLE_HOME/oam/server/rreg/input

アウトオブバンド・モードを使用する場合は、ディレクトリをRREGアーカイブを展開した場所に変更します。

2. OAM11GRequest.xmlファイル・テンプレートのコピーを作成します。

3. ファイルにリストされているプロパティを確認してから、プロパティが環境に固有のホスト名およびその他の値を参照するように、OAM11GRequest.xmlファイルのコピーを更新します。

OAM11gRequest.xmlプロパティ

設定値

serverAddress

Oracle Access Managerドメイン内の管理サーバーのホストとポート。

agentName

エージェントのカスタム名。一般に、シングル・サインオンを構成しているFusion Middleware製品を識別する名前を使用します。

applicationDomain

シングル・サインオンを構成しているWeb層ホストおよびFMWコンポーネントを識別する値です。

security

Oracle Access Managerサーバーのセキュリティ・モードで、オープン・モード、簡易モードまたは証明書モードがあります。

エンタープライズ・デプロイメントの場合、認証および認可トラフィックの暗号化のためにカスタム・セキュリティ証明書を実装する追加の要件が存在する場合を除いて、簡易モードが推奨されます。

オープン・モードではOracle Access Managerサーバーとのトラフィックは暗号化されないため、ほとんどの場合、オープン・モードの使用は避けてください。

証明書モードの使用またはOracle Access Managerでサポートされている一般的なセキュリティ・モードの詳細は、『Oracle Access Management管理者ガイド』のOAMサーバーとWebゲート間の通信の保護に関する項 を参照してください。

cachePragmaHeader

プライベート

cacheControlHeader

プライベート

ipValidation

0

<ipValidation>0<ipValidation>

ipValidationExceptions

フロントエンド・ロード・バランサのIPアドレス。例:

<ipValidationExceptions>
<ipAddress>130.35.165.42</ipAddress>
</ipValidation>

agentBaseUrl

Oracle HTTP Server 12c WebGateがインストールされているマシンのホストとポート。

23.5.3 エンタープライズ・デプロイメント用の保護されたリソース、パブリック・リソースおよび除外されたリソースの更新

Oracle Fusion Middleware環境をシングル・サインオン用に設定する場合、Oracle Access Managerがシングル・サインオンで保護する一連のURLを特定します。これらは、OAM11gRequest.xmlファイルの特定セクションを使用して特定します。URLを特定するには:

1. まだOAM11GRequest.xmlファイルが編集用に開かれていない場合は、ファイルを探してテキスト・エディタで開きます。

詳細は、次を参照してください。

- OAM11gRequest.xmlファイルでの標準プロパティの更新

2. ファイルからサンプル・エントリを削除してから、次の例に示すように、保護されたリソース、パブリック・リソースおよび除外されたリソースのリストをファイルの適切なセクションに入力します。

注意:

Oracle Access Manager 11gリリース2 (11.1.2.2)以降を使用している場合、Oracle Access Managerの前のバージョンとの下位互換性のためにワイルドカード構文のエントリ(“.../*”)が含められます。

<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>/DefaultToDoTaskFlow</resource>
<resource>/DefaultToDoTaskFlow/.../*</resource>
<resource>/ess</resource>
<resource>/ess/.../*</resource>
<resource>/EssHealthCheck</resource>
<resource>/EssHealthCheck/.../*</resource>
<resource>/em</resource>
<resource>/em/.../*</resource>
<resource>/console</resource>
<resource>/console/.../*</resource>
<resource>/servicebus</resource><!-- (For OSB systems only) -->
<resource>/servicebus/.../*</resource><!-- (For OSB systems only) -->
<resource>/lwpfconsole</resource><!-- (For OSB systems only) -->
<resource>/lwpfconsole/.../*</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>/oracle/bam/server</resource><!-- (For BAM systems only) -->
<resource>/oracle/bam/server/.../*</resource><!-- (For BAM systems only) -->
<resource>/bam/composer </resource><!-- (For BAM systems only) -->
<resource>/bam/composer/.../*</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>
<resource>/healthcare/.../*</resource><!-- (For HC systems only) -->
<resource>/healthcare</resource><!-- (For HC systems only) -->
</protectedResourcesList>
<publicResourcesList>
<resource>/soa-infra/directWSDL</resource>
<resource>/sbinspection.wsil</resource><!-- (For OSB systems only) -->
</publicResourcesList>
<excludedResourcesList>
<resource>/wsm-pm</resource>
<resource>/wsm-pm/.../*</resource>
<resource>/soa-infra</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>/sbconsole</resource><!-- (For OSB systems only) -->
<resource>/sbconsole/.../*</resource><!-- (For OSB systems only) -->
<resource>/sbresource</resource><!-- (For OSB systems only) -->
<resource>/sbresource/.../*</resource><!-- (For OSB systems only) -->
<resource>/integration/services/.../*</resource>
<resource>/integration/services</resource>
<resource>/b2b/services/</resource>
<resource>/b2b/services/.../*</resource>
</excludedResourcesList>

3. OAM11GRequest.xmlファイルを保存して閉じます。

23.5.4 RREGツールの実行

次の項では、RREGツールを実行してOracle HTTP Server WebゲートをOracle Access Managerに登録する方法を示します。

- RREGツールをインバンド・モードで実行

- RREGツールをアウトオブバンド・モードで実行

23.5.4.1 RREGツールをインバンド・モードで実行

RREGツールをインバンド・モードで実行するには:

1. RREGホーム・ディレクトリに移動します。
インバンド・モードを使用している場合、RREGディレクトリはOracle Access ManagerのOracleホーム内にあります。

RREG_HOME/oam/server/rreg

アウトオブバンド・モードを使用している場合、RREGホーム・ディレクトリはRREGアーカイブを展開した場所です。

2. RREGホーム・ディレクトリで、binディレクトリに移動します。

cd RREG_HOME/bin/

3. ファイルを実行できるように、oamreg.shコマンドの権限を設定します。

chmod +x oamreg.sh

4. 次のコマンドを実行します。

./oamreg.sh inband input/OAM11GRequest.xml

この例では、次のようになります。

- 編集したOAM11GRequest.xmlファイルはRREG_HOME/input ディレクトリにあると想定されます。

- このコマンドの出力は、次のディレクトリに保存されます。

RREG_HOME/output/

次の例は、RREGセッションのサンプルを示しています。

Welcome to OAM Remote Registration Tool!
Parameters passed to the registration tool are:
Mode: inband
Filename: /u01/oracle/products/fmw/iam_home/oam/server/rreg/client/rreg/input/OAM11GWCCDomainRequest.xml
Enter admin username:weblogic_idm
Username: weblogic_idm
Enter admin password:
Do you want to enter a Webgate password?(y/n):
n
Do you want to import an URIs file?(y/n):
n

----------------------------------------
Request summary:
OAM11G Agent Name:WCC1221_EDG_AGENT
URL String:null
Registering in Mode:inband
Your registration request is being sent to the Admin server at: http://host1.example.com:7001
----------------------------------------

Jul 08, 2015 7:18:13 PM oracle.security.jps.util.JpsUtil disableAudit
INFO: JpsUtil: isAuditDisabled set to true
Jul 08, 2015 7:18:14 PM oracle.security.jps.util.JpsUtil disableAudit
INFO: JpsUtil: isAuditDisabled set to true
Inband registration process completed successfully! Output artifacts are created in the output folder.

23.5.4.2 RREGツールをアウトオブバンド・モードで実行

RREGツールをWEBHOSTサーバー上でアウトオブバンド・モードで実行するには、管理者は次のコマンドを使用します。

RREG_HOME/bin/oamreg.sh outofband input/OAM11GRequest.xml

この例では、次のようになります。

- RREG_HOMEを、RREGアーカイブ・ファイルを展開したサーバー上の場所に置き換えます。

- 編集したOAM11GRequest.xmlファイルは、RREG_HOME/inputディレクトリにあります。

- RREGツールにより、このコマンドの出力(AgentID_response.xmlファイル)は次のディレクトリに保存されます。

RREG_HOME/output/

Oracle Access Managerサーバー管理者は、OAM11GRequest.xmlファイルを提供したユーザーにAgentID_response.xmlを送信できます。

RREGツールをWebサーバー・クライアント・マシン上でアウトオブバンド・モードで実行するには、次のコマンドを使用します。

RREG_HOME/bin/oamreg.sh outofband input/AgentID_response.xml

この例では、次のようになります。

- RREG_HOMEを、RREGアーカイブ・ファイルを展開したクライアント・システム上の場所に置き換えます。

- Oracle Access Managerサーバー管理者によって提供されたAgentID_response.xmlファイルは、 RREG_HOME/inputディレクトリにあります。

- RREGツールにより、このコマンドの出力(Webゲート・ソフトウェアの登録に必要なアーティファクトとファイル)は、クライアント・マシン上次のディレクトリに保存されます。

RREG_HOME/output/

23.5.5 RREGによって生成されるファイルおよびアーティファクト

RREGツールによって生成されるファイルは、WebゲートとOracle Access Managerサーバー間の通信に使用するセキュリティ・レベルによって異なります。サポートされるセキュリティ・レベルの詳細は、『Oracle Access Management管理者ガイド』のOAMサーバーとWebゲート間の通信の保護に関する項を参照してください。

この項では、RREG_HOMEへの参照はすべて、RREGツールを実行するディレクトリへのパスに置き換える必要があります。これは一般的に、Oracle Access Managerサーバー上の次のディレクトリ、または(アウトオブバンド・モードを使用している場合)RREGアーカイブを展開したディレクトリです。

OAM_ORACLE_HOME/oam/server/rreg/client

次の表に、Oracle Access Managerのセキュリティ・レベルに関係なく、RREGツールによって常に生成されるアーティファクトをリストします。

ファイル

場所

cwallet.sso

RREG_HOME/output/Agent_ID/

ObAccessClient.xml

RREG_HOME/output/Agent_ID/

次の表に、Oracle Access ManagerにSIMPLEまたはCERTセキュリティ・レベルを使用している場合に作成される、追加のファイルをリストします。

ファイル

場所

aaa_key.pem

RREG_HOME/output/Agent_ID/

aaa_cert.pem

RREG_HOME/output/Agent_ID/

password.xml

RREG_HOME/output/Agent_ID/

password.xmlファイルには、SSLで使用される秘密鍵を暗号化するための不明瞭化されたグローバル・パスフレーズが含まれます。このパスフレーズは、サーバーで使用されているパスフレーズと異なるものを使用できます。

RREGによって生成されたファイルを使用して証明書リクエストを生成し、サードパーティの認証局に署名を求めることができます。既存の証明書をインストールするには、既存のaaa_cert.pemおよびaaa_chain.pemファイルをpassword.xmlおよびaaa_key.pemと合せて使用する必要があります。

23.5.6 生成済アーティファクトのOracle HTTP Server WebGateインスタンスの場所へのコピー

RREGツールにより必要なアーティファクトが生成された後、アーティファクトをRREG_Home/output/agent_IDディレクトリからWeb層ホスト上のOracle HTTP Server構成ディレクトリに手動でコピーします。

Oracle HTTP Server構成ディレクトリ内のファイルの場所は、Oracle Access Managerのセキュリティ・モード設定(OPEN、SIMPLEまたはCERT)によって異なります。

次の表に、Oracle Access Managerのセキュリティ・モード設定に基づく、生成された各アーティファクトに必要なOracle HTTP Server構成ディレクトリ内の場所をリストします。ディレクトリが存在しない場合、ディレクトリを作成しなければならないことがあります。たとえば、ウォレット・ディレクトリは構成ディレクトリ内に存在しないことがあります。

注意:

エンタープライズ・デプロイメントの場合、認証および認可トラフィックの暗号化のためにカスタム・セキュリティ証明書を実装する追加の要件が存在する場合を除いて、簡易モードが推奨されます。オープン・モードまたは証明書モードを使用する場合の情報が、利便性のために示されています。

オープン・モードではOracle Access Managerサーバーとのトラフィックは暗号化されないため、オープン・モードの使用は避けてください。

証明書モードの使用またはOracle Access Managerでサポートされている一般的なセキュリティ・モードの詳細は、『Oracle Access Management管理者ガイド』のOAMサーバーとWebゲート間の通信の保護に関する項を参照してください。

ファイル

OPENモードを使用する場合の場所

SIMPLEモードを使用する場合の場所

CERTモードを使用する場合の場所

wallet/cwallet.sso

OHS_CONFIG_DIR/webgate/config/wallet

OHS_CONFIG_DIR/webgate/config/wallet/

注意:
デフォルトではwalletフォルダは使用できません。walletフォルダを作成してください。

OHS_CONFIG_DIR/webgate/config/wallet/

ObAccessClient.xml

OHS_CONFIG_DIR/webgate/config

OHS_CONFIG_DIR/webgate/config/

OHS_CONFIG_DIR/webgate/config/

password.xml

なし

OHS_CONFIG_DIR/webgate/config/

OHS_CONFIG_DIR/webgate/config/

aaa_key.pem

なし

OHS_CONFIG_DIR/webgate/config/simple/

OHS_CONFIG_DIR/webgate/config/

aaa_cert.pem

なし

OHS_CONFIG_DIR/webgate/config/simple/

OHS_CONFIG_DIR/webgate/config/

注意:
WEBHOST1およびWEBHOST2にObAccessClient.xmlを再デプロイする必要がある場合、サーバーからObAccessClient.xmlのキャッシュされたコピーを削除します。WEBHOST1のキャッシュの場所は次のとおりです。

OHS_DOMAIN_HOME/servers/ohs1/cache/

また、WEBHOST2で2番目のOracle HTTP Serverインスタンスに対して、同様の手順を実行する必要があります。

OHS_DOMAIN_HOME/servers/ohs2/cache/

23.5.7 Oracle HTTP Serverインスタンスの再起動

Oracle HTTP Serverインスタンスの再起動の詳細は、『Oracle HTTP Server管理者ガイド』のWLSTを使用したOracle HTTP Serverインスタンスの再起動に関する項を参照してください。

WebLogic ServerドメインにOracle HTTP Serverを構成した場合、Oracle Fusion Middleware Controlを使用してOracle HTTP Serverインスタンスを再起動することもできます。詳細は、『Oracle HTTP Server管理者ガイド』のFusion Middleware Controlを使用したOracle HTTP Serverインスタンスの再起動に関する項を参照してください。

23.6 WebLogic Server認証プロバイダの設定

WebLogic Server認証プロバイダを設定するには、構成ファイルのバックアップ、Oracle Access Manager IDアサーション・プロバイダの設定およびプロバイダの順序の設定を行います。

次の項では、「新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング」の手順に従って、LDAPオーセンティケータがすでに構成されていると想定します。LDAPオーセンティケータをまだ作成していない場合は、この項の作業を進める前に作成しておいてください。

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

- Oracle Access Manager IDアサーション・プロバイダの設定

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

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

念のため、まず、次の関連する構成ファイルをバックアップする必要があります。

ASERVER_HOME/config/config.xml
ASERVER_HOME/config/fmwconfig/jps-config.xml
ASERVER_HOME/config/fmwconfig/system-jazn-data.xml

管理サーバーのboot.propertiesファイルもバックアップします。

ASERVER_HOME/servers/AdminServer/security/boot.properties

23.6.2 Oracle Access Manager IDアサーション・プロバイダの設定

Oracle WebLogic Server管理コンソールを使用してOracle Access Manager IDアサーション・プロバイダを設定します。

Oracle Access Manager IDアサーション・プロバイダを設定する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 左のナビゲーション・バーにある「セキュリティ・レルム」をクリックします。

4. myrealmというデフォルト・レルム・エントリをクリックします。

5. 「プロバイダ」タブをクリックします。

6. 「新規」をクリックし、ドロップダウン・メニューからアサータ・タイプ「OAMIdentityAsserter」を選択します。

7. アサータに名前(OAM ID Asserterなど)を付け、「OK」をクリックします。

8. 新しく追加したアサータをクリックし、Oracle Access Manager IDアサーション・プロバイダの構成画面を確認します。

9. 制御フラグを「必須」に設定します。

10. 「選択済み」タイプで、デフォルトで選択されていない場合、ObSSOCookieオプションとOAM_REMOTE_USERオプションを両方とも選択します。

11. 「保存」をクリックして設定を保存します。

12. 「変更のアクティブ化」をクリックして変更を伝播します。

23.6.3 プロバイダの順序の設定

WebLogic Server管理コンソールを使用してIDアサーション・プロバイダと認証プロバイダを設定します。

プロバイダの順序を設定する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 左のナビゲーション・バーにある「セキュリティ・レルム」をクリックします。

4. myrealmというデフォルト・レルム・エントリをクリックします。

5. 「プロバイダ」タブをクリックします。

6. OAM IDアサーション・プロバイダが最初で、DefaultAuthenticatorプロバイダが最後になるように、プロバイダを並べ替えます。

7. OAM IDアサーション・プロバイダを構成したら、デフォルト・オーセンティケータの制御フラグがSUFFICIENTに設定されていることを確認し、次のようにプロバイダを並べ替えます。

- OAMIdentityAsserter: REQUIRED

- LDAP認証プロバイダ: SUFFICIENT

- DefaultAuthenticator: SUFFICIENT

- デフォルトIDアサーション・プロバイダ

8. 「OK」をクリックします。

9. 「変更のアクティブ化」をクリックして変更を伝播します。

10. 必要に応じて、管理サーバー、管理対象サーバーおよびシステム・コンポーネントを再起動します。

23.7 Oracle Access ManagerでのOracle ADFおよびOPSSセキュリティの構成

一部のOracle Fusion Middleware管理コンソールでは、Oracle Access Managerシングル・サインオン(SSO)と統合できるOracle Application Development Framework(Oracle ADF)セキュリティを使用しています。これらのアプリケーションではユーザー認証にOracle Platform Security Services (OPSS) SSOを利用できますが、まずドメイン・レベルのjps-config.xmlファイルを構成して、これらの機能を有効にする必要があります。

ドメインレベルのjps-config.xmlファイルは、Oracle Fusion Middlewareドメインの作成後に次の場所に配置されます。

DOMAIN_HOME/config/fmwconfig/jps-config.xml

注意:

ドメインレベルのjps-config.xmlをカスタム・アプリケーションでデプロイされたjps-config.xmlと混同しないでください。

OPSS構成を更新してOracle Access ManagerのSSOアクションを委任するには、次の手順に従います。

1. ディレクトリを次のディレクトリに変更します。

cd ORACLE_COMMON_HOME/common/bin

2. WebLogic Server Scripting Tool (WLST)を起動します。

./wlst.sh

3. 次のWLSTコマンドを使用して管理サーバーに接続します。

connect(‘admin_user’,’admin_password’,’admin_url’)

例:

connect(‘weblogic_bi’,’mypassword’,’t3://ADMINVHN:7001’)

4. 次のように、addOAMSSOProviderコマンドを実行します。

addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication", logouturi="/oamsso/logout.html")

次の表では、addOAMSSOProviderコマンドの各引数に予想される値を定義しています。

引数

定義

loginuri

ログイン・ページのURIを指定します

注意: ADFセキュリティが有効なアプリケーションの場合、"<context-root/adfAuthentication"を'loginuri'パラメータに指定する必要があります。

例:

/${app.context}/adfAuthentication

手順を示します。

a. たとえば、ユーザーがOPSSの認証ポリシーで保護されているリソースにアクセスします。

b. ユーザーがまだ認証されていない場合、ADFはユーザーを'loginuri'で設定したURIにリダイレクトします。

c. Access Managerには'loginuri'の値を保護するポリシー、たとえば、"/<context-root/adfAuthenticationが存在する必要があります。

d. ADFがこのURIにリダイレクトすると、Access Managerにより「ログイン」ページが表示されます(このURI用のAccess Managerで構成された認証スキームにより異なる)。

logouturi

ログアウト・ページのURIを指定します

注意:

- ADFセキュリティが有効なアプリケーションの場合、logouturiを『Oracle Access Management管理者ガイド』の11g Webゲートが関与するセッションの集中ログアウトの構成に関する項に基づいて構成する必要があります。

- Webゲート11gを使用している場合、logouturiの値は11g Webゲートの管理者が検索する必要があります。

- Webゲート10gを使用している場合、logouturiの値は/oamsso/logout.htmlである必要があります。

autologinuri

自動ログイン・ページのURIを指定します。これはオプションのパラメータです。

5. 管理サーバーからの切断:

disconnect()

6. 管理サーバーとすべての管理対象サーバーを再起動します。

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

新しいOracle RACアプリケーションを構築する際には、GridLinkデータ・ソースを使用することをお薦めします。ただし、GridLinkデータ・ソースをサポートしないレガシー・アプリケーションとデータベースを使用している場合、この付録の次の情報を参照します。

この付録では、マルチ・データ・ソースとOracle RACについて、およびエンタープライズ・デプロイメントでマルチ・データ・ソースを構成する手順について説明します。

- マルチ・データ・ソースとOracle RACについて
マルチ・データ・ソースでは、接続リクエストを満たすために使用する、データ・ソースの順序付きリストが提供されます。

- エンタープライズ・デプロイメントでマルチ・データ・ソースを構成するための標準的な手順
ドメインを構成するときにデータ・ソースを構成します。GridLinkデータ・ソースのかわりにマルチ・データ・ソースを使用する場合は、GridLinkの手順をこの項に示す手順に置き換えます。

A.1 マルチ・データ・ソースとOracle RACについて

マルチ・データ・ソースでは、接続リクエストを満たすために使用する、データ・ソースの順序付きリストが提供されます。

通常、このようなマルチ・データ・ソースへの接続リクエストはすべて、リストの先頭のデータ・ソースによって処理されます。データベース接続テストが失敗して接続を置き換えられなかった場合、またはデータ・ソースが中断された場合は、リストの次のデータ・ソースから順番に接続が検索されます。

Oracle RACを使用したマルチ・データ・ソースの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のOracle RACを使用したマルチ・データ・ソースの使用に関する項を参照してください。

A.2 エンタープライズ・デプロイメントでマルチ・データ・ソースを構成するための標準的な手順

ドメインを構成するときにデータ・ソースを構成します。GridLinkデータ・ソースのかわりにマルチ・データ・ソースを使用する場合は、GridLinkの手順をこの項に示す手順に置き換えます。

たとえば、エンタープライズ・デプロイメント参照トポロジに最初の管理ドメインを構成する場合、構成ウィザードを使用してドメインの特性およびデータ・ソースを定義します。

このエンタープライズ・デプロイメント・ガイド内のトポロジの構成手順には、Oracle RACでGridLinkデータ・ソースを定義するための具体的な手順が含まれています。GridLinkデータ・ソースのかわりにマルチ・データ・ソースを使用する場合は、GridLink用の説明を次のように置き換えてください。

1. 「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。

a. 適切なスキーマを選択します。

b. コンポーネント・スキーマのRAC構成については、「RACマルチ・データ・ソースへ変換」を選択します。

c. リポジトリ作成ユーティリティを実行した際、次のデータ・ソースがスキーマの接頭辞とともに表示されることを確認してください。

d. 「次へ」をクリックします。

2. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面が表示されます(図A-1)。

図A-1 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面

この画面で、次の手順を実行します。

a. 次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: 「Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11」を選択します。

- サービス名: データベースのサービス名を入力します。

- ユーザー名: スキーマの完全なユーザー名(接頭辞を含む)を入力します。

- パスワード: スキーマへのアクセスに使用するパスワードを入力します。

b. ホスト名、インスタンス名およびポートを入力します。

c. 「追加」をクリックします。

d. この手順をOracle RACインスタンスごとに実行します。

e. 「次へ」をクリックします。

3. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利について

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

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)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

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

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

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

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

Oracle Supportへのアクセス

サポートをご契約のお客様には、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を参照してください。