5 Oracle SOA Suiteの高可用性の構成

Oracle SOA Suiteは、コンポジット・アプリケーションを設計、デプロイおよび管理するためのサービス・インフラストラクチャ・コンポーネントのセットです。Oracle SOA Suiteを使用することで、サービスの作成、管理、およびコンポジット・アプリケーションとビジネス・プロセスへの編成が可能になります。コンポジットを使用すると、様々なテクノロジのコンポーネントを1つのSOAコンポジット・アプリケーションにアセンブルできます。Oracle SOA Suiteは異種ITインフラストラクチャを組み込み、SOAを段階的に導入できます。

この章では、Oracle SOA Suiteコンポーネントについて高可用性の観点から説明します。また、高可用性を備えたデプロイメントの設計に重要なSOAコンポーネントの単一インスタンスの概念について概要を説明します。

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

第5.1項「Oracle SOA Suiteの概要」
第5.2項「Oracle SOAインフラストラクチャの高可用性」
第5.3項「Oracle BPEL Process Managerと高可用性の概要」
第5.4項「Oracle BPM Suiteと高可用性の概要」
第5.5項「Oracle Mediatorと高可用性の概要」
第5.6項「Oracle Human Workflowと高可用性の概要」
第5.7項「Oracle B2Bと高可用性の概要」
第5.8項「Oracle Web Services Managerと高可用性の概要」
第5.9項「Oracle User Messaging Serviceと高可用性の概要」
第5.10項「Oracle JCAアダプタと高可用性の概要」
第5.11項「Oracle Business Activity Monitoringと高可用性の概要」
第5.12項「Oracle Service Busと高可用性の概要」
第5.13項「Oracle SOAインフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」
第5.14項「SOAインフラストラクチャとコンポーネント・サービス・エンジンを使用するOracle Service Busの高可用性の構成」
第5.15項「Oracle BAMの高可用性の構成」

5.1 Oracle SOA Suiteの概要

図5-1に示すように、Oracle SOA Suiteは、サービス指向アーキテクチャ(SOA)を開発、保護および監視するための包括的な製品スイートを提供します。Oracle SOA Suite 11gは、SCA標準に準拠した、統一されたランタイム・エンジンを実現します。ランタイム・エンジンは、共通のサービス・インフラストラクチャによって管理およびインターコネクトされるサービス・エンジン(BPEL Process Manager、Human Workflow、Mediator、Rules)およびバインディング・コンポーネント(JCAアダプタ、B2B)で構成されます。サービス・インフラストラクチャは、ライフサイクル管理やデプロイメントなどの共通サービスも提供します。

図5-1 Oracle SOA Suiteとコンポーネント

「図5-1 Oracle SOA Suiteとコンポーネント」の説明

SOAコンポジット・アプリケーションは、SOAランタイム・エンジンへのデプロイメントの基本単位です。サービス・コンポーネント(BPELプロセス、ビジネス・ルール、ヒューマン・タスクおよびMediatorルーティング・ルール)は、SOAコンポジットの構成要素です。サービス・コンポーネントは、デプロイメント時にサービス・エンジンにターゲット指定され、サービスと参照は、バインディング・コンポーネントを使用することにより有効になります。実行時には、メッセージはバインディング・コンポーネントによって受信され、サービス・インフラストラクチャによって適切なサービス・エンジンにルーティングされます。

図5-2 Oracle SOAインフラストラクチャ・スタックの図

「図5-2 Oracle SOAインフラストラクチャ・スタックの図」の説明

SOAランタイム・エンジンはOracle WebLogic Application Serverなどのアプリケーション・サーバーのコンテキスト内で動作します。これは、基盤となるアプリケーション・サーバーのロード・バランシングと高可用性の機能を利用します。

5.2 Oracle SOAインフラストラクチャの高可用性

この項では、SOAインフラストラクチャの高可用性クラスタを設計するために必要な課題および考慮事項について説明します。

SOAインフラストラクチャは、Oracle SOA Suiteを実行するための基礎となるサービスを提供するJava EEアプリケーションです。このJava EEアプリケーションは、Oracle SOA Suiteをインストールすると、自動的にデプロイされるランタイム・エンジンです。コンポジット(ソフトウェア・コンポーネント・アーキテクチャの基本のアーティファクト)をOracle SOAインフラストラクチャにデプロイすると、コンポジットの実行に必要なサービスが提供されます。Oracle SOAインフラストラクチャは、コンポジットに対して、デプロイメント、接続およびスレッド管理のサービスを提供します。このようなサービスによって、コンポジットのライフサイクルやランタイム動作が支えられています。

バックアップとリカバリに関する考慮事項

SOAインフラストラクチャ・ファイルのバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の「バックアップとリカバリの概要」および「環境のバックアップ」の各章を参照してください。

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

第5.2.1項「Oracle SOAインフラストラクチャの単一インスタンスの特性」
第5.2.2項「Oracle SOAインフラストラクチャの高可用性アーキテクチャとフェイルオーバーに関する考慮事項」

5.2.1 Oracle SOAインフラストラクチャの単一インスタンスの特性

SOAインフラストラクチャは、コンポジットの実行に必要なサービスを提供します。コンポジットは、サービス・コンポーネント・アーキテクチャ(SCA)のデプロイメントの基本単位です。SCAアセンブリ・モデルは、XMLファイルに記述されている要素によって定義される一連のアーティファクトで構成されます。

コンポジットは、コンポーネント、ワイヤ、サービスおよび参照で構成されるソフトウェア・パッケージです。たとえば、Oracle BPELプロセスがコンポーネント、インバウンド・アダプタがサービス、アウトバウンド・アダプタが参照となります。ワイヤはサービス・エンジン間の接続を確立します。

各コンポーネントは、Oracle BPEL PMなどの特定のサービス・エンジンにターゲット指定されます。SOAインフラストラクチャは、コンポジット状態を保持するためにSOAデータベースに接続し、デプロイメントやバージョン追跡などのコンポジット・メタデータを保持するためにSOA Oracle Metadata Services (MDS)リポジトリに接続します。これら2つのデータベースは、同一の物理データベースである場合がありますが、使用されるスキーマはそれぞれの目的に応じて異なります。SOAインフラストラクチャは、コンポジットのリモート・デプロイメント用のサーブレットを提供します。リモート・デプロイメント用のメタデータとアーティファクトも、MDSリポジトリに格納されます。

また、SOAインフラストラクチャ・アプリケーションは、個々のコンポーネントを特定エンジンにターゲット指定し、リクエストがSOAシステムに届いたときにそれらのコンポジットをインスタンス化します。ターゲット指定とインスタンス化が終了すると、SOAインフラストラクチャはスレッドとリソースの割当てを制御します。これは、コンポジットが実行されるJVMで行われます。

図5-3に示すように、SOAインフラストラクチャは、SOAコンポジット・アプリケーションをUDDIレジストリに統合します。UDDIレジストリは、公開されているサービスの特定、サービスの呼出しおよびサービス・メタデータの管理のための、標準ベースの基盤を提供します。SOAインフラストラクチャは中央のハブでもあり、サービス・エンジンがOracle User Messaging Serviceインフラストラクチャを通じて通信チャネルにメッセージを配信する際に使用されます。

SOAインフラストラクチャは、SC内の様々なコンポーネントを支える必須サービスを提供し、コンポーネント間の通信を可能にします。SCAシステムにおける様々なコンポーネントの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

図5-3 SOAインフラストラクチャの基本的な単一ノード・アーキテクチャ

「図5-3 SOAインフラストラクチャの基本的な単一ノード・アーキテクチャ」の説明

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

第5.2.1.1項「Oracle SOAインフラストラクチャ・アプリケーションの特性」
第5.2.1.2項「Oracle SOAインフラストラクチャの起動とシャットダウンのライフサイクル」
第5.2.1.3項「Oracle SOAインフラストラクチャの外部依存性」
第5.2.1.4項「Oracle SOAインフラストラクチャのプロセスの起動とシャットダウン」
第5.2.1.5項「Oracle SOAインフラストラクチャの構成アーティファクト」
第5.2.1.6項「Oracle SOAインフラストラクチャのログ・ファイルの場所」

5.2.1.1 Oracle SOAインフラストラクチャ・アプリケーションの特性

soa-infra-wls.earファイルには、SOAインフラストラクチャ・サービスが含まれています。SOAインフラストラクチャ・システムで提供されるサービスは、いずれもシングルトンではないため、SOAインフラストラクチャは、完全なアクティブ/アクティブ・モードで実行可能です。SOAインフラストラクチャのJava EEアプリケーションには、デプロイされているコンポジットの参照と、これらコンポジットのテスト・ページへのリンクを可能にするWebモジュールが含まれています。このWebモジュールでは、関連付けられたURLコンテキストとして/soa-infraを使用しています。このWebモジュールはステートレスであり、特別なセッション・レプリケーション要件はありません。

SOAインフラストラクチャ・アプリケーションの他のモジュールは、プロセスをインスタンス化およびトラッキングするためのタスク制御機能と、Oracle User Messaging System (UMS)にアクセスするためのクライアント・サービスを提供します。

タスク・サービスは、プロセスのインスタンス化とトラッキングを非同期で制御します。その他にも、SOAインフラストラクチャ・システムでは、複数のEJBが使用されます。しかし、EJBはすべてステートレスであり、Oracle SOAクラスタでのステートフル・セッションBeanレプリケーションに要件はありません。これらEJBでのトランザクションの処理は、WebLogic Serverのトランザクション制御サービスに依存します。WebLogic Serverコンテナの障害から確実にリカバリできるようにするために、WebLogic Serverの基本ガイドラインで推奨されている適切なトランザクション・ストアを構成してください。

5.2.1.2 Oracle SOAインフラストラクチャの起動とシャットダウンのライフサイクル

Oracle SOAコンポジットは次のものから構成されます。

BPELプロセス、Human Workflowタスク、Business Rulesなどのコンポーネント。
Oracle SOAコンポジット・アプリケーションと外部サービス、アプリケーションおよびテクノロジを接続する、サービスおよび参照。

これらのコンポーネントは、Oracle SOAコンポジット・アプリケーションにアセンブルされます。このアプリケーションは、Oracle SOAアプリケーションの管理とライフサイクルを簡素化するデプロイメントの1つの単位です。

SOAインフラストラクチャ・アプリケーションは、起動時に、各種サービス・エンジンを初期化し、MDSリポジトリからコンポジットをロードします。これは、個々のコンポーネントを特定エンジンにターゲット指定します。コンポジットがロードされると、システムはリクエストを受信できるようになります。SOAインフラストラクチャは、実行時にサービス・コンポーネント間のすべての通信を管理します。サービス・エンジン間でのコールは、インプロセス・コールです。図5-4は、起動と操作処理の手順を表しています。

図5-4 Oracle SOAインフラストラクチャ・アプリケーションの起動とシャットダウンのライフサイクル

「図5-4 Oracle SOAインフラストラクチャ・アプリケーションの起動とシャットダウンのライフサイクル」の説明

5.2.1.3 Oracle SOAインフラストラクチャの外部依存性

前述の項で説明したとおり、SOAインフラストラクチャ・システムは、次のコンポーネントに依存します。

インスタンス・マネージャ・サービスは、ランタイムSOAデータベース・スキーマ(soa-infra)に依存します。
コンポジット・メタデータは、リポジトリとして機能するMDSデータベース・スキーマに格納されます。
クラスタ化された環境での、デプロイメント・コーディネータ・サービスによるシグナルの伝播は、基盤となるCoherenceクラスタに依存します。

SOAインフラストラクチャが適切に起動し、実行されるためには、これらのコンポーネントが使用可能である必要があります。

5.2.1.4 Oracle SOAインフラストラクチャのプロセスの起動とシャットダウン

SOAインフラストラクチャがデプロイされている管理対象サーバーが起動するたびに、SOAインフラストラクチャ・アプリケーションがデフォルトで起動します。通常は、SOAインフラストラクチャやそのコンポーネント自体を停止する必要はありません。一部の操作では、SOAインフラストラクチャが実行されている管理対象サーバーの再起動が必要な場合があります。詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』の管理対象サーバーおよびSOAインフラストラクチャの停止および起動に関する説明を参照してください。

5.2.1.5 Oracle SOAインフラストラクチャの構成アーティファクト

Oracle Fusion Middleware 11g以降、Oracleサービス・インフラストラクチャの構成パラメータはSOA MDSデータベースに格納されます。SOAインフラストラクチャの主な制御は、Oracle Enterprise Manager Fusion Middleware Controlを使用して構成します。詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のSOAインフラストラクチャ・プロパティの構成に関する項を参照してください。

デハイドレーションを処理するためのデータ・ソースJNDI名。

注意:

このファイルからJNDI名が読み取られると、システムで使用されるデータベースが、WebLogic ServerのJDBSリソース構成内でそれらのJNDI名と一致するデータ・ソースによって決定されます。

サーバーおよびコールバック・サーバーURL

コールバック・サーバーURLとは、非同期サービスにおいて、呼び出したサービスへのレスポンスが通知されるように指定されているアドレスのことです。

注意:

外部または内部の非同期サービスへのリクエストがOracle SOA Suiteから送られると、コールバック・サーバーURLは次のように、優先度の高い順に決定されます。

特定の参照用のバインド・プロパティとして指定されたcallbackServerURLを使用します(このプロパティは、コンポジットのモデリング時または実行時にMBeansを使用して設定できます)。これにより、サービス・コールごとに異なるコールバック・サーバーURLを割り当てることができます。このプロパティは、実行時に、対応するバインディングMbeanによって、システムMBeanブラウザを使用して設定されます。特定のURLを追加するには、callbackServerURLプロパティをプロパティ属性に追加し、保存操作を実行します。
SOAデータベースに指定されているコールバック・サーバーURLを使用します。この場合は、考えられるすべてのサービスに対して適切に機能するアドレスを1つのみ指定できます。
WebLogic ServerでSOA_Clusterに対して指定されるフロントエンド・ホストとしてコールバック・サーバーURLを使用します。この場合も同様に、アドレスは1つのみ指定でき、SOAデータベース構成オプションに指定されているアドレスと同じであることが推奨されます。
WebLogic Server MBean APIによって提供されるローカル・ホスト名を使用します。これは、高可用性環境ではお薦めしません。

メッセージ・トラッキング・インフラストラクチャで収集する情報の監査レベル。

データ・ソース、JTA構成および永続ストアなどのコンテナ・レベルの他の構成オプションは、WebLogic Serverのドメイン構成の一部として保持され、WebLogic Serverのコア・インフラストラクチャにより、WebLogic Serverのクラスタ上で同期化されます。

5.2.1.6 Oracle SOAインフラストラクチャのログ・ファイルの場所

SOAインフラストラクチャとそのコンポーネントにより実行される操作は、SOAインフラストラクチャが実行されているOracle WebLogic管理対象サーバーによって記録されます。ログは、次の場所にあります。

DOMAIN_HOME/servers/WLS_ServerName/logs/WLS_ServerName.log

別のWebLogic Server管理対象サーバーのログ・ファイルも、管理コンソールで使用できます。ログを確認するには、admin_server_host:port/consoleで管理コンソールにアクセスします。「診断-ログ・ファイル」をクリックします。

SOAインフラストラクチャが実行されているOracle WebLogic管理対象サーバーの出力を確認することも重要です。この情報は次の場所に格納されています。

DOMAIN_HOME/servers/WLS_ServerName/logs/WLS_ServerName.out

さらに、管理対象サーバーのログ・ディレクトリに診断ログが作成されます。このログの粒度とロギング・プロパティは、domain_dir/config/fmwconfig/servers/WLS_ServerName/logging.xmlファイルで変更できます。このファイルのプロパティは、Oracle Enterprise Manager Fusion Middleware Controlから、「ファーム」→「SOA」→SOAサーバーを選択して変更することもできます。右クリックして、「ログ」→「ログ構成」を選択します。

Oracle Enterprise Manager Fusion Middleware Controlでは、SOAドメインのすべてのログの選択検索が可能です。選択検索を実行するには、Oracle Fusion Middleware Controlにアクセスし、ファーム・ログをクリックして、soa-infraまたはデプロイされているコンポジットに関する検索条件を入力します。Oracle Enterprise Manager Fusion Middleware ControlのSOAシステムに関してレポートされるログおよび情報の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

5.2.2 Oracle SOAインフラストラクチャの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

図5-5は、2つのOracle WebLogic ServerでSOAインフラストラクチャの2ノード・クラスタが実行されている様子を示しています。これらのサーバーは、それらの前面のロード・バランサからリクエストを受信する、Web層ホスト上の2つのOracle HTTP Serverインスタンスによってフロントエンド処理されます。

図5-5 Oracle SOAインフラストラクチャの高可用性アーキテクチャ

「図5-5 Oracle SOAインフラストラクチャの高可用性アーキテクチャ」の説明

図5-5は、この高可用性の構成の持つ次の主要な特性を表しています。

SOAインフラストラクチャは、WebLogic Serverクラスタの一部であるOracle WebLogic Server管理対象サーバーで実行されます。WebLogic Serverクラスタは、JTS構成、データ・ソースおよび永続ストア定義など、SOAインフラストラクチャで使用するWebLogic Serverクラスタの共通アーティファクトの構成を同期化します。

SOAインフラストラクチャでは、WebLogic Serverクラスタに対して構成されたフロントエンド・ホストおよびポート情報を、サーバーおよびコールバック・サーバーURLとして使用します。これらの設定は、管理コンソールから定義します。「クラスタ」→「SOA_Cluster_Name」→HTTP/HTTPSフロントエンド・ホスト→「ポート」を選択します。SOAインフラストラクチャが実行されているWebLogic Serverクラスタのアドレスがない場合、システムでは、サーバーおよびコールバック・サーバーURLに物理ホスト名が使用されます。

Oracle HTTP Serverによってフロントエンド処理されるSOA高可用性インストールでは、Oracle HTTP Serverのリスニング・ポートでの監視が必要になります。これは、SOA管理対象サーバーにデプロイされたすべてのコンポーネントがデプロイメントで使用される場合です。HTTP/HTTPSポートをpingし、事前に決められた応答が返されることを予期する単純なHTTPモニターであれば十分です。特定のSOAコンポーネント(B2Bなど)のみが使用されている場合は、使用中のコンポーネントの状態を検証するために、破損したサーバー全体のより深いレベルまでチェックするモニターを使用することも考えられます。ご使用のロード・バランサでのHTTPモニターの設定方法については、ロード・バランサのベンダーにご確認ください。

サーバーおよびコールバック・サーバーURLの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。クラスタのHTTPフロントエンド・アドレスの変更では、クラスタの一部である管理対象サーバーを再起動する必要があります。

デプロイメント・コーディネータが構成され、コンポジットのデプロイと更新に使用されます。グループ・リーダーによりアーティファクトが更新されると、デプロイメント・コーディネータは、デプロイメント・コーディネータ・クラスタのメンバーに通知を送って、MDSリポジトリから新しいアーティファクトを取得します。デプロイメント後、またはコンポジットに変更があったときに、リーダー・ノードは、クラスタに対してMDSの更新などのシングルトン操作を実行します。

SOAインフラストラクチャ・システムでは、WebLogic Serverクラスタ名をキーとして使用し、デプロイメント・コーディネータ・グループを確認します。WebLogic Serverクラスタのすべてのノードが(マルチキャストまたはユニキャストで)通信できる場合、デプロイメント・コーディネータ・クラスタは、SOAインフラストラクチャを実行するWebLogic Serverクラスタと同じです。

管理サーバーは、アクティブ/パッシブ・モードで実行されます。SOAHOST1で障害が発生したときには、いつでもSOAHOST2の管理サーバーを再起動できます。管理サーバーは、リスナー・アドレスとして仮想IPまたは仮想ホスト名を使用します。

管理サーバーの仮想IPの構成および高可用性のための管理サーバーの構成の詳細は、第12章「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。

Oracle WebLogic Serverのサーバー全体の移行

SOAインフラストラクチャは完全なアクティブ/アクティブ・モードで実行可能ですが、アーキテクチャでは一部のSOAコンポーネントを障害から保護するために、WebLogic Serverの移行機能を使用します。

図5-5に示すように、WLS_SOA1はVIP1でリスニングし、WLS_SOA2はVIP2でリスニングします。各管理対象サーバーはフェイルオーバー・リソースとして他方のノードを使用し、システムは交差的に構成されます。WLS_SOA1はSOAHOST2にフェイルオーバーし、WLS_SOA2はSOAHOST1にフェイルオーバーします。2つのSOA管理対象サーバーが同一ノード上で実行されるシナリオを予想して、適切な容量計画を立てる必要があります。サーバー移行機能の詳細は、このガイドの第3章「WebLogic Serverの高可用性」を参照してください。

サーバーの移行後にトランザクションを再開するため、トランザクションとJMSストアを共有記憶域に構成します。サーバー・インフラストラクチャ・インスタンスの1つで障害が発生した場合、他のインスタンスがその共有記憶域から永続ストアを読み取って、トランザクションとJMS操作を再開できます。

メタデータ・ストアは、データベースの障害から保護するために、Oracle RACデータベース内に構成されます。同時に、Oracle RACデータベースには、SOAプロセスの状態情報も格納されます。この例では、どちらのOracle RACデータベースも同一になります。

Oracle SOAインフラストラクチャ・コンポーネントについて

これらの高可用性の特性は、クラスタにデプロイされるコンポジット・アプリケーションに組み込まれているほとんどのOracle SOA Suiteコンポーネントに当てはまります。個々のコンポーネントの特定の2ノード高可用性の特性については、この章の個別のコンポーネントの項を参照してください。

5.2.2.1 Oracle SOAインフラストラクチャの障害からの保護および予想される動作

この項では、Oracle SOA Suiteの高可用性クラスタ・デプロイメントによって、コンポーネントを障害から保護する仕組みと、コンポーネントの障害が発生したときに予想される動作について説明します。

WebLogic Serverインフラストラクチャは、SOAインフラストラクチャ・システムをあらゆるプロセス障害から保護します。

このトピックには、次の項があります。

第5.2.2.1.1項「WebLogic Serverの障害」
第5.2.2.1.2項「ノード障害」
第5.2.2.1.3項「データベース障害」

5.2.2.1.1 WebLogic Serverの障害

WLS_SOAxサーバーで障害が発生すると、ノード・マネージャはローカルでこのサーバーを再起動します。繰り返し再起動しても失敗する場合、WebLogic Serverインフラストラクチャは、クラスタ内の他のノードへのWLS_SOAxサーバーのサーバー移行を実行します。フェイルオーバーの実行中は、他のSOAインフラストラクチャ・インスタンスがデプロイメントとコンポジットの更新を主導的に実行し、システム内のサービス・エンジンに必要な基本サービスを提供します。

Oracle HTTP Serverからの処理中のリクエストはタイムアウトして、新しいリクエストは他のWLS_SOAxサーバーに送られます。他のノードでサーバーが正常に再起動されると、Oracle HTTP Serverは、サーバーへの受信したリクエストのルーティングを再開します。移行先のサーバーは、再起動中に実行された更新をMDSリポジトリから読み取り、デプロイメント・コーディネータ・クラスタを結合して新しい更新をリスニングします。また、共有記憶域にあるトランザクション・ログを基に、保留されていたトランザクションを再開します。

サーバー移行シナリオでは、Oracle BPEL PMやOracle Mediatorなどのサービス・エンジンは、SOAインフラストラクチャとともにフェイルオーバーされます。サービス・エンジン自体は、他のSOAインフラストラクチャ・インスタンスに対してリクエストを再発行しません。フェイルオーバーが完了すると、サービス・エンジンは、SOAインフラストラクチャとともに操作を再開します。

SOAインフラストラクチャ・アプリケーションは、リソースへのアクセスの失敗、デプロイメント・コーディネータ・インフラストラクチャが原因で発生するエラーまたは管理対象サーバーが実行されているかどうかには関係なく発生する問題が原因で使用できなくなる場合があります。そのため、管理者がsoa-infraアプリケーションによって引き起こされるエラーを管理対象サーバーのログで監視することをお薦めします。ログ・ファイルの場所の詳細は、第5.2.1.6項「Oracle SOAインフラストラクチャのログ・ファイルの場所」を参照してください。

5.2.2.1.2 ノード障害

ノード障害が発生した場合、使用可能なサーバーによりデータベース・リース・システム内のタイムスタンプが検証された後、サーバーの移行がトリガーされます。障害が発生したサーバーがデプロイメント・コーディネータ・クラスタ・マスターであった場合、使用可能なサーバーが新しいマスターとなり、SOAインフラストラクチャはデプロイメントおよびコンポジット・ライフサイクルに対して引き続き使用可能となります。リースのタイムスタンプが検証された後、現在も使用可能なノードのノード・マネージャが、障害が発生した管理対象サーバーで使用されているVIPの移行を試行し、VIPアドレスをローカルで再起動します。これによって、SOAインフラストラクチャ・アプリケーションは同一ノードで実行される2つのインスタンスを持つようになります。フェイルオーバー・プロセスの詳細は、第3.9項「サーバー全体の移行」を参照してください。

サービス・エンジンは、サービス・インフラストラクチャ・アプリケーションの一部としてコンテナにデプロイされます。このようなサービス・エンジンには、すべてのEARファイルとライブラリ・コールが含まれます。

5.2.2.1.3 データベース障害

SOAインフラストラクチャ・システムは、GridLinkデータ・ソースおよびマルチ・データ・ソースによって、データベースの障害から保護されます。GridLinkデータ・ソースおよびマルチ・データ・ソースは、システムの設定時に構成し、Oracle RACデータベース・インスタンスで障害が発生した場合に、使用可能なデータベース・インスタンスとの接続が確実に再確立されるようにします。

注意:

SOAに対して高速接続フェイルオーバー・フラグを無効化する必要があり、無効化しない場合、NULLポインタ例外が発生します。

Oracle RACおよびMDSリポジトリでのGridLinkデータ・ソースの構成の詳細は、第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」を参照し、マルチ・データ・ソースのOracle RACおよびMDSリポジトリでの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

5.2.2.2 Oracle SOAインフラストラクチャのクラスタワイドのデプロイメント

前述の項で説明したとおり、コンポジットのデプロイメントは、SOAインフラストラクチャによって、中央のMDSリポジトリに格納されます。SOAインフラストラクチャは、起動するたびにMDSリポジトリおよびSOAストアと同期化して、デプロイメントとプロセスの状態を取得します。デプロイメント・コーディネータ・インフラストラクチャは、コンポジットのデプロイメントと更新の通知を作成します。新たなデプロイメントまたは更新が実行されると、デプロイメント・コーディネータは、クラスタ内のすべてのメンバーに通知します。デプロイメントが正常に終了したことをクラスタ内のすべてのメンバーが確認すると、マスターはコンポジットの起動通知を送信します。ノードの1つでデプロイメントが失敗すると、他のクラスタにデプロイメントがロールバックされます。デプロイメント・コーディネータ・マスター(WebLogic Serverの管理対象サーバー)のエラー・メッセージで、デプロイメントが失敗したノードが示されます。図5-6はこのプロセスを表しています。

図5-6 Oracle SOA Suiteコンポジットのクラスタワイドのデプロイメント

「図5-6 Oracle SOA Suiteコンポジットのクラスタワイドのデプロイメント」の説明

5.2.2.3 クラスタ内でのOracle SOAインフラストラクチャ・コンポジットのオンライン再デプロイメント

SOAインフラストラクチャがコンポジットの更新や再デプロイメントを実行するときに、既存のバージョン(x)に上書きしたり、新バージョン(x+1)を作成することができます。コンポジットはすべて、コンポジット名とリビジョンに基づいて一意に識別されます。デフォルトでは、コンポジットにアクセスするクライアントは、MDSリポジトリ内で識別されるバージョン(Oracle Enterprise Manager Fusion Middleware Controlでも参照可能)をデフォルト・バージョンとして使用します。各バージョンのライフサイクルを個別に管理して、SOAインフラストラクチャの単一インスタンスであっても、オンラインでコンポジットを再デプロイメントできます。この操作を実行する手順は次のとおりです。

バージョンxをデプロイします。
バージョンxをデフォルトに指定します。
コンポジットの新バージョン(x+1)をデプロイし、version xをデフォルトに指定します。この手順によって、ユーザーがデフォルト・アクセスで新バージョンにアクセスしないようにします。
テスト・クライアントからコンポジットのバージョン(x+1)を指定し、新バージョンにアクセスしてテストします。
x+1をデフォルト・バージョンに指定します。新クライアントはバージョンx+1にルーティングされ、一方、旧クライアントはバージョンx内で処理を完了します。

前バージョンをデプロイしたままにすることも、アンデプロイすることもできます。進行中のインスタンスのあるコンポジットをアンデプロイすると、それらのインスタンスは失効し、完了しません。コンポジットをアンデプロイメントすることにより、MDSリポジトリからコンポジットが削除されます。

5.2.2.4 Oracle SOAインフラストラクチャのクラスタワイドの構成変更

SOAインフラストラクチャが使用する標準Java EEアーティファクトは、SOAがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソース、永続ストアおよびJMSモジュールなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、SOAインフラストラクチャで使用されるライブラリの同期化を制御します。

第5.2.1項「Oracle SOAインフラストラクチャの単一インスタンスの特性」で説明したとおり、SOAインフラストラクチャ固有の構成は、SOAデータベースに格納されます。変更はSOAサーバーごとに一度適用されますが、同じSOAドメイン内のすべてのSOAサーバーに影響します。たとえば、この章で説明する高可用性テクノロジでは、サーバーWLS_SOA1のコールバック・サーバーURLまたは監査レベルを変更した場合、その変更はサーバーWLS_SOA2にも適用されます。

注意:

MBeanブラウザを使用してOracle Enterprise Manager Fusion Middleware Controlからコンポジットのプロパティを変更すると、SOAクラスタ内のすべてのノードにも反映されます。たとえば、oracle.soa.config node、server:WLS_SOA1(クラスタ化されたノード)、SCAComposite、My Compositeを選択してMbeanを変更した場合、この変更はクラスタ内の他のサーバーにも伝播します。

5.3 Oracle BPEL Process Managerと高可用性の概要

この項では、高可用性のためのOracle BPEL PMの構成を実行する前に知っておく必要のある問題や考慮する必要のある事項を紹介します。

第5.3.1項「Oracle BPEL Process Managerの単一インスタンスの特性」
第5.3.2項「Oracle BPEL Process Managerの高可用性アーキテクチャとフェイルオーバーに関する考慮事項」

5.3.1 Oracle BPEL Process Managerの単一インスタンスの特性

サービス・エンジンは、SOAコンポジット・アプリケーション内のサービス・コンポーネントのビジネス・ロジックをホストするコンテナです。各サービス・コンポーネントは、自身のサービス・エンジンで実行されます。サービス・エンジンはSOAインフラストラクチャに組み込まれます。Oracle BPELプロセス・エンジンは、SOAインフラストラクチャ内で実行され、BPELプロセスを実行可能にするサービス・エンジンです。

BPELプロセスは、個々のサービスのセットをエンドツーエンド・プロセス・フローにアセンブルし、同期および非同期サービスをエンドツーエンドBPELプロセス・フローに展開するための標準を提供します。これにより、長期にわたって実行される非同期プロセスがオーケストレーションされ、保存されます。

図5-7は、BPELエンジンがSOAインフラストラクチャのステートレスな部分であることを示しています。SOAインフラストラクチャ・アプリケーションを使用して起動し、BPELプロセスを実行するモジュールを含んでいます。デプロイされたコンポジットにBPELプロセスがある場合、SOAインフラストラクチャは、BPEL Process Managerを起動して、MetaDataStoreからコンポーネントを取得します。

図5-7 Oracle BPEL PMの単一インスタンス・アーキテクチャ

「図5-7 Oracle BPEL PMの単一インスタンス・アーキテクチャ」の説明

BPEL Process Managerは、作業ユニットが格納されているメモリー内論理キューを管理するディスパッチャ・モジュールを使用して、バインディング・コンポーネント(JMS、データベース、Webサーバー)からの受信メッセージを処理します。

BPEL Process Managerエンジンは、Oracle TopLinkに基づいた永続モジュールによって、プロセスの実行状態をSOAデータベースに保存します。監査フレームワークは、プロセスの実行情報をSOAデータベースに格納して、実行中の処理を継続的に監査します。

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

第5.3.1.1項「BPEL Process Managerのコンポーネントの特性」
第5.3.1.2項「Oracle BPEL Process Managerの起動とシャットダウンのライフサイクル」
第5.3.1.3項「Oracle BPEL Process Managerのリクエスト・フローとリカバリ」
第5.3.1.4項「Oracle BPEL Process Managerの構成アーティファクト」

5.3.1.1 BPEL Process Managerのコンポーネントの特性

BPELサービス・エンジンは、SOAインフラストラクチャのJava EEアプリケーション(soa-infra.ear)内で実行されます。BPELサービス・エンジンではシングルトン・サービスはありません。BPELプロセスに関連するすべての状態がデータベース(デハイドレーション・ストア)に格納されるため、メモリー内の状態のレプリケーションは必要ありません。

SOAインフラストラクチャのJava EE EJBで実行される処理は、トランザクション処理され、Oracle WebLogic Serviceのトランザクション制御サービスに依存します。WebLogic Serverコンテナの障害から確実にリカバリできるようにするために、WebLogic Serverのガイドラインで推奨されている適切なトランザクション・ストアを構成してください。BPELエンジン・システムにはWebモジュールがないため、Oracle BPEL PMをアクティブ/アクティブ・モードで実行している場合は、サーブレット・レイヤーにセッション・レプリケーションは必要ありません。

BPELサービス・コンテナでの非同期メッセージ・ディスパッチは、JMSに依存しないため、分散JMSインフラストラクチャへの依存性はありません。

外部依存性

BPELエンジン・システムは、次のコンポーネントに依存します。

BPELプロセスの状態の永続性については、SOAインフラストラクチャ・データベース
BPEプロセスのメタデータ・ストアについては、MDSリポジトリ

BPELエンジン・システムが適切に起動し、実行されるためには、どちらのコンポーネントも使用可能である必要があります。

5.3.1.2 Oracle BPEL Process Managerの起動とシャットダウンのライフサイクル

図5-8に示すとおり、SOAインフラストラクチャ・アプリケーションは、起動時にBPELエンジンを初期化し、MDSリポジトリからコンポジットをロードします。コンポジットにBPELプロセスが含まれる場合は、それら個々のコンポーネントをBPELエンジンにターゲット指定します。プロセスがロードされると、システムはリクエストを受信できるようになります。実行時に、BPELエンジンは、JMSおよびデータベースなどの様々なチャネルからのリクエストを待機します。

図5-8 Oracle BPEL Process Managerの起動とシャットダウンのライフサイクル

「図5-8 Oracle BPEL Process Managerの起動とシャットダウンのライフサイクル」の説明

起動とシャットダウンのライフサイクルの詳細は、次のとおりです。

SOAサーバーを起動します。
BPELエンジンを起動します。
SOAインフラストラクチャによってMDSリポジトリからコンポジットがロードされます。
BPEL PMコンポーネントが、ロードされるBPELエンジンにディスパッチされます。
コンポジット・バインディング・コンポーネントがアクティブになります。
BPELエンジンがリクエストを処理します。
シャットダウン・シグナルがSOAインフラストラクチャによって受信されます。
SOAインフラストラクチャは、ロードされているコンポジットのアンデプロイを開始します。
コンポジット・バインディング・コンポーネントが無効化されます。
BPELコンポーネントが、アンロードされるBPELエンジンにディスパッチされます。
BPELエンジンがシャットダウンされます。

5.3.1.3 Oracle BPEL Process Managerのリクエスト・フローとリカバリ

リカバリ可能なアクティビティは、失敗したアクティビティですが、リカバリが可能です。たとえば、非同期BPELプロセスを起動するファイル・アダプタを使用しているときに、システムがインスタンスの処理中にクラッシュした場合は、すべてのメッセージ・レコードが確実にリカバリされるように、サーバーが再起動したときに手動でリカバリを実行できます。

BPELプロセスには、呼出しインタフェースに応じて2つのタイプがあります。

一方向: もっとも一般的な非同期ファイア・アンド・フォーゲット・パターン
双方向: 同期リクエスト・レスポンス・パターン

サーバー障害後のリカバリ・セマンティックは、プロセスが同期的に呼び出されるか、非同期的に呼び出されるかによって決まります。次に、呼出しとプロセスのタイプ別の動作を説明します。

同期呼出し(リクエスト): 同期リクエストでは、サーバー障害時にエラーがクライアントに戻されます。クライアントは、エラー・メッセージを処理して、リクエストの再試行などの適切な措置を講じます。これは、一時プロセスと永続プロセスの両方に対して当てはまります。

注意:

永続プロセスでは、メッセージは、特定時点のデハイドレーション・ストアに永続的に保持されます。Enterprise Managerを使用してデハイドレーション・ストアのメッセージをリカバリしプロセスを再実行することは、クライアントにレスポンスが通知されないためお薦めしません。すべてのリカバリはクライアントから管理してください。

非同期呼出し(ポスト): 非同期呼出しには2つのタイプがあり、1つはプロセスを新しく開始するもので、もう1つは既存プロセスへのコールバックです。コールバックの場合、エンジンは、それが継続操作であることを認識した後、最初に対話ID、次に相関セット(定義されている場合)により、サブスクライブ・プロセスの解決を試行します。非同期リクエストに関連するメッセージは、クライアント・コールの一部として、デハイドレーション・ストアに永続的に保持されます。永続的に保持される前に障害が発生した場合、クライアントは、エラー・メッセージを受け取るとともに、同期呼出しのエラーの場合と同様の方法でエラーを処理します。永続的な保持が成功すると、クライアント・コールが戻され、以降の処理がクライアント・コールのコンテキストの外部で実行されます。サーバーの障害が発生した場合は、Oracle Enterprise Managerを使用して、非同期に呼び出された一方向プロセスを再起動できます。

図5-9 Oracle Enterprise Manager BPEL PMエンジンのリカバリ

「図5-9 Oracle Enterprise ManagerのBPEL PMエンジンのリカバリ」の説明

BPELエンジンでサポートされている同期モデルと非同期モデルの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』および『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。

5.3.1.4 Oracle BPEL Process Managerの構成アーティファクト

Oracle BPEL PMの構成パラメータはSOAデータベースに格納されます。

これらのパラメータを構成するには、Oracle Enterprise Manager Fusion Middleware Controlに移動して、ナビゲーション・ツリーで「SOA」→「soa-infra」→「(server_name)」を選択します。「SOA管理」を右クリックし、「BPELプロパティ」を選択するか、MBeanブラウザを使用して、適切なプロパティに移動します。

これらのプロパティは、Oracle SOA Suiteを実行するWebLogic Serverが属する各WebLogicドメイン・ディレクトリに固有のものです。データソースおよび永続ストアなど、コンテナ・レベルの他の構成オプションは、WebLogic Serverのドメイン構成の一部として保持され、WebLogic Serverのコア・インフラストラクチャにより、WebLogic Serverのクラスタ上で同期化されます。BPELエンジンの構成の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

図5-10は、WebLogic Server管理コンソールを示しており、この管理コンソールでOracle BPEL PMプロパティを構成できます。

図5-10 Oracle BPEL PMの構成プロパティ

「図5-10 Oracle BPEL PMの構成プロパティ」の説明

クラスタ環境でOracle SOA Suiteを使用している場合、あるノードで構成プロパティを変更する場合、その変更をすべてのノードで行う必要があります。

構成プロパティを設定するには、次の手順に従います。

「SOAインフラストラクチャ」メニューから、「管理」、「システムMBeanブラウザ」の順に移動します。
「SOA管理」→任意のプロパティを選択します。

5.3.2 Oracle BPEL Process Managerの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

図5-5は、2つのWebLogic ServerでOracle SOAインフラストラクチャの2ノード・クラスタが実行されている様子を示しています。Oracle BPEL PMは、SOAインフラストラクチャの一部としてデプロイされます。

5.3.2.1 Oracle BPEL Process Managerの障害からの保護および予想される動作

SOAインフラストラクチャの障害からの保護および予想される動作の詳細は、第5.2.2.1項「Oracle SOAインフラストラクチャの障害からの保護および予想される動作」を参照してください。

WebLogic Serverインフラストラクチャは、BPELエンジンをあらゆるプロセス障害から保護します。次のプロセス障害に関する考慮事項は、Oracle BPEL PMに適用されます。

管理対象サーバーで障害が発生すると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。サーバー全体の移行が構成されており、繰り返し再起動しても失敗する場合、WebLogic Serverインフラストラクチャは、クラスタ内の他のノードへのサーバー移行を実行します(サーバー移行が構成されている場合)。他のノードでサーバーが再起動されると、Oracle HTTP Serverは、サーバーへの受信したリクエストのルーティングを再開します。移行されたサーバーは、SOAデータベースを読み取って、保留されていた処理を再開し、共有記憶域にあるトランザクション・ログを基にトランザクションを再開します。
管理対象サーバーが正常に起動した後でも、JDBCデータ・ソースやOracle Coherence構成に関連するエラーが原因で、BPEL PMサービス・エンジンまたはSOAインフラストラクチャ全体が使用できなくなる場合があります。そのため、SOAインフラストラクチャのログでエラーを監視する必要があります。サーバー・ログの場所の詳細は、第5.2.1.6項「Oracle SOAインフラストラクチャのログ・ファイルの場所」を参照してください。

さらに、WebLogic Serverインフラストラクチャを使用したBPELエンジン自体の障害の処理では、Oracle Enterprise Manager Fusion Middleware Controlで、リカバリ可能として識別されたBPELプロセス・フォルトに対して、フォルト・リカバリ・アクションを定義して実行できます。フォルトに対して実行するリカバリ・アクションは、フォルト・リカバリ・ポリシー・ファイルでBPELプロセス・サービス・コンポーネントに定義されたアクションに基づくものです。

Oracle Enterprise Manager Fusion Middleware Controlでは、これらの障害のタイプを表示できます。

ビジネス: 処理中の情報に問題がある(データベースで社会保障番号が見つからないなど)ときに発生するアプリケーション固有のフォルト。
システム: データベース・サーバーが完全に使用不可能であったり、Webサービスにアクセス不可能であったりするなどの、ネットワークおよび他のタイプのエラー。
Oracle Web Services Manager (WSM): SOAコンポジット・アプリケーション、サービス・コンポーネントまたはバインディング・コンポーネントにアタッチされているポリシーのエラー。

フォルト・リカバリ・ポリシーは設計時に定義します。コンポジットに付属のフォルト・ポリシー・ファイルには、障害発生時に講じる措置が定義されています。詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

インスタンスの欠落

一方向呼出しリクエストのインバウンド・ペイロードは、デハイドレーション・ストアに格納され、現行のグローバル・トランザクションのコンテキストに従ってコミットされます。コール元がすでにグローバル・トランザクションを開始している場合は、コール元がトランザクションをコミットするときに呼出しメッセージが保存され、受信トランザクションがない場合は、新しいトランザクションが開始されて呼出しメッセージがコミットされます。

Enterprise ManagerにBPEL PMインスタンスが見つからない場合は、手動リカバリ・コンソールに呼出しメッセージが存在することがあります(リカバリ・コンソールには、未配信のすべての受信メッセージがリストされます)。

リカバリ・コンソールに呼出しメッセージがない場合は、コール元のトランザクションのステータスをチェックしてください。

エンドポイントでのトランザクションの問題

BPELは、リクエストが開始されたグルーバル・トランザクション内でデハイドレートできないインスタンスの監査証跡を非同期に保存します。BPELコンポーネントから参照されるトランザクション・サービスがトランザクションをロールバックした場合にも、BPELインスタンスの監査証跡がEnterprise Managerに保存されます。デハイドレーション・ストアに問題がある場合は、グルーバル・トランザクション全体がロールバックされ、監査証跡は保存されません。この場合、メッセージやアクティビティをリカバリして、最後に認識されたデハイドレーション地点から処理を取得できます。

デハイドレーション・ポイントが複数ノードを持つOracle RACデータベースであり、BPELエンジンがホストされているJava EEサーバーがOracle RACノードへのJDBC接続を失った場合、BPELエンジンはトランザクションを再試行します(これにより、現行トランザクションで加えられたすべての変更はロールバックされます)。新たなOracle RACノードへの新たな接続が確立できない場合は、リカバリ・コンソールを使用してBPELメッセージまたはBPELアクティビティをリカバリできます。

ロギング

BPELエンジン・ロガーは、デフォルトでINFOレベルに設定されます。メッセージやインスタンスを検索するには、ロガーをTRACEレベルに設定して、WebLogic Serverログ・ファイルに詳細を出力できます。デハイドレーションのログ・メッセージについては、oracle.soa.bpel.engine.dataを有効にします。スレッドまたはディスパッチャのログ・メッセージについては、oracle.soa.bpel.engine.dispatcherを有効にします。すべてのエンジン・ログ・メッセージを取得するには、oracle.soa.bpel.engineを有効にします。

5.3.2.1.1 失敗したBPELインスタンスおよびMediatorインスタンスのリカバリ

サーバーの障害が発生した場合は、非同期に呼び出された進行中の一方向プロセスの手動リカバリが必要になることがあります。このようなプロセスは、リカバリ可能とマークされるため、図5-11で示すとおり、Oracle Enterprise Managerを使用して再起動します。

図5-11 Oracle Enterprise Managerを使用したBPEL PMインスタンスのリカバリ

「図5-11 Oracle Enterprise Managerを使用したBPEL PMインスタンスのリカバリ」の説明

5.3.2.2 Oracle BPEL Process Managerのクラスタワイドの構成変更

BPELエンジンが使用する標準Java EEアーティファクトは、SOAがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソース、永続ストアおよびJMSモジュールなどのアーティファクトの自動構成同期化機能を提供します。

第5.3.1項「Oracle BPEL Process Managerの単一インスタンスの特性」で説明したように、BPELエンジン固有の構成は、SOAデータベースに格納されます。変更はSOAサーバーごとに一度適用されますが、同じSOAドメイン内のすべてのBPELインスタンスに影響します。たとえば、WLS_SOA1およびWLS_SOA2が同じSOAクラスタの一部である場合、WLS_SOA1内のBPELのディスパッチャ・スレッド数が20に変更されると、WLS_SOA2のディスパッチャ・スレッドも20に設定されます。

5.4 Oracle BPM Suiteと高可用性の概要

Oracle BPM Suiteは、ビジネス・プロセス管理(BPM)プロジェクトを設計、デプロイおよび管理するコンポーネントの完全なセットを提供します。

5.4.1 Oracle BPM Suiteの単一インスタンスの概要

図5-12に示すとおり、Oracle BPM Suiteは、BPMプロジェクトを開発、管理および監視するための包括的な製品セットを提供します。BPMランタイムは、共通のサービス・インフラストラクチャによって管理およびインターコネクトされるサービス・エンジン(BPMNサービス・エンジン、BPEL Process Manager、Human Workflow、Rules、Mediator)およびバインディング・コンポーネント(JCAアダプタ、B2B)で構成されます。サービス・インフラストラクチャは、ライフサイクル管理およびBPMプロジェクトのデプロイメントの共通サービスも提供します。

図5-12 BPM Suiteの単一インスタンス・アーキテクチャ

「図5-12 BPM Suiteの単一インスタンス・アーキテクチャ」の説明

BPMプロジェクトは、BPMランタイム・エンジンへのデプロイメントの基本単位です。BPMプロジェクトは、サービス・コンポーネントと参照情報で構成されており、この参照情報は、SOAコンポジット、組織データ(ロールなど)、ビジネス・インジケータのメタデータおよびダッシュボード・データとして編成されています。

コンポーネントは、デプロイメント時にサービス・エンジンにターゲット指定され、サービスと参照は、バインディング・コンポーネントを使用することで有効になります。組織データ、ビジネス・インジケータおよびダッシュボードのメタデータは、永続的に保持され、実行時にコンポーネントによって評価されます。実行時には、メッセージはバインディング・コンポーネントまたはBPM Workspaceによって受信され、サービス・インフラストラクチャによって適切なサービス・エンジンにルーティングされます。

図5-13は、Oracle BPM Suiteインフラストラクチャ・スタックの図を示しています。

図5-13 BPM Suiteインフラストラクチャ・スタックの図

「図5-13 BPM Suiteインフラストラクチャ・スタックの図」の説明

BPMランタイム・エンジンは、WebLogic Serverなどのアプリケーション・サーバーのコンテキスト内で実行されます。これは、基盤となるアプリケーション・サーバーのロード・バランシングと高可用性の機能を利用します。

5.4.1.1 Oracle BPM Suiteのコンポーネントの特性

図5-14は、BPM Suiteのコンポーネント、それらの関係、およびそれらが相互に通信するために使用するテクノロジを示しています。

図5-14 BPM Suiteのコンポーネントとインタフェース

「図5-14 BPM Suiteのコンポーネントとインタフェース」の説明

BPM Suiteのコンポーネントは次のとおりです。

BPMNサービス・エンジン

BPMNは、Business Process Modeling Notationの略称です。BPMNサービス・エンジンは、既存のBPELサービス・エンジンの拡張機能であり、BPELのコア・インフラストラクチャを活用します。BPMNサービス・エンジンは、JPA/EclipseLinkを活用して、データベースによって保持されるSOAインフラストラクチャ・デハイドレーション・ストア内のプロセス・インスタンスの状態を格納またはリカバリし、プロセスの実行の過程で作成される監査レコードを永続的に保持します。MDS APIは、BPMNプロセス・モデルなどのBPMプロジェクト・アーティファクト(ビジネス・カタログなど)に関するメタデータ情報を取得します。
BPM Composer

BPM Composerは、標準のJ2EE Webアプリケーションです。エンド・ユーザーはブラウザからアクセスします。BPM Composerは、BPMインフラストラクチャ・ライブラリを活用します。プロジェクト・メタデータ層を使用して、BPMプロジェクトのアーティファクト(ビジネス・ルールやBPMNプロセスなど)を作成およびMDSから取得します。
BPM Workspace

BPM Workspaceは、標準のJ2EE Webアプリケーションです。エンド・ユーザーはブラウザからアクセスします。BPM Workspaceは、Oracle Business Process Interface(OBPI)のAPIを使用して、ワークリストに表示するための、BPMNプロセス・インスタンスおよびユーザー・タスクに関する情報を取得します。また、標準およびカスタムのダッシュボード用にCube Persistence APIを活用します。
BPMインフラストラクチャ・ライブラリ

もっとも重要なBPMインフラストラクチャ・ライブラリは次のとおりです。
- OBPI:
  
  Oracle Business Process Interfaceは、プロセス・インスタンスやユーザー・タスクなどに関する情報にアクセスする方法を提供します。これは、WebLogic Server内のライブラリとしてデプロイされ、EJBインタフェースおよび依存関係インジェクションのSpring Beanを公開します。OBPIは、ヒューマン・ワークフロー・サービス、アイデンティティ・サービス、ファサードAPIなど、既存のSOAサービスを活用します。OBPIは、BPMインフラストラクチャにアクセスする必要のあるクライアントにとって第一のインタフェースです。
- PML:
  
  プロジェクト・メタデータ層(Project Metadata Layer)は、BPMプロジェクトを管理するための内部APIです。これは、BPMプロジェクトの格納、取得およびラベル付けのためにMDSを活用し、BPM ComposerおよびBPMNサービス・エンジンによって使用されます。
- 分析:
  
  分析ライブラリは、プロセス・キューブを管理する方法を提供します。このライブラリは、EJB3(ステートレス)インタフェースを公開し、永続性のためにJPA/EclipseLinkを使用します。このライブラリは、BPM Workspaceによって使用されます。
注意:

Oracle BPMNサービス・エンジンはBPM Suiteのコアな部分であるため、次の各項で詳細に説明します。

5.4.1.2 Oracle BPM Suiteのコンポーネントの相互作用

表5-1は、BPM Suiteコンポーネントの相互作用のしくみ、およびBPMNプロセスの実行時に実行されるタスクについて示しています。

表5-1の各行は、特定のBPM Suiteコンポーネントを示します。表5-1の最初の列に続く、各列の見出しは、BPMNプロセスの実行時の特定の時点を表します(T1は最初の時点、T2は次の時点など)。T8は、プロセス実行の最後の時点になります。コンポーネントごとに実行可能なタスクは、BPMNプロセスの実行時にタスクが実行される時点におけるそのコンポーネントの行に示されます。

表5-1 BPMNプロセスの実行時にBPM Suiteコンポーネントによって実行されるタスク

コンポーネント	T1	T2	T3	T4	T5	T6	T7	T8
BPM Workspace		タスクの開始を使用してプロセス・インスタンスをインスタンス化する		ユーザー・タスクを承認する		タスクのパフォーマンスとワークロードを監視する		プロセスのパフォーマンスを監視する
BPM Composer	BPMプロジェクトをデプロイする
BPMNサービス・エンジン			プロセス・インスタンスを実行する		プロセス・インスタンスの実行を続行する		プロセス・インスタンスを完了する
BPM Studio	BPMプロジェクトをデプロイする
Webサービス・クライアント		コンポジット・サービスを呼び出してプロセス・インスタンスをインスタンス化する						結果を返す

次に、表5-1に示されているBPMNプロセス実行時の8つの時点(T1からT8)に関する詳細を示します。

T1.表5-1の例では、BPMプロジェクトが、BPM StudioとBPM Composerのいずれかで使用可能であり、デプロイメントの準備が整っていると想定します。BPM StudioまたはBPM ComposerからBPMプロジェクトをデプロイする処理の一環として、(SCA)アーカイブが作成され、WebLogic Serverで実行されている標準のSOAコンポジット・デプロイヤ・サーブレットに転送されます。コンポジット・デプロイヤ・サーブレットは、MDS内のBPMプロジェクトのコンテンツを格納し、新しいBPMプロジェクトがデプロイされたことを適切なサービス・エンジンに通知します。その後、BPMNサービス・エンジンは、処理するリクエストを受信できるようになります。
T2.BPMNプロセスを開始するには次の2つの方法があります。
- タスクの開始を使用する:
  
  ユーザーが、プロセス・インスタンスを起動するために、BPMNプロセスの図にあるタスクの開始をモデル化している場合は、デプロイメント・タスクがBPM Workspaceに表示された後、プロセス・インスタンスはここから起動できます。
- 任意のWebサービス(WSクライアント)を使用してタスクの開始でコンポジット・サービスを呼び出します。BPMNプロセスがサービス・インタフェースを公開している場合、そのサービスはコンポジット・サービスとして公開され、したがって、任意のWSクライアントを使用してプロセス・インスタンスをインスタンス化できます。
T3.BPMNサービス・エンジンは、プロセスの実行を開始し、最初のユーザー・タスクを実行するまでプロセスの実行を続行します。ユーザー・タスクの場合、BPMNサービス・エンジンは、OBPIを使用してヒューマン・タスクを作成します。その結果、SOAインフラストラクチャのデハイドレーション・ストアに新しいタスクが作成されます。
T4.BPM WorkspaceがOBPIを使用して、ワークリストに表示するための新しいタスクを問い合せます。BPM Workspaceにログインしたユーザーがタスクを処理するとみなされます。最終的に、タスクは承認または拒否され、そのタスクの処理は完了します。BPM WorkspaceがOBPIを使用してタスクを完了します。
T5.タスクが完了すると、BPMNプロセス内のユーザー・タスク・アクティビティも完了し、プロセスは続行可能になります。
T6.プロセス・インスタンスの実行時はいつでも、ユーザーがBPM Workspaceを使用してタスクのパフォーマンスとワークロードを監視できます。このために、BPM Workspaceは、Cube Persistence APIを活用して、データベース内に格納されているプロセス・キューブからタスク・パフォーマンス・データを問い合せます。
T7.最終的に、BPMNプロセスが完了します。
T8.通常、この最後の手順は、MessageEndイベントを通じてプロセスを呼び出したクライアントに結果を返します。プロセスが完了すると、ユーザーはBPM Workspaceを使用してプロセスのパフォーマンスを監視できます。

5.4.1.3 Oracle BPM Suiteの起動とシャットダウンのライフサイクル

BPELサービス・エンジンを基にしているため、起動とシャットダウンのライフサイクルは、BPELサービス・エンジンと同じです。詳細は、第5.3.1.2項「Oracle BPEL Process Managerの起動とシャットダウンのライフサイクル」および第5.4.2.1.3項「Oracle BPMNサービス・エンジンの起動とシャットダウンのライフサイクル」を参照してください。

BPM ComposerおよびBPM Workspaceでは、ライフサイクルは、WebLogic Serverに存在するWebアプリケーションと同じです。

BPMインフラストラクチャ・ライブラリのライフサイクルは、それらのライブラリを使用し、呼び出すシステムのライフサイクルになります。

5.4.1.4 Oracle BPM Suiteの構成アーティファクト

Enterprise ManagerでBPMNサービス・エンジンを構成するには、図5-15に示すとおり、soa-infraの「SOAインフラストラクチャ」リストから、「SOA管理」→「BPMNプロパティ」を選択します。

図5-15 BPMNサービス・エンジンの「プロパティ」ページの表示

「図5-15 BPMNサービス・エンジンの「プロパティ」ページの表示」の説明

図5-16に、BPMNサービス・エンジンの「プロパティ」ページを示します。BPMNサービス・エンジンの「プロパティ」ページで「詳細BPMN構成プロパティ」をクリックして、BPMN MBeanブラウザを起動し、追加のパラメータを確認します。

図5-16 BPMN MBeanブラウザの起動

「図5-16 BPMN MBeanブラウザの起動」の説明

Enterprise Managerを使用したOracle BPMNサービス・エンジンの構成の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。

Oracle BPMNサービス・エンジンの高可用性を構成するには、第5.13項「Oracle SOAインフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」を参照してください。

5.4.2 Oracle BPMNサービス・エンジンの高可用性

この項では、Oracle BPMNサービス・エンジンの単一インスタンスおよび高可用性について説明します。

第5.4.2.1項「Oracle BPMNサービス・エンジンの単一インスタンスの特性」
第5.4.2.2項「Oracle BPMNサービス・エンジンの高可用性に関する考慮事項」

5.4.2.1 Oracle BPMNサービス・エンジンの単一インスタンスの特性

サービス・エンジンは、BPMプロジェクト内のサービス・コンポーネントのビジネス・ロジックをホストするコンテナです。各サービス・コンポーネントは、自身のサービス・エンジン(SOAインフラストラクチャに組み込まれる)で実行されます。

BPMNプロセスは、標準化されたアクティビティ、ゲートウェイおよびイベントを使用して、ビジネス・プロセスをアセンブルするための標準を提供します。BPMNサービス・エンジンは、実行に長い時間がかかる可能性のあるBPMNプロセス・モデルの実行のための機能を提供します。

5.4.2.1.1 Oracle BPMNサービス・エンジンの単一インスタンス・アーキテクチャ

図5-17に示すとおり、BPMNサービス・エンジンは、Oracle BPEL Process Managerサービス・エンジン上に構築されたSOAインフラストラクチャのステートレスな部分です。Oracle BPEL Process Managerの高可用性の詳細は、第5.3項「Oracle BPEL Process Managerと高可用性の概要」を参照してください。

図5-17 Oracle BPMNサービス・エンジンの単一インスタンス・アーキテクチャ

「図5-17 Oracle BPMNサービス・エンジンの単一インスタンス・アーキテクチャ」の説明

BPMNサービス・エンジンは、BPEL PMディスパッチャ・モジュールを使用して、バインディング・コンポーネントからの受信メッセージを処理するためにディスパッチします。

プロセス実行の状態は、Java Persistence Architecture(JPA)に基づいた永続モジュールによってSOAデータベースに保存されます。BPMNサービス・エンジンの監査インフラストラクチャは、エンジンが実行する作業を継続的に監査し、監査レコードをBPMデータベースに格納します。これらの監査レコードは、Oracle Business Activity Monitoring(BAM)での測定およびBAMとの統合のソースとして使用されます。

BPMNサービス・エンジンは、SOAインフラストラクチャのJava EEアプリケーション(soa-infra.ear)内で実行されます。これはBPEL Process Manager上に構築されているため、特性もBPEL Process Managerと同じです。詳細は、第5.3.1.1項「BPEL Process Managerのコンポーネントの特性」を参照してください。

5.4.2.1.2 Oracle BPMNサービス・エンジンの外部依存性

BPMNサービス・エンジンは、次のコンポーネントに依存します。

BPMNプロセスの状態の永続性については、SOAインフラストラクチャ・データベース
分析データの永続性については、BPMデータベース

デフォルトでは、BPMデータベースはSOAインフラストラクチャ・データベースに連結され、追加の手順は必要ありません。
BPMNプロセスのメタデータ・ストアについては、MDSリポジトリ

BPMNサービス・エンジンが適切に起動し、実行されるためには、図5-17のコンポーネントが使用可能である必要があります。

BPMプロジェクトに応じて、BPMNサービス・エンジンは、次の追加コンポーネントに依存する場合があります。

BAMアダプタ
ユーザー・ディレクトリ。たとえば、Oracle Internet Directoryや、BPMと連動するように構成されている別のLDAPサーバーです。

5.4.2.1.3 Oracle BPMNサービス・エンジンの起動とシャットダウンのライフサイクル

図5-18に示すとおり、SOAインフラストラクチャ・アプリケーションは、起動時にBPMNサービス・エンジンを初期化し、MDSリポジトリからコンポジットをロードします。コンポジットにBPMNプロセスが含まれる場合は、それら個々のコンポーネントをBPMNサービス・エンジンにターゲット指定します。プロセスがロードされ、そのBPM固有のメタデータがデータベース内で永続的に保持された後に、システムはリクエストを受信できるようになります。

図5-18 Oracle BPMNサービス・エンジンの起動とシャットダウンのライフサイクル

「図5-18 Oracle BPMNサービス・エンジンの起動とシャットダウンのライフサイクル」の説明

起動とシャットダウンのライフサイクルの詳細は、次のとおりです。

BPMサーバーを起動します。
BPMNサービス・エンジンを起動します。
SOAインフラストラクチャによってMDSリポジトリからBPMプロジェクト・コンポジットがロードされます。
BPMNコンポーネントが、ロードされるBPMNサービス・エンジンにディスパッチされます。
組織データや監査/測定メタデータなどのBPMプロジェクト・メタデータがインフラストラクチャ・データベース内で永続的に保持されます。
コンポジット・バインディング・コンポーネントがアクティブになります。
BPMNエンジンがリクエストを処理します。
シャットダウン・シグナルがSOAインフラストラクチャによって受信されます。
SOAインフラストラクチャがコンポジットのアンロードを開始します。
コンポジット・バインディング・コンポーネントが無効化されます。
BPMNコンポーネントが、アンロードされるBPMNエンジンにディスパッチされます。
BPMNサービス・エンジンがシャットダウンされます。

5.4.2.1.4 Oracle BPMNサービス・エンジンのログ・ファイル

BPMNサービス・エンジン・ロガーは、デフォルトでINFOに設定されます。メッセージやインスタンスを追跡する場合、ロガーをTRACEレベルに設定して、WebLogic Serverログ・ファイルに詳細を出力できます。

BPMNサービス・エンジンは、SOAインフラストラクチャと同じファイルにトレース情報をログします。サーバー・ログの場所の詳細は、第5.2.1.6項「Oracle SOAインフラストラクチャのログ・ファイルの場所」を参照してください。

5.4.2.2 Oracle BPMNサービス・エンジンの高可用性に関する考慮事項

この項では、高可用性のためのOracle BPMN Process Managerの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。

5.4.2.2.1 Oracle BPMNサービス・エンジンの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

BPMNサービス・エンジンは、プロセス・インスタンスのリカバリのためにBPEL PMの機能を活用します。インスタンスのリカバリの詳細は、第5.3.2.1項「Oracle BPEL Process Managerの障害からの保護および予想される動作」を参照してください。

Oracle Enterprise Manager Fusion Middleware Controlで、図5-19に示すように、BPMNサービス・エンジンの管理用の「BPMNエンジン(サービス・エンジン)」を選択します。

図5-19 Enterprise ManagerにおけるBPMNサービス・エンジンのホーム・ページ

「図5-19 Enterprise ManagerにおけるBPMNサービス・エンジンのホーム・ページ」の説明

BPMNサービス・インスタンスをリカバリするには、「リカバリ」タブを選択してBPMNサービス・エンジンの「リカバリ」ページを開きます(図5-20を参照)。

図5-20 Enterprise ManagerにおけるBPMNサービスの「リカバリ」ページ

「図5-20 Enterprise ManagerにおけるBPMNサービスの「リカバリ」ページ」の説明

5.4.2.2.2 高可用性のためのOracle BPMNサービス・エンジンの構成

5.4.2.2.3 Oracle BPMNサービス・エンジンのクラスタワイドの構成変更

Oracle BPMNコンポーネントが使用する標準Java EEアーティファクトは、SOAがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、アーティファクトの自動構成同期化機能を提供します。WebLogic Serverクラスタは、デプロイメントと、BPMNコンポーネントで使用されるライブラリを同期します。第5.4.1.4項「Oracle BPM Suiteの構成アーティファクト」で説明したとおり、Oracle BPMNコンポーネントの構成は、SOA MDSデータベースに格納されます。変更はSOAサーバーごとに一度適用されますが、同じSOAドメイン内のすべてのOracle BPMNインスタンスに影響します。

5.4.3 Oracle Business Process Webアプリケーションの高可用性

この項では、Oracle Business Process Webアプリケーションの単一インスタンスおよび高可用性について説明します。

第5.4.3.1項「Oracle Business Process Webアプリケーションの単一インスタンスの特性」
第5.4.3.2項「Oracle Business Process Webアプリケーションの高可用性に関する考慮事項」

5.4.3.1 Oracle Business Process Webアプリケーションの単一インスタンスの特性

この項では、Oracle Business Process Webアプリケーションの単一インスタンスについて説明します。

5.4.3.1.1 Oracle Business Process Webアプリケーションの単一インスタンス・アーキテクチャ

図5-21に、Oracle BPM Suite Webアプリケーション、および他のBPMNコンポーネントとそれらの相互作用を示します。

図5-21 Oracle BPM Suite Webアプリケーション

「図5-21 Oracle BPM Suite Webアプリケーション」の説明

Webアプリケーションはステートレスです。状態はデハイドレーション・サービスで保持され、データは操作APIを通じて、またはMDSで公開されます。

5.4.3.1.2 Oracle Business Process Webアプリケーションの外部依存性

BPM WorkspaceとBPM Composerは両方とも、BPMNサービス・エンジンとは別にデプロイされますが、BPMNサービス・エンジンに完全に依存しています。BPMNサービス・エンジンが(soa-infraシステムで)停止した場合、BPM WorkspaceもBPM Composerも、デプロイ済のプロジェクトの情報とメタデータにアクセスできません。soa-infraはSOA MDSデータベースに依存しているため、Business Process Webアプリケーションが使用できるかどうかは、MDSデータベースにかかっています。

5.4.3.1.3 Oracle Business Process Webアプリケーションの起動とシャットダウンのライフサイクル

BPM WorkspaceとBPM Composerは、標準のJ2EEアプリケーションです。これらは、BPMがデプロイされているWebLogic Serverの起動時に起動されます。アプリケーションは、管理コンソールから制御し、強制シャットダウンまたは正常なシャットダウンで停止します。

5.4.3.1.4 Oracle Business Process Webアプリケーションのログ・ファイル

WorkspaceおよびComposerのWebアプリケーションは、SOA WebLogic Serverのログ・ファイルおよびSOA WebLogic Serverの出力に書き込みます。サーバー・ログの場所の詳細は、第5.2.1.6項「Oracle SOAインフラストラクチャのログ・ファイルの場所」を参照してください。

Oracle Enterprise Manager Fusion Middleware Controlを使用して、ログ・ファイル・メッセージを診断します。

5.4.3.2 Oracle Business Process Webアプリケーションの高可用性に関する考慮事項

この項では、Oracle Business Process Webアプリケーションの高可用性の考慮事項について説明します。

5.4.3.2.1 Oracle Business Process Webアプリケーションの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

BPM WorkspaceとBPM Composerは両方とも、ステートレスWebアプリケーションです。これらが存在するWebLogic Serverがロード・バランサまたはHTTPサーバーの背後にデプロイされると、フロントエンド・デバイスは、アプリケーションが実行されているいずれかのノードにリクエストをルーティングします。ノードの障害が発生すると、リクエストは、使用可能な他のWebLogic Serverにリダイレクトされ、ユーザー・インタフェースでの作業は、中断されることなく続行できます。

5.4.3.2.2 高可用性のためのOracle Business Process Webアプリケーションの構成

Oracle Business Process Webアプリケーションの高可用性の構成の詳細な手順は、第5.13項「Oracle SOAインフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」を参照してください。

5.4.3.2.3 Oracle Business Process Webアプリケーションのクラスタワイドの構成変更

サーバーのファイル・システムにローカルに存在するWebアプリケーションに対しては、特別な構成ファイルはありません。Workspaceのプロパティ・ファイルであるworkspace.propertiesなどの一部のプロパティ・ファイルは、OracleBPMWorkspace.earファイルの一部ですが、インスタンス固有の設定は含まれていません。これらは、Oracle BPM Workspaceがデプロイされている場所にデプロイされ、使用可能になります。

5.4.4 Oracle Business Process Analyticsの高可用性

この項では、Oracle Business Process Analyticsの単一インスタンスおよび高可用性について説明します。

5.4.4.1 Oracle Business Process Analyticsの単一インスタンスの特性

次の項では、Oracle Business Process Analyticsの単一インスタンスの特性について説明します。

5.4.4.1.1 Oracle Business Process Analyticsの単一インスタンス・アーキテクチャ

Oracle BPM Suiteには、ビジネスフレンドリなプロセス・ダッシュボードをサポートし、Oracle BAMを使用してビジネス・プロセスをリアルタイムに監視するための組込みの分析機能があります。

図5-22は、Oracle BPM Suite分析インフラストラクチャを示しています。

図5-22 Oracle BPM Suite分析インフラストラクチャ

「図5-22 Oracle BPM Suite分析インフラストラクチャ」の説明

技術的な観点から見ると、Oracle BPM Suite分析インフラストラクチャは、次のようなプロセス分析をサポートするために使用されます。

監査の永続性

BPMNサービス・エンジンは、アクティビティのラインタイム・データで構成される監査イベントを継続的に生成します。これらの監査イベントのデータは、サービス・エンジンのデハイドレーション・ストアの監査表に永続的に保持されます。監査データは、すべての分析データのソースです。
JMSトピック

分析データの準備と公開からプロセスの実行を切り離すには、SOAインフラストラクチャの一部として構成されたJMSトピックが使用されます。
キューブ・アクションMDB

メッセージ・ドリブンBean (MDB)は、分析データの集計と永続性を、SOAインフラストラクチャ・データベース内に格納されているBPMキューブ・スキーマにトリガーするために使用されます。
BAMアクションMDB

メッセージ・ドリブンBean (MDB)は、分析データを、SOAインフラストラクチャの一部としてインストールされたBAMアダプタに公開するために使用されます。
プロセスの永続性

SOAインフラストラクチャ・データベースに対する監査イベントおよび分析データの永続性のために、Oracle BPM Suiteは、Java Persistence API(JPA)インフラストラクチャを活用します。

永続性ユニットは、JTAデータ・ソースjdbc/SOADataSourceおよびプロバイダorg.eclipse.persistence.jpa.PersistenceProviderを使用して構成されます。

5.4.4.1.2 Oracle Business Process Analyticsの外部依存性

Oracle Business Process Analyticsライブラリおよびコンポーネントは、BPMNサービス・エンジン・インフラストラクチャの一部として実行されます。これらは、正常に機能するためには、BPMNサービス・エンジンのアーティファクト(問合せ、ストアおよびJDBCリソース)に大きく依存します。サービス・インフラストラクチャの場合と同様に、分析フレームワークが機能するには、SOAデータベースが使用可能である必要があります。さらに、BAMにデータをフィードする際、分析情報を処理するために、必須のBAMシステムが稼働している必要があります。

5.4.4.1.3 Oracle Business Process Analyticsの起動とシャットダウンのライフサイクル

Oracle Business Process AnalyticsはBPMNサービス・エンジンの一部であるため、そのライフサイクルはBPMNサービス・エンジンのライフサイクルと同じです。

5.4.4.1.4 Oracle Business Process Analyticsのログ・ファイル

Oracle Business Process Analyticsコンポーネントのトレースには、次のロガーが使用可能です。

oracle.bpm.analytics.measurement
oracle.bpm.analytics.cube
oracle.bpm.analytics.bam

分析コンポーネントのいずれかに対するロギングを有効にするには、ログ・レベルをTRACEに設定します。

5.4.4.2 Oracle Business Process Analyticsの高可用性に関する考慮事項

この項では、Oracle Business Process Analyticsの高可用性の考慮事項について説明します。

5.4.4.2.1 Oracle Business Process Analyticsの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

Oracle Business Process Analyticsは、他のシステムに情報をフィードする役割を持つサブシステムであるため、フェイルオーバーについて特別な考慮事項は必要ありません。Oracle Business Process Analyticsによって使用される多数のJMSキューは、可用性とロード・バランシングを最適にするために、(SOAシステムの高可用性の設定時に)均一に分散された宛先として構成されます。永続的に保持されるすべてのBPMキューブ・データは、SOA JDBCサービスを使用します。SOA JDBCサービスは、Oracle RACデータベース用に構成されたマルチ・データ・ソースを使用します。

5.4.4.2.2 高可用性のためのOracle Business Process Analyticsの構成

Oracle Business Process Analyticsの高可用性の構成の詳細な手順は、第5.13項「Oracle SOAインフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」を参照してください。

5.4.4.2.3 Oracle Business Process Analyticsのクラスタワイドの構成変更

Oracle Business Process Analyticsインスタンスには、ローカルのインスタンス固有プロパティは格納されません。クラスタの構成変更は、各Oracle Business Process Analyticsインスタンスに適用されます。

5.5 Oracle Mediatorと高可用性の概要

この項では、高可用性のためのOracle Mediatorの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。

5.5.1 Oracle Mediatorの単一インスタンスの特性

Oracle Mediatorは、SOAインフラストラクチャ内のサービス・エンジンです。各種プロバイダと、サービスやイベントのコンシューマとを仲介するフレームワークを提供します。Oracle Mediatorサービス・エンジンは、SOAインフラストラクチャのJava EEアプリケーションとともに即時実行されます。非同期の相互作用やパラレル・ルーティング・ルールの呼出しにより開始された実行のランタイム状態は、SOAランタイム・データベース内に保持されます。Oracle Mediatorの管理の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

同期および非同期の相互作用

Oracle Mediatorは、同期および非同期リクエスト・レスポンス相互作用をサポートします。同期相互作用では、リクエストを発行するクライアントは、ブロックされた状態のままでレスポンスを待機します。非同期相互作用では、クライアントはサービスを呼び出しますが、レスポンスを待機しません。非同期相互作用の場合は、タイムアウト期間を指定できます。
順次およびパラレルのメッセージ・ルーティング

Oracle Mediatorでは、メッセージを、順次またはパラレルに宛先にルーティングできます。
- 順次ルーティングでは、データは1つのトランザクション内で処理されます。
- パラレル・ルーティングでは、情報のエンキューに1つのトランザクションが使用され、デキューには別のトランザクションが使用されます。

5.5.1.1 Oracle Mediatorのコンポーネントの特性

コンポジットにOracle Mediatorコンポーネントが含まれる場合、SOAインフラストラクチャはこのコンポーネントをOracle Mediatorエンジンにターゲット指定してデプロイメントします。Oracle Mediatorエンジン・システムで提供されるサービスは、いずれもシングルトンではないため、Oracle Mediatorエンジンは完全なアクティブ/アクティブ・モードで実行可能です。Oracle Mediatorのワーカー・スレッドによるメッセージ処理は、トランザクション処理され、WebLogic Serverのトランザクション制御サービスに依存します。WebLogic Serverコンテナの障害から確実にリカバリできるようにするために、WebLogic Serverのガイドラインで推奨されている適切なトランザクション・ストアを構成してください。また、Oracle MediatorのエンジンにはステートフルなWebモジュールやステートフルなセッションBeanがないため、Oracle Mediatorをアクティブ/アクティブ・モードで実行するときには、セッション・レプリケーションの構成は一切必要ありません。処理の状態や必要な処理は、Oracle Mediatorによってデータベース内に保持されます。したがって、Oracle Mediatorのデータベースが高可用性に対応している必要があります。そのためには、第5.13.4項「SOAのドメインを作成するためのSOAHOST1でのOracle Fusion Middleware構成ウィザードの実行」の説明に従って、SOAデータ・ソースに対するマルチ・データ・ソースを構成する必要があります。Oracle RACおよびMDSリポジトリでのマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

外部依存性

Oracle Mediatorは、次のコンポーネントに依存します。

Mediatorメッセージおよびメッセージの状態の永続性については、SOAデータベース
コンポジットのメタデータ・ストアについては、MDSリポジトリ

Oracle Mediatorが適切に起動し、実行されるためには、どちらのコンポーネントも使用可能である必要があります。

5.5.1.2 Oracle Mediatorの起動とシャットダウンのライフサイクル

SOAインフラストラクチャ・アプリケーションは、起動時にOracle Mediatorエンジンを初期化し、MDSリポジトリからコンポジットをロードします。コンポジットにOracle Mediatorコンポーネントが含まれる場合は、それらのコンポーネントをOracle Mediatorエンジンにターゲット指定します。Oracle Mediatorルーティング・ルールは、実行時に、インバウンド・バインディング・コンポーネントや別のサービス・エンジンによって呼び出すことができます。Oracle Mediatorエンジンの正常なシャットダウンは、SOAインフラストラクチャによって開始され、進行中のインスタンスにシグナルが送信され、ロードされていたコンポーネントがアンロードされます。

図5-23は、Oracle Mediatorの起動のライフサイクルを表しています。

図5-23 Oracle Mediatorの起動のライフサイクル

「図5-23 Oracle Mediatorの起動のライフサイクル」の説明

5.5.1.3 Oracle Mediatorのリクエスト・フロー

サーバー障害後のOracle Mediatorのリカバリ・セマンティックは、クライアントの相互作用のタイプとルーティング・ルールのタイプによって決まります。

Oracle Mediatorは、同期および非同期リクエスト・レスポンス相互作用をサポートします。次に、相互作用のタイプ別の動作を説明します。

同期相互作用: 同期相互作用では、サーバー障害時にエラーがクライアントに戻されます。クライアントは、エラー・メッセージを処理して、リクエストの再試行などの適切な措置を講じます。
非同期呼出し: 非同期呼出しには2タイプあります。1つはルーティング・ルールの実行を新たに開始するもので、もう1つは既存のルールの実行へのコールバックです。コールバックでは、エンジンが相関IDによるサブスクライブ・インスタンスの解決を試行します。コールバックの処理で障害が発生した場合、クライアントは、エラー・メッセージを受け取るとともに、エラーを適切に処理する必要があります。サーバーの障害が発生した場合は、コールバック処理の信頼性を保証するために、クライアント呼出しをトランザクション処理する必要があります。

Oracle Mediatorでは、メッセージを、順次またはパラレルにルーティングできます。サーバーの障害が発生した場合は、パラレルで処理されたメッセージにかぎり、手動リカバリが必要です。次に、ルーティング・ルールのタイプ別の動作を説明します。

順次ルーティング・ルール: 順次ルーティング・ルールでは、ルール全体が1つのトランザクション内で実行されます。サーバーの障害が発生した場合、Oracle Mediatorは、基盤となるトランザクション・マネージャにリカバリを依存します。
パラレル・ルーティング・ルール: パラレル・ルーティング・ルールでは、Oracle Mediatorは、2つの異なるトランザクションを実行するストア/フォワード・パラダイムを使用しており、1つはメッセージを永続的に保持するトランザクション、もう1つはルーティング・ルールを実行するトランザクションです。永続的に保持される前に障害が発生した場合、クライアントは、エラー・メッセージを受け取るとともに、順次ルーティング・ルールと同様の方法でエラーを処理する必要があります。永続的な保持が成功すると、クライアント・コールが戻され、以降の処理がクライアント・コールのコンテキストの外部で実行されます。サーバーの障害が発生した場合、Oracle Mediatorは、ContainerIdLeaseRefreshで指定された構成可能な時間間隔が経過した後のサーバーの再起動時に、リカバリを開始します。

5.5.1.4 Oracle Mediatorの構成アーティファクト

Oracle Fusion Middleware 11g リリース1(11.1.1.2)からは、Oracle Mediatorの構成パラメータはSOA MDSデータベースに格納されます。これらのパラメータは、Oracle Enterprise Manager Fusion Middleware Controlを使用して構成できます。

これらのパラメータを構成するには、Oracle Enterprise Manager Fusion Middleware Controlに移動して、ナビゲーション・ツリーで「SOA」→「soa-infra」→「(server_name)」を選択します。「SOA管理」を右クリックし、「メディエータ・プロパティ」を選択するか、MBeanブラウザを使用して、適切なプロパティに移動します。

5.5.2 Oracle Mediatorの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

Oracle Mediatorは、SOAインフラストラクチャと同じ高可用性アーキテクチャを活用する埋込みサービス・エンジンです。図5-5は、2つのWebLogic ServerでSOAインフラストラクチャの2ノード・クラスタが実行されている様子を示しています。Oracle Mediatorは、SOAインフラストラクチャのコンポジット・アプリケーションの一部としてデプロイされます。

クラスタ化された構成では、シングルトン・サービスはなく、すべての状態がSOAランタイム・データベースに格納されるため、Oracle Mediatorはアクティブ/アクティブ・モードで実行可能です。

注意:

単一ノード環境では、中間層とデータベースの間に長い待機時間がある場合(たとえば、中間層とデータベースが異なるサブネットにある場合)、Oracle Mediatorのパフォーマンスは低下します。

5.5.2.1 Oracle Mediatorの障害からの保護および予想される動作

パラレル・ルーティング・ルールの実行時に、Oracle Mediatorは、SOAランタイム・データベース内のメッセージのバッチに対する論理ロックを取得します。このロックには、Oracle Mediatorエンジンを一意に識別するコンテナIDへの参照が含まれています。コンテナIDは、起動時に割り当てられます。ユーザーは、DeferredMaxRowsRetrievedを使用してバッチ・サイズを構成できます。前述のように、バッチ・サイズが小さいほど、サーバーの障害が発生したときにリカバリが必要になるロックの行数が少なくなります。

計画外停止が発生した場合は、サーバーの再起動後に、ContainerIdLeaseRefresh間隔で指定された時間だけ待機する必要があります。これにより、サーバーは実行状態のままインスタンスを完了できます。

マルチノードのクラスタ環境で、非同期メッセージ交換パターンにOracle Mediatorが使用されている場合は、リクエストが完了する前にコールバックが返されてきても、Oracle Mediatorでコールバックが処理されない可能性があります。こうした現象は、Oracle Mediatorによりターゲット・サービスに対して開始されたリクエストが完了するのに長時間かかり、リクエストが完了する前にターゲット・サービスからのコールバックが返されるようなシナリオにおいて発生することがあります。

プロセス障害

Oracle Mediatorは、WebLogic Serverインフラストラクチャによってあらゆるプロセス障害から保護されます。次のプロセス障害に関する考慮事項は、Oracle Mediatorに適用されます。

管理対象サーバーで障害が発生すると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。サーバー全体の移行が構成されており、繰り返し再起動しても失敗する場合、WebLogic Serverインフラストラクチャは、クラスタ内の他のノードへの管理対象サーバーのサーバー移行を試行します(サーバー移行が構成されている場合)。他のノードでサーバーが再起動されると、Oracle HTTP Serverは、サーバーへの受信したリクエストのルーティングを再開します。移行されたサーバーは、SOAデータベースを読み取って、保留されていた処理を再開し、共有記憶域にあるトランザクション・ログを基にトランザクションを再開します。
リソースへのアクセスの失敗、コヒーレンス・インフラストラクチャが原因で発生するエラーまたはOracle Mediatorエンジンが配置されている管理対象サーバーのステータスとは関係なく発生する他の問題が原因で、Oracle Mediatorエンジンが実行されているSOAインフラストラクチャ・アプリケーションが停止する場合があります。そのため、SOAインフラストラクチャ・アプリケーションによって引き起こされるエラーを、管理対象サーバーのログで監視してください。サーバー・ログの場所については、第5.2.1.6項「Oracle SOAインフラストラクチャのログ・ファイルの場所」を参照してください。
サーバーで障害が発生した後のリカバリ時に、Oracle Mediatorは、部分的に処理されたメッセージの再配信を試行します。自動再試行が失敗すると、Oracle Mediatorは、メッセージを手動リカバリできるようにエラー・ホスピタルにエンキューします。

ノード障害

ノード障害が発生した場合、使用可能なサーバーによりデータベース・リース・システム内のタイムスタンプが検証された後、サーバーの移行がトリガーされます。クラッシュしたサーバーがコヒーレンス・クラスタ・マスターであった場合、使用可能なサーバーが新しいマスターとなり、Oracle Mediatorエンジンはバインディング・コンポーネントからのメッセージの処理に対して引き続き使用可能となります。リースのタイムスタンプが検証された後、他のノードのノード・マネージャは、障害が発生した管理対象サーバーで使用されているVIPの移行を試行し、VIPをローカルで再起動します。これは、同一ノードで実行される2つのインスタンスを持つOracle Mediatorエンジンに効果的な結果をもたらします。

クラスタワイドの構成変更

Oracle Mediatorエンジンが使用する標準Java EEアーティファクトは、SOAがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソース、永続ストアおよびJMSモジュールなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、Oracle Mediatorエンジンで使用されるライブラリを同期化する役割を持ちます。

第5.5.1項「Oracle Mediatorの単一インスタンスの特性」で説明したように、Oracle Mediatorエンジン固有の構成は、SOA MDSデータベースに格納されます。変更は(SOAサーバーごとに)一度適用されますが、同じSOAドメイン内のすべてのOracle Mediatorインスタンスに影響します。たとえば、WLS_SOA1およびWLS_SOA2が同じSOAクラスタの一部である場合、WLS_SOA1内のOracle Mediatorのハートビート間隔が20に変更されると、WLS_SOA2のハートビート間隔も20に設定されます。

5.5.2.1.1 失敗したMediatorインスタンスのリカバリ

サーバー障害からのリカバリ時に、特定の状況下で、ルーティング・ルールが進行中のメッセージが、手動リカバリのためエラー・ホスピタルに置かれる場合があります。このようなメッセージは、図5-24に示すように、Enterprise Managerを使用してリカバリできます。

図5-24 Oracle Enterprise Managerを使用したMediatorインスタンスのリカバリ

「図5-24 Oracle Enterprise Managerを使用したMediatorインスタンスのリカバリ」の説明

5.5.2.1.2 クラスタ内でのOracle Mediatorの再順序付け

Oracle Mediatorのリシーケンサを使用すると、関連する(ただし必ずしも順序が正しくない)メッセージのストリームを再配置して順序どおりに戻すことができます。ランダムな順序で到着した受信メッセージを順序付けしてから、ターゲット・サービスに正しい順序で送信します。

リシーケンサでは、グループと順序IDの2つの中心的な概念が使用されます。順序IDはメッセージの識別子の部分で、メッセージはこれに基づいて再編成されます。再順序付けのために着信したメッセージは、複数のグループに分割され、各グループ内のメッセージは順序IDに従って順序付けされます。順序付けは、選択された順序付け戦略(Oracle JDeveloper Composite Designerで標準、FIFOおよびベスト・エフォートの各戦略を選択可能)に基づいて行われます。

メッセージ処理は、Oracle Mediatorのキュー・システムのメッセージのバッチにグループIDを割り当てる処理に基づいています。リシーケンサ・デキュー・システムは、インスタンス識別子(ID)を使用してグループをロックし、グループ・メッセージを処理します。ハートビート・インフラストラクチャは、Oracle MediatorでインスタンスIDを作成して保持します。すべてのOracle Mediatorインスタンスに対して1つのインスタンスIDが作成されます。ハートビート・インフラストラクチャは、MEDIATOR_CONTAINERID_LEASE表にインスタンスIDと現在時刻を挿入します。ハートビート・インフラストラクチャには、1つのハートビート・スレッドがあります。このスレッドは、インスタンスIDに関連付けられている時刻を定期的に更新し、その存在を他のOracle Mediatorインスタンスに知らせます。Oracle Mediator構成パラメータContainerIdLeaseRefreshはこの目的で使用され、分単位で指定されます(デフォルトは1)。ハートビート・スレッドは、構成可能な期間内に更新されていないインスタンスIDの検索も行います。Oracle Mediator構成パラメータContainerIdLeaseTimeoutはこの目的で使用され、分単位で指定されます(デフォルトは5)。このスレッドは、それらのインスタンスIDによって保持されているロックを解放します。解放されたグループは、他のOracle Mediatorインスタンスのデキュー・システムが選択して処理することが可能になります。

MEDIATOR_GROUP_STATUS表に格納されているグループの取り得る状態は次のとおりです。

処理可能なグループ - 0
ロック中のグループ - 1
処理完了済グループ - 2
グループの処理中にエラー発生 - 3

ContainerIdLeaseTimeoutパラメータとContainerIdLeaseRefreshパラメータはどちらも、Oracle Enterprise Manager Fusion Middleware ControlのOracle Mediator構成画面で構成できます。これらのプロパティにより、リシーケンス用に構成されているOracle Mediatorインスタンスのクラスタの動作が決まります。各グループの処理は、1つのサーバーがそのリース期間が切れる(インスタンスIDが更新されない)まで実行します。グループを処理中の管理対象サーバーが停止した場合、クラスタ内の他のインスタンスが、リース期間が切れたとき(すなわち、グループに割り当てられている一意なIDがリースのタイムアウト期間中に更新されなかったとき)の順序に従って処理を進めます。

5.5.2.2 Oracle Mediatorの高可用性のトラブルシューティング

Oracle Mediatorの障害をデバッグするには、データベース表をチェックして、障害が発生しているコンテナを特定します。Oracle Mediatorに障害が発生した時点で処理中だったリクエストを特定するには、まだロック状態になっている行を特定し、ロック解除します。この行はBlobとして格納されているため、ペイロードを確認することもできます。

Oracle Mediatorインスタンス・マネージャのポーリング間隔は、すべてのノードで同一である必要があります。使用されているタイムスタンプは、データベースのタイムスタンプです。

データベース内のメッセージは、次のような段階を踏んで処理されます。

準備完了
ロック
完了
エラー

5.6 Oracle Human Workflowと高可用性の概要

この項では、高可用性のためのOracle Human Workflowの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。

5.6.1 Oracle Human Workflowの単一インスタンスの特性

Oracle Human Workflowは、SOAインフラストラクチャ内で実行され、インタラクティブなヒューマン・ドリブン・プロセスの実行を可能にするサービス・エンジンです。Human Workflowは、プロセス内外での承認、却下および再割当てのアクションなどの、ヒューマン・インタラクションをサポートします。Human Workflowサービスは、ビジネス・プロセスとのヒューマン・インタラクションを多様な側面から処理する多数のサービスで構成されます。

ヒューマン・タスク・メタデータはすべてメタデータ・サービス(MDS)リポジトリに格納されて、管理されます。Human Workflowエンジンは、SOAインフラストラクチャ内で実行するサービス・エンジンと、DefaultToDoTaskFlowおよびワークリスト・アプリケーションのための追加のJava EEアプリケーションで構成されます。Human Workflowは、ヒューマン・タスク関連の通知に内部JMS キューを利用します。

Oracle Human Workflowの管理の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

5.6.1.1 Oracle Human Workflowの起動とシャットダウンのライフサイクル

Human Workflowの起動は、Java EEアプリケーションのロードとサービス・エンジンの初期化という、2つのフェーズから成り立ちます。Java EEアプリケーションは、アプリケーション・サーバーの起動時にロードされます。サービス・エンジンの初期化とシャットダウンは、SOAインフラストラクチャによって制御されます。初期化後、Human Workflowコンポーネントを含むコンポジットは、SOAインフラストラクチャによってHuman Workflowサービス・エンジンにターゲット指定されます。

5.6.1.2 Oracle Human Workflowのリクエスト処理

Human Workflowは、他のSOAエンジン(Oracle BPEL PMなど)による呼出しで開始できます。メッセージは、SOAインフラストラクチャによってエンジンにルーティングされ、ワークフロー・エンジンによってランタイム・スキーマ内に永続的に保持されます。メッセージは、呼出しに関連するクライアント・トランザクションがコミットされた後、ブラウザベースのUIを通じ、管理者アクションに対して使用できるようになります。ユーザー・アクションによるメッセージやランタイム状態の更新は、それぞれ個別のトランザクションです。

ワークフローがトランザクションをコミットするとすぐにBPELに制御が戻され、それとほぼ同時にBPELがトランザクションをコミットします。このウィンドウ間でOracle RACインスタンスが停止すると、フェイルオーバー時にメッセージが再試行され、それがタスクの重複の原因になる場合があります。

5.6.1.3 Oracle Human Workflowの構成アーティファクト

Oracle Fusion Middleware 11g リリース1(11.1.1.2)からは、Oracle Human Workflowの構成パラメータはSOA MDSデータベースに格納されます。これらのパラメータは、Oracle Enterprise Manager Fusion Middleware Controlを使用して構成できます。

これらのパラメータを構成するには、Oracle Enterprise Manager Fusion Middleware Controlに移動して、ナビゲーション・ツリーで「SOA」→「soa-infra」→「(server_name)」を選択します。「SOA管理」を右クリックし、ワークフロー通知/タスク・サービス・プロパティを選択するか、MBeanブラウザを使用して、適切なプロパティに移動します。

5.6.1.3.1 ヒューマン・タスク・サービス・コンポーネントのタスク詳細アプリケーションのURIの管理

Oracle Human Workflowで使用するタスク詳細アプリケーションのURIは、追加したり削除したりできます。

ヒューマン・タスク・サービス・コンポーネントのタスク詳細アプリケーションのURIを管理する手順は、次のとおりです。

次のいずれかのオプションを使用して、このページにアクセスします。

SOAインフラストラクチャのメニュー	ナビゲータのSOAフォルダ
「ホーム」を選択します。「デプロイ済コンポジット」タブを選択します。「コンポジット」セクションで、特定のSOAコンポジット・アプリケーションを選択します。	「soa-infra」で、特定のSOAコンポジット・アプリケーションを選択します。

「コンポーネント・メトリック」表で、ヒューマン・タスク・サービス・コンポーネントを選択します。
「管理」をクリックします。

「管理」ページにタスク詳細アプリケーションのURIが表示されます。

図hwf_comp_admin.gifの説明
「追加」アイコンをクリックして、URIに次の詳細を指定します。
- アプリケーション名
- ホスト名
- HTTPポート
- HTTPSポート(オプション)
- URI
「適用」をクリックします。

5.6.2 Oracle Human Workflowの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

図5-5は、2つのWebLogic ServerでSOAインフラストラクチャの2ノード・クラスタが実行されている様子を示しています。Oracle Human Workflowは、SOAインフラストラクチャのコンポジット・アプリケーションの一部としてデプロイされます。

5.6.2.1 Oracle Human Workflowの障害からの保護および予想される動作

Oracle Human Workflowのエンジンでは、トランザクションEJBを使用して永続性を実現し、JMSキューを使用してユーザー通知を格納します。すべての状態がデータベースとJMSキューに格納され、メモリー内セッション状態がリカバリ用にレプリケートされることはありません。そのため、Oracle Human Workflowのサービス・エンジンと関連Java EEアプリケーションは、WebLogicクラスタ上のアクティブ/アクティブ・トポロジで実行されます。サーバーまたはハードウェアで障害が発生した場合に保留中のトランザクションやローカル・キューに格納されているJMSメッセージをリカバリするために、サーバー全体の移行を構成する必要があります。サーバーが再起動されるまで通知は送信されません。

5.6.2.2 拒否メッセージ表でのHuman Workflowタスクに必要な手動リカバリ

FabricInstanceManager.persistCompositeInstanceBean API(または他のInstanceManager API)には、組込みの再試行ロジックがありません。Oracle RACフェイルオーバーによって引き起こされた一時的な障害があると、WSの呼出しは直接拒否されます。これらの拒否メッセージの手動リカバリは、Oracle Enterprise Manager Fusion Middleware Controlを使用して行われます。

拒否メッセージを手動でリカバリするには、Oracle Enterprise Manager Fusion Middleware Controlで、「SOA」→「soa-infra(soa_server1)」→「<composite_name>」→「フォルトと拒否メッセージ」を選択し、メッセージを選択して、「オプションを指定してリカバリ」を選択します。これでワークフロー・リクエストが再試行されるようになります。

5.6.3 Oracle Human Workflowの高可用性のトラブルシューティング

ヒューマン・ワークフローは、ブラウザ・ベースのクライアントで標準Java EEアプリケーションと同じように動作します。メッセージがランタイム・スキーマ内に永続的に保持されると、そのメッセージをワークフローUIを使用して処理できます。トランザクションの途中でサーバーに障害が発生した場合は、リカバリまたはロールバックが正常に実行されるようサーバーをリカバリする必要があります。Oracle Human Workflowに関連するエラーのデバッグには、次のログが関係します。

oracle.soa.services.common
oracle.soa.services.notification
oracle.soa.services.workflow
oracle.soa.services.workflow.common
oracle.soa.services.workflow.evidence
oracle.soa.services.workflow.metadata
oracle.soa.services.workflow.persistency
oracle.soa.services.workflow.query
oracle.soa.services.workflow.runtimeconfig
oracle.soa.services.workflow.soa
oracle.soa.services.workflow.task
oracle.soa.services.workflow.task.dispatch
oracle.soa.services.workflow.task.routing

5.7 Oracle B2Bと高可用性の概要

この項では、高可用性のためのOracle B2Bの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。この項では、次の項目について説明します。

第5.7.1項「Oracle B2Bの単一インスタンスの特性」
第5.7.2項「Oracle B2Bの高可用性アーキテクチャとフェイルオーバーに関する考慮事項」

5.7.1 Oracle B2Bの単一インスタンスの特性

Oracle B2Bは、SOAコンポジット・アプリケーションと外部サービス、アプリケーションおよびテクノロジを接続します。Oracle B2Bは、業界が認めるB2B標準対応マルチプロトコル・ゲートウェイを提供します。Oracle B2Bは、Oracle SOA Suiteを、電子データ交換(EDI)、ebXML、HL7、RosettaNetなどのビジネス・プロトコル標準で拡張します。Oracle B2Bの機能の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

Oracle B2Bは、SOAインフラストラクチャ内のバインディング・コンポーネントです。B2Bメタデータは、取引パートナの詳細と、サポート・ドキュメントおよびデリバリ・チャネルで構成され、MDSリポジトリに格納されています。SOAコンポジットは、このメタデータへの参照を持ちます。

Oracle B2Bは、様々なチャネルからのメッセージを受け取ります。リスナー・スレッドは、SOAデータベースの表内のメッセージをログに記録し、対応するイベントをJMSキューに送ります。イベント・ハンドラは、JMSキューにあるリクエストを処理するために、イベントをリスニングします。

Oracle B2Bは、ビジネス・エンティティと通信するための、次のトランスポート・プロトコルをサポートしています。

HTTP(HTTPS)
Oracle Advanced Queue
電子メール(SMTP 1.0、IMAP 1.0、POP3)
ファイル
FTPおよびSFTP(SSH FTP)
TCP/IP
JMS

HTTPプロトコルの場合、Oracle B2Bは、システムのHTTPリスナーを使用します。FTPおよび電子メールの場合、Oracle B2Bは、外部FTPと、システム内で構成されている電子メール・サーバーを使用します。高可用性モードでも、1つのB2Bインスタンスだけが、FTP、ファイルおよび電子メールの各プロトコルの受信メッセージをポーリングします。

注意:

MLLP & TCP/IPプロトコルは、クラスタ化された環境ではサポートされません。

5.7.1.1 Oracle B2Bのコンポーネントの特性

Oracle B2Bは、SOAインフラストラクチャのJava EEアプリケーションとともに即時実行されます。Oracle B2Bのユーザー・インタフェースは、SOAインフラストラクチャと同じ管理対象サーバーにスタンドアロンのWARファイルとしてデプロイされるWebアプリケーションです。Oracle B2B UIアプリケーションは、ステートフルで、HTTPセッションに情報を格納します。

Oracle B2Bは、状態情報をJMSキューとSOAランタイム・データベースに格納します。サーバーの障害が発生した後のJMSメッセージおよびトランザクションの自動リカバリには、サーバー全体の移行が必要です。

Oracle B2Bは、JMSを集中的に使用します。Oracle B2Bは、Oracle B2BのJMSリソースを障害から保護するために、Oracle WebLogic Serverの移行機能を使用します。Oracle B2Bのエンジンは、EJBとサーブレットを使用しますが、そのどちらもステートレスです。すべての状態情報は、JMSキューとデータベース内に永続的に保持されます。

B2Bの高可用性は、ランタイム・データベースの高可用性に依存します。したがって、GridLinkデータ・ソースまたはマルチ・データ・ソースとして構成して、高可用性を確保することをお薦めします。第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」または第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

外部依存性

Oracle B2Bは、次のコンポーネントに依存します。

Oracle B2Bメッセージおよびメッセージの状態の永続性については、Oracle SOAデータベース
Oracle B2Bのメタデータ・ストアについては、MDSリポジトリ
対応するアダプタが使用されている場合は、FTPおよび電子メール・サーバー

Oracle B2Bが適切に起動し、実行されるためには、SOAデータベースとMDSリポジトリが使用可能である必要があります。

5.7.1.2 Oracle B2Bの起動とシャットダウンのライフサイクル

SOAインフラストラクチャ・アプリケーションは、起動時にOracle B2Bのエンジンを初期化します。Oracle B2Bメタデータのデプロイメントは、コンポジットがSOAインフラストラクチャにデプロイされる前に実行される必要があります。Oracle B2Bのエンドポイントは、チャネルとして定義され、エンジンの初期化時に起動されます。構成された各チャネルには、プロトコルに応じて次のような外部依存性があります。

FTPを使用する場合は、適切なFTPサーバーを起動する必要があります。
電子メールを使用する場合は、適切な電子メール・サーバーを起動する必要があります。
HTTP/HTTPSを使用する場合は、B2Bシステムをフロントエンド処理するHTTPサーバーを起動する必要があります。

5.7.1.3 Oracle B2Bのリクエスト・フロー

Oracle B2Bシステムでは、すべての処理が非同期で実行されます。リクエストが到着すると、対応するメッセージがSOAデータベースに挿入されます。保留中の処理のプレースホルダとしてのJMSキューに通知が挿入されます。イベント・ハンドラ・スレッドは、このキューにあるイベントをリスニングして、処理を順次実行します。

図5-25 Oracle B2Bのリクエスト・フロー

「図5-25 Oracle B2Bのリクエスト・フロー」の説明

5.7.1.4 Oracle B2Bの構成アーティファクト

Oracle B2Bのサーバーのメトリックは、Oracle Enterprise Manager Fusion Middleware Controlを使用して有効および無効にできます。これは、Oracle Enterprise Manager Fusion Middleware Controlにより直接公開される唯一のプロパティです。Oracle B2Bのサーバーの構成はSOAデータベースに保持され、その多くはOracle B2Bのユーザー・インタフェース・アプリケーションにより公開されます。Oracle B2B構成の詳細は、『Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド』を参照してください。

5.7.2 Oracle B2Bの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

図5-5は、2つのWebLogic ServerでSOAインフラストラクチャの2ノード・クラスタが実行されている様子を示しています。Oracle B2Bは、SOAインフラストラクチャのコンポジット・アプリケーションの一部としてデプロイされます。次の高可用性の特性は、Oracle B2Bの高可用性デプロイメントに固有のものです。

Oracle B2Bのユーザー・インタフェース・アプリケーションは、Oracle WebLogic Serverの各サーバー内で、SOAインフラストラクチャ・アプリケーションと同じクラスタの一部として実行されます。
Oracle B2Bのサーバーは、パートナ、ドキュメントおよびチャネルの定義を、Oracle RACデータベースを使用するSOAデータベースに保持します。

5.7.2.1 Oracle B2Bの障害からの保護および予想される動作

この項では、Oracle B2Bの高可用性クラスタ・デプロイメントによって、コンポーネントを障害から保護する仕組みと、コンポーネントの障害が発生したときに予想される動作について説明します。

Oracle B2BのUI障害

Oracle B2Bのユーザー・インタフェース・アプリケーションは、ナビゲーションの情報の一部をメモリーに保持します。Oracle B2Bのユーザー・インタフェースを実行する管理対象サーバーの1つで障害が発生すると、ユーザーのリクエストは、アプリケーションを実行しているアクティブな別のWebLogic Serverにリダイレクトされます。Oracle HTTP Serverからの処理中のリクエストは、Oracle HTTP Serverの構成のタイムアウト設定に応じてタイムアウトします。アプリケーションではセッション情報のシリアライズが有効化されていないため、フェイルオーバーには、障害が発生したインスタンスにアクセスしているユーザーの再ログインが必要となります。

Oracle B2Bのユーザー・インタフェースのメモリー内データはトランザクションではなく、フェイルオーバー時にはいくつかの手順の繰り返しが必要になる場合があります。

SOAインフラストラクチャ・プロセスの障害の一般情報は、第5.2.2.1項「Oracle SOAインフラストラクチャの障害からの保護および予想される動作」を参照してください。

ノード障害

ノード障害が発生したり、Oracle WebLogic Serverのローカルのノード・マネージャで、障害の発生した管理対象サーバーの再起動の最大試行回数に達したりした場合には、使用可能なサーバーがデータベース・リース・システム内のタイムスタンプを検証した後、サーバー全体の移行がトリガーされます。他のOracle B2Bエンジンでは、別のチャネルからの新しいメッセージの処理が引き続き可能です。同時に、他のOracle B2Bサーバーは、障害の発生したノードでデータベースに設定されているタイムスタンプのデフォルトのタイムアウト期間(デフォルトは2分)が経過した後、FTP、電子メールまたはファイルなど、シングルトン・チャネルの保留中の操作を再開します。Oracle B2Bのユーザー・インタフェース・アプリケーションでは、Oracle HTTP Serverの構成に応じて、Oracle HTTP Serverからの処理中のリクエストがタイムアウトします。

データベース障害

Oracle B2B・データベースの障害の詳細は、第5.2.2.1項「Oracle SOAインフラストラクチャの障害からの保護および予想される動作」を参照してください。

5.7.2.2 Oracle B2Bのクラスタワイドの構成変更

Oracle B2Bエンジンが使用する標準Java EEアーティファクトは、SOAインフラストラクチャがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソース、永続ストアおよびJMSモジュールなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、Oracle B2Bのエンジンで使用されるライブラリの同期化を制御します。

第5.7.1項「Oracle B2Bの単一インスタンスの特性」で説明したとおり、Oracle B2Bサーバー固有のすべての構成はデータベース内に保持され、構成変更は、WebLogic Serverドメインで実行されるすべてのSOAサーバーに適用されます。したがって、ペイロード・サイズやアウトバウンド・ディスパッチャ数などの構成プロパティはクラスタワイドで適用されるため、Oracle SOAクラスタ内のすべてのインスタンスで使用されることになります。

ファイル、FTPまたは電子メールのトランスポートを高可用性環境で設定するには、b2b.HAInstanceName unique_instance_nameを使用して、各インスタンスの一意の名前を指定します。値に#ServerName#を使用すると、Oracle B2Bは、HAInstanceNameとしてWebLogic Server名を取得します。

『Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド』のFusion Middleware Controlで設定するプロパティに関する項でも、高可用性環境におけるファイル、FTPまたは電子メールのトランスポートの設定について説明しています。

5.7.2.3 クラスタ内へのOracle B2Bのデプロイメント

B2Bでのメタデータのデプロイ、パージ、またはインポートにコマンドライン・ユーティリティを使用すると、B2Bシステム内での不整合やエラーが発生する場合があります。B2Bでのアグリーメントのデプロイ、メタデータのパージまたはインポートには、コマンドライン・ユーティリティを使用しないで、B2Bコンソールで使用可能なGUIのみを使用してください。

5.7.2.4 Oracle B2Bのアクティブ/アクティブ構成のトラブルシューティング

この項では、Oracle B2Bのアクティブ/アクティブ構成のトラブルシューティングのヒントと有効な解決法について説明します。

5.7.2.4.1 B2Bメタデータのパージ、インポートまたはデプロイメント

B2Bメタデータをクラスタにパージ、インポートまたはデプロイメントするときに、エラーのタイミングとロード・バランシングによって、操作を再試行した場合に発生する可能性の低い例外が発生する場合があります。

この場合に必要なクリーンアップ手順や追加手順はありません。[java] MDS-02202: メタデータ・オブジェクトのコンテンツのようなエラーがデプロイメントで表示されたり、postTransfer: MDS-00521: ドキュメント読取り時のエラー... のようなエラーがパージやインポートで表示された場合は、操作を再試行してください。

5.7.2.4.2 Oracle B2Bのドキュメント定義取得時のエラー

問題: Oracle B2Bからドキュメント定義XSDの取得を試行する際にエラーが発生します。B2Bはクラスタ内に配置され、ロード・バランサを通じてアクセスされます。B2Bコンソールには、次のようにレポートされます。

An error occured while loading the document definitions.
 java.lang.IllegalArgumentException: Cluster address must be set when clustering
 is enabled.

ソリューション: このエラーは、フロントエンドHTTPホスト、およびOracle B2Bが配置されているOracle WebLogicクラスタのポートを設定していないために起きます。このエラーを解決するには、次の手順を実行してSOAクラスタのフロントエンド・アドレスを設定します。

管理コンソールの「チェンジ・センター」セクションで、「ロックして編集」をクリックします。
左側のペインで、「ドメイン構造内の環境」ウィンドウを選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。
「WLS_SOA」クラスタを選択します。
「HTTP」を選択します。
次の値を設定します。
- フロントエンド・ホスト: soa.mycompany.com
- フロントエンドHTTPSポート: 443
- フロントエンドHTTPポート: 80
「保存」をクリックします。
変更をアクティブにするには、管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。
サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効化します。

5.8 Oracle Web Service Managerと高可用性の概要

この項では、高可用性のためのOracle Web Services Manager (WSM)の構成で検討する必要のある問題や考慮する必要のある事項を紹介します。

5.8.1 Oracle WSMの単一インスタンスの特性

Oracle Web Services Manager(Oracle WSM)は、組織全体でWebサービスを一貫して管理および保護するポリシー・フレームワークを提供します。これは、セキュリティ、WSRM、MTOMおよびアドレス指定ポリシーなどのWebサービス・ポリシーを構築、施行、実行および監視する機能を提供します。通常、SOAインフラストラクチャとともにデプロイされます。

Oracle WSMを構成するコンポーネントは、次のとおりです。

ポリシー・マネージャは、MDSリポジトリに対して、事前定義済ポリシーやカスタム・ポリシーをはじめとするセキュリティ・ポリシーおよび管理ポリシーの読取りと書込みを実行します。通常は、SOAインフラストラクチャの管理対象サーバーにデプロイされます。一方、ポリシー・マネージャは個別の管理対象サーバーにデプロイできます。

ポリシー・マネージャは、ステートレスJava EEアプリケーションです。ステートレス・セッションBeanによって、その機能が公開されます。ポリシー・マネージャは、データを一切キャッシュしません(アクセスの対象は、すべてMDSリポジトリとなります)。
エージェントは、ポリシーの施行、実行、およびランタイム統計の収集を行います。Oracle WSMエージェントは、Oracle Fusion Middlewareのすべての管理対象サーバー上で使用できます。これは、保護するアプリケーションと同じサーバー上で構成されます。

Oracle WSMエージェントは、jarファイルのセットで構成され、そのセットが、基盤となるWebサービス・スタックの一部となります。これには、セッションの状態はありません。エージェントは、メモリー内ポリシー・キャッシュを保持し、これがエージェントの起動時に移入されます。JTAまたはJMSは使用しません。

Oracle WSMエージェントは、次の2つの部分で構成されます。
- ポリシー・アクセス・ポイント(PAP)は、ポリシー・マネージャと通信します。エージェントは、T3(SSLが有効な場合はT3s)プロトコル上でのEJBの呼出しによってポリシー・マネージャと通信します。
- ポリシー・インターセプタは、Webサービスがデプロイされてアクティブ化されたとき、またはポリシーがEnterprise Managerを使用してWebサービスにアタッチされたときに生成されます。新たなWebサービスがOracle WSMを使用して保護された場合は、各新規Webサービスに対してインターセプタの追加インスタンスが生成されます。インターセプタは、ポリシーを施行します。
メタデータ・ストア・ポリシーは、MDSリポジトリに格納されます。通常は、Oracle Databaseがバックエンドで使用されます。高可用性を確保するため、MDSリポジトリのバックエンドとしてOracle RACデータベースを使用することをお薦めします。
Oracle WSMの構成には、Enterprise Managerが使用されます。Oracle WSMによって収集された様々なWebサービス・メトリックも表示されます。

Oracle WSMアーキテクチャの詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。

図5-26 Oracle WSMの単一インスタンス・アーキテクチャ

「図5-26 Oracle WSMの単一インスタンス・アーキテクチャ」の説明

5.8.1.1 Oracle WSMのコンポーネントの特性

Oracle WSMエージェントは、Webサービス・スタック内のOracle Fusion Middlewareのすべての管理対象サーバーで使用可能な.jarファイルのセットです。

ポリシー・マネージャは、wsm-pm.earファイルに格納されます。Oracle WSMで提供されるサービスは、いずれもシングルトンではないため、Oracle WSMエンジンは完全なアクティブ/アクティブ・モードで実行可能です。Oracle WSMサービスは、http://SOAHOSTx:port/wsm-pm/validatorで検証できます。このバリデータには、Oracle WSMポリシーが表示されます。

Oracle WSMエージェントとOracle Enterprise Managerは、EJBインタフェースを使用してポリシー・マネージャと対話します。Oracle WSMで使用されるEJBはステートレスであり、クラスタ化された環境にデプロイできます。そのため、クラスタ内で状態のレプリケーションを有効化するための要件はありません。

Oracle WSMエージェントとポリシー・マネージャを同じ場所に配置する必要はありません。ただし、エージェントでは、ポリシー・マネージャがドメインの最低1つのノードにデプロイされていると想定します。Oracle WSMエージェントには、ドメインにデプロイされているポリシー・マネージャを自動検出する機能があります。

Oracle WSMエージェントとポリシー・マネージャは、どちらもJTAまたはJMSメッセージ機能を使用しません。MDSベースのポリシー・ストアも、JTAをサポートしません。

外部依存性

Oracle WSM Policy Managerは、次のコンポーネントに依存します。

ポリシーの格納についてはMDSリポジトリ
Oracle WSMエージェントは、Oracle WSMポリシー・マネージャにのみ依存します。

Oracle WSMが適切に起動し、実行されるためには、どちらのコンポーネントも使用可能である必要があります。

5.8.1.2 Oracle WSMの起動とシャットダウンのライフサイクル

Oracle WSMの起動ライフサイクルには、Oracle WSMの次の主要コンポーネントが関係します。

Oracle WSM Policy Manager
Oracle WSMエージェント

ポリシー・マネージャは、ステートレス・アプリケーションであり、キャッシュは一切行いません。ポリシー・マネージャがデプロイされている管理対象サーバーの起動時に実行される、アプリケーション・レベルの特別な起動シーケンスはありません。ポリシー・マネージャは、MDSリポジトリと通信してポリシーを取得します。MDSリポジトリをOracle RACデータベースに格納すると、MDSの高可用性を実現できます。

エージェントが構成されている管理対象サーバーが起動すると、エージェントは、ポリシー・マネージャに接続して、最新リビジョンのポリシーを取得します。ポリシーが正常に取得されると、ポリシーの変更がダウンロードされてキャッシュされます。エージェントが起動して実行されると、構成可能な間隔に基づいて定期的にキャッシュのリフレッシュが試行されます。デフォルトの間隔は1分です。

Oracle WSMエージェントは、T3(sslが有効な場合はT3s)プロトコル上でのEJBの呼出しによってポリシー・マネージャと通信します。ポリシー・マネージャが別のノードにデプロイされており、一部のノードのSSLが有効で他のノードのSSLが有効でない場合、エージェントはSSL接続されているノードのみと通信します。

Oracle WSMエージェントの接続先ポリシー・マネージャが使用できなくなると、基盤となるインフラストラクチャは、クラスタ内の他の場所で実行されている別のポリシー・マネージャのインスタンスに自動的に接続します。これは、Oracle WebLogicのEJBクラスタリングによって実現されます。

高可用性シナリオでは、Oracle WSMアプリケーションのターゲットが複数のノードに設定される場合、ターゲット設定は、個々の管理対象サーバーではなく、クラスタに対して行われる必要があります。

管理対象サーバーにWebサービスがデプロイされており、これがOracle WSMによって保護されている場合、Oracle WSMエージェントは起動時にいずれのポリシー・マネージャとも通信できず、Webサービスの呼出しが失敗します。

5.8.1.3 Oracle WSMのリクエスト・フロー

保護されているWebサービスがクライアント・アプリケーションからアクセスされたときに、Oracle WSMエージェントはポリシー・キャッシュに問い合せて、アプリケーション・ポリシーを施行します。リクエストの認証、暗号化、復号化、認可またはログは、ポリシーに基づいて行われます。これらの操作のいずれについても、ポリシー・マネージャに接続しません。Oracle WSMによって保護された新しいWebサービスがデプロイされたり、既存のWebサービスに新しいポリシーがアタッチされたなどの構成変更がないかぎり、ポリシー・マネージャの実行時の可用性がOracle WSMエージェントの機能に影響することはありません。このような構成の変更があった場合、Oracle WSMエージェントは、ポリシー・マネージャに接続して、適切なポリシーを取得する必要があります。初期起動後に接続できない場合は、キャッシュされているポリシーに基づいて動作し続けます。

5.8.1.4 Oracle WSMの構成アーティファクト

Oracle WSMエージェントの構成は、policy-accessor-config.xmlに格納されています。このファイルは、DOMAIN_HOME/config/fmwconfigディレクトリにあります。この構成ファイルでは、次のことを指定できます。

ポリシー・マネージャのURL(構成されている場合)。
キャッシュ・リフレッシュ間隔。
時間誤差(クライアントとサーバーのシステム・クロックの誤差を許容します)。

これらのオプションは、Oracle Enterprise Manager Fusion Middleware Controlからでも使用でき、Oracle WSMエージェントのインストールごとに固有です。

MDSリポジトリの場所のデータ・ソースやアプリケーションのターゲット指定など、コンテナ・レベルの他の構成オプションは、Oracle WebLogic Serverのドメイン構成の一部として保持され、WebLogic Serverのコア・インフラストラクチャによって、Oracle WebLogic Serverのクラスタ上で同期化されます。

5.8.2 Oracle WSMの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

図5-5は、2つのWebLogic ServerでSOAインフラストラクチャの2ノード・クラスタが実行されている様子を示しています。Oracle WSMは、SOAインフラストラクチャのコンポジット・アプリケーションの一部としてデプロイされます。次の高可用性の特性は、Oracle WSMの高可用性デプロイメントに固有のものです。

Oracle WSMポリシー・マネージャとOracle WSMエージェントは、WLS_SOA_INFRAにデプロイされます。Oracle WSMエージェントにデプロイされるカスタムWebサービスの保護が必要な場合には、Oracle WSMエージェントをすべてのカスタムWLSクラスタで使用できます。
Oracle WSMポリシー・マネージャとOracle WSMエージェントは、WebLogic Serverクラスタの一部であるWebLogic Serverインフラストラクチャの管理対象サーバーで実行されます。WebLogic Serverクラスタは、SOAインフラストラクチャ(JDBC)で使用されるWebLogic Serverの共通アーティファクトの構成を同期化します。
Oracle WSMポリシー・マネージャEJBは、WebLogic Serverクラスタのクラスタリングと高可用性の機能を利用します。
Oracle WSMポリシー・マネージャのクラスタ内のインスタンスは、すべて同一のMDSリポジトリを指します。
Oracle WSMポリシーが格納されたMDSリポジトリが、データベースの障害から保護するためにOracle RACデータベース内に構成されます。

5.8.2.1 Oracle WSMの障害からの保護および予想される動作

Oracle WSMエージェントは、アプリケーションがデプロイされているサーバーと同じ管理対象サーバーにデプロイされるため、サーバーの再起動や移行によりアプリケーションが使用可能になると同時に、エージェントが使用可能になります。次の各項では、ポリシー・マネージャのフェイルオーバーについて説明します。

プロセス障害

Oracle WSMコンポーネントは、WebLogic Serverインフラストラクチャによってプロセス障害から保護されます。

管理対象サーバーで障害が発生すると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。サーバー全体の移行が構成されており、繰り返し再起動しても失敗する場合、WebLogic Serverインフラストラクチャは、クラスタ内の他のノードへの管理対象サーバーのサーバー移行を試行します。他のノードでサーバーが再起動されると、Oracle HTTP Serverは、サーバーへの受信したリクエストのルーティングを再開します。第5.8.1.2項「Oracle WSMの起動とシャットダウンのライフサイクル」で説明したように、Oracle WSMエージェントとポリシー・マネージャは、起動ライフサイクルを経て起動されます。
ポリシー・マネージャを実行する管理対象サーバーが再起動または移行される場合、フェイルオーバーはそのサーバーに接続されているエージェントに透過的に実行されます。ポリシー・マネージャは、基盤となるEJBクラスタリングと、WebLogic Serverのフェイルオーバー・インフラストラクチャを利用します。

ノード障害

ノードの障害が発生した場合、サーバー全体の移行が構成されていないと、Oracle WSMエージェントはポリシー・マネージャの他のインスタンスに透過的にフェイルオーバーします。

サーバー全体の移行が構成されていると、使用可能なサーバーによりデータベース・リース・システム内のタイムスタンプが検証された後、サーバーの移行がトリガーされます。リースのタイムスタンプが検証された後、現在も使用可能なノードのノード・マネージャが、障害が発生した管理対象サーバーで使用されているVIPの移行を試行し、VIPをローカルで再起動します。これは、同一ノードで実行される2つのインスタンスを持つOracle WSMポリシー・マネージャ・アプリケーションに効果的な結果をもたらします。フェイルオーバー・プロセスの詳細は、第3.9項「サーバー全体の移行」を参照してください。このような状況では、Oracle WSMエージェントは、同一ノード上で実行される2つのポリシー・マネージャ・インスタンスに対するロード・バランシングを実行します。

5.8.2.2 Oracle WSMのクラスタワイドの構成変更

ポリシー・マネージャが使用する標準Java EEアーティファクトは、SOAインフラストラクチャがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソースなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、別のOracle WSMコンポーネントで使用されるライブラリの同期化を制御します。

単一インスタンスの項で説明したように、Oracle WSMインスタンス固有の面に関して、WebLogic Serverドメイン・ディレクトリ(通常、1つのノードに1つのドメイン・ディレクトリ)ごとに、policy-accessor-config.xmlファイルで個別に構成されます。このファイルは、Oracle WebLogic Serverのpackユーティリティを使用するときに作成される.jarファイルに含まれるため、ユーザーがpack/unpackを実行してSOAインフラストラクチャに高可用性を設定するときに、他のノードに伝播されます。ただし、policy-accessor-config.xmlに対して現在加えている変更は、他のノードに自動的にレプリケートされません。つまり、ポリシー・マネージャのURLやキャッシュ・リフレッシュ間隔を更新したときなどに、各ノードを個別に修正する必要があります。このような修正は、高可用性トポロジにかかわるすべてのドメイン・ディレクトリで、手動で行う必要があります。ユーザーは、policy-accessor -config.xmlファイルを直接編集したり、Oracle Enterprise Manager Fusion Middleware Controlを使用して各管理対象サーバーの構成を変更したりできます。

Oracle WSMエージェントは、デプロイされているOracle WSMポリシー・マネージャを自動検出できます。この動作をオーバーライドして、特定のポリシー・マネージャ・インスタンスをポイントするには、policy-accessor-config.xmlファイルを編集します。

5.8.2.3 Oracle WSMについてのJavaオブジェクト・キャッシュの構成

Oracle WSMが稼働するすべてのサーバー間でJavaオブジェクト・キャッシュ(JOC)を構成します。このローカル・キャッシュは、Oracle WSMのパフォーマンスを向上させるために用意されています。

Oracle WSMを実行するすべてのサーバー間でのJavaオブジェクト・キャッシュの構成については、第F.1項「Javaオブジェクト・キャッシュの構成」を参照してください。

5.8.2.4 MDSリポジトリに対する分散通知の構成

高可用性環境では、MDSリポジトリに対して分散通知を構成することをお薦めします。詳細は、付録G「MDSに対する分散通知の構成」を参照してください。

5.9 Oracle User Messaging Serviceと高可用性の概要

この項では、高可用性のためのOracle User Messaging Serviceの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。

5.9.1 Oracle User Messaging Serviceの単一インスタンスの特性

Oracle User Messaging Service(Oracle UMS)は、ユーザーと、デプロイされているアプリケーションとの双方向通信を可能にします。電子メール、IM、SMSおよびText-to-Voiceメッセージなど、多様なチャネルに対応しています。Oracle UMSは、Oracle BPEL PMやOracle WebCenterポータルなどのOracle Fusion Middlewareコンポーネントに統合されます。通常は、SOAインフラストラクチャとともにデプロイされます。

Oracle UMSは、次のコンポーネントで構成されています。

UMSサーバーは、WebLogic Server上で実行されるJava EEアプリケーションです。UMSサーバーは、アプリケーションとユーザー間のメッセージ・フローをオーケストレートします。サーバーは、アウトバウンド・メッセージをクライアント・アプリケーションから適切なドライバにルーティングし、インバウンド・メッセージを適切なクライアント・アプリケーションにルーティングします。また、サーバーは、すでに送信されたメッセージのリポジトリを永続ストアに保持し、すでに送信されたメッセージに配信ステータス情報を関係付けます。
UMSドライバ: UMSをメッセージ・ゲートウェイに接続し、コンテンツをUMSでサポートされている様々なプロトコルに適応させます。ドライバは、指定のインストールで使用可能なメッセージング・チャネルに応じて、個別にデプロイまたはアンデプロイできます。

UMSドライバは、電子メール、XMPPおよびSMPPなど、外部プロトコルに対して送受信されたコンテンツを適応させます。UMSドライバは、Oracle WebLogic ServerにデプロイされるJava EEアプリケーションでもあります。
UMSクライアント・アプリケーション: メッセージの送受信のビジネス・ロジックを実装します。UMSクライアント・アプリケーションの例としては、Oracle BPEL PMワークフローの1手順としてメッセージを送信するOracle SOAアプリケーション、またはWebインタフェースからメッセージを送信できるOracle WebCenterポータル: Spacesアプリケーションがあります。

UMSクライアント・アプリケーションは、UMS固有の埋込みEJBモジュールを持つか、標準のWebサービス・クライアントとして対話します。

図5-27は、Oracle UMSの単一インスタンス・アーキテクチャのサービスと依存性を表しています。

図5-27 Oracle User Messaging Serviceの単一インスタンス・アーキテクチャ

「図5-27 Oracle User Messaging Serviceの単一インスタンス・アーキテクチャ」の説明

5.9.1.1 Oracle User Messaging Serviceのコンポーネントの特性

この項では、Oracle UMSのコンポーネントの特性を説明します。

UMSサーバーは、次のものから構成されます。

JMSキューからメッセージをデキューするメッセージドリブンBean(MDB)
メッセージング・ビジネス・ロジックを実装するステートレス・セッションBean
メッセージングWebサービスを実装するJAX-WSサーブレット
エンドユーザー・メッセージング・プリファレンスを管理するための簡易Oracle ADF Facesユーザー・インタフェースのコンポーネント

UMSドライバには、通常、次のものが含まれます。

外部プロトコル・ゲートウェイとのインタフェースを保つためのJCAリソース・アダプタ(EARに埋込み)
2つのMDB。1つはインバウンド用、もう1つはアウトバウンド用で、リソース・アダプタとJMSキューとのインタフェースを保ちます。
VoiceXMLのようなHTTPベース・プロトコルを実装する一部のUMSドライバは、サーブレット・モジュールも持っています。

EJBインタフェースを使用するUMSクライアント・アプリケーションは、クライアント・ビジネス・ロジックで使用されるAPIを提供するステートレス・セッションBean、およびインバウンド・メッセージを非同期で受信するためのMDBを持ちます。

UMSは、JMSに大きく依存します。JMSキューは、クライアントとサーバー間、およびサーバーとドライバ間のコンテンツのバッファにも使用されます。

一般的なメッセージング操作(アウトバウンド・メッセージの送信やインバウンド・メッセージの受信)では、クライアントとサーバー間、およびサーバーとドライバ間の、2つのJMSキューを使用します。

UMSメッセージングの状態は、データベースと永続JMSキューに格納されます。

外部依存性

UMSは、メッセージと構成の状態の保持を外部データベース・リポジトリに依存します。この状態は、クラスタ化されたインスタンス間で共有されます。UMSサーバーは、インストール時にプロビジョニングされたJava EE JDBCデータ・ソースを使用してデータベースにアクセスします。このデータ・ソースは、非XAデータ・ソースです。そのため、UMSは、基盤となるインフラストラクチャのJTA機能に依存しません。

UMSでは、メッセージング・アプリケーション間のメッセージの配信にJMSを使用します。デフォルトでは、ファイル・ベースの永続JMSストアを使用するように構成されるため、そのファイルが存在するストレージ・デバイスに依存します。

5.9.1.2 Oracle User Messaging Serviceの起動とシャットダウンのライフサイクル

Java EEアプリケーションと同様、すべてのUMSコンポーネントは、WebLogic Serverコンテナにより起動します。

UMSサーバーの起動

UMSサーバーは、起動時に、データベース・リポジトリへの接続を確立するTopLinkセッションを初期化します。その後、UMSサーバーは、Webサービス・エンドポイントでのリスニングを開始します。また、メッセージの送信や配信ステータスの取得などの機能の呼出しにEJBを使用できるようになります。

UMSドライバの起動

UMSドライバがクラスタにデプロイされると、ドライバは登録メッセージをローカルUMSサーバーに送信します。UMSサーバーは、登録情報をデータベースに記録し、クラスタ内のすべてのUMSサーバーで使用できるようにします。すると、UMSサーバーは、クラスタ内のすべてのUMSドライバにメッセージをルーティングできるようになります。こうした状況は、新しいドライバがデプロイされたり、構成の変更後に既存のドライバが再起動されたりしたときに起こります。

通常、UMSドライバは、サーバーの起動時に、ドライバが構成されている外部ゲートウェイへの接続を確立します。たとえば、SMPPやXMPPなどの永続的なソケット・レベルの接続です。また、SMTP接続やIMAP接続のように、各リクエストに対して確立され、切断される接続もあります。その後、ドライバは、UMSサーバーへのリモートEJBコールを実行して、ドライバ自体を登録します。

UMSクライアント・アプリケーションの起動

クライアントがデプロイされている管理対象サーバーが起動すると、通常、EJBクライアントは、リモートEJBコールを実行し、UMSサーバーでドライバ自体を登録します。Webサービス・クライアントには明確な登録メカニズムはありません。

5.9.1.3 Oracle User Messaging Serviceのリクエスト・フロー

UMSクライアントは、UMSサーバーへの連続した短期リクエストを作成します。Webサービス・クライアントは、SOAPまたはHTTPを使用してリクエストを作成します。EJBクライアントは、JMSを使用した対話および管理の初期化と構成を目的とした、サーバーへのリモートEJBコールを実行します。

初期起動と登録の後のUMSのリクエスト・フローは、次のように分類できます。

アウトバウンド・メッセージング: アウトバウンド・メッセージの場合、クライアント・アプリケーションは、ユーザーにメッセージを送信します。クライアント・アプリケーションは、UMSサーバーに対してWebサービス・リクエストを送るか、UMSサーバーの送信JMSキューにメッセージをエンキューします。UMSサーバーは、リクエストを受信し、メッセージの状態を記録して、適切なドライバを選択します。UMSサーバーは、別のアウトバウンドJMSキューにメッセージをエンキューします。対応するドライバは、アウトバウンド・キューをリスニングし、メッセージをデキューして、所定のプロトコルに適した形式に変換し、これを外部ゲートウェイ(SMTPサーバーまたはIMゲートウェイなど)に配信します。
インバウンド・メッセージング: インバウンド・メッセージの場合、エンド・ユーザーは、クライアント・アプリケーションにメッセージを返信したいと考えます。ユーザーは、IMクライアントや電話などのデバイスからメッセージを送信します。メッセージは、外部ゲートウェイからドライバに渡されます。ドライバは、メッセージをUMS形式に適応させて、JMSキューにエンキューします。サーバーは、JMSキューからメッセージをデキューし、メッセージの状態を記録して、アプリケーションの適切なインバウンドJMSキューにメッセージをエンキューします。この後、クライアント・アプリケーションは、メッセージをデキューし、必要に応じて処理を実行します。

5.9.1.4 Oracle User Messaging Serviceの構成アーティファクト

UMSサーバーとUMSドライバは、それぞれのXML構成ファイルを持ちます。このファイルは、構成Mbeanのアーティファクトであり、Oracle Fusion MiddlewareのJMXフレームワークを使用して実装されます。構成は、Oracle Enterprise Manager Fusion Middleware Controlを使用して変更できます。

図5-28 Oracle Enterprise Manager Fusion Middleware Controlを使用したOracle User Messaging Serviceの構成

「図5-28 Oracle Enterprise Manager Fusion Middleware Controlを使用したOracle User Messaging Serviceの構成」の説明

すべてのUMSコンポーネントでは、標準のJava EEデプロイメント・ディスクリプタとOracle WebLogic固有のディスクリプタを使用して、Java EEコンポーネントを構成します。これらのディスクリプタは、管理コンソールやWLSTなどの標準Oracle WebLogicツールを使用して構成できます。詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のUMS管理に関する項を参照してください。

Oracle SOA Suiteをクラスタ環境で使用している場合、あるノードの構成プロパティをOracle Enterprise Managerで変更したときには、その変更がすべてのノードに適用される必要があります。構成プロパティは、Oracle Enterprise Managerで、「SOAインフラストラクチャ」メニューの次のオプションを使用して設定します。

「管理」→「システムMBeanブラウザ」

「SOA管理」→任意のプロパティを選択

5.9.2 Oracle User Messaging Serviceの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

SOAインフラストラクチャの2ノード高可用性の特性の説明は、第5.2.2項「Oracle SOAインフラストラクチャの高可用性アーキテクチャとフェイルオーバーに関する考慮事項」を参照してください。図5-5は、2つのWebLogic ServerでSOAインフラストラクチャのクラスタが実行されている様子を示しています。Oracle User Messaging Serviceは、SOAインフラストラクチャのコンポジット・アプリケーションの一部としてデプロイされます。次の高可用性の特性は、Oracle User Messaging Serviceの高可用性デプロイメントに固有のものです。

すべてのUMSコンポーネントは、WebLogic Serverクラスタの一部であるOracle WebLogic Serviceインフラストラクチャの管理対象サーバーにデプロイされます。WebLogic Serverクラスタは、JDBCデータ・ソースなど、UMSで使用されるWebLogic Serverの共通アーティファクトの構成を同期化します。
Oracle UMSコンポーネントは、すべてステートレスです。
UMSのサーバーおよびクライアントのステートレスEJBは、WebLogic Serverクラスタのクラスタリングと高可用性の機能を利用します。
UMSサーバーは、永続記憶域に関して、共有データベース・リポジトリに依存します。
UMSは、クラスタ・ノード間のロード・バランシングと可用性に関して、JMS分散宛先に依存します。また、障害の発生時には、別のJMSサーバーにフェイルオーバーするために、JMSコネクション・ファクトリの機能に依存します。
ユーザー・メッセージング・プリファレンスのユーザー・インタフェースでは、セッション振分けは必要ありません。基本ロード・バランシングを使用することで、使用可能な状態に保たれます。セッションの状態はすべて、データベースに永続的に保持され、クラスタ化されたインスタンスにより共有されるため、セッション・ルーティング要件は特にありません。
UMSは、グローバル・トランザクションにはまったく関与しません。
UMSでは、GridLinkデータ・ソースまたはマルチ・データ・ソースを使用して、バックエンドOracle RACデータベースに接続します。

5.9.2.1 Oracle User Messaging Serviceの障害からの保護および予想される動作

通常、Oracle UMSは、SOAインフラストラクチャと同じ管理対象サーバーにデプロイされます。SOAインフラストラクチャは、Oracle WebLogic Serverのサーバー全体の移行を使用して、プロセスやノードの障害から保護されます。サーバー全体の移行では、JMS使用時のフェイルオーバー機能も提供されます。

Oracle UMSの障害からの保護および予想される動作の詳細は、第5.2.2.1項「Oracle SOAインフラストラクチャの障害からの保護および予想される動作」を参照してください。

プロセス障害

この項では、Oracle User Messaging Serviceの高可用性構成のプロセス障害に固有の考慮事項について説明します。

障害が発生した場合、ノード・マネージャはこのサーバーの再起動をローカルで試行します。
Oracle UMSコンポーネントのデプロイ先のWebLogic Server管理対象サーバーに対してサーバー全体の移行が構成されており、再起動の回数がしきい値を超えた場合、WebLogic Serverインフラストラクチャは、クラスタ内の別のノードへの管理対象サーバーの移行を試行します。前述のように、サーバーの移行が正常に完了すると、UMSサーバーとUMSドライバは、起動時に、起動サイクルを経てドライバを登録します。ドライバの登録は依存性のない操作であるため、使用可能な他のインスタンスにはまったく影響しません。サーバーの移行の詳細は、第3章「WebLogic Serverの高可用性」を参照してください。
管理対象サーバー内のUMS JMSサーバーは、再起動時に(同じノードまたは別のノードで)、メッセージの作成、およびJMSストアのメッセージの使用を開始します。
UMSサーバーとUMSドライバを実行する管理対象サーバーが再起動または移行される場合、フェイルオーバーは接続されているUMSクライアントに透過的に実行されます。フェイルオーバーが透過的に実行されるのは、UMSコンポーネントがステートレスであるためです。サーバーの再起動が完了すると、Webサーバーは、Webサービス・クライアントに対して、サーバーへのリクエストのルーティングを開始します。同様に、EJBクライアントは、サーバーが使用可能であることを認識して、サーバーへのリクエストのルーティングを開始します。これは、Oracle WebLogicのクラスタリング・インフラストラクチャによって実現されます。

ノード障害

Oracle UMSのノード障害の詳細は、第5.2.2.1項「Oracle SOAインフラストラクチャの障害からの保護および予想される動作」を参照してください。

データベース障害

Oracle UMSデータベース障害の詳細は、第5.2.2.1項「Oracle SOAインフラストラクチャの障害からの保護および予想される動作」を参照してください。

外部メッセージ・ゲートウェイ障害からの保護

UMSは、メッセージの配信を試行する前に、メッセージをあらかじめデータベースに永続的に保持しておきます。外部メッセージ・ゲートウェイが使用できなくなると、対応するUMSドライバは、ゲートウェイへの再接続と、データベースに永続的に保持されている未配信のメッセージの配信を定期的に試行します。また、メッセージが配信されない場合、管理者は、Oracle Fusion MiddlewareのEnterprise Managerで、UMSサーバーの「メッセージ・ステータス」ページを使用して手動でメッセージを再送信できます。

5.9.2.2 Oracle User Messaging Serviceのクラスタワイドの構成変更

UMSは、ファイルベースの標準Java EEデプロイメント・ディスクリプタと、標準JMXフレームワークを使用するJMX構成Mbeanで構成されます。変更は、標準のWebLogic Server Mbeanサーバー・メカニズムによって伝播されます。クラスタワイドの構成機能はありません。そのため、クラスタのすべてのメンバーに対して構成の変更を繰り返す必要があります。

UMSは、標準のJava EEアーティファクトを使用します。このアーティファクトは、Oracle UMSがインストールされているOracle WebLogicのドメインの一部として構成されます。WebLogic Serverクラスタは、WebLogic Serveドメイン全体にわたる、データ・ソースなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、別のOracle UMSコンポーネントで使用さるライブラリの同期化を制御します。

5.10 Oracle JCAアダプタと高可用性の概要

この項では、高可用性のためのOracle JCAアダプタの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。

5.10.1 Oracle JCAアダプタの単一インスタンスの特性

Oracle JCA Adaptersは、Service Infrastructureが異なるプロトコルを使用してエンドポイントと通信できるようにするJCAバインディング・コンポーネントです。Oracle JCAアダプタは、JCAリソース(RAR)としてデプロイされるものであり、SOAインフラストラクチャの一部ではありません。

Oracle JCAアダプタのランタイム・コンポーネントは、特定のバックエンド・アプリケーションのJ2CA 1.5リソース・アダプタです。Oracle JCAアダプタは、Oracle WebLogic ServerのJ2CAコンテナにデプロイされます。Oracle Fusion Middlewareは、JCAバインディング・コンポーネントを介してこれらのJ2CA 1.5アダプタと統合され、このJCAバインディング・コンポーネントによって、Webサービス・メッセージがJ2CA相互作用との間で変換されます。そのため、アダプタは、WebLogic Serverの基盤となるプラットフォームのスケーラビリティと高可用性を完全に利用できます。

図5-29は、Oracle JCAアダプタの単一インスタンス・アーキテクチャのサービスと依存性を表しています。

図5-29 Oracle JCAアダプタの単一インスタンス・アーキテクチャ

「図5-29 Oracle JCAアダプタの単一インスタンス・アーキテクチャ」の説明

5.10.1.1 Oracle JCAアダプタのコンポーネントのライフサイクル

アダプタのライフサイクルは、SOAインフラストラクチャによって制御されます。Oracle JCAアダプタの初期化では、3つの高レベルな手順を実行します。

デプロイメント: Oracle JCAアダプタは、J2CA 1.5リソース・アダプタ(RARファイル)として、インストール時にOracle Fusion Middlewareと同じOracle WebLogic Serverコンテナ内にデプロイされます。アダプタの物理的デプロイメントには、RARファイルの使用と、基盤となるWebLogic Serverまたは中間層プラットフォームへのコネクタとしてのアダプタの登録が必要になります。RARファイルにはra.xmlファイルが含まれ、このファイルには、WebLogic Serverとリソース・アダプタとの間の規定に関する宣言情報が記述されています。さらに、RARファイルには、weblogic-ra.xmlファイルが含まれています。これは、リソース・アダプタに関するデプロイメント固有の情報が記述されたデプロイメント・ディスクリプタ・ファイルです。
ロード: ロードとは、メモリー内リソースの作成と構成済エンドポイントへの接続の確立のプロセスを表します。Oracle JCAアダプタは、J2CA 1.5リソース・アダプタとして物理的にデプロイされますが、論理的デプロイメントでは、weblogic-ra.xmlファイルを編集して、J2CA 1.5リソース・アダプタのコネクション・ファクトリ・エントリを作成する必要があります。このファイルは、リソース・アダプタ用の、WebLogic Server固有のデプロイメント・ディスクリプタです。これには、リソース・アダプタのデプロイメント・ディスクリプタで指定されているバックエンド・アプリケーション接続情報、使用されるJava Naming and Directory Interface (JNDI)名、接続プーリング・パラメータ、リソース・プリンシパル・マッピング・メカニズム、構成などの、リソース・アダプタをWebLogic Serverにデプロイするための構成が含まれています。
アクティブ化: アクティブ化とは、コンポジット内のJCAバインディング・コンポーネント(サービスおよび参照)の開始を表します。リスナーは、コンポジット内のアダプタ構成で参照されるエンドポイントに対して開始されます。

Oracle JCAアダプタの実行時のプロパティ変更

Oracle JCAアダプタは、基盤となるバックエンド操作固有のプロパティをヘッダー・プロパティとして公開して、ビジネス・プロセス内でのこれらの要素の操作を可能にします。基盤となるプロパティは、次のとおりです。

interactionspecプロパティまたはactivationspecプロパティ: リサイクルする(再アクティブ化する)アダプタ・エンドポイントが必要です。
エンドポイント・プロパティ: これらのプロパティの変更はアダプタに通知され、エンドポイントを再起動する必要はありません。

5.10.1.2 Oracle JCAアダプタの信頼性とトランザクションの動作

Oracle JCAアダプタは、基盤となるアプリケーション・サーバーのトランザクション・マネージャを利用するJCA 1.5 XA規定に基づいて、グローバル・トランザクションをサポートします。XAトランザクションをサポートするアダプタとして、Oracle Applications、データベース、アドバンスト・キューイング、JMSおよびMQSeries向けOracleアダプタがあります。非トランザクション・アダプタとしては、Oracle File AdapterおよびOracle FTP Adapterがあります。

インバウンド・トランザクション

同期プロセスでは、アダプタによって開始されるグローバル・トランザクションは、メッセージの配信やコンポジットの実行にまでわたります。

非同期サービスのエントリ・ポイントでは、トランザクション・アダプタはインバウンド・メッセージをコンポジットに送信する前に、グローバルJTAトランザクションを開始します。制御がアダプタに戻ると、アダプタは、JTAトランザクションをコミットし、次の一連のアクションを自動作業ユニットとして実行します。

表やキューなどのインバウンド・アダプタ・エンドポイントからのメッセージの削除をコミットします。
コンポジット・インスタンスの実行をコミットします。

このプロセスのいずれかが失敗すると、XAで保証されているとおり、これら2つのアクションがロールバックされます。

アウトバウンド・トランザクション

トランザクション・アダプタでは、アウトバウンドJCA相互作用(呼出しアクティビティ)は、コンポジット・インスタンスのグローバルJTAトランザクションの範囲に含まれます。つまり、Oracle JCAアダプタの起動をはじめとするすべてのコンポジット・アクティビティは、グローバル・トランザクションの一部であり、すべてのアクティビティがコミットされ、またエラー発生時にはロールバックされます。したがって、インバウンド・アダプタとアウトバウンド・アダプタの両方がトランザクション・アダプタであり、XAグローバル・トランザクションをサポートする接続ファクトリが構成されている場合は、メッセージが必ず1回配信されることが保証されます。

非トランザクション

Oracle File Adapterは、インバウンド・ディレクトリからファイルを選択し、ファイルを処理して、処理済ファイルを出力ディレクトリに送信します。ただし、この処理中にOracle RACバックエンドまたはSOA管理対象サーバーでフェイルオーバーが発生した場合は、Oracle File Adapterの非トランザクション特性によりファイルは2回処理されます。その結果、出力ディレクトリにファイルが重複して存在する場合があります。

5.10.1.3 Oracle JCAアダプタ: 拒否メッセージの処理

SOAインフラストラクチャ・メッシュにポストされる前にエラーになったメッセージは、拒否メッセージとして参照されます。たとえば、Oracle File Adapterにより、CSV形式のデータを持つファイルが選択され、NXSDを使用したXML形式への変換が試みられたとします。このとき、トランザクションでなんらかのエラーが発生すると、メッセージが拒否され、ターゲット・コンポジットにポストされません。

拒否メッセージは、すべてペイロードとともにデータベースに格納されます。拒否メッセージの格納先は、次の2つです。

アダプタ拒否表: 破損メッセージに関連するバインディング・エラーがある場合、メッセージはアダプタ拒否表に格納されます。

拒否メッセージ表をホストするデータベースがオフラインになっている場合、拒否メッセージはバックアップとして一時的にローカル・ファイル・システムに格納され、オンラインに戻って検出されたときに、最終的に再度データベースにロードされます。
コンポジット・インスタンス障害表: この表は、インスタンス・トラッキングの一部であり、各コンポーネントが障害を検出したときに移入されます。

SOAインフラストラクチャ・レイヤーによってエラーがスローされた場合のアダプタ・フレームワークの動作は、エラーが再試行可能として指定されているかどうかにより異なります。エラーが再試行可能でない場合、メッセージは拒否メッセージとして処理され、拒否メッセージ表に永続的に保持されます。

拒否ハンドラの構成

拒否ハンドラは、フォルト・ポリシーを使用して、次の手順で定義および構成されます。

拒否メッセージのフォルト・ポリシーをfault-policies.xmlファイルに定義します。このファイルは、composite.xmlとともにOracle JDeveloperプロジェクト・ディレクトリに格納されています。
fault-bindings.xmlファイルで、フォルト・ポリシーをコンポジットのサービス・エンドポイントに関連付けます。
fault-policies.xmlファイルとfault-bindings.xmlファイルをOracle SOAコンポジット・プロジェクト・ディレクトリにコピーします。
Oracle SOAコンポジット・プロジェクトをデプロイします。

再試行の頻度と間隔は、どちらも構成可能です。サービス・エンジンの起動は、再試行可能としてマークできます。クラスタ化された環境でロールバックが実行された場合、その情報を別のインスタンスで取得できます。別のノードがメッセージを取得すると、一意のIDが作成されます。再試行の回数は、コンポジットのbinding.jca要素で構成されます。詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。

システム定義の拒否メッセージ・ハンドラ

次のシステム定義のエラー・ハンドラをフォルト・ポリシーで構成できます。

Webサービス・ハンドラ: 事前定義のWSDLインタフェースは、ターゲット・サービスにより実装される必要があります。
カスタムJavaハンドラ: 事前定義のJavaインタフェースは、ターゲット・クラスにより実装される必要があります。
JMSキュー: 拒否メッセージは、適切なコンテキストとペイロードとともに、JMSメッセージとしてキューにエンキューされます。
ファイル: 拒否メッセージは、適切なコンテキストとペイロードとともにファイル・システムに格納されます。

ペイロードの永続性

拒否メッセージの再発行には、ペイロードの永続性が必要です。ペイロードは、データベースに格納され、Oracle Enterprise Manager Fusion Middleware Controlで表示されます。エラー・ハンドラは、エラーの自動処理時に起動され、起動中にペイロードも受け取ります。データベース内でのエラーのペイロードの永続性は、デフォルトで有効になっています。

5.10.2 Oracle JCAアダプタの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

この項では、Oracle SOAクラスタ上で実行されるOracle JCAアダプタの構成の高可用性に関する考慮事項について説明します。

5.10.2.1 Oracle JCAアダプタの高可用性に関するエラーの処理

この項では、Oracle JCAの高可用性に関するエラーの処理について説明します。

接続エラー

Oracle Applications向けOracle JCAアダプタおよびOracle Adapterは、次の相互作用に関する接続エラーを処理します。

アウトバウンド相互作用: Oracle Applications向けOracle JCAアダプタおよびOracle Adapterでは、一時接続エラーに関するoracle.tip.adapter.api.exception.PCRetriableResourceException例外が発生します。これらのエラーは、リカバリ可能な接続エラーです。たとえば、データベース・リスナーが起動しない場合に接続エラーとなります。再接続の最大試行回数をfault-policy.xmlファイルで定義できます。再接続の試行に関するパラメータは、このファイルで指定できます。設定された再試行の回数に達すると、fabricInvocationException例外がスローされます。

フォルト処理と再試行のプロパティは、バインディング・レベルの構成の一部として定義されます。バインディング・レベルの再試行が最大回数に達すると、fault-policy.xmlで指定されているポリシーに基づいてフォルトが処理されます。バインディング・プロパティの詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。
インバウンド相互作用: Oracle Applications向けOracle JCAアダプタおよびOracle Adapterと、レガシー・アダプタは、イベント受信のためのバックエンド・アプリケーションへの接続に対するポーリング・モデルをサポートします。リカバリ不能な接続障害が発生した場合、アダプタは旧接続をリサイクルし、SOAインフラストラクチャにアラートまたは通知を送ります。インバウンド相互作用の接続エラーはログに記録され、管理コンソールで表示できます。

5.10.2.2 Oracle File AdapterとOracle FTP Adapterの高可用性

Oracle File AdapterおよびOracle FTP Adapterは、アクティブ/アクティブ・トポロジを使用した高可用性構成が可能です。クラスタ・ベースの高可用性構成は、インバウンドとアウトバウンドの両方の操作でサポートされています。Oracle File AdapterおよびOracle FTP Adapterでは、XAに対応していないため、最低一回のメッセージの配信のみが保証されます。そのため、サーバー障害からのリカバリ後は、メッセージが重複する可能性があります。

高可用性のための前提条件

Oracle File AdapterとOracle FTP Adapterの高可用性のための前提条件は、次のとおりです。

クラスタ化された構成では、管理対象サーバー上のインバウンド・アダプタが共有ドライブの同一物理ディレクトリを指す必要があります。
接続ファクトリでは、制御ディレクトリに同一の共有フォルダを指定し、それらの名前が一致している必要があります。たとえば、あるコネクション・ファクトリのデプロイメント・ディスクリプタで、controlDirの値が/shared/control_dirとなっている場合は、他のデプロイメント・ディスクリプタの値も同じである必要があります。

Oracle File AdapterおよびOracle FTP Adapterでは、必ず1つのノードのみが分散トポロジ内の特定ファイルを処理するようにする必要があります。データベース表をコーディネータとして使用して、Oracle File AdapterおよびOracle FTP Adapterのインバウンド操作に対する高可用性を確保できます。データベース表をコーディネータとして構成する方法の詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。

Oracle File AdapterおよびOracle FTP Adapterでは、複数の参照が同一ディレクトリに書き込む場合に、相互に上書きしないようにする必要があります。アウトバウンド操作に対するOracle File AdapterおよびOracle FTP Adapterの高可用性を確保するために、次のロック機能を使用できます。

データベースmutex
ユーザー定義mutex

データベースmutexの構成の詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。

Oracle File AdapterとOracle FTP Adapterの高可用性の構成

クラスタ・ベースの高可用性構成は、インバウンドとアウトバウンドの両方の操作でサポートされています。ただし、次の点を考慮してください。

インバウンド操作: Oracle File AdapterおよびOracle FTP Adapterでは、必ず1つのノードのみが分散トポロジ内の特定ファイルを処理するようにする必要があります。
アウトバウンド操作: Oracle File AdapterおよびOracle FTP Adapterでは、複数の参照が同一ディレクトリに書き込む場合に、相互に上書きしないようにする必要があります。

クラスタ化されたトポロジでのこれらの動作を保証するため、データベース・ベースのmutexがコーディネータとして使用されます。

データベースmutexの構成

次の手順を実行して、管理コンソールから、eis/HAFileAdapterに対応するconnection-instance用のOracle File AdapterおよびOracle FTP Adapterのデプロイメント・ディスクリプタを変更し、データベース表をコーディネータとして構成します。

管理コンソールで、「デプロイメントの概要」の「FileAdapter」をクリックします。
「アウトバウンド接続プール」タブをクリックし、「javax.resource.cci.ConnectionFactory」を開いて、構成済接続ファクトリを表示します。
「eis/HAFileAdapter」をクリックします。
接続ファクトリ・プロパティを更新します。

接続ファクトリを使用するためのアダプタ構成を、次の例のように更新します。

<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>

注意:

接続ファクトリの位置属性は、eis/HAFileAdapterに設定されています。

Oracle File AdapterおよびOracle FTP Adapterの接続ファクトリの新しいパラメータは、次のとおりです。

controlDir: このパラメータには、制御ファイルを格納するディレクトリ構造を設定します。クラスタ内で複数のWebLogic Serverインスタンスが実行されている場合は、共有場所に設定します。
inboundDataSource: このパラメータには、jdbc/SOADataSourceを設定します。これは、高可用性に対応するスキーマがあらかじめ作成されているデータ・ソースです。事前に作成されたスキーマは、MW_HOME/ASreleaseSOA/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sqlにあります。それ以外の場所にスキーマを作成するには、このスクリプトを使用します。別のスキーマを選択する場合は、そのスキーマに応じてinboundDataSourceプロパティを設定します。
outboundDataSource: このパラメータには、jdbc/SOADataSourceを設定します。これは、高可用性に対応するスキーマがあらかじめ作成されているデータ・ソースです。スキーマの場所については、「inboundDataSource」を参照してください。
outboundLockTypeForWrite: Oracle Databaseを使用している場合は、このパラメータにoracleを設定します。Oracle File AdapterおよびOracle FTP Adapterは、デフォルトでメモリー内mutexを使用してアウトバウンド書込み操作をロックします。書込み操作を同期化するには、次の値の1つを選択します。
- メモリー: Oracle File AdapterおよびOracle FTP Adapterは、メモリー内mutexを使用してファイル・システムへのアクセスを同期化します。
- oracle: アダプタは、Oracle Databaseシーケンスを使用します。
- db: アダプタは、事前に作成されたデータベース表(FILEADAPTER_MUTEX)をロック・メカニズムとして使用します。このオプションは、Oracle Databaseスキーマ以外のスキーマを使用しているときにかぎり使用します。
- ユーザー定義: アダプタはユーザー定義のmutexを使用します。ユーザー定義のmutexを構成するには、mutexインタフェースoracle.tip.adapter.file.Mutexを実装し、oracle.tip.adapter.file.mutexという名前の新しいバインディング・プロパテと、アウトバウンド参照用mutexに対して完全修飾されたクラス名の値を構成します。

注意:

大きなペイロードの場合は、次の行を追加して、SOA DataSourceのトランザクション・タイムアウトを増やします。

<xa-set-transaction-timeout>true</xa-set-transaction-timeout>

<xa-transaction-timeout>1000</xa-transaction-timeout>

データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトを増やします。

5.10.2.3 Oracle Databaseアダプタの高可用性

Oracle Databaseアダプタは、アクティブ/アクティブ設定での高可用性をサポートします。アクティブ/アクティブ設定では、インバウンド・データベース・アダプタに対して分散ポーリング技術を使用して、同一データが重複して取得されないようにできます。分散ポーリングのベスト・プラクティスの詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』の「データベースのOracle JCAアダプタ」を参照してください。他のアダプタと同様、Oracle Databaseアダプタをアクティブ/パッシブ設定内でのシングルトン動作に対して構成することもできます。これにより、アクティブ/パッシブ設定で動作するパフォーマンスの高いマルチスレッドのインバウンドOracle Databaseアダプタ・インスタンスは、ファンアウト・パターンに従ってクラスタ全体で複数のコンポジット・インスタンスを起動できます。Oracle Databaseアダプタは、データベース障害時や再起動時にも、高可用性機能をサポートします。DBアダプタは、メッセージを損失することなく、再度メッセージを取得します。

フォルト・ポリシーを使用したインバウンド拒否メッセージの処理の詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。

データベースの障害発生時の再起動

Oracle Databaseアダプタは、データベースが停止した場合にも、メッセージを損失することなく、再度メッセージを取得できます。データを損失しないようにするには、データ・ソースがXA対応であり、Oracle RAC(マルチ・データ・ソース)用に構成されている必要があります。データ・ソースの高可用性構成の詳細は、付録B「推奨されるマルチ・データ・ソース」を参照してください。

5.10.2.4 Oracle JMSアダプタの高可用性

Oracle JMSアダプタは、WLS JMS、MQ SeriesおよびOracle AQをはじめとする複数のプロバイダをサポートします。プロバイダごとに高可用性の側面は異なる可能性があり、基盤となるメッセージング・インフラストラクチャ機能に依存します。たとえば、Oracle AQではXAおよびOracle RAC用に適切に構成されたデータ・ソースが必要です。高可用性のためのGridLinkデータ・ソースの構成の詳細は、第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」を参照し、マルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

Oracle JMSアダプタを使用する場合、整合性と信頼性を確保することとトランザクション制御は密接に関連しています。Oracle JMSアダプタは、基盤となるアプリケーション・サーバーのトランザクション・マネージャを利用するJCA 1.5 XA規定に基づいて、グローバル・トランザクションをサポートします。JMSアダプタのコンテキストでは、送信または受信されたメッセージを1つの単位として扱うことで、アプリケーションは、1つのトランザクションで発行および消費のメッセージのグループを調整できます。アプリケーションがトランザクションをコミットすると、そのトランザクション内で受信したすべてのメッセージが、JMSプロバイダにより削除されます。そのトランザクション内で送信したメッセージは、1つの単位としてすべてのJMSコンシューマに配信されます。アプリケーションがトランザクションをロールバックすると、そのトランザクション内で受信したメッセージはメッセージ・システムに戻され、送信したメッセージは破棄されます。

WLS JMSプロバイダを使用する場合、アダプタはXA対応接続ファクトリ(デフォルトのweblogic.jms.XAConnectionFactory)を使用して、XAトランザクションをサポートします。このプロバイダの場合、高可用性の動作は、アダプタによって使用されるキューとトピックの構成およびWebLogic Serverによって提供されるJMSインフラストラクチャに結び付けられています。プロバイダとしてOracle WLS JMSを使用する場合、主に次の2つの側面がJMSアダプタの動作に影響を及ぼします。

メッセージ再配信
WebLogic Server分散宛先の使用

次の2つの項では、これらのトピックについて説明します。JMSアダプタの高可用性の構成の詳細は、Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイドのOracle JMSアダプタの高可用性の有効化に関する説明を参照してください。

5.10.2.4.1 メッセージ再配信

メッセージ再配信は、高可用性構成で重要な役割を果たします。WLS JMSでは、一時的な外部条件によりアプリケーションが適切にメッセージを処理できない場合、メッセージの再配信を遅らせることができます。これにより、アプリケーションが現在処理できない有害なメッセージの受信を一時的に抑制できます。再配信遅延時間は、メッセージをロールバックまたはリカバリする際、そのメッセージの再配信を試行するまでメッセージを保留しておく時間です。JMSがすぐにメッセージを再配信する場合、エラー条件が解決されていない可能性があり、アプリケーションは依然としてそのメッセージを処理できない可能性があります。しかし、アプリケーションに対して再配信の遅延が構成されている場合、メッセージがロールバックまたは再配信される際、再配信遅延時間が経過するまでそのメッセージは保留され、その時間が経過すると、そのメッセージは再配信可能になります。セッションにより消費された後にロールバックまたはリカバリされるすべてのメッセージは、ロールバックまたはリカバリの際にそのセッションの再配信遅延時間を受信します。1つのユーザー・トランザクションの一部として複数のセッションにより消費されるメッセージは、個々のメッセージを消費したセッションの関数として異なる再配信遅延時間を受信します。意図的に、または障害の結果として、クライアントによって確認もコミットもされずに残っているメッセージには、再配信遅延時間は割り当てられません。

JMSコンテキストのセッションは、セッション作成時に接続ファクトリから再配信遅延時間を継承します。接続ファクトリのRedeliveryDelay属性の構成には、管理コンソール(「構成」→「デフォルト配信」画面)を使用します。WebLogic JMSにはデフォルトの接続ファクトリが2つ定義されていますが、それらは次のJNDI名を使用して検索できます。

weblogic.jms.ConnectionFactory
weblogic.jms.XAConnectionFactory

WLS JMSプロバイダ用に構成されたJMSアダプタでは、デフォルトでweblogic.jms.XAConnectionFactoryが使用されるので、XAConnectionFactoryと同じ再配信設定が使用されます。異なるアダプタで使用する接続ファクトリの構成の詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』の「Oracle JMSアダプタのユースケース」を参照してください。

5.10.2.4.2 WebLogic Server分散宛先の使用

以前のリリースのOracle JMSアダプタでは、一部のタイプのOracle WebLogic共通分散宛先を使用する場合、メッセージが必ず1回配信されることを保証できませんでした。Oracle Fusion Middleware 11gR1では、JMSアダプタにより消費されるWLS JMSレイヤーで様々な拡張が行われ、共通分散宛先のサポートが向上しています。主な拡張として共有ClientID、パーティション分散トピック、共有サブスクリプションがあります。これらの拡張は、スケーラビリティ、高可用性、および様々なシナリオにおける一貫したメッセージ配信を容易にします。

共有ClientID: 恒久サブスクライバは、同じClientIDを使用して分散宛先から消費できます。JMS標準では、恒久サブスクリプションから消費するトピック・アプリケーションはClientIDを指定する必要があること、および任意の時点で動作中の複数の接続により同じClientIDが使用されないようにする必要があることが要求されます。この機能は、この制限をオーバーライドします。
パーティション分散トピック: パーティション分散トピックは、共通分散キューと共通分散トピックの動作を融合した機能です。これにより、メッセージを分散キューと同じように分散トピック・メンバー間でロード・バランシングでき、さらに1つの分散トピック・メンバーに複数のメッセージの受信者(サブスクライバ)を存在させることができます。パーティション分散トピックに対してメッセージを1つパブリッシュすると、そのメッセージは、以前の実装のようにすべてのメンバーによって受信されるのではなく、いずれか1つのメンバーによってのみ受信されます。
共有サブスクリプション: 複数のサブスクライバが、必要に応じて、接続のSubscriptionSharingPolicyをSHARABLEに設定することによって、恒久または非恒久の同じサブスクリプションを共有できます。この機能をパーティション・トピックおよび無制限の接続Client-IDポリシーとともに使用すると、同じ分散サブスクリプションを共有するすべてのサブスクライバのうち、1つのサブスクライバのみがトピックに送信された特定の1つのメッセージを受信することが保証されます。同じ分散サブスクリプションを共有するすべてのサブスクライバは、一体となって、そのトピックにパブリッシュされる各メッセージを処理します。

また、11gのWLS JMSインフラストラクチャでは、特定の分散宛先のメンバーの実行時の可用性を通知できる通知ヘルパーが提供されます。分散キューを使用する場合、これらのJMS機能には、JMSアダプタの観点から見て、次の影響があります。

インバウンド - 分散キュー

注意:

Oracle BAMのエンタープライズ・メッセージ・ソース(EMS)は、プロデューサのフィード先である分散キューをUDDにロード・バランシングするように構成することはできません。UDDの動作では、各コンシューマが1つの物理宛先に固定されるので、EMS側でメッセージが失われる可能性があります。かわりに、標準宛先であるクラスタワイドのJNDI名でEMSを構成し、プロデューサのフィード先を(クラスタワイドのJNDI名を使用するのではなく、その特定のサーバー・ホストを使用することにより)1つの物理JMSキューに固定します。

アウトバウンド - 分散キュー

分散キュー宛のメッセージを作成する場合、JMSアダプタの動作に変化はありません。メッセージは特定メンバーではなく分散宛先を対象とするMessageProducerを作成することによって作成されるので、「使用可能」/「使用不可」/「障害」の通知は、アウトバウンド・アダプタ参照の動作には影響を及ぼしません。

分散トピックを使用する場合、これらのJMS機能には、次の影響があります。

インバウンド - 分散トピック

JMSアダプタは、エンドポイントのアクティブ化の際、自動的にWLS JMSに通知リスナーを登録します。「使用不可」通知を受信した場合、対応するポーラー・スレッドが停止し、必要なクリーンアップが実行されます。同様に、「使用可能」通知を受信した場合、ポーラー・スレッドが開始され、アダプタは新しいメンバーから消費を開始します。恒久サブスクリプションは、非分散トピック・シナリオの場合と同様に保持されます。アダプタは、エンドポイントの非アクティブ化の際、通知リスナーを登録解除します。分散トピックに到着するメッセージは、使用する様々な設定および使用中の分散宛先のタイプに応じて、次の説明のように処理されます。

アプリケーションごとにメッセージを1つ処理: 各メッセージは、必ず1回処理されます(重複して処理されることはありません)。パーティション分散トピックを使用すること、および無制限ClientIDと共有サブスクリプション・ポリシー(これらはデフォルト設定)を使用するようにJMSアダプタを構成することをお薦めします。このシナリオでは、クライアントIDとサブスクリプション名はすべて同一であり、各アダプタ・インスタンスはすべてのメンバーに対してサブスクリプションを作成します。名前は一意であり、サーバーの再起動の前後で変化しません。アダプタの接続インスタンス(ローカル・クラスタのweblogic-ra.xml)に、固有のClientIDを構成する必要があります。
```
<property>
<name>FactoryProperties</name>
      <value>ClientID=SOAClient1;</value>
</property>
```
レプリケートされた分散トピックを使用する場合も、アプリケーションごとにメッセージを1つ処理するように強制できます。そのために、無制限ClientIDと共有サブスクリプション・ポリシー(デフォルト設定)を使用するようにJMSアダプタを構成する必要があります。また、アクティブ化仕様を定義する際に、メッセージ・セレクタ(NOT JMS_WL_DDForwarded)を指定する必要があります。このタイプの構成は非常に効率が悪く、お薦めしません。なぜなら、この構成ではメッセージがすべてのコンシューマに配布されますが、コンシューマ側で拒否が発生するからです。
クラスタ内のアダプタ・エンドポイント・インスタンスごとにメッセージを1つ処理: このシナリオでは、ClientIDまたはサブスクリプション名のどちらかが、アダプタ・インスタンスごとに一意です。また、名前の一意な部分は、サーバーの再起動の前後で変化しません。このタイプの構成は、レプリケート・トピックまたはパーティション・トピックの両方を使用することにより実現可能です。

パーティション分散トピックの場合、無制限のClientIDと共有サブスクリプション・ポリシーを使用するようにJMSアダプタを構成(すなわちSubscriptionSharingPolicyプロパティをSHARABLEに設定)します。これはデフォルト設定です。また、サブスクリプション名が一意であることを保証するために、TopicMessageDistributionAllプロパティをtrueに設定します(デフォルト値はfalse)。このプロパティは、weblogic-ra.xmlで接続インスタンスのFactoryPropertiesプロパティを設定することによって定義できます。使用例(weblogic-ra.xmlの接続インスタンスのスニペット)を次に示します。
```
<property>
<name>FactoryProperties</name>
      <value>ClientID=SOACLient2; TopicMessageDistributionAll=true</value>
</property>
```
レプリケート分散トピックの場合、無制限のClientIDと共有サブスクリプション・ポリシーを使用するようにJMSアダプタを構成(すなわちSubscriptionSharingPolicyプロパティをSHARABLEに設定)します。これはデフォルト設定です。パーティション分散トピックの場合と同じように、サブスクリプション名が一意であることを保証するために、アダプタのTopicMessageDistributionAllプロパティをtrueに設定する必要があります(デフォルト値はfalse)。このプロパティは、weblogic-ra.xmlで接続インスタンスのFactoryPropertiesプロパティを設定することによって定義できます。使用例(ローカル・クラスタのweblogic-ra.xmlの接続インスタンスのスニペット)を上に示します。

レプリケート分散トピックでアダプタ・エンドポイントごとにメッセージを1つ処理することを保証するには、次の.jcaファイルの例に示すように、アクティブ化仕様を定義する際にメッセージ・セレクタNOT JMS_WL_DDForwardedを使用する必要があります。
```
<activation-spec className="oracle.tip.adapter.jms.inbound.JmsConsumeActivationSpec">
<property name="DestinationName" value="jms/DemoInTopic"/>
<property name="UseMessageListener" value="false"/>
<property name="DurableSubscriber" value="dsub1"/>
<property name="MessageSelector" value="NOT JMS_WL_DDForwarded"/>
<property name="PayloadType" value="TextMessage"/>
</activation-spec>
```
ただし、この構成は非常に効率が悪く、メッセージがすべてのコンシューマに配布されるものの、コンシューマ側で拒否が発生するため、お薦めしません。パフォーマンスを向上するには、パーティション分散トピックを使用します。

アウトバウンド - 分散トピック

分散トピック宛のメッセージを作成する場合、アダプタの動作に変化はありません。「使用可能」/「使用不可」/「障害」の通知は、アウトバウンド・アダプタ参照の処理には影響しません。メッセージは特定メンバーではなく分散宛先を対象とするMessageProducerを作成することによって作成されます。

注意:

Oracle BAMでは、恒久分散トピックはサポートされていませんが、非恒久(一時)分散トピックはサポートされています。

5.10.2.5 Oracle JCAアダプタのログ・ファイルの場所

Oracle JCAアダプタのログは、次のようにして表示できます。

Oracleアプリケーション向けOracle JCAアダプタおよびOracle Adapter: アウトバウンドとインバウンドの両方の相互作用で、ログ・ファイルはsoa-diagnostic.logファイルにリダイレクトされます。server-soa管理対象サーバーにデプロイされるOracle SOA Suiteのログ・ファイルは、次の場所に格納されます。

MW_HOME/user_projects/domains/domain_name/servers/server-soa/logs/soa-diagnostic.log

パッケージ・アプリケーション・アダプタ: これらのアダプタは、J2CA 1.5標準に準拠していないため、LogManagerインタフェースを実装しません。そのため、OPMN管理コンポーネントでは、ログ出力は次の場所にリダイレクトされます。

ORACLE_INSTANCE\diagnostics\logs\component_type\component_name

アウトバウンド相互作用では、ログは同じ場所に送られます。これに対して、インバウンド相互作用では、ログはsoa-diagnostic.logにリダイレクトされます。

レガシー・アダプタ: レガシー・アダプタは、J2CAリソース・アダプタとOracle Connectで構成され、Oracle Connectはメインフレーム・アプリケーションおよびデータ・ストアと通信するためのネイティブ・アダプタで構成されます。Oracle Connectのログは、Oracle Studioを使用して表示できます。Oracle Studioは、メインフレーム・アダプタのデザインタイム・ツールであり、Oracle Connectの管理ツールです。Oracle Connectは、デーモン・ログ、ワークスペース・ログ、サーバー・プロセス・ログなど、様々なタイプのログを生成します。

5.11 Oracle Business Activity Monitoringと高可用性の概要

この項では、高可用性のためのOracle BAMの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。

5.11.1 Oracle Business Activity Monitoringの単一インスタンスの特性

Oracle BAMは、企業のビジネス・サービスおよびビジネス・プロセスを監視するツールを提供します。これにより、市場の指標を実際のビジネス・プロセスと相関させることや、ビジネス・プロセスをすばやく変更したり、ビジネス環境の変化に応じて修正を加えたりすることが可能になります。Oracle Business Activity Monitoring(Oracle BAM)は、リアルタイムのデータ・フローを表示し、特定の状況においてアラートを送信するルールを定義するダッシュボードの作成に必要なツールやランタイム・サービスを提供します。

図5-30は、Oracle BAMインスタンスの特徴である主要サービスと依存性を表しています。

図5-30 Oracle Business Activity Monitoringの単一インスタンス・アーキテクチャ

「図5-30 Oracle Business Activity Monitoringの単一インスタンス・アーキテクチャ」の説明

5.11.1.1 Oracle Business Activity Monitoringのコンポーネントの特性

Oracle BAMは、次のコンポーネントで構成されます。

Oracle BAM Server: 様々なデータ・ソースからの受信データを処理するランタイム・コンポーネントのセットです。Oracle BAMコンポーネントは、ユーザーにアラートを送信し、それらのアラートに対して構成されている必要なアクションをトリガーするための条件の評価にも使用されます。Oracle BAM Serverの主要コンポーネントは、次のとおりです。
- アクティブ・データ・キャッシュは、リアルタイム・ソリューションで大容量データを処理することを目的として、設計および最適化されています。データへのアクセスおよびデータの配信を迅速化するために、データのリアルタイム・ビューを保持しています。アクティブ・データ・キャッシュへのデータ・フィードは、データ・ウェアハウスの情報からトランザクション・フィードおよび他企業のソースまでの、ビジネス・データ・ソースの組合せです。Oracle BAMに統合されている様々なデータ・ストリーム・テクノロジにより、データが変更されたときに、この情報が連続したストリームでアクティブ・データ・キャッシュに送られます。
  
  アクティブ・データ・キャッシュは、データ・オブジェクト、ビュー・セットおよびアクティブ・ビュー・セットをホストおよび実行します。データ・オブジェクトへのトランザクション(挿入、更新および削除)を受け取ると、これらのデータ・オブジェクトが、参照によってリンクされている他のデータ・オブジェクトに通知します。また、これらのデータ・オブジェクトを監視しているアクティブ・ビュー・セットに変更が通知され、アクティブ・データが作成されます。
- イベント・エンジン: イベント・エンジンは、複雑なデータ条件を監視して、指定のルールを実装します。ルールには、イベントに関連付けられている一連の条件とアクションを含めることができます。イベント・エンジンは、アクティブ・データ・キャッシュ内の情報の特定条件を継続的に監視し、関連付けられているルールに定義されている関連アクションを実行します。
  
  イベント・エンジンは、日付、時刻またはデータ変更に基づいてイベントを追跡します。イベント・エンジンの設計では、サテライトの概念が採用されています。サテライトの概念では、4つの異なる体系(サテライト)があり、それによってイベント句を登録でき、その内部でイベント句を追跡できます。
- レポート・キャッシュは、アクティブ・データ・キャッシュのビュー・セット・スナップショットをメモリー内に保持しておかなくても済むようにするためのものです。レポート・キャッシュは、Oracle BAM Webアプリケーションのコンポーネント・セット内のレポート・サーバーのアクティブ・データ・キャッシュにあるビュー・セットとアクティブ・ビュー・セットを開きます。次に、スナップショット(チャンク単位)とアクティブ・データを、レポート・サーバーに送信する前にキャッシュします。これにより、スナップショットへのランダム・アクセスと、インターネット接続の切断からのリカバリが可能になります。また、レポート・キャッシュは、ステートレスなレポート・サーバーを実現し、アクティブ・データ・キャッシュを使用してビュー・セットの共有をサポートします。
リアルタイム・データ・ストリーミング・クライアント: Oracle BAMシステム・クライアントでは、様々なタイプのプロトコルとAPIを使用してOracle BAM Serverにデータを送ることができます。Oracle BAM Serverへのデータの送信で使用可能なメカニズムは、次のとおりです。
- Oracle BAMアダプタは、JCA準拠のアダプタで、Java EEアプリケーションがOracle BAM Serverにデータを送信する際に使用できます。
- エンタープライズ・メッセージ・ソースは、アプリケーションが、メッセージをOracle BAMデータ・オブジェクトに直接マッピングすることにより、Oracle BAM Serverに直接Java Message Service(JMS)接続できるようにするために使用します。Oracle BAM Serverは、JMSベースのメッセージ・キューやトピックから、データを直接読み取ることができます。このオプションにより、保証されたメッセージングが可能になります。
  
  エンタープライズ・メッセージ・ソースを使用するOracle BAMの高可用性環境では、エンタープライズ・メッセージ・ソースのプロパティ「BAMサーバーの起動時に起動」を「はい」に設定します。
  
  フェイルオーバー時にメッセージを損失しないように、エンタープライズ・メッセージ・ソースでは「永続サブスクライバ名」を設定する必要があります。
- Oracle Data Integratorは、Oracle BAMで正確なデータ変換を実行するために使用されるETLツールです。Oracle BAM ServerはODIテクノロジ(DB2、SQL ServerなどもODIテクノロジです)として実装されており、Oracle BAMにはODIナレッジ・モジュールが搭載されています。ODIでは、このモジュールにより、Oracle BAM Server上ですべての操作を実行して、チェンジ・データ・キャプチャをはじめとする様々な方法でのデータの読取りおよび書込みを容易化します。
- WebサービスAPIは、リモート・クライアントから直接Oracle BAMデータ・オブジェクトと対話します。
Oracle BAM Webアプリケーション: Oracle BAMデータを表示するためのWebユーザー・インタフェース(Java EE Webアプリケーション)です。Oracle BAM Webアプリケーションでは、データ・モデルの構築や、ダッシュボードおよびアラートの作成も可能です。Oracle BAM Webアプリケーションは、レポートを作成したり、BAMユーザー・インタフェースへのアクセス権があるユーザーを管理したりするための、ブラウザ・ベースのインタフェースです。レポート・サーバーは、Webアプリケーションの一部として、アクティブ・データ・キャッシュから取得したデータ・セットにレポート定義を適用して、ブラウザに表示します。
ICommandは、アクティブ・データ・キャッシュ内のデータを管理するためのコマンドライン・インタフェースです。これは、アクティブ・データ・キャッシュのアイテムをエクスポート、インポート、名前変更、クリアおよび削除するためのコマンド・セットを提供します。

BAMアプリケーションは、他のOracle SOA Suiteコンポーネントから独立して実行されます。Oracle BAM Webアプリケーションは、BAM Serverとともにデプロイされます。Oracle BAM Serverは、サービスを実装してデータベースに情報を永続的に保持するために、EJBとDAOを使用します。EJBは、すべてステートレスです。ただし、Oracle BAM Serverはシングルトンであり、送られてきたデータを保持して、それをWebアプリケーション・レポートにプッシュするために、アクティブなOracle BAM Serverが1つのみ使用されます。Oracle BAM Serverを障害から保護するために、WebLogic Serverの移行機能が使用されます。Oracle BAM Serverは、JMSを集中的に使用します。ただし、Oracle BAM JMSキューはすべて内部的なものであり、高可用性構成で構成する必要はありません。フェイルオーバーが発生した場合、新しいアクティブOracle BAMインスタンスでキューが再作成されます。

Oracle BAM Webアプリケーション・モジュールは、使用可能なOracle BAM Serverに接続して、完全なアクティブ/アクティブ・モードで実行可能です。リモート・コンシューマに情報を提供するEJBにアクセスするための情報は、RMIプロトコルによって取得されます。レポートのセッションIDや、システムにアクセスするユーザーを管理するReports Serverを除き、Oracle BAM Webアプリケーションはステートレスです。そのためには、Oracle BAM Webアプリケーションが実行されるWebLogic管理対象サーバーに対してセッション・レプリケーションを有効にする必要があります。

Oracle BAMでのEJBおよびスレッドにより実行される処理は、非トランザクションであるため、WebLogic Serverの特別なトランザクション・ログ構成は必要ありません。同時に、Oracle BAMはデータベースを集中的に使用するため、データベースの障害に備えたOracle BAMのデータベース・アクセスが重要となります。そのため、第5.15項「Oracle BAMの高可用性の構成」の説明に従って、Oracle BAMデータ・ソースにGridLinkデータ・ソースまたはマルチ・データ・ソースを構成する必要があります。

外部依存性

Oracle BAMエンジン・システムは、Oracle BAMデータおよびレポート・メタデータに関して、Oracle BAMデータベース(Oracle BAMスキーマを含む)にのみ依存します。Oracle BAMシステムが適切に起動し、実行されるためには、データベースが使用可能である必要があります。

5.11.1.2 Oracle Business Activity Monitoringの起動とシャットダウンのライフサイクル

図5-31に示すように、WebLogic Serverが起動するときに、Oracle BAM Serverアプリケーションが初期化されます。アクティブ・データ・キャッシュは、起動時にすべてのデータをリポジトリからロードします。レポート・キャッシュは、使用可能なシステムに必要なデータで初期化されます。イベント・エンジンは、データの分析と通知の準備を開始します。Oracle BAM Webアプリケーションは、起動時にOracle BAM Serverのアドレスで構成されます。Oracle BAM Webアプリケーションは、起動時にOracle BAM Serverのアクティブ・データ・キャッシュに接続し、Reports Serverを通じて対応するビューセットを取得します。初期化が終了すると、クライアントからのデータ受信、イベントの呼出し、およびレポートの動的更新が可能になります。

図5-31 Oracle Business Activity Monitoringの起動とシャットダウンのライフサイクル

「図5-31 Oracle Business Activity Monitoringの起動とシャットダウンのライフサイクル」の説明

5.11.1.3 Oracle Business Activity Monitoringのプロセスの起動とシャットダウン

Oracle BAM Serverは、SOAインフラストラクチャの他のアプリケーションから独立して動作する1つのアプリケーション(oracle-bam)です。Oracle BAMがインストールされている管理対象サーバーで実行されます。また、Oracle BAMがデプロイされているOracle WebLogic管理対象サーバーによってデフォルトで起動されます。管理コンソールを使用して、Oracle BAM Serverのステータスを確認したり、Oracle BAM Serverを起動および停止します。アプリケーションの制御に、WebLogic Server WLSTのコマンドラインも使用できます。

図5-32 WebLogic Serverを使用したOracle Business Activity Monitoringの起動とシャットダウン

「図5-32 WebLogic Serverを使用したOracle Business Activity Monitoringの起動とシャットダウン」の説明

Oracle Enterprise Manager Fusion Middleware Controlを使用すると、BAM Serverの多数の操作と構成を行えるだけでなく、ステータスを監視することもできます。Oracle BAMエンジンの監視と制御の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

図5-33 Fusion Middleware Controlを使用したOracle Business Activity Monitoringの起動とシャットダウン

「図5-33 Fusion Middleware Controlを使用したOracle Business Activity Monitoringの起動とシャットダウン」の説明

BAM Webアプリケーションは、デフォルトでBAM Serverと同じ管理対象サーバーにコロケートされて実行されます。たとえば、BAM ServerとBAM Webアプリケーションは、管理コンソールで同一デプロイメントの一部となります。デフォルトでは、これらをBAM Serverと切り離して停止したり管理したりできません。ただし、それぞれを個別のコンポーネントにターゲット指定してWebLogic Serverアプリケーションを処理することは可能です。Oracle WebLogic Administration Consoleを使用すると、Oracle BAMを起動および停止できます。

Oracle Enterprise Manager Fusion Middleware Controlのコンソールを使用すると、BAM Webアプリケーションの多数の操作と構成を行えます。

図5-34 Oracle Enterprise Manager Fusion Middleware Control

「図5-34 Oracle Enterprise Manager Fusion Middleware Control」の説明

注意:

Enterprise ManagerはOracle BAM ServerとOracle BAM Webアプリケーションを個別に起動および停止しますが、停止操作は、実際には両方のコンポーネントに影響します。つまり、Oracle BAM ServerがEnterprise Managerにより停止されると、対応するOracle BAM Webアプリケーションも停止し、その逆も同様です。このことは、起動操作にも当てはまります。

5.11.1.4 Oracle Business Activity Monitoringの構成アーティファクト

Oracle Enterprise Manager Fusion Middleware Controlは、Oracle BAM Serverに関するいくつかの構成オプションを公開します。

図5-35 Oracle Business Activity Monitoringの構成

「図5-35 Oracle Business Activity Monitoringの構成」の説明

Oracle Enterprise Managerにより公開されるプロパティは、BAMServerConfig.xmlとBAMCommonConfig.xmlという2つの異なるファイルの情報が混ざったものです。これらのファイルは、DOMAIN_HOME/servers/BAM_Server_Name/tmp/_WL_user/oracle-bam_11.1.1/yhryfp/APP-INF/classes/configディレクトリにあります(yhryfpは、BAMアプリケーションのデプロイでインストール時に生成されたランダム・ディレクトリであることに注意してください)。これはOracle BAMアプリケーションのデプロイでインストール時に生成されたランダム・ディレクトリです。これらのファイルのプロパティは、Oracle Enterprise Manager Fusion Middleware Controlで公開されるMbeanを使用して変更可能です。Oracle BAM Serverの構成オプションの詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』および『Oracle Fusion Middleware Oracle Business Activity Monitoringユーザーズ・ガイド』を参照してください。

同様に、図5-36に示すように、Oracle Enterprise Manager Fusion Middleware Controlによって、Oracle BAM Webアプリケーションに対するいくつかのプロパティが公開されます。

図5-36 Oracle Business Activity Monitoringの構成プロパティ

「図5-36 Oracle Business Activity Monitoringの構成プロパティ」の説明

データ・ソースや永続ストアなど、コンテナ・レベルの構成オプションは、Oracle WebLogic Serverドメイン構成の一部として保持され、WebLogic Serverのコア・インフラストラクチャによって、WebLogic Serverのクラスタ上で同期化されます。Oracle BAMの構成の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

5.11.2 Oracle Business Activity Monitoringの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

図5-37は、2つのOracle WebLogic Serverで2ノードのOracle BAMクラスタが実行されている様子を示しています。WebLogic Serverは、それらのサーバーへの受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。この構成の主要な特性は、次のとおりです。

Oracle BAM Webアプリケーションは、クラスタ化された2つのWebLogic Serverの管理対象サーバー上で実行されます。WebLogic Serverクラスタは、データ・ソース、永続ストアおよび定義など、Oracle BAM Webアプリケーションで使用されるWebLogic Serverの共通アーティファクトの構成を同期化します。Oracle BAM Serverは、BAM Webアプリケーションが実行されているいずれかのサーバーからターゲット指定されます。Oracle BAM Serverを実行するWebLogic Serverは、1つのみです。
アーキテクチャは、Oracle WebLogic Serverの移行機能を使用して、Oracle BAM WebアプリケーションとOracle BAM Serverの両方(BAMHOST1内)を実行するWebLogic Serverを障害から保護します。これにより、シングルトンのOracle BAM Serverが保護されます。Oracle BAM Serverが実行されているWebLogic管理対象サーバーは、フェイルオーバーの発生時に別のノードに移行された仮想IPをリスニングします。これは、BAMHOST2内のOracle BAM WebアプリケーションがOracle BAM Serverへの接続に使用するアドレスです。Oracle BAM Serverと、Oracle BAM Webアプリケーションの2つのインスタンスが、BAMHOST2上で実行されるシナリオを考慮し、適切に計画してください。サーバー移行機能の詳細は、第3章「WebLogic Serverの高可用性」を参照してください。
Oracle BAMのデータベースは、データベースの障害から保護するために、Oracle Real Application Cluster(Oracle RAC)で構成されます。データベース・インスタンスの障害が発生すると、Oracle BAM Serverは、再接続と操作の再試行を適切に実行します。

図5-37 Oracle BAMの高可用性アーキテクチャ

「図5-37 Oracle BAMの高可用性アーキテクチャ」の説明

5.11.2.1 Oracle Business Activity Monitoringの障害からの保護および予想される動作

Oracle BAM ServerとOracle BAM Webアプリケーションは、WebLogic Serverインフラストラクチャによってあらゆるプロセス障害から保護されます。この項では、コンポーネントの障害が発生した場合の予想される動作についても説明します。

プロセス障害

Oracle BAM ServerとBAM Webアプリケーションは、WLSインフラストラクチャによってあらゆるプロセス障害から保護されます。この項では、Oracle BAMのプロセス障害に関する考慮事項について説明します。

WLS_BAMxサーバーで障害が発生すると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。これは、構成済の再起動回数のしきい値に基づいてサーバーの再起動を試行します。
- BAM Serverが実行されているWebLogic Serverに関連する障害の場合、繰り返し再起動しても失敗すると、WebLogic Serverインフラストラクチャは、クラスタ内の他のノードへのサーバー移行を試行します。クライアントからの処理中のリクエストは、フェイルオーバー時にタイムアウトします。他のノードでサーバーが正常に再起動されると、クライアントが再起動されて、そのサーバーへのルーティングを続行します。Webブラウザで実行中の開かれているレポートについては、BAM Serverと同じ管理対象サーバーで実行されているBAM WebAppsを通じてリクエストが配信されている場合、再接続メッセージがBAM WebAppsレポートに出力されます。他のノードで実行されているBAM WebAppsを通じてリクエストが配信されている場合、メッセージは出力されません。このような状況では、フェイルオーバー時に、失効したデータが表示されることがあります(フェイルオーバーの実行中、またはWebappsからサーバーへの接続の再確立中)。BAMWebAppsサーブレットは、引き続き使用可能であり、BAM Serverが起動するとすぐに再接続します。新しいレポートおよびリクエストについては、VIPが移行されて管理対象サーバーが再起動すると、BAMHOST2内のBAM Webアプリケーションが再接続します。VIP1をリスニングするBAM Webアプリケーションは、サーバー移行が完了すると機能し始めます。このときに、HTTP Serverは、管理対象サーバーへのHTTPリクエストのルーティングを再開します。
- BAM Webアプリケーションのみが実行されているWebLogic Serverに影響のある障害は、BAMシステムには影響しません。他のBAM Webアプリケーション(BAMHOST1で実行)は、引き続き使用可能であり、WebLogic Serverのセッション・レプリケーション・クラスタを使用してセッション情報を保持します。フェイルオーバーは、透過的に実行されます。
BAM ServerとBAM Webアプリケーションが実行されているoracle-bamアプリケーションは、リソースへのアクセスの失敗、データベースの読取りエラー、またはデータベースが配置されている管理対象サーバーのステータスには関係なく発生する他の問題が原因で停止する場合があります。そのため、SOAインフラストラクチャ・アプリケーションによって引き起こされるエラーを管理対象サーバーのログで監視する必要がありますが、ログ・ファイルの場所の詳細は、第5.2.1.6項「Oracle SOAインフラストラクチャのログ・ファイルの場所」を参照してください。
レポートが開かれており、クラスタ内でBAM管理対象サーバーが1つしか起動していず、クラスタ内での追加の管理対象サーバーの起動後に他の操作を何も実行していない場合は、開かれたレポートのフェイルオーバーは正常に終了しません。セッション状態レプリケーションの1回のトリガーでレポートが開かれます。セッション状態レプリケーションは、アクティブ・データの更新ではトリガーされません。

Oracle BAMの高可用性環境では、停止されて再起動されたOracle BAMサーバー上でOracle BAM Active Viewerが実行されていると、サーバーのログに「ビューセットが見つかりません」というエラーが書き込まれます。このエラーは、Oracle BAM Active Viewerの機能には影響しないので無視してかまいません。

ノード障害

SOAHOST2でのノード障害の場合、ノード障害時の動作はプロセス障害のシナリオの場合と同じです。つまり、他のノード内のOracle BAM Webアプリケーションは、引き続き使用可能であり、リクエストを処理できます。セッションは、WebLogic Serverが提供するセッション・レプリケーション・フレームワークによって維持され、他のノードへのフェイルオーバーが透過的に実行されます。

SOAHOST1でのノード障害が発生した場合、使用可能なサーバーによりデータベース・リース・システム内のタイムスタンプが検証された後、サーバーの移行がトリガーされます。フェイルオーバーの実行中には、クライアントはデータをシステムに送信できず、必要に応じて送信を再試行します。サーバーに接続しているOracle BAM Webアプリケーションは、VIPが移行されてサーバーが再起動するまで、再接続を試行します。

データベース障害

Oracle BAMデータベース障害の詳細は、第5.2.2.1項「Oracle SOAインフラストラクチャの障害からの保護および予想される動作」を参照してください。

5.11.2.2 Oracle Business Activity Monitoringのクラスタワイドの構成変更

Oracle BAM ServerとOracle BAM Webアプリケーションが使用する標準Java EEアーティファクトは、Oracle BAMがインストールされているOracle WebLogicドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソース、永続ストアおよびJMSモジュールなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、Oracle BAM WebアプリケーションおよびOracle BAM Serverで使用されるライブラリを同期化する役割を持ちます。

単一インスタンスの項で説明したように、Oracle BAM ServerおよびOracle BAM Webアプリケーションの構成は、DOMAIN_HOME/servers/BAM_Server_Name/tmp/_WL_user/oracle-bam_11.1.1/yhryfp/APP-INF/classes/configディレクトリに保持されます(yhryfpは、BAMアプリケーションのデプロイでインストール時に生成されたランダム・ディレクトリであることに注意してください)。これらのファイル内のプロパティは、Oracle Enterprise Manager Fusion Middleware Controlで公開されるMbeanを使用して変更可能です。MBeanによって公開されるプロパティは、各サーバーに固有のものです。Enterprise Manager固有の画面を通じて公開されるプロパティは、クラスタワイドであり、1つのサーバー上でのみで変更できます。Enterprise ManagerまたはMBeanブラウザのいずれで適用されていても、すべてのプロパティで、Oracle BAMが実行されているWebLogic Serverの再起動が必要です。BAM ServerおよびBAM Webアプリケーションの構成オプションの詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』および『Oracle Fusion Middleware Oracle Business Activity Monitoringユーザーズ・ガイド』を参照してください。

高可用性の環境に関連する構成オプションの1つに、クラスタ構成でシステムにより使用されるフロントエンド・ホストを決定するために使用されるアプリケーションURLがあります。このオプションは、レポートおよびアラートのショートカットURLのコピーの作成に使用されます。Oracle BAMの高可用性構成に関連する他のパラメータには、OracleBAM Web構成画面のサーバー名があります。このパラメータは、Oracle Webアプリケーションがアクティブ・データ・キャッシュにアクセスするための接続先のOracle BAM Serverを決めるのに使用されます。

Oracle HTTP Serverによってフロントエンド処理されるSOA高可用性インストールでは、実質的なバックエンド・サーバーのOracle HTTP Serverポートでの監視をお薦めします。すなわち、SOA管理対象サーバーにデプロイされたすべてのコンポーネントがデプロイメントで使用される場合です。HTTP/HTTPSポートをpingし、事前に決められた応答が返されることを予期する単純なHTTPモニターであれば十分です。特定のSOAコンポーネント(B2Bなど)のみを使用している場合は、使用中のコンポーネントの状態を検証するために、管理対象サーバー全体のさらに深いレベルまでチェックするモニターを検討する必要がある場合があります。お使いのロード・バランサでのHTTPモニターの設定について、ロード・バランサのベンダーにご確認ください。

5.11.2.3 BAMクライアントの再試行に関する考慮事項

BAM Serverと通信するOracle BAMクライアントは、再試行可能なメソッドを実行して再試行可能な例外を原因とする障害が発生した場合、そのメソッドを再試行します。再試行可能な例外の代表は、BAM Serverとの通信に障害が発生したことを示す例外(ネットワーク通信例外など)です。BAM Serverの一部のメソッドは、障害発生時に自動的にBAMクライアントによって再試行されます。また、再試行する例外を増やすこともできます。それには、クライアントの構成ファイルの次の構成フィールドに、再試行可能として処理する例外クラス名をカンマで区切ったリストを追加します。

再試行可能な例外に関する他の構成パラメータは次のとおりです。

<BamEjbRetryCount>180</BamEjbRetryCount>: このパラメータは、getSessionまたは再試行可能なメソッドの呼出しで再試行可能な例外を原因とする障害が発生した場合の再試行回数を構成します。デフォルトは180です。
<BamEjbRetryInterval>10000</BamEjbRetryInterval>: このパラメータは、再試行の間隔をミリ秒単位で構成します。デフォルトは10000ミリ秒または10秒です。

これらのパラメータは、BAM Serverにアクセスする次のクライアントの構成ファイルに追加できます。

BAM Server、BAM Web、BAMデータ・コントロール: BamCommonConfig.xml構成ファイル
ICommand: BAMICommandConfig.xml構成ファイル
ODI: BAMODIConfig.xml構成ファイル
BAMアダプタ: BAMAdapterConfig.xml構成ファイル

5.12 Oracle Service Busと高可用性の概要

Oracle Service Busは、SOAライフサイクル管理のために一から構築された、実績あるEnterprise Service Bus(ESB)です。サービスの検出と仲介、サービスの迅速なプロビジョニングとデプロイメント、および管理を実行するための基盤機能を提供します。

図5-38は、Oracle Service Busの高レベルの機能を示します。

図5-38 Oracle Service Busの機能

「図5-38 Oracle Service Busの機能」の説明

Oracle Service Busの機能の詳細は、『Oracle Fusion Middleware Oracle Service Busコンセプトおよびアーキテクチャ』を参照してください。

5.12.1 Oracle Service Busの単一ノードの特性

Oracle Service Busは、Oracle WebLogic Server上で実行されるステートレスJava EEアプリケーションです。

Oracle Service Busでは、次のJava EEテクノロジが使用されています。

サーブレット: Oracle Service Bus Web Console、Service Busリソース・サーブレット、WSILサーブレット、HTTPプロキシ・サービス
EJB: 次の目的で使用されます。
- Java EJBプロトコル・プロキシ・サービス。このサービス(別名JEJB)は、プロキシ・サービスをEJBとして公開するために使用されます。
- Service Busトランスポート。このプロトコル(別名SB)は、2つのOracle Service Busサービス間の通信に使用されます。
- Webサービスをテストするためのテスト・コンソール。
JMS: FTP、SFTP、電子メールおよびファイル転送のインバウンド・メッセージ処理に使用されます。また、Oracle Service Busレポート作成フレームワークおよびWeb Services Reliable Messaging(WS-RM)で使用されます。
JDBCデータ・ソース: Oracle Service Busは、JMSレポート作成プロバイダに関連付けられているデータベース表のデータ・ソースを定義します。
JCAアダプタ: Oracle Service Busは、JCAトランスポートを使用して、DB、Oracle Applications、AQ、File、BAM、FTP、SAP、Siebel、PeopleSoftおよびJD Edwardsの各アダプタをサポートします。これらのアダプタでは、SOA Suiteの場合と同じアダプタ実装が使用されています。

Oracle Service Busでは、次の非Java EEコンポーネントも使用されています。

Configuration Framework: Oracle Service BusリソースのCRUD (作成、読取り、更新、削除)機能、リソースとファイルの整合性保護、セッション管理、キャッシュと索引付け、参照整合性および構成伝播を提供します。Oracle WebLogic Server管理サーバーではマスター構成がファイルに格納され、これらのファイルがWebLogicデプロイメント・サービスによって管理対象サーバーに伝播されます。
Monitoring and Alert Framework: Monitoring Frameworkは、カウンタ(メッセージ・カウンタ、エラー・カウンタ)、間隔(応答または実行の最小/最大/平均時間)およびステータス(エンドポイントの稼働/停止)に基づく統計を定義します。Monitoring Frameworkには、次のサブコンポーネントがあります。
- Collector: チェックポイントと呼ばれる1分間隔で統計を収集し、収集した統計のWebLogic永続ストアへの格納およびAggregatorへの送信を行います。コレクタは、クラスタ内の各管理対象サーバーで実行されます。
- Aggregator: クラスタ内の各管理対象サーバーから受信した統計を集計します。Aggregatorは、クラスタ内の1つの管理対象サーバーでのみ実行されるシングルトン・サービスです。
- Retriever: メモリーに格納されている統計を取得します。これは、Aggregatorが存在する管理対象サーバーにのみ存在します。
- Alert Manager: Alert Managerは、集計された統計に基づいてアラートを起動します。これは、Aggregatorが存在する管理対象サーバーにのみ存在します。Aggregatorは、ルールを評価する必要がある集計間隔(サービスまたはアラート・ルールに対して定義)が存在する場合に、集計された統計をAlert Managerにプッシュします。Alert Managerは、Aggregatorとは別のスレッドでトリガーされます。
Transport SDK: Oracle Service Busにおけるメッセージ処理では、メッセージがシステムに対してどのように入出力されたかは考慮されません。Transport SDKは、Oracle Service Busに対して入出力されるデータのフローを処理するコンポーネントとOracle Service Busとの間を抽象化するレイヤーを提供します。この抽象化レイヤーにより、ユーザーは、固有のトランスポート・プロトコルを処理するための新しいトランスポート・プロバイダを開発できます。トランスポート・プロバイダは、Transport SDKのインタフェースを実装し、Oracle Service Busとメッセージの送受信メカニズムとの間のブリッジを提供します。トランスポート・プロバイダは、トランスポート・エンドポイントのライフサイクルと実行時動作を管理します。エンドポイントは、メッセージの発行元またはターゲットに指定されるリソースです。
Message Flow Engine: メッセージ・フロー・デザイナによって構成されたアクションを使用して、メッセージ・フロー・ロジックを実行する機能を提供します。
Split-Join Engine: Split-Joinで指定されているロジックを実行する機能を提供しますが、これは、高性能なメッセージ処理をパラレルにメモリー内で実行するために使用されます。

図5-39は、Oracle Service Busとその機能サブシステムを示す高レベルのアーキテクチャ図です。

図5-39 Oracle Service Busの単一インスタンス・アーキテクチャ

「図5-39 Oracle Service Busの単一インスタンス・アーキテクチャ」の説明

Oracle Service Busが高可用性構成でデプロイされている場合、AggregatorコンポーネントとAlert Managerコンポーネントは、シングルトンです。それらをクラスタ内の1つのホストにのみデプロイすることをお薦めします。

Transport SDKやレポート作成フレームワークなどのOracle Service Bus拡張フレームワークを使用して、カスタム・クライアント・アプリケーションを記述できます。

Oracle Service Busのアーキテクチャの詳細は、『Oracle Fusion Middleware Oracle Service Busコンセプトおよびアーキテクチャ』の「Oracle Service Busのアーキテクチャ」を参照してください。

5.12.1.1 Oracle Service Busのセッション状態

Oracle Service Busは、短期メッセージの処理/仲介を行うユースケース向けに最適化されています。したがって、メッセージのコンテキスト状態はすべてメモリー内に保持されます。HTTP、EJB、SBなどの同期トランスポートでは、同期リクエストを処理中のOracle Service Busサーバーで障害が発生した場合、クライアントが再試行する必要があります。Oracle Service Busでは、JMSやWS (WS-RM)などの非同期トランスポートのリクエスト/レスポンス・パターンがサポートされています。この場合、リクエストを対応するレスポンス先にマップする相関情報はメモリー内に保持されます。レスポンスを送信する前にOracle Service Busで障害が発生した場合、相関情報は失われます。したがって、サーバーの再起動後に、Oracle Service Busはレスポンスを送信することができません。JMSトランスポートとWSトランスポートの詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』の「JMSトランスポート」と「WSトランスポート」を参照してください。

5.12.1.2 Oracle Service Bus外部依存性

Oracle Service Busには、次のような外部依存性があります。

JMSレポート作成プロバイダは、データベースを使用してレポート・データを格納します。
UDDI (Oracle Service Registry)は、Oracle Service Busのプロキシ・サービスを格納するため、およびOracle Service Busのビジネス・サービスを作成するサービスを参照するために使用されます。
Oracle Enterprise Repositoryは、サービスを参照および消費するために使用されます。その結果として、Oracle Service Busのビジネス・サービスが生成されます。Oracle Service Busのプロキシ・サービスは、Oracle Enterprise Repositoryにより収集されます。
Oracle Service Busには、Oracle Service Busのプロキシ・サービスとビジネス・サービスにアタッチされているOracle WSMセキュリティ・ポリシーを施行するOracle WSMエージェントが実装されています。
Oracle Service Busは、SOA SuiteのJCAアダプタの実装(HTTP、FTPなどのJCAアダプタ)およびJCAフレームワークに依存します。
Oracle Service Busは、サービス結果キャッシュ(Oracle Service Busにより起動されたサービスの結果のキャッシュ)のためにCoherenceインフラストラクチャに依存します。

Oracle Service Busメッセージ・フローは一般に短期です。メッセージ・フロー状態は常にメモリー内に存在します。Oracle Service Busは、即時利用可能な様々なトランスポートを提供します。たとえば、HTTPトランスポートでは、HTTP 1.1永続接続がサポートされています。

Oracle Service Busは、HTTP、JMS、電子メール、ファイル、FTP、SFTP、JCA - DB、AQ、Oracle Applications、Peoplesoft、Siebel、SAP、JD Edwards、ファイル、FTP、JEJB、EJB (アウトバウンドのみ)、Local (同一JVM内)、MQ、SB (RMIベース、2つのOSBサーバー/ドメイン間)、Tuxedo、Web Services Reliable Messaging (WS-RM)、SOA-Direct (RMIベース)、BPEL 10g (RMIベース)の各トランスポートをサポートしています。

Oracle Service Busは、JMS、ファイル、FTP、電子メール、SFTP、WS-RM、JCA - DB、AQ、SB、JEJB、EJB、SOA-DIRECTおよびBPEL 10gなど、一部のトランスポート・タイプに対して、JTAを使用します。

5.12.1.3 Oracle Service Busの構成アーティファクト

Oracle Service Busの主な構成ファイルは次のとおりです。

DOMAIN_HOME/config/config.xml: すべてのアプリケーションとライブラリ、JMSシステム・リソース、JDBCシステム・リソース、ワーク・マネージャ、起動/停止クラス、SAFエージェント、セキュリティの構成が含まれます。
DOMAIN_HOME/config/osb/coherence/osb-coherence-override.xml: このOracle Coherenceオーバーライド・ファイルでは、Oracle Coherenceのユニキャスト/マルチキャスト・リスナー情報を指定します。このファイルは、管理サーバーによって、管理サーバー・ドメイン・ディレクトリから他の管理対象サーバーのドメイン・ディレクトリに伝播されます。
DOMAIN_HOME/config/osb/coherence/osb-coherence-cache-config.xml: このCoherenceキャッシュ構成ファイルでは、Oracle Service Busサービス結果キャッシュ機能で使用されるキャッシュを定義します。
DOMAIN_HOME/config/osb/transports/sftp/known_hosts: このファイルはSFTPトランスポートで使用されます。リモートSFTPサーバーに関する情報が含まれます。known_hostsファイルの作成の詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』を参照してください。仮想ホスト名は、known_hostsファイルで使用できます。

5.12.1.4 Oracle Service Busのデプロイメント・アーティファクト

Eclipse IDEまたはOracle Service Bus Webコンソールを使用して、Oracle Service Busアーティファクト(リソース)をjarファイルにエクスポートし、選択した名前を付けることができます。エクスポートできるリソースには、プロキシ・サービス、ビジネス・サービス、WSDL、XSDおよびXSLTなどがあります。このjarファイルには、エクスポートされたすべてのOracle Service Busリソースが含まれます。構成jarファイル(およびその内部のOracle Service Busリソース)をOracle Service Busサーバーにインポートするには、次の2通りの方法があります。

パブリックOracle Service Bus APIを使用するWLST/ANTスクリプト
Oracle Service Bus Webコンソール: 「構成jarからインポート」オプションを使用

Oracle Service Busリソースは、構成フレームワーク・コンポーネントによって管理されます。構成フレームワークのデータはすべて、各管理対象サーバー(および管理サーバー)上のDOMAIN_HOME/osb/config (CONFIG_HOME)に格納されます。各リソースは、CONFIG_HOME/coreにある固有のファイルに格納されます。Oracle Service Bus構成フレームワークでは、各リソースで使用されるファイルに自動的に一意なファイル名が割り当てられるので、それらのファイル間で名前の衝突が発生しないことが保証されます。CONFIG_HOME/coreディレクトリは、すべてのリソース・データと構成データのマスター・ビューです。ランタイムは、このデータに基づいて動作します。これは、セッションで変更された内容がアクティブ化されたときにのみ変更されます。各管理対象サーバーでは、CONFIG_HOME/coreに、リソースのコピーが置かれます。管理対象サーバーの場所に応じて、このディレクトリが別システムにマウントされる可能性があります。

5.12.1.5 Oracle Service Busの起動とシャットダウン

ノード・マネージャまたはstartWebLogic/stopWebLogicスクリプトを使用して、Oracle Service Busサーバーを起動および停止できます。Oracle Enterprise Manager Grid Controlは、Oracle Service Busサービスの管理と監視をサポートします。

Oracle Service Busは、アプリケーション・リスナーを使用して初期化します。ALSB Framework Starter Applicationは、アプリケーション・リスナーを使用して、メイン・フレームワークを初期化します。このアプリケーションは、管理サーバーおよびクラスタにデプロイされます。このアプリケーション・リスナーの事前起動で、ロギング、ALSBConfigService、セキュリティ・サービス、クラスタ・タイマー・サービスおよびALSBStatisticsManagerを初期化します。XBus Kernelは、デプロイされる次に重要なアプリケーションであり、Oracle Service Busコンポーネントの初期化と起動のそれ以外の手順を実行します。このアプリケーションは管理サーバーとクラスタにターゲット指定され、アップグレーダ、リソース、Split-Join、Coherenceなどを初期化します。

障害検出機能は、Oracle WebLogic Serverによって提供されます。

5.12.1.6 Oracle Service Busのログ・ファイルの場所

Oracle Service Busの動作は、アプリケーションが実行されるOracle WebLogic管理対象サーバーに記録されます。

DOMAIN_HOME/servers/WLS_ServerName/logs/WLS_ServerName.log

Oracle Service Busは、デバッグ・ロギングもサポートします。これは、DOMAIN_HOME/alsbdebug.xmlとDOMAIN_HOME/configfwkdebug.xmlを更新することによって、有効化または無効化できます。

5.12.2 Oracle Service Busの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

図5-40は、2つのOracle WebLogic ServerでOracle Service Busの2ノード・クラスタが実行されている様子を示しています。WebLogic Serverは、それらの前面のロード・バランサからリクエストを受信する、Web層ホスト上の2つのOracle HTTP Serverによってフロントエンド処理されます。

図5-40 Oracle Service Busの高可用性アーキテクチャ

「図5-40 Oracle Service Busの高可用性アーキテクチャ」の説明

図5-40に示す高可用性構成の主要な特性は次のとおりです。

Oracle WebLogic Serverの移行機能を使用して、一部のコンポーネントを障害から保護します。これは、Oracle Service Busが実行されている各WebLogic管理対象サーバーが、フェイルオーバー時に別のボックスに移行される仮想IPをリスニングすることを意味します。Enterprise Managerは、図5-40の管理サーバーにデプロイされます。

図5-40は、WLS_OSB1管理対象サーバーはVIP1でリスニングし、WLS_OSB2管理対象サーバーはVIP2でリスニングすることを示しています。各管理対象サーバーはフェイルオーバー・リソースとして他方のノードを使用するため、システムは交差的に構成されます。WLS_OSB1はOSBHOST2にフェイルオーバーし、WLS_OSB2はOSBHOST1にフェイルオーバーします。2つのOracle Service Bus管理対象サーバーが同一ノード上で実行されるシナリオを予想して、適切な容量計画を立てる必要があります。サーバー移行機能の詳細は、第3.9項「サーバー全体の移行」を参照してください。

サーバーの移行後にトランザクションを再開するため、トランザクションとJMSストアを共有記憶域に構成します。サーバー・インフラストラクチャ・インスタンスの1つで障害が発生した場合、他のインスタンスがその共有記憶域から永続ストアを読み取って、トランザクションとJMS操作を再開できます。
管理サーバーは、アクティブ/パッシブ・モードで実行されます。OSBHOST1で障害が発生したときはいつでも、OSBHOST2で管理サーバーを再起動できます。そのため、管理サーバーでは、リスニング・アドレスに仮想IPまたは仮想ホスト名が使用されます。管理サーバーの仮想IPの構成および高可用性のための管理サーバーの構成の詳細は、第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」を参照してください。
Oracle RACデータベースをデータベース障害から保護することをお薦めします。このOracle Service Bus高可用性構成では、Oracle RACデータベースは、JMSレポート作成プロバイダとOracle WSMのポリシーで使用されます。

注意:

前述の図では、Oracle Service Busの高可用性構成を見やすくするために、SOAインフラストラクチャの高可用性構成は図示されていません。SOAインフラストラクチャの高可用性の図は、図5-5を参照してください。

ALSB Cluster Singleton Marker Applicationは、AggregatorとAlert Managerを監視するシングルトンを実行する管理対象サーバーをクラスタ内で決定します。同様に、データベースからの(JMSレポート作成プロバイダの)レポート作成データの消去に使用されるMessage Reporting Purger MDBは、クラスタ内の1つの管理対象サーバーにのみデプロイされます。他のOracle Service Busコンポーネントはすべて、クラスタをターゲットに設定するか、またはクラスタと管理サーバーをターゲットに設定します。Oracle Service BusのWebコンソール・サポートを提供するServiceBus_ConsoleおよびUDDIインポートのリソース・タイプを構成フレームワークに登録するUDDI Managerだけは、管理サーバーのみをターゲットに設定します。これらのコンポーネントは、WebLogicのシングルトン・サービスとしては定義されません。これらの高可用性は、WebLogicのサーバー全体の移行によって保証されます。

Oracle Service Busのすべてのサービスとリソースは、クラスタに均一に(クラスタ内のすべての管理対象サーバーに)デプロイされます。この唯一の例外を次に示します。

ポーラー・トランスポートである電子メール、ファイル、FTPおよびSFTPのインバウンド(プロキシ・サービス)エンドポイント。ポーラーはクラスタ内の1つの管理対象サーバーのメッセージのみをポーリングします。ポーリングする管理対象サーバーは、ユーザー構成により決まります。
JMSトランスポートのインバウンド(プロキシ・サービス)エンドポイント。JMSトランスポートは、WebLogic JMSトピック宛先を(互換トピック・メッセージ分散モードを使用して)リスニングし、ユーザーによって構成された管理対象サーバーで(クラスタ内で)1回のみトピックからのメッセージを処理するように構成されます。

可用性の高い基本的なトポロジは、1つの管理サーバーと2つの管理対象サーバーが異なるシステムで実行されるWebLogic Serverの同種クラスタ(前述のOracle Service Busシングルトン・サービスを除く)です。

WebLogicドメインでは、Oracle Service Busのクラスタが1つのみサポートされます。ローカル・データは、SANストレージ・システム、マルチポート・ディスク、NASストレージなどの共有ストレージに格納する必要があります。

ローカル・データ(ローカル・ファイルとしてアクセスされ、管理対象サーバーまたは管理サーバーにプライベート)には、次のデータが含まれます。

WebLogic構成ファイルやサーバー・ログなどのシステム・ファイル。必要に応じて、WLS JMSデータをOracle RACデータベースに格納できます。JMSは、サービス・バス内部でも、外部サービスおよびプロキシ・サービスへのトランスポートとしても、使用されます。
構成ファイルやログなどのOracle Service Busデータ。
ユーザー定義Oracle Service Bus構成データ
プロキシ・サービスによってファイル/FTPトランスポートを使用して読取りまたは書込みされるデータ・ファイルなどのユーザー・ファイル。
アラート・ログや集計されたパフォーマンス・メトリックを格納するJMS永続ストア。

Oracle RACデータベースは、レポート作成プロバイダの高可用性のため、およびサーバー移行に使用するleasingデータソースとして、使用されます。

必要に応じて、Webサーバー・ファームをOracle Service Busクラスタのフロントエンドとして使用できます。ハードウェア・ロード・バランサによって、Webサーバーまたはアプリケーション・サーバーを直接ロード・バランシングできます。Webサーバーを使用する場合、Oracle Service Bus管理対象サーバー間でHTTPトラフィックをロード・バランシングするように、WebLogicプラグインを構成する必要があります。

電子メール、FTPまたはNFSのサーバーはネットワーク内に存在でき、サード・パーティJMSのサーバーまたはサーバー・クラスタもネットワーク内に存在できます。

5.12.2.1 Oracle Service Busの障害からの保護および予想される動作

この項では、Oracle Service Busの高可用性クラスタのデプロイメントでコンポーネントがどのようにして障害から保護されるかを説明します。この項では、コンポーネントの障害が発生した場合の予想される動作についても説明します。

Oracle Service Busは、WebLogic Serverインフラストラクチャによってあらゆるプロセス障害から保護されます。

5.12.2.1.1 WebLogic Serverの障害

Oracle Service Busは、状態を保持することも、ユーザー・セッションという概念をサポートすることもありません。そのため、Oracle Service Busには、セッション状態のレプリケーションとフェイルオーバーは実装されていません。HTTP、SB、EJBなどの同期インバウンド・トランスポートの場合、リクエストを処理中の管理対象サーバーが停止した場合、クライアントは接続例外を受信するので、再試行する必要があります。

ノード・マネージャは、管理対象サーバーで障害が発生した場合にWebLogic Serverの自動移行を実行するように構成する必要があります。WebLogic Serverの移行の詳細は、第3.9項「サーバー全体の移行」を参照してください。

JMSのフェイルオーバーの場合は、WebLogicサーバーの移行を使用します。

Aggregator、Alert Manager、Reporting Message PurgerなどのOracle Service Busシングルトン・コンポーネントの場合、自動フェイルオーバーは存在しません。シングルトン・コンポーネントをフェイルオーバーするには、WebLogicサーバー移行を使用します。

注意:

Aggregator、Alert ManagerおよびReporting Message Purgerサービスはシングルトンであるにもかかわらず、障害時のサービス停止はありません。ポーラー・トランスポート(ファイル、FTP、SFTPおよび電子メール)については、サーバーで障害が発生した場合に、ポーラー・トランスポートを使用するプロキシ・サービスのみに障害が発生します。

5.12.2.1.2 ノード障害

外部ロード・バランサを使用して、HTTPリクエストを直接、クラスタ内の管理対象サーバー上のOracle Service Bus HTTPプロキシ・サービスまたはOracle Service BusクラスタのフロントエンドとなるWebサーバー/Oracle HTTP Server(OHS)にロード・バランシングできます。スティッキー・セッション・ルーティング要件はありません。

ノード・マネージャを、障害が発生したOracle Service Busノードをフェイルオーバーするように構成できます。

HTTPリクエストを処理中のOracle Service Bus管理対象サーバーに障害が発生した場合、クライアントは同じリクエストを再送信する必要があります。JEJBトランスポートおよびSBトランスポートの場合、サーバーが停止すると、クライアントは接続エラーを受け取ります。すべてのポーラー・トランスポートの場合、メッセージはXA接続ファクトリを使用してデキューされるので、メッセージ処理の整合性は、トランザクション・セマンティクスによって処理されます。ポーラー・トランスポートは、「少なくとも1回」というセマンティックを提供します。しかし、(障害が発生したノードの)サーバー全体が移行した後、ポーラーはポーリング中のリソースにアクセスする必要があります。JTAトランスポートも、JMSトランスポートを使用する際、トランザクションの整合性を維持します。進行中のJTAトランザクションをリカバリするには、JTAのTlogをリカバリする必要があります。

Oracle Service Busは、「必ず1回」というメッセージ配信セマンティックを保証します。この動作は、プロキシ・サービスで構成される$outboundコンテキスト変数のQoSプロパティによって制御されます。様々なQoS設定の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』を参照してください。

管理対象サーバーが起動したとき、進行中のグローバル・トランザクションが存在する場合は、それをリカバリします。たとえば、プロキシ・サービスがXA接続ファクトリを使用して2つのJMSプロバイダ間を必ず1回のQoSでブリッジしている場合、グローバル・トランザクションのリカバリが必要になる可能性があります。もう1つの例として、JMSレポート作成プロバイダがあります。デフォルトのJMSレポート作成プロバイダを使用している場合、レポート・メッセージはまずJMSキューに書き込まれます。MDBは、JMSキューからレポート・メッセージをデキューして、それをデータベースに書き込みます。(データベースの)データ・ソースは、LLR (ロギング・ラスト・リソース最適化)のトランザクション・セマンティックにより構成されています。この場合、リカバリの実行中にデータベースが実行中である必要があります。実行されていない場合、サーバーは起動しません。LLRが有効な場合も、Tlogは使用されます。ただし、それはトランザクション単位に限定されます。したがって、すべてのトランザクションがLLRトランザクションだとしても、Tlogの可用性は高くする必要があります。トランザクション・マネージャは、特定のトランザクションには無関係でも、トランザクションの完全な安全性を提供するために必要とされるチェックポイントTlogレコードを永続的に保持します。

次の2つのケースでは、管理対象サーバーの障害によって特定の状態が失われ、メッセージが正しく処理されません。

JMSリクエスト/レスポンス・ビジネス・サービス: メモリー内に表のマッピングの相関情報を保持しています。これは、管理対象サーバーが停止すると失われます。そのため、JMSサービスからのレスポンスが、JMSリクエスト/レスポンス・ビジネス・サービスへのルーティングを行うプロキシ・サービスを利用した元のクライアントに返されない可能性があります。
WS(信頼できるメッセージング)ビジネス・サービス: JMSリクエスト/レスポンス・ビジネス・サービスと同様に、WSビジネス・サービスはメモリー内に表のマッピングの相関情報を保持しています。これは管理対象サーバーが停止すると失われ、レスポンスを処理できません。

5.12.2.1.3 データベース障害

データベース障害は、データベース・リース(サーバー移行に使用)に対する影響以外に、JMSレポート作成プロバイダの機能のコンテキストでのみOracle Service Busに影響を及ぼします。プロキシ・サービスでレポート・アクションが実行されている場合、レポート・データはレポート作成JMSキューにエンキューされます。レポート作成MDBは、JMSキューからメッセージをデキューし、それを、ロギング・ラスト・リソース(LLR)グローバル・トランザクション・プロトコルで構成されているデータ・ソースを使用して、データベースに挿入します。レポート作成JMSキューは、2回の再配信の制限とエラー・キューで構成されています。データベース障害が発生し、再配信が制限回数に達すると、レポート・メッセージはエラー・キューに移動されます。データベースが再稼働した後でこれらのレポート・メッセージをJMSレポート作成キューに戻すことによって、データベースに挿入できます。LLRトランザクションの処理中にデータベース障害が発生した場合、トランザクション・リカバリが実行されます。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JTAのプログラミング』の「ロギング・ラスト・リソース・トランザクションの最適化」を参照してください。

5.12.2.2 Oracle Service Busのクラスタワイドのデプロイメント

Oracle Service Busのリソースの更新/デプロイは、WebLogic管理サーバー上で行われます。管理サーバーは、WebLogicデプロイメント・サービスを使用して、Oracle Service Busのリソースを、クラスタ内のすべての管理対象サーバーに伝播します。

5.12.2.3 クラスタ内のOracle Service Busのオンライン再デプロイメント

Oracle Service Busでは、複数のレコード(バージョン)またはリソースの履歴のコピーを保持しません。リソースの更新は、新しいバージョンがデプロイされ、古いバージョンは上書きされるという形で実行されます。構成フレームワークにより、セッション内のリソースが変更されます。セッション内のリソースは、セッション作成時にコア(すべての管理対象サーバーが現在使用している)からコピーされたものです。このセッションがコミットされると、変更によってコアが更新されます。この変更はトランザクション的にクラスタ内の管理対象サーバーに伝播されます。進行中のリクエスト(プロキシ・サービス・メッセージ・フローをすでに実行しているリクエスト)は、更新が行われている間、更新前のリソースを引き続き使用します。コアが変更された後のリクエストは、更新後のリソースを使用します。

5.12.2.4 Oracle Service Busのクラスタワイドの構成変更

Oracle Service Busのリソースは、クラスタ・レベルで更新されます。これらの変更は、WebLogic管理サーバーによって、クラスタ内のすべての管理対象サーバーに伝播されます。構成変更は、Oracle Service Bus Webコンソール、管理コンソールおよびパブリックMBeanで実行できます。

次のファイルは、クラスタ内の管理対象サーバーへの自動伝播の対象外です。

DOMAIN_HOME/config/osb/coherence/ディレクトリのファイル
DOMAIN_HOME/config/osb/transports/sftp/known_hosts

これらのディレクトリにあるファイルにアクセスする各管理対象サーバーは、DOMAIN_HOMEへのアクセス権が必要です。

注意:

高可用性構成のOracle Service Busのインストールと構成の詳細な手順は、第5.14項「SOAインフラストラクチャとコンポーネント・サービス・エンジンを使用するOracle Service Busの高可用性の構成」を参照してください。

5.13 Oracle SOAインフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成

この項では、Oracle BPEL/Oracle PM、Oracle Mediator、Oracle Human WorkflowおよびOracleデシジョン・サービスの他、Oracle B2B、Oracle User Messaging Serviceなど、SOAインフラストラクチャ・システムに含まれるサービス・エンジンの設定手順について説明します。

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

第5.13.1項「環境の準備: SOAの高可用性構成の設定前に必要な手順」
第5.13.2項「Oracle Fusion Middlewareホームのインストール」
第5.13.3項「SOAHOST1のVIP1およびSOAHOST2のVIP2の有効化」
第5.13.4項「SOAのドメインを作成するためのSOAHOST1でのOracle Fusion Middleware構成ウィザードの実行」
第5.13.5項「SOAHOST1での管理サーバー用boot.propertiesの作成」
第5.13.6項「SOAHOST1での管理サーバーの起動と検証」
第5.13.7項「管理サーバーおよびWLS_SOAn管理対象サーバーに対するホスト名の検証の無効化」
第5.13.8項「コンポジットのデプロイでのOracle Coherenceの構成」
第5.13.9項「SOAHOST1でのシステムの起動」
第5.13.10項「pack/unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播」
第5.13.11項「第2ノードのXEngineファイルの抽出」
第5.13.12項「SOAHOST2でのシステムの起動」
第5.13.13項「管理サーバーおよび管理対象サーバーWLS_SOAnのOracle HTTP Serverの構成」
第5.13.14項「Oracle HTTP Serverを使用したアクセスの検証」
第5.13.15項「サーバー間で共有するJMS永続ストアの構成」
第5.13.16項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」
第5.13.17項「フロントエンドHTTPのホストおよびポートの設定」
第5.13.18項「コンポジットへの直接バインディング/RMI呼出しのためのWLSクラスタ・アドレスの設定」
第5.13.19項「アプリケーションのデプロイ」
第5.13.20項「WLS_SOAサーバーのサーバー移行の構成」
第5.13.21項「トポロジのスケーリング」

注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

注意:

このガイドで定義されているアーキテクチャとデプロイメント手順を使用することにより、単純なクラスタ・デプロイメントを実現できます。各章に記載されている手順は、このトポロジおよび他の類似する高可用性トポロジを、該当するFusion Middlewareコンポーネントで実現する場合の基礎的要素として使用できます。また、本番デプロイメントでは、セキュリティ・ポリシーと一元的なLDAPサーバーを関連付けるなど、この他にも必要な手順を使用することが予想されます。セキュアな複数層アーキテクチャおよびデプロイメント手順の詳細は、構成対象のコンポーネントのエンタープライズ・デプロイメント・ガイドを参照してください。

図5-41は、この項の構成手順で作成するアーキテクチャの例を表しています。

図5-41 Oracle SOAインフラストラクチャの高可用性アーキテクチャ

「図5-41 Oracle SOAインフラストラクチャの高可用性アーキテクチャ」の説明

図5-41は、2つのOracle WebLogic Serverで2ノードのSOAクラスタが実行されている様子を示しています。WebLogic Serverは、受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。ロード・バランサは、システムをフロントエンド処理し、クライアントから受信したリクエストを2つのOracle HTTP Serverに配布します。通常、カスタムの論理デプロイメントとアプリケーション・デプロイメントには、(図には示されていない)異なるWebLogic Serverが使用されます。この構成では、メタデータとSOAスキーマの格納にはOracle RACデータベース、トランザクションとJMSストアには共有記憶域を使用しています。仮想IPアドレス(VIP)は、管理サーバーとOracle SOA Server(サーバー移行用)の手動フェイルオーバーに使用されます。このアーキテクチャに含まれるコンポーネントの詳細は、この章の個々のコンポーネントの項を参照してください。

管理サーバーの仮想IPの構成および高可用性のための管理サーバーの構成の詳細は、第12.2.2.3項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。

5.13.1 環境の準備: SOAの高可用性構成の設定前に必要な手順

次の各項では、SOAインフラストラクチャの高可用性構成を設定する前に必要となる手順について説明します。

プラットフォーム固有のコマンドの詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteインストレーション・ガイド』を参照してください。

第5.13.1.1項「データベースに関する前提条件」
第5.13.1.2項「VIPとIPの前提条件」
第5.13.1.3項「共有記憶域に関する前提条件」
第5.13.1.4項「LDAPプロバイダのインストールと構成」
第5.13.1.5項「システム・クロックの同期」
第5.13.1.6項「ディレクトリとディレクトリ環境変数の用語」
第5.13.1.7項「データベース・リポジトリのインストールと構成」
第5.13.1.8項「Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用したデータベースへのFusion Middlewareスキーマのロード」
第5.13.1.9項「ロード・バランサの仮想サーバー名とポートの構成」
第5.13.1.10項「WEBHOST1およびWEBHOST2へのOracle HTTP Serverのインストール」

5.13.1.1 データベースに関する前提条件

Oracle SOA Suiteでは、サポートされているデータベースおよびスキーマが存在している必要があります。

データベースが動作保証されているかどうかを確認するか、または動作保証されたデータベースをすべて表示するには、次の動作保証ドキュメントで、動作保証されたデータベースに関する項を参照してください。

http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html

データベースのバージョンを調べるには、次の問合せを実行します。

SQL>select version from sys.product_component_version where product like 'Oracle%';

5.13.1.2 VIPとIPの前提条件

表5-2に示されているように、それぞれ異なる仮想IPをリスニングする管理サーバーとSOA管理対象サーバーを構成します。そのためには、ノード内の対応するVIPのプロビジョニングと、ネットワーク上のDNSシステムで関連付けられているホスト名が必要です。各VIPが使用可能であり、SOAHOST1、SOAHOST2およびクライアント・システムからアクセスできることを確認してから、インストールを実行してください。

表5-2 仮想ホスト

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

5.13.1.3 共有記憶域に関する前提条件

障害発生時に適切にリカバリできるようにするには、すべてのノードからアクセスできる場所にJMSとトランザクションの両方のログを格納して、管理対象サーバーで障害が発生した後にすべてのノードが操作を再開できるようにします。そのためには、複数ノードで参照可能な共有記憶域の場所が必要です。表5-3は、共有記憶域の内容を示しています。

表5-3 共有記憶域の内容

サーバー	データの型	共有記憶域のボリューム	ディレクトリ	ファイル
WLS_SOA1	Txログ	VOL1	ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs	共通の場所(WebLogicサーバーにより決められたストア)
WLS_SOA2	Txログ	VOL1	ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs	共通の場所(WebLogicサーバーにより決められたストア)
WLS_SOA1	JMSストア	VOL1	ORACLE_BASE/admin/domain_name/soa_cluster_name/jms	共通の場所である、サーバーごとに個別のストア(SOAJMSStore1、UMSJMSStore1など)
WLS_SOA2	JMSストア	VOL1	ORACLE_BASE/admin/domain_name/soa_cluster_name/jms	共通場所である、サーバーごとに個別のストア(SOAJMSStore2、UMSJMSStore2など)

共有記憶域にはNASやSANなどのデバイスを使用できます。具体的には、NFSマウント・システムの場合、ファイルのロックに関連する別の問題および突然のノード障害が検出されます。『Oracle Fusion Middlewareリリース・ノート』をチェックし、記憶域のベンダーに、マウント・オプションとして使用する主な推奨パラメータについて問い合せてください。NASデバイス別のコマンド例を次に示します。この項で指定しているオプションは、実際のオプションと異なる場合があります。

SOAHOST1> mount nasfiler:/vol/volX/FMWshared
MW_HOME -t nfs -o
rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

5.13.1.4 LDAPプロバイダのインストールと構成

本番環境では、Oracle SOA Suiteの高可用性トポロジに外部のLDAPポリシー・ストアが必須です。サポートされているポリシー・ストアの詳細と、LDAPの構成手順は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

5.13.1.5 システム・クロックの同期

高可用性SOAのデプロイメントでは、各クラスタ・ノードのシステム・クロックを同期することが必要です。

5.13.1.6 ディレクトリおよびディレクトリ環境変数の用語

次のリストは、この章で使用するディレクトリと変数について説明しています。

ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指します。
MW_HOME: この環境変数および関連するディレクトリ・パスは、Fusion Middleware(FMW)が常駐している場所を指します。
WL_HOME: この環境変数および関連するディレクトリ・パスには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています。
ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、Oracle FMW SOA Suiteがインストールされている場所を指します。
ORACLE_COMMON_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリ・ファイルおよびライブラリ・ファイルが含まれているOracleホームを指します。

それぞれのMiddlewareホーム内のOracle共通ホームは、1つに限られます。
DOMAINディレクトリ: このディレクトリ・パスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されている場所を指します。
ORACLE_INSTANCE: Oracleインスタンスには、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなどのシステム・コンポーネントが1つ以上含まれています。Oracleインスタンス・ディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなどの更新可能ファイルが格納されています。

このディレクトリで一貫性を保つために使用することをお薦めする値は、次のとおりです。

ORACLE_BASE:

/u01/app/oracle

MW HOME(アプリケーション層):

ORACLE_BASE/product/fmw

WL_HOME:

MW_HOME/wlserver_10.3

ORACLE_HOME:

MW_HOME/soa

ORACLE_COMMON_HOME:

MW_HOME/oracle_common

JMSファイル・ベースのストアとTlogの場所:

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

マウント・ポイント:

ORACLE_BASE/admin/domain_name/soa_cluster_name/

5.13.1.7 データベース・リポジトリのインストールと構成

次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。

Oracle Clusterware

10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。
11g リリース1(11.1)以降については、Oracle Clusterwareインストレーション・ガイドを参照してください。

自動ストレージ管理

10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。
11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。
インストーラを実行するときは、「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。

Oracle Real Application Cluster

10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。
11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

Oracle Fusion Middlewareのコンポーネントをインストールする前に、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clusterデータベースにインストールする必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。RCUは、専用のMiddlewareホームにインストールします。

最新バージョンのRCUを使用して、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clustersデータベースにインストールします。

最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

データベースの初期化パラメータ

次の初期化パラメータが、必要な値に設定されていることを確認します。これは、リポジトリ作成アシスタントによってチェックされます。

表5-4 必要な初期化パラメータ

パラメータ	必要な値	パラメータ・クラス
`PROCESSES`	300以上	静的

SQL*Plusを使用して初期化パラメータの値をチェックするには、SHOW PARAMETERコマンドを次のように使用します。

SYSユーザーとして、SHOW PARAMETERコマンドを次のように発行します。

SQL> SHOW PARAMETER processes

次のコマンドを使用して初期化パラメータを設定します。

SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE

データベースを再起動します。

注意:

パラメータの値を変更する方法は、パラメータが静的か動的かによって異なり、データベースがパラメータ・ファイルとサーバー・パラメータ・ファイルのどちらを使用しているかによっても異なります。パラメータ・ファイル、サーバー・パラメータ・ファイル、およびパラメータ値の変更方法の詳細は、Oracle Database管理者ガイドを参照してください。

5.13.1.8 Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用したデータベースへのFusion Middlewareスキーマのロード

Oracle SOA Suiteのコンポーネントをインストールする前に、11g(11.1.1)Oracle Fusion Middlewareのメタデータ・ストアとOracle SOAスキーマをReal Application Clusterデータベースにインストールします。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。RCUのインストールの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

5.13.1.8.1 RCUの実行

RCUを実行して、Oracle Fusion Middleware 11gに必要なメタデータをインストールします。

Linuxでは、RCU_Home/binに移動して、次のコマンドを使用します。
```
./rcu
```
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードし、「次へ」をクリックします。
「データベース接続の詳細」画面で、データベースの接続情報を入力します。
- データベース・タイプ: Oracle Databaseを選択します。
- ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合、ホスト名としてVIP名またはノード名の1つを指定します: SOADBHOST1VIRTUAL
- ポート: データベースのポート番号: 1521
- サービス名: データベースのサービス名を入力します: soaha.mycompany.com
- ユーザー名: SYS
- パスワード: SYSユーザーのパスワードを入力します。
- ロール: SYSDBA
「次へ」をクリックします。
次のような警告メッセージを受信する場合があります。

接続先のデータベースには非UTF8 charsetが含まれています。このデータベースを使用して複数言語のサポートを求める場合、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。
その場合は、「無視」または「停止」をクリックします。
「コンポーネントの選択」画面で「接頭辞の新規作成」を選択し、SOAHAのように、データベース・スキーマに使用する接頭辞を入力します。

後の手順で利用できるように、このスキーマ名を書き留めておきます。
- 次のスキーマを選択します。
  - 「AS共通スキーマ」で、メタデータ・サービスを選択します。
  - 「SOAインフラストラクチャ」で、「SOAサービス・インフラストラクチャ」と「ユーザー・メッセージング」を選択します。
「次へ」をクリックします。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。
「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。

RCUの使用の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

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

Oracle WebLogic Serverトランザクション・マネージャがトランザクションの状態情報を問い合せて、WebLogic Serverコンテナで障害が発生した後の処理中トランザクションのリカバリ時に、commitやrollbackなどの適切なコマンドを発行できるようにするには、適切なデータベース権限が必要です。

トランザクション・リカバリ権限のSOAスキーマを構成する手順は次のとおりです。

sysdba権限を持つユーザーとしてSQL*Plusにログオンします。例:
```
sqlplus "/ as sysdba"
```
sys.dba_pending_transactionsに対してselectをsoaha_soainfraに付与します。
任意のトランザクションに対してforceをsoaha_soainfraに付与します。

注意:

これらの権限は、RCUの操作によって決定されるsoainfraスキーマの所有者に付与する必要があります。

5.13.1.9 ロード・バランサの仮想サーバー名とポートの構成

この項では、Oracle SOA Suiteの高可用性環境をデプロイするためのロード・バランサの前提条件について説明します。

ロード・バランサ

Oracle SOA Suiteは、2つのOracle HTTP ServerがWeb層コンポーネントとして含まれた高可用性構成にデプロイされた場合は、ハードウェア・ロード・バランサを使用します。ハードウェア・ロード・バランサには、次の機能が必要です。

仮想ホスト名を介した実サーバー・プールへのトラフィックのロード・バランシング機能: クライアントは、仮想ホスト名を使用して(実ホスト名を使用するかわりに)、サービスにアクセスします。これにより、ロード・バランサは、プール内のサーバーに対するリクエストをロード・バランシングできます。
ポート変換の構成: ロード・バランサには、1つのポートで受信した受信リクエストを別のポートで実行されているサーバー・プロセスにルーティングできるポート変換機能が必要です。たとえば、ポート80で受信したリクエストをポート7777にルーティングできます。
ポート(HTTP、HTTPS)の監視
仮想サーバーとポートの構成: 外部ロード・バランサの仮想サーバー名とポートを構成する機能。さらに、仮想サーバー名とポートは次の要件を満たしている必要があります。
- ロード・バランサには複数の仮想サーバーを構成できる必要があります。各仮想サーバーに対し、ロード・バランサには2つ以上のポートでトラフィック管理を構成できることが必要です。たとえば、通常は、HTTPおよびHTTPSトラフィック用の仮想サーバーとポートでロード・バランサを構成する必要があります。
- 仮想サーバー名をIPアドレスに関連付け、DNSに含める必要があります。クライアントは、仮想サーバー名を介してロード・バランサへアクセスできる必要があります。
ノード障害を検出し、障害が発生したノードへのトラフィックのルーティングを即座に停止する機能。
リソースの監視/ポートの監視/プロセス障害検出: ロード・バランサは、サービスおよびノードの障害を通知などの方法を通じて検出し、障害が発生したノードへの非Oracle Netトラフィックの送信を停止できる必要があります。ロード・バランサに障害の自動検出機能がある場合は、それを使用する必要があります。
フォルト・トレラント・モード: ロード・バランサをフォルト・トラレント・モードに構成することを強くお薦めします。
その他: トラフィックの転送先となるバックエンド・サービスが使用できない場合、コール元のクライアントに即座に戻るようにロード・バランサの仮想サーバーを構成することを強くお薦めします。この構成は、クライアント・システムにおけるTCP/IPの設定に基づいてタイムアウト後にクライアント側で接続を切断する構成よりも推奨されます。
スティッキーなルーティング機能: CookieまたはURLに基づいたコンポーネントへのスティッキーな接続を維持する機能。
SSLアクセラレーション: SSLアクセラレーションは、SSLトランザクションで実行され、プロセッサを集中的に使用する公開鍵暗号化アルゴリズムを、ハードウェア・アクセラレータにオフロードする方法です。

この機能は推奨されますが、必須ではありません。

表5-5は、Oracle SOA Suiteの高可用性環境で外部ロード・バランサに使用する仮想サーバー名の例を示しています。

表5-5 外部ロード・バランサの仮想サーバー名

コンポーネント	仮想サーバー名
Oracle SOA Suite	soa.mycompany.com
WebLogic Server管理コンソール	admin.mycompany.com
Oracle Enterprise Manager Fusion Middleware Control	admin.mycompany.com

仮想サーバー名

この項では、この章で説明する高可用性デプロイメントのために設定が必要な仮想サーバー名について説明します。

soa.mycompany.com

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

admin.mycompany.com

この仮想サーバーは、管理サービスへ送信されるすべての内部HTTPトラフィックのアクセス・ポイントとして機能します。クライアントからの受信トラフィックはすべて非SSLに対応しています。このため、クライアントはアドレスadmin.mycompany.com:80を使用してこのサービスにアクセスし、トラフィックはWEBHOST1およびWEBHOST2のポート7777に順に転送されます。この仮想ホストでアクセスされるサービスには、WebLogic管理サーバー・コンソールやOracle Enterprise Managerなどがあります。

さらに、仮想サーバー名に対応するIPアドレスが設定されていることと、仮想サーバー名がドメイン・ネーム・システム(DNS)に登録されていることを確認します。Oracle Fusion Middlewareを実行するコンピュータには、これらの仮想サーバー名を解決できることが必要です。

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

WEBHOST1にOracle HTTP Serverをインストールする手順は次のとおりです。

サーバーが次の要件を満たしていることを確認します。
- システム、パッチ、カーネルなどの要件が、『Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド』で指定されている要件を満たしています。
- ポート7777が、ノード上のどのサービスによっても使用されていない。このことを確認するには、次のコマンドを実行します。
  
  UNIX:
```
netstat -an | grep LISTEN | grep "7777"
```
  Windows:
```
netstat -an | findstr "LISTEN" | findstr ":7777"
```
ポートを使用中の場合は、それらのポートを使用可能にします。
UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。

/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。
Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。

UNIXでは、コマンドrunInstallerを実行します。

Windowsでは、setup.exeをダブルクリックします。
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。
「前提条件のチェック」画面で、前提条件がすべて満たされていることを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、場所を次のように設定します。

/u01/app/oracle/product/11.1.1/ohs_1
「次へ」をクリックします。
「コンポーネントの構成」画面で、次の操作を行います。
- 「Oracle HTTP Server」を選択します。
- 「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。
- 「次へ」をクリックします。
「コンポーネントの詳細の指定」画面で、次の値を入力します。
- インスタンス・ホームの場所: インスタンス・ホーム
- インスタンス・ホームの場所: /u01/app/oracle/product/11.1.1/ohs_1/instances/ohs_instance1
- インスタンス名: ohs_instance1
- OHSコンポーネント名: ohs1
「次へ」をクリックします。
「Web Tierポートの詳細の指定」画面で、次の操作を行います。
- 「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。
- 「Oracle HTTP Serverポート」に値を入力します(例: 7777)。
「次へ」をクリックします。
「構成サマリー」画面で、選択内容が正しいことを確認して「インストール」をクリックします。
「インストールの進行状況」画面で、次の操作を行います。

UNIXシステムでは、ダイアログ・ボックスが表示され、oracleRoot.shスクリプトを実行するように求められます。コマンド・ウィンドウを開き、表示される指示に従ってスクリプトを実行します。

「次へ」をクリックします。
「構成」画面で、いくつかの構成アシスタントが連続して開始されます。構成アシスタントが終了すると、「構成が完了しました」画面が表示されます。
「構成が完了しました」画面で、「終了」をクリックして終了します。

WEBHOST2に対して手順を繰り返し、WEBHOST1アドレスとWEBHOST2アドレスの両方を含むプールを使用してLBRを構成します。

5.13.1.10.1 Oracle HTTP Serverの検証

Oracle HTTP Serverが正しく設定されていることを確認するには、ブラウザで次のURLを使用し、サーバーのルートURLコンテキストにアクセスします。

HTTP://WEBHOST1:7777/

Oracle HTTP Serverが正しく設定されている場合は、ブラウザにOracle FMWの「ようこそ」画面が表示されます。

5.13.2 Oracle Fusion Middlewareホームのインストール

この項では、Oracle WebLogic ServerとOracle SOA Suiteを実行するアプリケーション層のすべてのノードにOracle Fusion Middlewareをインストールする手順について説明します。WebLogic ServerとOracle SOAをSOAHOST2にインストールするために、この手順を繰り返します(次ではSOAHOST1を対象にして説明しています)。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。これらのパスとドメインが最初のノードに使用したものと同一でない場合には、フェイルオーバーは正しく機能しません。

Oracle Fusion Middlewareの、次のコンポーネントをインストールします。

Oracle WebLogic Server(第5.13.2.1項「Oracle WebLogic Serverのインストール」を参照)
Oracle SOA Suite(第5.13.2.2項「Oracle SOA用Oracle Fusion Middlewareのインストール」を参照)

5.13.2.1 Oracle WebLogic Serverのインストール

最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

アプリケーション層にあるすべてのノードにWebLogic Serverをインストールする手順は次のとおりです。

Oracle WebLogic Serverインストーラを起動します。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。
- 「新しいミドルウェア・ホームを作成する」を選択します。
- 「ミドルウェア・ホーム・ディレクトリ」フィールドで、MW_HOMEと入力します。
- 「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。
「製品とコンポーネントの選択」画面で、「次へ」をクリックします。
「JDKの選択」画面で、「Oracle JRockit 160_20_D1.0.1-2124 SDK」のみを選択して「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。

WL_HOME

「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」の選択を解除して「完了」をクリックします。

5.13.2.2 Oracle SOA用Oracle Fusion Middlewareのインストール

Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。

/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

Oracle Fusion Middleware 11g Oracle SOA Suiteのインストーラを起動します。

UNIXの場合:
```
SOAHOST1> runInstaller
```
Windowsの場合:
```
SOAHOST1> setup.exe
```
Oracle Fusion Middleware 11g Oracle SOA Suiteのインストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、MW_HOME/jrockit_160_<バージョン>のように入力します。
「インベントリ・ディレクトリの指定」画面で、次の操作を行います。
1. HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所が推奨されます)。
2. インストールを実行するユーザーのOSグループを入力します。
3. 「次へ」をクリックします。
4. 画面の手順に従って、/createCentralInventory.shをルートとして実行します。
5. 「OK」をクリックします。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、次の操作を行います。
- 「MiddleWareホーム」には、MW_HOMEと入力します。
- 「Oracleホーム・ディレクトリ」には、soaと入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
「インストール完了」画面で「終了」をクリックします。

注意:

第5.13.4項「SOAのドメインを作成するためのSOAHOST1でのOracle Fusion Middleware構成ウィザードの実行」の説明に従って構成ウィザードを実行する前に、Oracle Fusion Middlewareが最新バージョンになるように、最新のOracle Fusion Middlewareパッチ・セットおよびその他の既知のパッチがMiddlewareホームに適用されていることを確認してください。

最新バージョンのOracle Fusion Middlewareを取得するために実行する必要のある手順は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

5.13.3 SOAHOST1のVIP1およびSOAHOST2のVIP2の有効化

SOAドメインは、SOA管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのSOAマシン上でこれらのホスト名それぞれに対してVIPマッピングを有効にして(SOAHOST1ではVIP1、SOAHOST2ではVIP2)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーとhosts解決のいずれかで)正しく解決する必要があります。

仮想IPの構成の詳細は、第12.2.2.3項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。この項には、管理サーバーの例が記載されています。SOAサーバーのサーバー移行の構成の詳細は、第5.13.20項「WLS_SOAサーバーのサーバー移行の構成」を参照してください。

5.13.4 SOAのドメインを作成するためのSOAHOST1でのOracle Fusion Middleware構成ウィザードの実行

SOAホーム・ディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーとOracle SOAコンポーネントが格納されるドメインを作成します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースの場合は、すべてのインスタンスが実行されている必要があります。

注意:

同じWebLogic Serverドメイン内では、複数のSOAクラスタは許可されていません。

注意:

ドメインを拡張するためにOracle Fusion Middlewareの構成ウィザードを実行する前に、Oracle BPMはOracle Fusion Middlewareの適切なパッチ・セット・レベルのパッチの適用対象になるWL_HOMEホームとORACLE_HOMEホームを要求します。

MiddlewareホームのSOAディレクトリにある、Oracle Fusion Middlewareの構成ウィザードの場所に、ディレクトリを変更します。
```
SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
```
Oracle Fusion Middlewareの構成ウィザードを起動します。

Linuxの場合:
```
SOAHOST1> ./config.sh
```
Windowsの場合:
```
SOAHOST1> config.cmd
```
「ようこそ」画面で、「新しいWebLogicドメインの作成」を選択します。「次へ」をクリックします。
「ドメイン・ソースの選択」画面で、次を選択します。
- 「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。
- 次の製品を選択します。
  - Basic Weblogic Server Domain - 10.3.6.0 [wlserver_10.3](デフォルトで選択されており、グレーアウトされています)
  - Oracle BPM Suite - 11.1.1.0 [Oracle_SOA1](BPMシステムの場合のみ)
  - Oracle SOA Suite - 11.1.1.0 [Oracle_SOA1](BPM Suiteを選択した場合は、デフォルトで選択されています)
  - Oracle Service Bus OWSM Extension - 11.1.1.6
  - Oracle Enterprise Manager - 11.1.1.0 [oracle common](デフォルトで選択されています)
  - Oracle Service Bus - 11.1.1.6
  - WebLogic Advanced Web Services for JAX-RPC Extension - 10.3.6.0
  - Oracle WSM Policy Manager - 11.1.1.0 [oracle_common](SOA/BPM Suiteを選択した場合は、デフォルトで選択されています)
  - Oracle JRF - 11.1.1.0 [oracle_common](SOA/BPM Suiteを選択した場合は、デフォルトで選択されています)
ターゲットの一部を間違って選択解除した場合は、この画面で次の項目が選択されていることを確認してください。
- Oracle BPM Suite(BPMシステムの場合のみ)
- Oracle SOA Suite
- Oracle Enterprise Manager
- Oracle WSM Policy Manager
- Oracle JRF
「次へ」をクリックします。
「ドメイン名と場所の指定」画面で、次のエントリを作成します。
- ドメイン名: soadomain
- ドメインの場所: デフォルトを受け入れます。
- アプリケーションの場所: デフォルトを受け入れます。
「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
- WebLogicドメインの起動モード: 「本番モード」を選択
- JDKの選択: 「Oracle JRockit 160_20_D1.0.1-2124 SDK」を選択
「次へ」をクリックします。

「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。

画面下部の表に表示されるすべてのコンポーネント・スキーマ(SOAインフラストラクチャ、ユーザー・メッセージング・サービス、OWSM MDSスキーマおよびSOA MDSスキーマ)を選択します。
「コンポーネント・スキーマのRAC構成」については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択します。単一のデータベース構成の場合は、「変換しない」を選択します。

画面に次のデータ・ソースが表示されていることを確認します。表5-6に示されているユーザー名は、RCUからのスキーマ作成で、接頭辞にsoahaが使用されていることを想定しています。

Oracle RACでのGridLinkデータ・ソースの構成の詳細は、第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」を参照してください。

Oracle RACおよびMDSリポジトリでのマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

表5-6 データ・ソースの値の構成

コンポーネント・スキーマ	スキーマ所有者
SOAインフラストラクチャ	SOAHA_SOAINFRA
ユーザー・メッセージング・サービス	SOAHA_ORASDPM
OWSM MDSスキーマ	SOAHA_MDS
SOA MDSスキーマ	SOAHA_MDS

「次へ」をクリックします。

次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

マルチ・データ・ソースの場合は、次のフィールドに値を入力します。

図5-42 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面

「図5-42「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面」の説明

GridLinkデータ・ソースの場合は、次のフィールドに値を入力します。

図5-43 GridLink RACコンポーネント・スキーマの構成

「図5-43 GridLink RACコンポーネント・スキーマの構成」の説明

ドライバ: RACの場合には、OracleのRACサービス・インスタンス接続用ドライバ(Thin)、バージョン:10、11を選択します。GridLinkの場合は、OracleのGridLink接続用ドライバ(Thin)、バージョン:10以降を選択します。

サービス名 : データベースのサービス名を入力します。GridLinkデータ・ソースの場合は、RACサービス名を小文字で入力し、その後にドメイン名example.comを入力する必要があります。たとえば、<mydbservice>.example.comと入力します。

注意:

Oracle RACサービス名はデータベースで定義されており、固定名ではありません。データベース・ドメイン名(example.comなど)を含むRACサービス名を登録または追加することをお薦めします。

ユーザー名接頭辞: スキーマの接頭辞を入力します。表5-6に示されているユーザー名は、RCUからのスキーマ作成で、接頭辞にsoahaが使用されていることを想定しています。
「パスワード」と「パスワードの確認」: スキーマにアクセスするときのパスワードを入力します。

GridLinkデータ・ソースの場合は、SCANアドレスをリスナー・アドレス・フィールドに入力し、「ポート」フィールドにSCANポートを入力します。「ONSホスト」と「ポート」の各フィールドに、ONSホストおよびポート情報を入力します。

注意:

WebLogicコンソールでTNSリスナーとONSリスナーの両方にホストおよびポートを指定するには、SCANアドレスを使用することをお薦めします。Oracle RACノードを追加または削除する場合、SCANアドレスを含むGridLinkデータ・ソースを更新する必要はありません。ご使用の環境に対して適切に構成されたSCAN URLについては、ネットワーク管理者に問い合せてください。『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのSCANアドレスに関する説明を参照してください。

マルチ・データ・ソースの場合は、「追加」をクリックします。Oracle RACインスタンスの詳細を入力します。

一度に1つのデータ・ソースを選択し、適切な詳細を追加することにより、各スキーマを更新します。

すべてのスキーマ(SOAインフラストラクチャ、ユーザー・メッセージング・サービス、OWSM MDSスキーマおよびSOA MDSスキーマ)に情報が入力されていることを確認します。
「次へ」をクリックします。

「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が成功したことを確認します。正常に接続できない場合は、「前へ」をクリックしてエントリを修正します。

すべての接続が正常になったら「次へ」をクリックします。
「オプションの構成を選択」画面で、次を選択します。
- 管理サーバー
- JMS分散宛先
- 管理対象サーバー、クラスタ、およびマシン
「管理サーバーの構成」画面で、次の値を入力します。
- 名前: AdminServer
- リスニング・アドレス: VIP0仮想IPのホスト名を入力します。
- リスニング・ポート: 7001
- SSLリスニング・ポート: N/A
- SSL有効: 選択を解除
「次へ」をクリックします。
UDD設定で、UMSJMSSystemResource、SOAJMSModuleおよびBPMJMSModuleのUDDが設定されていることを確認します。

「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。

表5-7 管理対象サーバーの構成

名前	リスニング・アドレス	リスニング・ポート	SSLリスニング・ポート	SSL有効
WLS_SOA1	SOAHOST1VHN1	8001	n/a	いいえ
WLS_SOA2	SOAHOST2VHN1	8001	n/a	いいえ

表示されるどのサーバーも削除しないでください。サーバーは変更できます。サーバーを削除して新しいサーバーを追加すると、ターゲット指定が失敗します。

注意:

標準の推奨事項は、個々のWebLogic管理対象サーバー内でカスタム・アプリケーションおよび他のシステムを実行するためのものです。図5-41で説明しているカスタムWLS管理対象サーバーの作成については、ここでは取り上げません。

「次へ」をクリックします。

「クラスタの構成」画面で、次のクラスタを追加します。
- 名前: SOA_Cluster
- クラスタ・メッセージング・モード: unicast
- マルチキャスト・アドレス: N/A
- マルチキャスト・ポート: N/A
- クラスタ・アドレス: 空白のまま
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、SOA_Clusterに次のサーバーを割り当てます。
- WLS_SOA1
- WLS_SOA2
「次へ」をクリックします。
「マシンの構成」画面で、次の操作を行います。
- デフォルトとして表示される「LocalMachine」を削除します。
- 「UNIXマシン」タブをクリックし、次のマシンを追加します。
表5-8 マシンの構成

名前ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1のホスト名

SOAHOST2

SOAHOST2のホスト名

その他すべてのフィールドをデフォルト値のままにして、「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。

図5-44 「サーバーのマシンへの割当」画面

「図5-44 「サーバーのマシンへの割当」画面」の説明
- SOAHOST1: AdminServer、WLS_SOA1
- SOAHOST2: WLS_SOA2
「次へ」をクリックします。
WebLogicドメインの確認画面で、「次へ」をクリックします。
「構成のサマリー」画面で「作成」をクリックします。
ドメインの作成中画面で「完了」をクリックします。

注意:

マルチキャスト・アドレスとユニキャスト・アドレスは、WebLogic Serverクラスタでクラスタ通信に使用されるものとは異なります。SOAでは、2つのエンティティ(WebLogic Serverクラスタと、コンポジットがデプロイされるグループ)の通信プロトコルが異なっていても、コンポジットが単一のWebLogic Serverクラスタのメンバーにデプロイされることが保証されています。

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

この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。SOAHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。

管理サーバーに対しては、次の手順を実行します。

次のディレクトリを作成します。

SOAHOST1> mkdir -p ORACLE_BASE/product/fmw/user_
projects/domains/soadomain/servers/AdminServer/security

テキスト・エディタを使用して、前の手順で作成したセキュリティ・ディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

username=adminuser
password=password

注意:

管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

5.13.6 SOAHOST1での管理サーバーの起動と検証

この項では、SOAHOST1で管理サーバーを起動および検証する手順について説明します。

5.13.6.1 SOAHOST1での管理サーバーの起動

SOAHOST1上の管理サーバーを起動するには、次のコマンドを実行します。

SOAHOST1> cd MW_HOME/user_projects/domains/soadomain/bin

SOAHOST1> ./startWebLogic.sh

5.13.6.2 管理サーバーの検証

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

ブラウザでhttp://vip0:7001/consoleにアクセスします。
管理者としてログインします。
管理対象サーバーとしてWLS_SOA1およびWLS_SOA2が表示されていることを確認します。
SOA_Clusterクラスタが表示されていることを確認します。
Enterprise Manager(http://vip0:7001/em)にアクセスできることを確認します。

5.13.7 管理サーバーおよびWLS_SOAn管理対象サーバーに対するホスト名の検証の無効化

この手順が必要になるのは、管理サーバーとノード・マネージャの間にホスト名を検証するための適切な証明書を設定していない場合です。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。

ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定したら、再度有効化できます。

ホスト名の検証を無効化するには、次の手順を実行します。

管理コンソールで、「サーバー」→「AdminServer」を選択します。
「SSL」→「詳細」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ホスト名の検証」を「なし」に設定します。
変更を保存およびアクティブ化します。
WLS_SOA1およびWLS_SOA2サーバーに対してこの手順を繰り返します。
管理サーバーを再起動します。

5.13.8 コンポジットのデプロイでのOracle Coherenceの構成

コンポジットのデプロイではデフォルトでマルチキャスト通信を使用しますが、SOAの高可用性を実現するためにはユニキャスト通信を使用することをお薦めします。セキュリティ上の理由からマルチキャスト通信を無効化した場合には、ユニキャスト通信を使用します。

注意:

デプロイメントに使用されるOracle Coherenceフレームワークの構成が不適切な場合、SOAシステムは起動できません。SOAシステムが実行されるネットワーク環境に応じてデプロイメント・フレームワークを適切にカスタマイズする必要があります。この項でこれらから説明する構成をお薦めします。

ユニキャスト通信を使用したクラスタ内通信の有効化

マルチキャスト通信を使用すると、クラスタの中でコンポジットの動的なデプロイメント先となるすべてのメンバーをOracle SOA Suiteで検出できます。しかし、ユニキャスト通信では、ノードはこのように他のクラスタ・メンバーを検出することはできません。そのため、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加された新しいノードが既存ノードの1つを検出するために必要なノードを指定するだけで済みます。これによって、新しいノードがクラスタに追加されたときに、クラスタ内の他のすべてのノードを検出できるようになります。さらに、同じノードで複数のIPを使用可能な構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。

ヒント:

SOAコンポジットのデプロイメント時の高可用性を保証するためには、十分なノードを指定して、いつでも最低1つのコンポジットが実行されているようにします。

tangosol.coherence.wka<n>システム・プロパティを使用してノードを指定します。<n>は、1から9の数字です。最大9つのノードを指定できます。番号は、1から開始します。連続した番号を指定する必要があり、途切れていてはなりません。また、Oracle Coherenceがtangosol.coherence.localhostシステム・プロパティを使用してクラスタを作成するときに使用するホスト名を指定します。このホスト名は、対応するリスナー・アドレス(VIP1およびVIP2)をマップするSOAサーバーによって使用される仮想ホスト名である必要があります。このプロパティは、管理コンソールの「サーバーの起動」タブ(図5-45)の「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加して設定します。

図5-45 管理コンソールの「サーバーの起動」タブを使用したホスト名の設定

「図5-45 管理コンソールの「サーバーの起動」タブを使用したホスト名の設定」の説明

ホスト名の指定

Oracle Coherenceで使用するホスト名を追加する手順は次のとおりです。

管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの設定ページが表示されます。
「サーバーの起動」タブをクリックします(図5-45を参照)。

「引数」フィールドで、WLS_SOA1とWLS_SOA2について次のように入力します。

WLS_SOA1について、改行を入れず、1行で次のように入力します。

-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost1vhn1

WLS_SOA2について、改行を入れず、1行で次のように入力します。

-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost2vhn1

注意:

デプロイメントに使用されるCoherenceクラスタは、デフォルトでポート8088を使用します。このポートは、起動パラメータ-Dtangosol.coherence.wkan.portおよび-Dtangosol.coherence.localportで別なポート(8089など)を指定することで変更できます。例:

WLS_SOA1(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=soahost1vhn1
-Dtangosol.coherence.wka2=soahost2vhn1
-Dtangosol.coherence.localhost=soahost1vhn1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

WLS_SOA2(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=soahost1vhn1
-Dtangosol.coherence.wka2=soahost2vhn1
-Dtangosol.coherence.localhost=soahost2vhn1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

「保存」をクリックして、変更をアクティブ化します。
この変更を適用するには、SOAサーバーを再起動する必要があります。

注意:

前述のテキストを管理コンソールの引数テキスト・フィールドにコピーしないでください。コピーすると、HTMLタグがJava引数に挿入されることがあります。テキストには、前述のもの以外のテキストや文字を含めることはできません。

5.13.9 SOAHOST1でのシステムの起動

この項では、SOAHOST1でノード・マネージャを起動する方法、およびSOAHOST1で管理対象サーバーWLS_SOA1を起動して検証する方法について説明します。

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

SOAHOST1でノード・マネージャを起動する手順は次のとおりです。

ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。
```
SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
SOAHOST1> ./setNMProps.sh
```
注意:

クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。

ノード・マネージャを起動します。

SOAHOST1> cd WL_HOME/server/bin
SOAHOST1> ./startNodeManager.sh

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

WLS_SOA1管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認するには:

管理コンソールを使用してWLS_SOA1管理対象サーバーを起動します。
WLS_SOA1が起動すると、次のURLが使用できるようになります。
- http://SOAHOST1VHN1:8001/b2bconsole
  - B2Bコンソールへのログインを確認します。
- http://SOAHOST1VHN1:8001/integration/worklistapp
  - ワークリスト・コンソールへのログインを確認します。
- http://SOAHOST1VHN1:8001/wsm-pm
  - ポリシー・バリデータ・リンクを確認します。
- http://SOAHOST1VHN1:8001/soa/composer
- http://SOAHOST1VHN1:8001/soa-infra
- http://SOAHOST1VHN1:8001/bpm/composer(BPMシステムの場合のみ)
- http://SOAHOST1VHN1:8001/bpm/workspace(BPMシステムの場合のみ)

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

次の手順に従い、pack/unpackユーティリティを使用してドメイン構成をSOAHOST2に伝播します。

次のpackコマンドをSOAHOST1で実行し、テンプレート・パックを作成します。

SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
SOAHOST1> ./pack.sh -managed=true
-domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/
-template=soadomaintemplate.jar 
-template_name=soa_domain_template

次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをSOAHOST2にコピーします
```
SOAHOST1> scp soadomaintemplate.jar
 oracle@node2:ORACLE_COMMON_HOME/common/bin
```

unpackコマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。

SOAHOST2> cd ORACLE_COMMON_HOME/common/bin
SOAHOST2> ./unpack.sh
 -domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/
 -template=soadomaintemplate.jar

注意:

pack/unpackプロシージャを実行した後でFusion Middleware構成ウィザードを実行するときには、元のドメインにすでに存在し、「拡張ソースの選択」画面に表示される製品は、選択されていず、グレー表示されています。

packコマンドで作成されたテンプレートは、ユーザー作成テンプレートと見なされます。このようなテンプレートは、デフォルト・テンプレートとは別のものとして扱われます。ユーザー作成テンプレートは自己完結型で、元のドメインの作成に関連する情報は一切含んでいません。

5.13.11 第2ノードのXEngineファイルの抽出

B2BのXEngineを第2ノードで有効にするには、次のようにZEngine tarのコンテンツを手動で抽出する必要があります。

SOAHOST2>cd ORACLE_HOME/soa/thirdparty/edifecs
SOAHOST2>tar xzvf XEngine.tar.gz

5.13.12 SOAHOST2でのシステムの起動

この項では、SOAHOST2でシステムを起動する手順について説明します。

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

SOAHOST2でノード・マネージャを起動するには、第5.13.9.1項「SOAHOST1でのノード・マネージャの起動」の手順をSOAHOST2で繰り返します。

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

管理対象サーバーWLS_SOA2を起動して、正しく構成されていることをチェックする手順は、次のとおりです。

管理コンソールを使用してWLS_SOA2管理対象サーバーを起動します。
WLS_SOA2が起動すると、次のURLが使用できるようになります。
- http://SOAHOST2VHN1:8001/b2bconsole
  
  B2Bコンソールへのログインを確認します。
- http://SOAHOST2VHN1:8001/integration/worklistapp
  
  ワークリスト・コンソールへのログインを確認します。
- http://SOAHOST2VHN1:8001/wsm-pm
  
  ポリシー・バリデータ・リンクを確認します。
- http://SOAHOST2VHN1:8001/soa/composer
- http://SOAHOST2VHN1:8001/soa-infra
- http://SOAHOST2VHN1:8001/bpm/composer(BPMシステムの場合のみ)
- http://SOAHOST2VHN1:8001/bpm/workspace(BPMシステムの場合のみ)

5.13.13 管理サーバーおよび管理対象サーバーWLS_SOAnのOracle HTTP Serverの構成

管理対象サーバーWLS_SOAnを含むSOAクラスタへのOracle HTTP Serverのルーティングを有効にするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。

WEBHOST1およびWEBHOST2で、ORACLE_BASE/admin/<instance_name>/config/OHS/<component_name>/mod_wl_ohs.confファイルに次の行を追加します。

# WSM-PM
<Location /wsm-pm>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# SOA soa-infra app
<Location /soa-infra>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# Worklist
<Location /integration/>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# B2B
<Location /b2b>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST11VHN1:8001,SOAHOST2VHN1:8001
</Location>

<Location /b2bconsole>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# UMS
<Location /sdpmessaging/ >
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>
 
# UMS WS
<Location /ucs/messaging/webservice >
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow/>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# Workflow
<Location /workflow>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

#Required if attachments are added for workflow tasks
 <Location /ADFAttachmentHelper> 
    SetHandler weblogic-handler 
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 
 </Location>

# SOA composer application 
 <Location /soa/composer> 
     SetHandler weblogic-handler 
     WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 
 </Location>

# BPM composer (ONLY FOR BPM Systems)
<Location /bpm/composer >
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# BPM workspace (ONLY FOR BPM Systems)
<Location /bpm/workspace >
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

mod_wl_ohs.confファイルと同じディレクトリにあるhttpd.confファイルが次の行を含んでいることを確認します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://soa.mycompany.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>
 
NameVirtualHost *:7777
<VirtualHost *:7777>
    ServerName admin.mycompany.com:80
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit
</VirtualHost>

注意:

このドキュメントに記載されているsoa.mycompany.com:443、7777、admin.mycompany:80、you@youraddressなどの値は、例としてのみ示されています。実際の環境に基づく値を入力してください。

WEBHOST2のOracle HTTP Serverについて同じ手順を実行します。

WEBHOST1とWEBHOST2の両方でOracle HTTP Serverを起動します。

WEBHOST1> ORACLE_BASE/admin/<instance_name>/bin/opmnctl restartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/admin/<instance_name>/bin/opmnctl restartproc ias-component=ohs2

5.13.14 Oracle HTTP Serverを使用したアクセスの検証

管理コンソールでSOAサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中」と表示される場合は、サーバーの状態が「起動済」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。次のURLにアクセスできることを確認します。

http://WEBHOST1:7777/wsm-pm
http://WEBHOST2:7777/wsm-pm
http://WEBHOST1:7777/soa-infra
http://WEBHOST2:7777/soa-infra
http://WEBHOST1:7777/soa/composer
http://WEBHOST2:7777/soa/composer
http://WEBHOST1:7777/integration/worklistapp
http://WEBHOST2:7777/integration/worklistapp
http://WEBHOST1:7777/sdpmessaging/userprefs-ui
http://WEBHOST2:7777/sdpmessaging/userprefs-ui
http://WEBHOST1:7777/b2bconsole
http://WEBHOST2:7777/b2bconsole
http://WEBHOST1:7777/bpm/composer(BPMシステムの場合のみ)
http://WEBHOST2:7777/bpm/composer(BPMシステムの場合のみ)
http://WEBHOST1:7777/bpm/workspace(BPMシステムの場合のみ)
http://WEBHOST2:7777/bpm/workspace(BPMシステムの場合のみ)

次のURLがロード・バランシング・ルーター・アドレスを使用していることも確認します。

http://soa.mycompany.com:80/wsm-pm
http://soa.mycompany.com:80/soa-infra
http://soa.mycompany.com:80/soa/composer
http://soa.mycompany.com:80/integration/worklistapp
http://soa.mycompany.com:80/sdpmessaging/userprefs-ui
http://soa.mycompany.com:80/b2bconsole
http://soa.mycompany.com:80/bpm/composer(BPMシステムの場合のみ)
http://soa.mycompany.com:80/bpm/workspace(BPMシステムの場合のみ)

次の手順に従って、HTTP ServerからSOA_CLusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。

WLS_SOA2の実行中に、管理コンソールからWLS_SOA1を停止します。
次のURLにアクセスして、適切な機能を検証します。
- WEBHOST1:7777/wsm-pm
- WEBHOST1:7777/soa-infra
- WEBHOST1:7777/soa/composer
- WEBHOST1:7777/integration/worklistapp
- WEBHOST1:7777/sdpmessaging/userprefs-ui
- WEBHOST1:7777/b2bconsole
- WEBHOST1:7777/bpm/composer(BPMシステムの場合のみ)
- WEBHOST1:7777/bpm/workspace(BPMシステムの場合のみ)
管理コンソールから、WLS_SOA1を開始します。
WLS_SOA2を停止します。
前述のステップ2のURLにアクセスして、適切な機能を検証します。

5.13.15 サーバー間で共有するJMS永続ストアの構成

2つのノードから参照できるディレクトリに、すべての永続ストアの場所を構成します。そして、この共有のベース・ディレクトリを使用するように、すべての永続ストアを変更します。

Fusion Middleware管理コンソールで、「サービス」、永続ストア、「Persistence_Store_Name」、「ディレクトリ」の順に選択します。

保留されているJMSメッセージを再開できるようにするには、クラスタ内の他のサーバーで使用可能な永続記憶域ソリューション(NAS、SAN)上の場所を指定する必要があります。したがって、入力するディレクトリは、WLS_SOA1とWLS_SOA2の両方からアクセスできる必要があります。このディレクトリは、サーバーが再起動される前に存在している必要があります。

注意:

JMSメッセージ、トランザクション・ログおよびファイル・ストアでのロックの解放の詳細は、「NFSでのファイル・ストアの使用に関する考慮事項」を参照してください。

5.13.16 トランザクション・リカバリのためのデフォルトの永続ストアの構成

各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでトランザクション・ログを使用します。クラスタ内のサーバーに対してトランザクション回復サービスの移行機能を利用するためには、サーバーとそのバックアップ・サーバーで利用可能な場所、可能であればデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)にトランザクション・ログを格納する必要があります。デフォルトの永続ストアを構成する手順は、次のとおりです。

「ドメイン構造」ツリーで、「環境」を開き、「サーバー」を選択します。
変更するサーバーを選択します。
「構成」、「サービス」タブの順に選択します。
「デフォルト・ストア」の「ディレクトリ」フィールドに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。

トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定する必要があります。したがって、入力するディレクトリは、WLS_SOA1とWLS_SOA2の両方からアクセスできる必要があります。このディレクトリは、サーバーが再起動される前に存在している必要があります。

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

Oracle WebLogic Serverクラスタに対してフロントエンドHTTPのホストとポートを設定する必要があります。

管理コンソールの「チェンジ・センター」セクションで、「ロックして編集」をクリックします。
左側のペインで、「環境」→「クラスタ」を選択します。
「SOA_Cluster」を選択します。
「HTTP」を選択します。

次の値を設定します。

フロントエンド・ホスト: soa.mycompany.com

フロントエンドHTTPポート: 80
フロントエンドHTTPSポート: 空白のまま

注意:

このアドレスが正しく、使用可能である(ロード・バランシング・ルーターが稼働している)ことを確認してください。アドレスのhttp://やホスト名の末尾/など、値が誤っていると、仮想IPを使用してもSOAシステムにアクセスできません。

「保存」をクリックします。
変更をアクティブにするには、管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。

すでにサーバーを起動している場合、この変更にはクラスタの管理対象サーバーの再起動が必要であることに注意してください。

注意:

SOAシステムでは、次のようにコールバック・サーバーURLを計算します。

SOAへのリクエストが外部サービスから発行されたものであったり、内部サービスがSOAにリクエストを発行したりした場合、SOAは、クライアントによって指定されているコールバック・サーバーURLを使用します。
外部または内部サービスへのリクエストがSOAから発行されている場合は、SOAが発行元であるため、コールバックURLをSOAリクエストに動的に移入できません。しかし、callbackServerURLが特定参照のバインディング・プロパティに指定されている場合は、callbackServerURLが使用されます。(これは、コンポジットをモデル化するときに設定するか、実行時にOracle Enterprise Managerコンソールからアクセス可能なMBeanを使用して設定できます。)これにより、サービス・コールごとに異なるコールバック・サーバーURLを割り当てることができます。したがって、外部サービスからのコールバック・サーバーURLは、内部サービスへのコールバック・サーバーURLと異なります。

ただし、callbackServer URLがその参照のバインディング・プロパティに指定されていない場合、SOAシステムは、soa-infra-configに指定されているコールバック・サーバーURLを使用します。soa-infra-configにコールバック・サーバーURLが指定されていない場合、システムでは、WLSに指定されているフロントエンド・ホストがコールバック・サーバーURLとして使用されます。WLSにフロントエンド・ホストが指定されていない場合、システムでは、WLS MBean APIで指定されているローカル・ホスト名がコールバック・サーバーURLとして使用されます。

Oracle HTTP Serverによってフロントエンド処理されるSOA高可用性インストールでは、実質的なバックエンド・サーバーのOracle HTTP Serverポートでの監視が必要になります。すなわち、SOA管理対象サーバーにデプロイされたすべてのコンポーネントがデプロイメントで使用される場合です。HTTP/HTTPSポートをpingし、事前に決められた応答が返されることを予期する単純なHTTPモニターであれば十分です。特定のSOAコンポーネント(B2Bなど)のみが使用されている場合は、使用中のコンポーネントの状態を検証するために、管理対象サーバー全体のより深いレベルまでチェックするモニターを使用することも考えられます。お使いのロード・バランサでのHTTPモニターの設定について、ロード・バランサのベンダーにご確認ください。

フロントエンドHTTPのホストとポートを設定しない場合、Oracle B2Bからドキュメント定義XSDを取得しようとすると、次のメッセージを受け取ります。

An error occured while loading the document definitions.
java.lang.IllegalArgumentException: Cluster address must be set when
clustering is enabled.

5.13.18 コンポジットに対する直接バインディング/RMI呼出し用のWLSクラスタ・アドレスの設定

コンポジットへの直接バインディングを使用する場合は、SOA_ClusterのWLSクラスタ・アドレスを設定する必要があります。そのためには、次の手順に従ってください。

管理コンソールの「チェンジ・センター」セクションで、「ロックして編集」をクリックします。
左側のペインで、「ドメイン構造」ウィンドウの「環境」を選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。
「SOA_Cluster」クラスタを選択します。
「構成」→「一般」タブで、「クラスタ・アドレス」フィールドにSOAHOST1VHN1:8001,SOAHOST2VHN1:8001と入力します。
「保存」をクリックします。
変更をアクティブにするには、管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。
サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効化します。

注意:

直接バインディングでの非同期リクエスト/レスポンスの場合、SOAコンポジットでは、コールバックのBeanを検索するために、呼び出されたサービスのJNDIプロバイダURLを指定する必要があります。

soa-infra configプロパティは指定されていないが、WebLogic Serverクラスタ・アドレスは指定されている場合、クラスタ・アドレスを使用してJNDIプロバイダURLが形成されます。このクラスタ・アドレスには、クラスタ化されたサーバーのIPアドレスにマップする単一のDNS名、またはサーバーのip:portのカンマ区切りリストを使用できます。または、soa-infra configプロパティJndiProviderURL/SecureJndiProviderURLがユーザーによって明示的に指定されている場合は、同じ目的でそれを使用することもできます。

5.13.19 アプリケーションのデプロイ

SOAコンポジット・アプリケーションは、Oracle Enterprise Manager Fusion Middleware ControlのSOAコンポジットのデプロイ・ウィザードでデプロイできます。SOAコンポジットのデプロイ・ウィザードで、次のいずれかをデプロイします。

最初の新しいSOAコンポジット・アプリケーション
旧リビジョン(1.0など)と新リビジョン(2.0など)。旧リビジョンへの影響はありません。最後にデプロイされたリビジョンが、そのコンポジットの新しいデフォルト・リビジョンになります(デプロイメントのこの後の手順で他のリビジョンを指定しない場合にかぎります)。
現在デプロイされているもの(1.0など)とは異なるリビジョンをすでに持っているSOAコンポジット・アプリケーションの複数のSOAコンポジット・アプリケーション・リビジョン(リビジョン2.0、3.0、4.0など)が含まれているバンドル(ZIPファイル)。このオプションを使用すると、リビジョン1.0、2.0、3.0および4.0を同時にデプロイできます。バンドルには様々なコンポジットのリビジョンを含めることもできます。すべてのリビジョンが同一のコンポジット・アプリケーションのリビジョンでなければならないという制約はありません。

デプロイメントでは、SOAインフラストラクチャのコンポジット・アプリケーションを抽出し、アクティブ化します。アプリケーションがデプロイされると、インスタンスの作成、プロパティの構成、パフォーマンスの監視、インスタンスのライフサイクルの管理、ポリシーとフォルトの管理などの管理タスクを実行できます。

注意:

アプリケーションの既存のリビジョンを再デプロイする場合は、このウィザードを使用しないでください。かわりに、SOAコンポジットの再デプロイ・ウィザードを使用してください。

アプリケーションをデプロイする手順は、次のとおりです。

次のいずれかのオプションを使用して、SOAコンポジットのデプロイ・ウィザードにアクセスします。

SOAインフラストラクチャのメニュー	ナビゲータのSOAフォルダ	SOAインフラストラクチャのホーム・ページ	SOAコンポジットのメニュー
「SOAデプロイ」→「デプロイ」を選択します。	「soa-infra」を右クリックします。「SOAデプロイ」→「デプロイ」を選択します。	「デプロイ済コンポジット」タブをクリックします。「コンポジット」表の上にある「デプロイ」をクリックします。	「SOAデプロイ」→「別のコンポジットをデプロイ」を選択します。

「アーカイブの選択」ページが表示されます。

図sca_deploy.gifの説明

「アーカイブまたは展開済ディレクトリ」セクションで、デプロイするSOAコンポジット・アプリケーションのアーカイブを指定します。アーカイブには、デプロイするコンポジットのプロジェクト・ファイルが格納されています(たとえば、単一アーカイブのHelloWorld_rev1.0.jar、または複数アーカイブのOrderBooking_rev1.0.zip)。
「構成プラン」セクションで、アーカイブに含める構成プランのオプションを指定します。構成プランには、異なる環境で使用するURLとプロパティ値を定義できます。構成プランは、プロセスのデプロイメント時に、プロジェクトを別のターゲット環境に適合させるために置換する必要のある値に関するSOAプロジェクトを検索する際に使用されます。
「次へ」をクリックします。

「ターゲットの選択」ページが表示されます。
SOAコンポジット・アプリケーション・アーカイブのデプロイ先WebLogic Serverまたはクラスタを選択します。アーカイブは、複数のサーバーおよびクラスタにデプロイできます。
「次」をクリックします。
SOAコンポジット・アプリケーションをデフォルトのリビジョンとしてデプロイするかどうかを選択します。デフォルトのリビジョンは、新しいリクエストを受信するとインスタンス化されます。
「デプロイ」をクリックします。
デプロイメントが完了したら、「閉じる」をクリックします。

5.13.20 WLS_SOAサーバーのサーバー移行の構成

SOAシステムの高可用性アーキテクチャでは、一部のシングルトン・サービスを障害から保護するためにサーバー移行を利用します。サーバー全体の移行の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

WLS_SOA1管理対象サーバーは、障害発生時にSOAHOST2で再起動するように構成され、WLS_SOA2管理対象サーバーは、障害発生時にSOAHOST1で再起動するように構成されます。このような構成では、WLS_SOA1サーバーおよびWLS_SOA2サーバーは、WLSサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。

サーバー移行によって、サーバーまたはプロセスの障害時に、管理対象サーバーが別のノードにフェイルオーバーするよう設定する手順は、次のとおりです。

WebLogic管理対象サーバーのサーバー移行を構成する手順は、次のとおりです。

ステップ1: サーバー移行leasing表のユーザーと表領域を設定する
ステップ2: Oracle WebLogic管理コンソールを使用してGridLinkデータ・ソースまたはマルチ・データ・ソースを作成する
ステップ3: ノード・マネージャのプロパティ・ファイルを編集する
ステップ4: wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する
ステップ5: サーバー移行ターゲットを構成する
ステップ6: サーバー移行をテストする

5.13.20.1 サーバー移行leasing表のユーザーと表領域の設定

最初の手順では、サーバー移行leasing表のユーザーと表領域を設定します。

注意:

同じドメイン内の他のサーバーがすでにサーバー移行で構成されている場合、同じ表領域とデータ・ソースを使用できます。この場合、データベース・リース用にデータ・ソースおよびマルチ・データ・ソースを再作成する必要はありませんが、これらをサーバー移行用に構成しているクラスタにターゲット指定しなおす必要があります。

leasingという名前の表領域を作成します。たとえば、ユーザーsysdbaでSQL*Plusにログインし、次のコマンドを実行します。
```
SQL> create tablespace leasing logging datafile 'DB_HOME/oradata/orcl/leasing.dbf' size 32m autoextend on next 32m maxsize 2048m extent management local;
```

leasingという名前のユーザーを作成し、leasing表領域に割り当てます。

SQL> create user leasing identified by welcome1;
SQL> grant create table to leasing;
SQL> grant create session to leasing;
SQL> alter user leasing default tablespace leasing;
SQL> alter user leasing quota unlimited on LEASING;

leasing.ddlスクリプトを使用してleasing表を作成します。
1. WL_HOME/server/db/oracle/817ディレクトリまたはWL_HOME/server/db/oracle/920ディレクトリのleasing.ddlファイルを自身のデータベース・ノードにコピーします。
2. データベースにleasingユーザーとして接続します。
3. SQL*Plusでleasing.ddlスクリプトを実行します。
```
SQL> @Copy_Location/leasing.ddl;
```

5.13.20.2 Oracle WebLogic管理コンソールを使用したGridLinkデータ・ソースまたはマルチ・データ・ソースの作成

マルチ・データ・ソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバルleasingマルチ・データ・ソースの両方について作成します。データ・ソースを作成するときには、次の点に留意してください。

このデータ・ソースが非XAデータ・ソースであることを確認します。
Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。
したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。データ・ソースは、グローバル・トランザクションのサポートを必要としません。
これらのデータ・ソースをクラスタにターゲット指定します。
データ・ソースの接続プールの初期容量が0(ゼロ)に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データソース名」、「接続プール」タブの順にクリックし、「初期容量」フィールドに0(ゼロ)を入力します。
ONSデーモンがデータベース・サーバーで常に実行中であることを確認します。ONSデーモンをデータベース・サーバーで起動するには、onsctlコマンド(start)を実行します。

GridLinkデータソースの作成

GridLinkデータ・ソースを作成する手順は次のとおりです。

管理コンソールにログインします。
まだ行っていない場合は、管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
「データ・ソースの概要」ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択します。
次の情報を入力します。
1. 「名前」フィールドで、データ・ソースの論理名を入力します。たとえば、gridlinkと入力します。
2. JNDIの名前を入力します。たとえば、jdbc/gridlinkと入力します。
3. 「次へ」をクリックします。
「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」を選択解除して「次へ」をクリックします。
「個別のリスナー情報の入力」を選択して、「次へ」をクリックします。

次の接続プロパティを入力します。

サービス名: データベースのサービス名を入力します。GridLinkデータ・ソースの場合は、RACサービス名を小文字で入力し、その後にドメイン名example.comを入力する必要があります。たとえば、<mydbservice>.example.comと入力します。

注意:

Oracle RACサービス名はデータベースで定義されており、固定名ではありません。データベース・ドメイン名(example.comなど)を含むRACサービス名を登録または追加することをお薦めします。

ホスト名: データベースをホストするサーバーのDNS名またはIPアドレス。Oracle GridLinkサービスとインスタンス間の接続の場合、特定のマルチ・データ・ソースの各データ・ソースで同じ名前にする必要があります。
Port: データベース・サーバーが接続リクエストをリスニングするポート。
データベース・ユーザー名: データベース・ユーザー名。たとえば、myDataBaseと入力します。
パスワード: パスワード。たとえば、myPassword1と入力します。
パスワードを確認して、「次へ」をクリックします。

ヒント:

詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。

コンソールにより、完全なJDBC URLが自動的に生成されます。例:

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=left)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=right)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=center)(PORT=1234)))(CONNECT_DATA=(SERVICE_NAME=myService)))

「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。

Oracle WebLogicにより、管理サーバーからデータベースへの接続の作成が試行されます。接続テストの結果がページの上部に表示されます。テストに失敗した場合は、構成エラーをすべて修正してテストを再試行します。

「次へ」をクリックします。
「ONSクライアント構成」ページで、次の手順を実行します。
- 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。
- 「ONSホストとポート」で、ONSベースのFANイベントを受け取るためにONSデーモンが接続するリスニング・アドレスとリスニング・ポートのカンマ区切りのリストを入力します。単一クライアント・アクセス名(SCAN)アドレスを使用すると、FAN通知にアクセスできます。
- 「次へ」をクリックします。
「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。「次」をクリックします。
「ターゲットの選択」ページで「Dept1_Cluster1」をターゲットとして選択し、「クラスタのすべてのサーバー」を選択します。
「終了」をクリックします。
「変更のアクティブ化」をクリックします。

マルチ・データ・ソースの作成

マルチ・データ・ソースを作成する手順は、次のとおりです。

管理者の資格証明を使用して、管理コンソールにログインします。
「ドメイン構造」ウィンドウで「サービス」ノードを開き、次に、「データ・ソース」ノードを開きます。
「チェンジ・センター」で「ロックして編集」をクリックします。
「新規」をクリックしてから、「マルチ・データ・ソース」をクリックします。
名前として、leasingと入力します。
JNDI名として、jdbc/leasingと入力します。
アルゴリズムとして、「フェイルオーバー」(デフォルト)を選択します。「次へ」をクリックします。
ターゲット・クラスタを選択します。「次へ」をクリックします。
「非XAドライバ」(デフォルト)を選択します。「次へ」をクリックします。
「新しいデータ・ソースの作成」をクリックします。
名前として、leasing-rac0と入力します。JNDI名として、jdbc/leasing-rac0と入力します。データベースのタイプとして、oracleと入力します。ドライバのタイプとして、「Oracle Driver (Thin) for RAC server-Instance connection Version 10,11」を選択します。

注意:

leasing表のマルチ・データ・ソースを作成する場合は、名前を<MultiDS>-rac0や<MultiDS>-rac1などの形式で入力します。
「次へ」をクリックします。
「グローバル・トランザクションのサポート」の選択を解除します。「次へ」をクリックします。
leasingスキーマのサービス名、データベース名(racdb1やracdb2などのRACノードのインスタンス名)、ホスト・ポートおよびパスワードを入力します。「次へ」をクリックします。
「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。「次へ」をクリックします。
データ・ソースをクラスタにターゲット指定します。
データ・ソースを選択して、右の画面に追加します。
Oracle RACデータベースの2番目のインスタンスについて「新しいデータ・ソースの作成」をクリックして、そのターゲットをクラスタに設定してから、Oracle RACデータベースの2番目のインスタンスについても同じ手順を繰り返します。
2つ目のデータ・ソースをマルチ・データ・ソースに追加します。
保存して、「変更のアクティブ化」をクリックします。

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

nodemanager.propertiesファイルを編集して、サーバー移行を構成するノードごとに次のプロパティを追加する必要があります。

Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true

Interface: 浮動IPのインタフェース名(eth0など)を指定します。

注意:

サブ・インタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0または:1なしに使用されます。ノード・マネージャのスクリプトは、:Xに対応した各種のIPを横断して、どれを追加または削除するかを判定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

注意:

Windowsの場合、Interfaceには、ネットワーク・インタフェース名を設定する必要があります。例: Interface="Local Area Connection"

NetMask: 浮動IPのインタフェースのネット・マスクを指定します。ネット・マスクは、インタフェース上のネット・マスクと同じである必要があります(255.255.255.0は一例です)。実際の値は、ネットワークにより異なります。
UseMACBroadcast: ARPパケットの送信時にノードのMACアドレスを使用するかどうか、つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。

これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力(ノード・マネージャが起動されているシェル)で確認します。ノード・マネージャの出力で、次のようなエントリが表示されることを確認します。

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

注意:

サーバーのプロパティ(起動プロパティ)が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合、次の手順は必要ありません。

nodemanager.propertiesファイルで次のプロパティを設定します。
- StartScriptEnabled: このプロパティをtrueに設定して、ノード・マネージャが管理対象サーバーで起動するようにします。
WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行して、OIMHOST1とOIMHOST2でノード・マネージャを起動します。

注意:

共有記憶域のインストールからノード・マネージャを実行している場合、同じnodemanager.propertiesファイルを使用する複数のノードが起動します。ただし、ノードごとに異なるNetMaskプロパティまたはInterfaceプロパティが必要な場合があります。この場合、環境変数を使用して、ノードごとに個々のパラメータを指定します。たとえば、HOSTnで異なるインタフェース(eth3)を使用するには、Interface環境変数をHOSTn> export JAVA_OPTIONS=-DInterface=eth3のように使用して、この変数がシェル内で設定された後にノード・マネージャを起動します。

5.13.20.4 wlsifconfig.shスクリプトの環境権限とスーパーユーザー権限の設定

wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する手順は次のとおりです。

注意:

Windowsでは、このスクリプトはwlsifconfig.cmdであり、管理者権限を持つユーザーがこれを実行できます。

PATH環境変数に次のファイルが含まれていることを確認します。

表5-9 PATH環境変数に必要なファイル

ファイル格納されているディレクトリ

wlsifconfig.sh

DOMAIN_HOME/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domains

WL_HOME/common
wlsifconfig.shスクリプトに対するsudo構成権限を付与します。
- パスワード・プロンプトを使用しないで機能するsudoを構成します。
- セキュリティ上の理由から、wlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定することをお薦めします。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。
- WebLogicユーザー(oracle)に、パスワードによる制限なしのsudo権限を付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。
- WebLogicユーザーがこのスクリプトを実行できることを確認します。次の例は、oracleのsudo実行権限をifconfigとarpingにも付与する/etc/sudoers内のエントリを示しています。
```
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
```
注意:

この手順で使用できるsudoとシステム権限はシステム管理者にお問い合せください。

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

まず、クラスタのメンバーに対して使用可能なすべてのノードを割り当て、サーバー移行で構成される各サーバー用の候補サーバーを(適切な順に)指定します。クラスタ内の移行でクラスタ移行を構成する手順は次のとおりです。

管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。
「名前」列で、移行を構成するクラスタをクリックします。
「移行」タブをクリックします。「ロックして編集」をクリックします。
「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。
「保存」をクリックします。「変更のアクティブ化」をクリックします。

サーバー移行の候補マシンを設定します。このタスクは、次の手順に従って、すべての管理対象サーバーについて実行する必要があります。

管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。

ヒント:

「サーバーのサマリー」ページの「この表のカスタマイズ」をクリックして、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動し、サーバーが実行されているマシンを表示します。サーバーが自動的に移行される場合、これは実際の構成とは異なります。

移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックしてから、「変更のアクティブ化」をクリックします。
追加の管理対象サーバーに対して、前述の手順を繰り返します。
管理サーバー、ノード・マネージャ、サーバー移行が構成されたサーバーを再起動します。

5.13.20.6 サーバー移行のテスト

サーバー移行が適切に機能していることを確認する手順は次のとおりです。

SOAHOST1から次の処理を実行します。

WLS_SOA1管理対象サーバーを強制停止します。

これを行うには、このコマンドを実行します:

SOAHOST1> kill -9 <pid>

pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。

SOAHOST1> ps -ef | grep WLS_SOA1

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了できます。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_SOA1のpidを確認します。

MW_HOME\jrockit_160_<version>\bin\jps -l -v

ノード・マネージャ・コンソールを確認します。WLS_SOA1の浮動IPが無効になっていることを示すメッセージが表示されています。
ノード・マネージャがWLS_SOA1の2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

SOAHOST2から次の処理を実行します。

ローカルのノード・マネージャのコンソールを確認します。ノード1で最後にWLS_SOA1の再起動が試行されてから30秒経過した後、ノード2のノード・マネージャによって、WLS_SOA1の浮動IPが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。
同じIPのSOAサービス・インフラストラクチャ・コンソールにアクセスします。

管理コンソールで移行を検証する手順は、次のとおりです。

管理コンソールにログインします。
左側のペインで、「ドメイン」をクリックします。
「監視」タブ、「移行」サブタブの順にクリックします。

「移行ステータス」表に、移行の状態に関する情報が表示されます。

図5-46 管理コンソールの「移行の状態」画面

「図5-46 管理コンソールの「移行の状態」画面」の説明

注意:

Windowsでは、同一マシン上で複数のサーバーを同時に手動で停止し、次に、別のマシンで停止したサーバーの1つを起動しようとしても、IPバインドは機能しません。これは、IPアドレスが削除されていることがnetshによってレポートされても、元のマシンでそのIPアドレスに対する要求が引き続き保持されているために起こります。

これを解決するには、ipconfigユーティリティまたはWindowsネットワーク構成を使用して、ネットワーク構成をチェックする必要があります。どちらを使用した場合も、仮想IPアドレスまたは浮動IPアドレスのいずれかが、サーバーが停止後も引き続き構成されていることが示されます。その場合は、次の手順に従い、Windowsネットワーク構成を使用して、IPアドレスを削除できます。

Windowsのコントロール・パネルで、「ネットワーク接続」を選択します。
該当のネットワーク・インタフェースを選択して右クリックし、「プロパティ」を選択します。
「インターネットプロトコル (TCP/IP)」を選択して「プロパティ」ボタンをクリックします。
「詳細設定」を選択します。
該当のIPアドレスを選択して、「削除」ボタンをクリックします。

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

5.13.21 トポロジのスケーリング

この高可用性トポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。

5.13.21.1 トポロジのスケール・アップ(既存のノードへの管理対象サーバーの追加)

この場合は、SOAコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードには、既存の管理対象サーバーのMiddlewareホーム、Oracleホーム(SOA)およびドメイン・ディレクトリが含まれます。

新しいWLS_SOAサーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用します(新しい場所にSOAバイナリをインストールしたり、packとunpackを実行したりしないでください)。

トポロジをスケール・アップするには:

管理コンソールを使用し、WLS_SOA1のクローンを作成して新しい管理対象サーバーにします。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。

管理対象サーバーのクローンを作成する手順は次のとおりです。
1. 管理コンソールから「環境」→「サーバー」を選択します。
2. クローンを作成する管理対象サーバー(WLS_SOA1など)を選択します。
3. 「クローンの作成」を選択します。
新しい管理対象サーバーにWLS_SOAnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。

この後の手順では、すでにWLS_SOA1を実行しているSOAHOST1に新しいサーバーを追加することを想定しています。
リスニング・アドレスに対して、この新しい管理対象サーバーに使用する仮想ホスト名を割り当てます。このサーバーに対して推奨されている、サーバー移行の使用を計画している場合は、この仮想ホスト名により別のノードに移動できます。仮想ホスト名は、すでに実行されている管理対象サーバーで使用されているものとは別のものである必要があります。

管理対象サーバーのリスニング・アドレスを設定する手順は次のとおりです。
1. 管理コンソールにログインします。
2. 「チェンジ・センター」で、「ロックして編集」をクリックします。
3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
4. 「サーバー」をクリックします。
5. 表の「名前」列で、リスニング・アドレスを更新する管理対象サーバーを選択します。
6. 「リスニング・アドレス」をSOAHOST1VHN1に設定します。
7. 「保存」をクリックします。
8. 変更を保存およびアクティブ化します。
この変更は、管理対象サーバーを再起動するまで有効になりません。
クラスタ・アドレスを更新して、新しいサーバーを追加します。
1. 管理コンソールの「ドメイン構造」ウィンドウで「環境」→「クラスタ」を選択します。
2. SOA_Clusterサーバーをクリックします。
3. 「チェンジ・センター」で、「ロックして編集」をクリックします。
4. 新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。例:
```
SOAHOST1VHN1:8001,SOAHOST2VHN1:8001,SOAHOST1VHN2:8001
```

新しい管理対象サーバーにSOA、BPM(該当する場合)およびUMSのJMSサーバーを作成します。

管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_Nのような名前を付けます。このストアのパスを指定します。これには、第5.13.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定する必要があります。

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
```
ORACLE_BASE/admin/DOMAIN_NAME/cluster_name/jms/SOAJMSFileStore_N
```
SOAの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_N)。このJMSサーバーに対して、SOAJMSFileStore_Nを使用します。SOAJMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_n)。このストアのパスを指定します。これには、第5.13.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定する必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_N.

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

UMSの新しいJMSサーバーを作成します(たとえば、UMSJMSServer_N)。このJMSサーバーに対して、UMSJMSFileStore_Nを使用します。UMSJMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

(BPMシステムの場合のみ)新しいBPMJMSServerの新しい永続ストアを作成して(たとえば、BPMJMSFileStore_N)、このストアのパスを指定します。これには、第5.13.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定する必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_N.

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

新しいBPM JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

(BPMシステムの場合のみ)BPMの新しいJMSサーバーを作成します(たとえば、BPMJMSServer_N)このJMSServerにはBPMJMSFileStore_Nを使用します。BPMJMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウで「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列のハイパーリンク)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。SOAJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名はSOAJMSServerXXXXXX形式のランダムな名前で、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)の構成ウィザードJMS構成から生成されます。

サブデプロイメント「SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、SOAJMSServer_Nと呼ばれる、SOAの新しいJMSサーバーを追加します。「保存」をクリックします。

新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。UMSJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたUCMJMSServerXXXXXXという形式のランダム名です。

サブデプロイメント「UMSJMSServerXXXXXX」をクリックします。このサブデプロイメントに、UMSJMSServer_Nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。

(BPMシステムの場合のみ)新たに作成されたBPM JMSサーバーが含まれるように、BPMJMSModuleのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「BPMJMSSystemResource」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。BPMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。BPMJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたBPMJMSServerXXXXXXという形式のランダム名です。

サブデプロイメント「BPMJMSServerXXXXXX」をクリックします。このサブデプロイメントに、BPMJMSServer_Nと呼ばれる、BPMの新しいJMSサーバーを追加します。「保存」をクリックします。

デプロイするコンポジットのOracle Coherenceを構成します。第5.13.8項「コンポジットのデプロイでのOracle Coherenceの構成」を参照してください。

注意:

サーバーに対して変更が必要なのは、ローカル・ホスト・フィールドのみです。ローカル・ホストを、新しく追加されたサーバーのリスニング・アドレスに置き換えます。例:

Dtangosol.coherence.localhost=SOAHOST1VHNn

新しいサーバーに対してTX永続ストアを構成します。これは、共有記憶域についての推奨事項で示されているように、他のノードから参照できる場所に構成します。

管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_SOAn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。

ホスト名の検証を無効化するには、次の手順を実行します。
1. Oracle Enterprise Managerコンソールで、「管理コンソール」を選択します。
2. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
4. 表の「名前」列で「WLS_SOAn」を選択します。サーバーの「設定」ページが表示されます。
5. 「SSL」タブをクリックします。
6. 「詳細」をクリックします。
7. 「ホスト名の検証」を「なし」に設定します。
8. 「保存」をクリックします。
管理コンソールから新しい管理対象サーバーを起動して、テストします。
1. クラスタ内の既存の管理対象サーバーを停止します。
2. 新たに作成した管理対象サーバーWLS_SOAnが起動していることを確認します。
3. 新たに作成した管理対象サーバー上のアプリケーション(http://vip:port/soa-infra)にアクセスします。アプリケーションが機能している必要があります。

新しい管理対象サーバーに対してサーバー移行を構成します。

注意:

これはスケール・アップ操作であるため、ノード・マネージャ、サーバー移行に対して構成された環境および新しいSOA管理対象サーバーの浮動IPがノードに用意されている必要があります。

次の手順を実行してサーバー移行を構成します。

管理コンソールにログインします。
左側のペインで、「環境」を開き、「サーバー」を選択します。
移行を構成する新しい管理対象サーバーの名前を選択します。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。ノードの既存のサーバーと同じ移行ターゲットを選択します。

たとえば、すでにWLS_SOA1が実行されているSOAHOST1上の新しい管理対象サーバーには、SOAHOST2を選択します。すでにWLS_SOA2が実行されているSOAHOST2上の新しい管理対象サーバーには、SOAHOST1を選択します。

移行時に管理対象サーバーを同時に実行できるように、適切なリソースが使用可能になっていることを確認してください。
「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

この新しいサーバーのサーバー移行をテストします。新しいサーバーを追加したノードで次の手順を実行します。

管理対象サーバーWLS_SOAnを停止します。

これを行うには、kill -9 <pid>を管理対象サーバーのPIDに対して実行します。ノードのPIDを調べるには、ps -ef | grep WLS_SOAnを実行します。

注意:

Windowsの場合は、 taskkill コマンドを使用して管理対象サーバーを終了できます。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_SOAnのpidを確認します。

MW_HOME\jrockit_160_<バージョン>\bin\jps -l -v

ノード・マネージャ・コンソールを確認します。WLS_SOAnの浮動IPが無効になっていることを示すメッセージが表示されています。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーがローカルで再起動されないことを示すメッセージが、ノード・マネージャによってログに記録されます。

注意:

5.13.21.2 トポロジのスケール・アウト(新しいノードへの管理対象サーバーの追加)

トポロジのスケール・アウトでは、SOAで構成された新しい管理対象サーバーを新しいノードに追加します。

この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。

SOAで構成された管理対象サーバーを実行しているノードがトポロジ内に存在していること。

新しいノードがWebLogic ServerとSOAの既存のホーム・ディレクトリにアクセスできること。(新しい管理対象サーバーWLS_SOAまたはWLS_WSMを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic ServerやSOAバイナリをインストールする必要はありませんが、packとunpackを実行して、新しいノードでドメイン構成をブートストラップする必要があります。)

注意:

共有記憶域内に既存のインストールが存在しない場合は、新しいノードでWebLogic ServerとSOAをインストールする必要があります。第5.13項「Oracle SOAインフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」を参照してください。

注意:

異なるノードにおいてORACLE_HOMEまたはWL_HOMEが複数のサーバーで共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して、そのノードに共有記憶域内のインストールを追加するには、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、user_home/bea/beahomelistファイルを編集します。次の手順を参照してください。

トポロジをスケール・アウトするには、次の手順を実行します。

新しいノードで、SOAのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。
```
SOAHOSTn>cd ORACLE_BASE/product/fmw/soa/
SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>
```
Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。
Oracle WebLogic管理コンソールにログインします。
新しいノードに使用する新しいマシンを作成し、このマシンをドメインに追加します。
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。
管理コンソールを使用して、WLS_SOA1のクローンを作成して新しい管理対象サーバーにします。これにWLS_SOAnという名前を付けます。nは新しいマシンに割り当てる番号です。

注意:

これらの手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加することを想定しています。
リスニング・アドレスに対して、この新しい管理対象サーバーに使用する仮想ホスト名を割り当てます。このサーバーに対して推奨されている、サーバー移行の使用を計画している場合は、この仮想ホスト名により別のノードに移動できます。仮想ホスト名は、すでに実行されている管理対象サーバーで使用されているものとは別のものである必要があります。

次の手順を実行して、管理対象サーバーのリスニング・アドレスを設定します。
1. 管理コンソールにログインします。
2. 「チェンジ・センター」で、「ロックして編集」をクリックします。
3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
4. 「サーバー」をクリックします。
5. 表の「名前」列で、リスニング・アドレスを更新する管理対象サーバーを選択します。
6. 「リスニング・アドレス」をSOAHOSTnVHN1に設定します。
7. 「保存」をクリックします。
8. 変更を保存およびアクティブ化します。
変更内容は、管理対象サーバーが再起動されるまでは有効になりません。
クラスタ・アドレスを更新して、新しいサーバーを追加します。
1. 管理コンソールで「環境」→「クラスタ」を選択します。
2. SOA_Clusterサーバーをクリックします。SOA_Clusterの「設定」画面が表示されます。
3. 「チェンジ・センター」で、「ロックして編集」をクリックします。
4. 新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。例:
```
SOAHOST1VHN1:8001,SOAHOST2VHN1:8001,SOAHOSTNVHN1:8001
```

新しい管理対象サーバーにSOA、BPM(該当する場合)およびUMSのJMSサーバーを作成します。

管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_Nのような名前を付けます。このストアのパスを指定します。このパスには、第5.13.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定します。
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore _N
```
注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
SOAの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_N)。このJMSサーバーに対して、SOAJMSFileStore_Nを使用します。SOAJMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

新しいUMSJMSServerの新しい永続ストアを作成し、UMSJMSFileStore_Nのような名前を付けます。このストアのパスを指定します。このパスには、第5.13.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore _N

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

注意:

UMSの新しいJMSサーバーを作成します(たとえば、UMSJMSServer_N)このJMSサーバーに対して、UMSJMSFileStore_Nを使用します。UMSJMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

(BPMシステムの場合のみ)新しいBPMJMSServerの新しい永続ストアを作成し、BPMJMSFileStore_Nのような名前を付けます。このストアのパスを指定します。このパスには、第5.13.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore _N

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

注意:

(BPMシステムの場合のみ)BPMの新しいJMSサーバーを作成します(たとえば、BPMJMSServer_N)このJMSサーバーに対して、BPMJMSFileStore_Nを使用します。BPMJMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列にハイパーリンクとして表示)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。SOAJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたSOAJMSServerXXXXXXという形式のランダム名です。

新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。UMSJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュールは、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたUMSJMSServerXXXXXXという形式のランダム名です。

(BPMシステムの場合のみ)新たに作成されたBPM JMSサーバーが含まれるように、BPMJMSModuleのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「BPMJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。BPMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。BPMJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュールは、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたBPMJMSServerXXXXXXという形式のランダム名です。

サブデプロイメント「BPMJMSXXXXXX」をクリックします。このサブデプロイメントに、BPMJMSServer_Nと呼ばれる、BPMの新しいJMSサーバーを追加します。「保存」をクリックします。

次のようにpackコマンドをSOAHOST1で実行し、テンプレート・パックを作成します。

SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
 
SOAHOST1> ./pack.sh -managed=true -domain=MW_HOME/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale

次のコマンドをSOAHOST1で実行し、作成したテンプレート・ファイルをSOAHOSTNにコピーします。

SOAHOST1> scp soadomaintemplateScale.jar oracle@SOAHOSTN:/ ORACLE_BASE/product/fmw/soa/common/bin

次のようにSOAHOSTNでunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。

SOAHOSTN> cd ORACLE_BASE/product/fmw/soa/common/bin
 
SOAHOSTN> ./unpack.sh -domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar

第5.13.8項「コンポジットのデプロイでのOracle Coherenceの構成」の説明に従って、コンポジットをデプロイする場合のOracle Coherenceを構成します。

注意:

Dtangosol.coherence.localhost=SOAHOSTnVHN1

新しいサーバーに対してTX永続ストアを構成します。これは、共有記憶域についての推奨事項で示されているように、他のノードから参照できる場所に構成します。

管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_SOAN管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。

ホスト名の検証を無効化するには、次の手順を実行します。
1. Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
2. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
4. 表の「名前」列で「WLS_SOAn」を選択します。
  
  サーバーの「設定」ページが表示されます。
5. 「SSL」タブをクリックします。
6. 「詳細」をクリックします。
7. 「ホスト名の検証」を「なし」に設定します。
8. 「保存」をクリックします。
新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。
```
SOAHOSTN> WL_HOME/server/bin/startNodeManager <new_node_ip>
```
管理コンソールから新しい管理対象サーバーを起動して、テストします。
1. クラスタ内の既存の管理対象サーバーをすべて停止します。
2. 新たに作成した管理対象サーバーWLS_SOAnが実行されていることを確認します。
3. 新たに作成した管理対象サーバー上のアプリケーション(http://vip:port/soa-infra)にアクセスします。アプリケーションが機能している必要があります。

新しい管理対象サーバーに対してサーバー移行を構成します。

注意:

この新しいノードでは既存の共有記憶域インストールを使用しているため、ノードではすでに、ノード・マネージャと、ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限などの、サーバー移行用に構成された環境が使用されています。新しいノードには、すでに新しいSOA管理対象サーバーの浮動IPが存在します。

次の手順を実行してサーバー移行を構成します。

管理コンソールにログインします。
左側のペインで、「環境」を開き、「サーバー」を選択します。
移行を構成するサーバー(ハイパーリンクで表示)を、表の「名前」列から選択します。このサーバーの「設定」ページが表示されます。
「移行」タブをクリックします。

「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。

注意:

新しいサーバーの移行ターゲットには、負荷が最小のマシンを指定します。このノードのリソースが追加の管理対象サーバーの持続に十分対応できるように、必須の容量計画を立てる必要があります。

「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

この新しいサーバーのサーバー移行をテストします。新しいサーバーを追加したノードで次の手順を実行します。

1. 管理対象サーバーWLS_SOAnを停止します。

2. そのためには、管理対象サーバーのPIDに対してkill -9 <pid>を実行します。ノードのPIDは、ps -ef | grep WLS_SOAnを使用して確認できます。

注意:

Windowsの場合は、 taskkill コマンドを使用して管理対象サーバーを終了できます。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_SOAnのpidを確認します。

MW_HOME\jrockit_160_<バージョン>\bin\jps -l -v

3. ノード・マネージャ・コンソールを確認します。WLS_SOA1の浮動IPが無効になっていることを示すメッセージが表示されています。

4. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。

5. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:

5.14 SOAインフラストラクチャとコンポーネント・サービス・エンジンを使用するOracle Service Busの高可用性の構成

この項では、Oracle Service Busの設定手順について説明し、SOAインフラストラクチャ・システムに含まれる他のサービス・エンジン(Oracle BPEL/Oracle PM、Oracle Mediator、Oracle Human WorkflowおよびOracleデシジョン・サービスの他、Oracle B2B、Oracle User Messaging Serviceなど)の設定手順についても説明します。

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

第5.14.1項「環境の準備: SOAの高可用性構成の設定前に必要な手順」
第5.14.2項「Oracle Fusion Middlewareホームのインストール」
第5.14.3項「SOAHOST1のVIP1とVIP3およびSOAHOST2のVIP2とVIP4の有効化」
第5.14.4項「SOAとOSBのドメインを作成するためのSOAHOST1でのOracle Fusion Middleware構成ウィザードの実行」
第5.14.5項「SOAHOST1での管理サーバー用boot.propertiesの作成」
第5.14.6項「SOAHOST1での管理サーバーの起動と検証」
第5.14.7項「管理サーバーおよび管理対象サーバーWLS_SOAn/WLS_OSBnに対するホスト名の検証の無効化」
第5.14.8項「コンポジットのデプロイでのOracle Coherenceの構成」
第5.14.9項「Oracle Service Busの結果キャッシュのOracle Coherenceの構成」
第5.14.10項「B2Bキューの接続宛先識別子の設定」
第5.14.11項「SOAHOST1でのシステムの起動」
第5.14.12項「pack/unpackユーティリティを使用したSOAHOST2、OSBHOST1およびOSBHOST2へのドメイン構成の伝播」
第5.14.13項「第2ノードのXEngineファイルの抽出」
第5.14.14項「SOAHOST2、OSBHOST1およびOSBHOST2でのシステムの起動」
第5.14.15項「管理サーバーおよび管理対象サーバーWLS_SOAnとWLS_OSBnのOracle HTTP Serverの構成」
第5.14.16項「Oracle HTTP Serverを使用したアクセスの検証」
第5.14.17項「フロントエンドHTTPのホストおよびポートの設定」
第5.14.18項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」
第5.14.19項「アプリケーションのデプロイ」
第5.14.20項「WLS_SOAサーバーのサーバー移行の構成」
第5.14.21項「WLS_OSBサーバーのサーバー移行の構成」
第5.14.22項「トポロジのスケーリング」

注意:

図5-47は、この項の構成手順で作成するアーキテクチャの例を表しています。

図5-47 Oracle SOAインフラストラクチャ、コンポーネント・サービス・エンジンおよびOracle Service Busの高可用性アーキテクチャ

「図5-47 Oracle SOAインフラストラクチャ、コンポーネント・サービス・エンジンおよびOracle Service Busの高可用性アーキテクチャ」の説明

図5-47は、2つのOracle WebLogic ServerでOracle Service Busの2ノード・クラスタが実行されている様子を示しています。WebLogic Serverは、受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。ロード・バランサは、システムをフロントエンド処理し、クライアントから受信したリクエストを2つのOracle HTTP Serverに配布します。この構成では、Oracle RACデータベースを使用して、JMSレポート作成プロバイダからのレポート作成データ、およびJTAトランザクション・マネージャでLLRを使用する場合の2フェーズ・コミット・ログ(レポート作成データ・プロバイダによってのみ使用される)を格納します。また、クラスタ内のサーバーからのハートビート・データ(WebLog Serverのサーバー全体の移行機能で使用)を格納する場合もあります。トランザクションの永続ストアおよびJMSストアは、共有記憶域に置かれます。仮想IPアドレス(VIP)によって、管理サーバーおよびOracle Service Bus管理対象サーバーの手動フェイルオーバーが提供されます(サーバーの移行で使用)。

注意:

5.14.1 環境の準備: SOAの高可用性構成の設定前に必要な手順

次の各項では、SOAインフラストラクチャの高可用性構成を設定する前に必要となる手順について説明します。

第5.14.1.1項「データベースに関する前提条件」
第5.14.1.2項「VIPとIPの前提条件」
第5.14.1.3項「共有記憶域に関する前提条件」
第5.14.1.4項「LDAPプロバイダのインストールと構成」
第5.14.1.5項「システム・クロックの同期」
第5.14.1.6項「ディレクトリおよびディレクトリ環境変数の用語」
第5.14.1.7項「データベース・リポジトリのインストールと構成」
第5.14.1.8項「Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用したデータベースへのFusion Middlewareスキーマのロード」
第5.14.1.9項「ロード・バランサの仮想サーバー名とポートの構成」
第5.14.1.10項「WEBHOST1およびWEBHOST2へのOracle HTTP Serverのインストール」

5.14.1.1 データベースに関する前提条件

Oracle SOA Suiteでは、サポートされているデータベースおよびスキーマが存在している必要があります。Oracle Service Busは、JMSレポート作成プロバイダおよびOWSM Policy Managerの場合のみデータベースに依存します。

http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html

データベースのバージョンを調べるには、次の問合せを実行します。

SQL>select version from sys.product_component_version where product like 'Oracle%';

5.14.1.2 VIPとIPの前提条件

表5-10に示されているように、管理サーバーとSOAおよびOSBの管理対象サーバーがそれぞれ異なる仮想IPをリスニングするように構成します。そのためには、ノード内の対応するVIPのプロビジョニングと、ネットワーク上のDNSシステムで関連付けられているホスト名が必要です。各VIPが使用可能であり、SOAHOST1、SOAHOST2およびクライアント・マシンからアクセスできることを確認してから、インストールを実行してください。

表5-10 仮想ホスト

仮想IP	VIPのマップ先	説明
VIP0	SOAHOST1VHN0	SOAHOST1VHN0は、管理サーバーのリスニング・アドレスであり、管理サーバーの手動フェイルオーバーによりフェイルオーバーする、仮想ホストの名前です。管理サーバー・プロセスが実行されているノード(デフォルトはSOAHOST1)で有効化されます。
VIP1	SOAHOST1VHN1	SOAHOST1VHN1は、WLS_SOA1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_SOA1プロセスが実行されているノード(デフォルトはSOAHOST1)で有効化されます。
VIP2	SOAHOST2VHN1	SOAHOST2VHN1は、WLS_SOA2のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_SOA2プロセスが実行されているノード(デフォルトはSOAHOST2)で有効化されます。
VIP3	OSBHOST1VHN1	OSBHOST1VHN1は、WLS_OSB1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_OSB1プロセスが実行されているノード(デフォルトはSOAHOST1)で有効化されます。
VIP4	OSBHOST2VHN1	OSBHOST2VHN1は、WLS_OSB2のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_OSB2プロセスが実行されているノード(デフォルトはSOAHOST2)で有効化されます。

5.14.1.3 共有記憶域に関する前提条件

障害発生時に適切にリカバリできるようにするには、すべてのノードからアクセスできる場所にJMSとトランザクションの両方のログを格納して、管理対象サーバーで障害が発生した後にすべてのノードが操作を再開できるようにします。そのためには、複数ノードで参照可能な共有記憶域の場所が必要です。表5-11は、共有記憶域の内容を示しています。

表5-11 共有記憶域の内容

サーバー	データの型	共有記憶域のボリューム	ディレクトリ	ファイル
WLS_SOA1	Txログ	VOL1	ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs	共通の場所(WebLogicサーバーにより決められたストア)
WLS_SOA2	Txログ	VOL1	ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs	共通の場所(WebLogicサーバーにより決められたストア)
WLS_OSB1	Txログ	VOL1	ORACLE_BASE/admin/domain_name/osb_cluster_name/tlogs	共通の場所(WebLogicサーバーにより決められたストア)
WLS_OSB2	Txログ	VOL1	ORACLE_BASE/admin/domain_name/osb_cluster_name/tlogs	共通の場所(WebLogicサーバーにより決められたストア)
WLS_SOA1	JMSストア	VOL1	ORACLE_BASE/admin/domain_name/soa_cluster_name/jms	共通の場所である、サーバーごとに個別のストア(SOAJMSStore1、UMSJMSStore1など)
WLS_SOA2	JMSストア	VOL1	ORACLE_BASE/admin/domain_name/soa_cluster_name/jms	共通場所である、サーバーごとに個別のストア(SOAJMSStore2、UMSJMSStore2など)
WLS_OSB1	JMSストア	VOL1	ORACLE_BASE/admin/domain_name/osb_cluster_name/jms	共通の場所である、サーバーごとに個別のストア(WseeFileStore_auto_1など)
WLS_OSB2	JMSストア	VOL1	ORACLE_BASE/admin/domain_name/osb_cluster_name/jms	共通の場所である、サーバーごとに個別のストア(WseeFileStore_auto_2など)

SOAHOST1> mount nasfiler:/vol/volX/FMWshared
MW_HOME -t nfs -o
rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

5.14.1.4 LDAPプロバイダのインストールと構成

5.14.1.5 システム・クロックの同期

高可用性SOAのデプロイメントでは、各クラスタ・ノードのシステム・クロックを同期することが必要です。

5.14.1.6 ディレクトリおよびディレクトリ環境変数の用語

次のリストは、この章で使用するディレクトリと変数について説明しています。

ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指します。
MW_HOME: この環境変数および関連するディレクトリ・パスは、Fusion Middleware(FMW)が常駐している場所を指します。
WL_HOME: この環境変数および関連するディレクトリ・パスには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています。
ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、Oracle FMW SOA SuiteまたはOracle Service Busがインストールされている場所を指します。
ORACLE_COMMON_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリ・ファイルおよびライブラリ・ファイルが含まれているOracleホームを指します。

それぞれのMiddlewareホーム内のOracle共通ホームは、1つに限られます。
DOMAINディレクトリ: このディレクトリ・パスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されている場所を指します。
ORACLE_INSTANCE: Oracleインスタンスには、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなどのシステム・コンポーネントが1つ以上含まれています。Oracleインスタンス・ディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなどの更新可能ファイルが格納されています。

このディレクトリで一貫性を保つために使用することをお薦めする値は、次のとおりです。

ORACLE_BASE:

/u01/app/oracle

MW HOME(アプリケーション層):

ORACLE_BASE/product/fmw

WL_HOME:

MW_HOME/wlserver_10.3

ORACLE_HOME:

MW_HOME/soa

ORACLE_COMMON_HOME:

MW_HOME/oracle_common

JMSファイル・ベースのストアとTlogの場所:

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

マウント・ポイント:

ORACLE_BASE/admin/domain_name/soa_cluster_name/

共有記憶域の場所:

Shared storage location: ORACLE_BASE/admin/domain_name/aserver

5.14.1.7 データベース・リポジトリのインストールと構成

次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。

Oracle Clusterware

10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。
11g リリース1(11.1)以降については、Oracle Clusterwareインストレーション・ガイドを参照してください。

自動ストレージ管理

10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。
11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。
インストーラを実行するときは、「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。

Oracle Real Application Cluster

10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。
11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

最新バージョンのRCUを使用して、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clustersデータベースにインストールします。

最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

データベースの初期化パラメータ

次の初期化パラメータが、必要な値に設定されていることを確認します。これは、リポジトリ作成アシスタントによってチェックされます。

表5-12 必要な初期化パラメータ

パラメータ	必要な値	パラメータ・クラス
`PROCESSES`	300以上	静的

SQL*Plusを使用して初期化パラメータの値をチェックするには、SHOW PARAMETERコマンドを次のように使用します。

SYSユーザーとして、SHOW PARAMETERコマンドを次のように発行します。

SQL> SHOW PARAMETER processes

次のコマンドを使用して初期化パラメータを設定します。

SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE

データベースを再起動します。

注意:

5.14.1.8 Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用したデータベースへのFusion Middlewareスキーマのロード

5.14.1.8.1 RCUの実行

RCUを実行して、Oracle Fusion Middleware 11gに必要なメタデータをインストールします。

Linuxでは、RCU_Home/binに移動して、次のコマンドを使用します。
```
./rcu
```
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードし、「次へ」をクリックします。
「データベース接続の詳細」画面で、データベースの接続情報を入力します。
- データベース・タイプ: Oracle Databaseを選択します。
- ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合、ホスト名としてVIP名またはノード名の1つを指定します: SOADBHOST1VIRTUAL
- ポート: データベースのポート番号: 1521
- サービス名: データベースのサービス名を入力します: soaha.mycompany.com
- ユーザー名: SYS
- パスワード: SYSユーザーのパスワードを入力します。
- ロール: SYSDBA
「次へ」をクリックします。
次のような警告メッセージを受信する場合があります。

接続先のデータベースには非UTF8 charsetが含まれています。このデータベースを使用して複数言語のサポートを求める場合、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。
その場合は、「無視」または「停止」をクリックします。
「コンポーネントの選択」画面で「接頭辞の新規作成」を選択し、SOAHAのように、データベース・スキーマに使用する接頭辞を入力します。

後の手順で利用できるように、このスキーマ名を書き留めておきます。
- 次のスキーマを選択します。
  - 「AS共通スキーマ」で、メタデータ・サービスを選択します。
  - 「SOAサービス・インフラストラクチャ」で、「SOAサービス・インフラストラクチャ」と「ユーザー・メッセージング」を選択します(OSB Reporting ProviderスキーマはSOAインフラストラクチャの一部です)。
「次へ」をクリックします。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。
「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。

RCUの使用の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

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

トランザクション・リカバリ権限のSOAスキーマを構成する手順は次のとおりです。

sysdba権限を持つユーザーとしてSQL*Plusにログオンします。例:
```
sqlplus "/ as sysdba"
```
sys.dba_pending_transactionsに対してselectをsoaha_soainfraに付与します。
任意のトランザクションに対してforceをsoaha_soainfraに付与します。

注意:

これらの権限は、RCUの操作によって決定されるsoainfraスキーマの所有者に付与する必要があります。

5.14.1.9 ロード・バランサの仮想サーバー名とポートの構成

この項では、Oracle SOA Suiteの高可用性環境をデプロイするためのロード・バランサの前提条件について説明します。

ロード・バランサ

仮想ホスト名を介した実サーバー・プールへのトラフィックのロード・バランシング機能: クライアントは、仮想ホスト名を使用して(実ホスト名を使用するかわりに)、サービスにアクセスします。これにより、ロード・バランサは、プール内のサーバーに対するリクエストをロード・バランシングできます。
ポート変換の構成: ロード・バランサには、1つのポートで受信した受信リクエストを別のポートで実行されているサーバー・プロセスにルーティングできるポート変換機能が必要です。たとえば、ポート80で受信したリクエストをポート7777にルーティングできます。
ポート(HTTP、HTTPS)の監視
仮想サーバーとポートの構成: 外部ロード・バランサの仮想サーバー名とポートを構成する機能。さらに、仮想サーバー名とポートは次の要件を満たしている必要があります。
- ロード・バランサには複数の仮想サーバーを構成できる必要があります。各仮想サーバーに対し、ロード・バランサには2つ以上のポートでトラフィック管理を構成できることが必要です。たとえば、通常は、HTTPおよびHTTPSトラフィック用の仮想サーバーとポートでロード・バランサを構成する必要があります。
- 仮想サーバー名をIPアドレスに関連付け、DNSに含める必要があります。クライアントは、仮想サーバー名を介してロード・バランサへアクセスできる必要があります。
ノード障害を検出し、障害が発生したノードへのトラフィックのルーティングを即座に停止する機能。
リソースの監視/ポートの監視/プロセス障害検出: ロード・バランサは、サービスおよびノードの障害を通知などの方法を通じて検出し、障害が発生したノードへの非Oracle Netトラフィックの送信を停止できる必要があります。ロード・バランサに障害の自動検出機能がある場合は、それを使用する必要があります。
フォルト・トレラント・モード: ロード・バランサをフォルト・トラレント・モードに構成することを強くお薦めします。
その他: トラフィックの転送先となるバックエンド・サービスが使用できない場合、コール元のクライアントに即座に戻るようにロード・バランサの仮想サーバーを構成することを強くお薦めします。この構成は、クライアント・マシンのTCP/IP設定に基づいてタイムアウト後にクライアント側で接続を切断する構成よりも推奨されます。
スティッキーなルーティング機能: CookieまたはURLに基づいたコンポーネントへのスティッキーな接続を維持する機能。
SSLアクセラレーション: SSLアクセラレーションは、SSLトランザクションで実行され、プロセッサを集中的に使用する公開鍵暗号化アルゴリズムを、ハードウェア・アクセラレータにオフロードする方法です。

この機能は推奨されますが、必須ではありません。

表5-13は、Oracle SOA Suiteの高可用性環境で外部ロード・バランサに使用する仮想サーバー名の例を示しています。

表5-13 外部ロード・バランサの仮想サーバー名

コンポーネント	仮想サーバー名
Oracle SOA Suite	soa.mycompany.com
WebLogic Server管理コンソール	admin.mycompany.com
Oracle Enterprise Manager Fusion Middleware Control	admin.mycompany.com
Oracle Service Bus Webコンソール	admin.mycompany.com

仮想サーバー名

この項では、この章で説明する高可用性デプロイメントのために設定が必要な仮想サーバー名について説明します。

soa.mycompany.com

admin.mycompany.com

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

WEBHOST1にOracle HTTP Serverをインストールする手順は次のとおりです。

サーバーが次の要件を満たしていることを確認します。
- システム、パッチ、カーネルなどの要件が、『Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド』で指定されている要件を満たしています。
- ポート7777が、ノード上のどのサービスによっても使用されていない。このことを確認するには、次のコマンドを実行します。
  
  UNIX:
```
netstat -an | grep LISTEN | grep "7777"
```
  Windows:
```
netstat -an | findstr "LISTEN" | findstr ":7777"
```
ポートを使用中の場合は、それらのポートを使用可能にします。
UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。

/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。
Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。

UNIXでは、コマンドrunInstallerを実行します。

Windowsでは、setup.exeをダブルクリックします。
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。
「前提条件のチェック」画面で、前提条件がすべて満たされていることを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、場所を次のように設定します。

/u01/app/oracle/product/11.1.1/ohs_1
「次へ」をクリックします。
「コンポーネントの構成」画面で、次の操作を行います。
- 「Oracle HTTP Server」を選択します。
- 「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。
- 「次へ」をクリックします。
「コンポーネントの詳細の指定」画面で、次の値を入力します。
- インスタンス・ホームの場所: インスタンス・ホーム
- インスタンス・ホームの場所: /u01/app/oracle/product/11.1.1/ohs_1/instances/ohs_instance1
- インスタンス名: ohs_instance1
- OHSコンポーネント名: ohs1
「次へ」をクリックします。
「Web Tierポートの詳細の指定」画面で、次の操作を行います。
- 「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。
- 「Oracle HTTP Serverポート」に値を入力します(例: 7777)。
「次へ」をクリックします。
「構成サマリー」画面で、選択内容が正しいことを確認して「インストール」をクリックします。
「インストールの進行状況」画面で、次の操作を行います。

UNIXシステムでは、ダイアログ・ボックスが表示され、oracleRoot.shスクリプトを実行するように求められます。コマンド・ウィンドウを開き、表示される指示に従ってスクリプトを実行します。

「次へ」をクリックします。

「構成」画面で、いくつかの構成アシスタントが連続して起動されます。構成アシスタントが終了すると、「構成が完了しました」画面が表示されます。
「構成が完了しました」画面で、「終了」をクリックして終了します。

WEBHOST2に対して手順を繰り返し、WEBHOST1アドレスとWEBHOST2アドレスの両方を含むプールを使用してLBRを構成します。

5.14.1.10.1 Oracle HTTP Serverの検証

Oracle HTTP Serverが正しく設定されていることを確認するには、ブラウザで次のURLを使用し、サーバーのルートURLコンテキストにアクセスします。

HTTP://WEBHOST1:7777/

Oracle HTTP Serverが正しく設定されている場合は、ブラウザにOracle FMWの「ようこそ」画面が表示されます。

5.14.2 Oracle Fusion Middlewareホームのインストール

Oracle Fusion Middlewareの、次のコンポーネントをインストールします。

Oracle WebLogic Server(第5.14.2.1項「Oracle WebLogic Serverのインストール」を参照)
Oracle SOA Suite(第5.14.2.2項「Oracle SOA用Oracle Fusion Middlewareのインストール」を参照)
Oracle Service Bus(第5.14.2.3項「Oracle Service Busのインストール」を参照)

5.14.2.1 Oracle WebLogic Serverのインストール

最新バージョンのOracle Fusion Middlewareとともに使用するWebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する説明を参照してください。

アプリケーション層にあるすべてのノードにOracle WebLogic Serverをインストールする手順は次のとおりです。

Oracle WebLogic Serverインストーラを起動します。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。
- 「新しいミドルウェア・ホームを作成する」を選択します。
- 「ミドルウェア・ホーム・ディレクトリ」フィールドで、MW_HOMEと入力します。
- 「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。
「製品とコンポーネントの選択」画面で、「次へ」をクリックします。
「JDKの選択」画面で、「Oracle JRockit 160_20_D1.0.1-2124 SDK」のみを選択して「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。

WL_HOME

「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」の選択を解除して「完了」をクリックします。

5.14.2.2 Oracle SOA用Oracle Fusion Middlewareのインストール

/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

Oracle Fusion Middleware 11g Oracle SOA Suiteのインストーラを起動します。

UNIXの場合:
```
SOAHOST1> runInstaller
```
Windowsの場合:
```
SOAHOST1> setup.exe
```
Oracle Fusion Middleware 11g Oracle SOA Suiteのインストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、MW_HOME/jrockit_160_<バージョン>のように入力します。
「インベントリ・ディレクトリの指定」画面で、次の操作を行います。
1. HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所が推奨されます)。
2. インストールを実行するユーザーのOSグループを入力します。
3. 「次へ」をクリックします。
4. 画面の手順に従って、/createCentralInventory.shをルートとして実行します。
5. 「OK」をクリックします。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、次の操作を行います。
- 「MiddleWareホーム」には、MW_HOMEと入力します。
- 「Oracleホーム・ディレクトリ」には、soaと入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
「インストール完了」画面で「終了」をクリックします。

5.14.2.3 Oracle Service Busのインストール

Oracle Service Busをインストールするには、次の手順に従ってください。

Oracle Fusion Middleware 11g Oracle Service Busインストーラを起動します。

UNIXの場合:
```
SOAHOST1> runinstaller
```
Windowsの場合:
```
SOAHOST1> setup.exe
```
Oracle Fusion Middleware 11g Oracle Service Busのインストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、MW_HOME/jrockit_160_<バージョン>のように入力します。
「ようこそ」画面で「次へ」をクリックします。
「ソフトウェア更新のインストール」画面で、更新のプリファレンスを入力します。
「インストール場所の指定」画面で、次の操作を行います。
- 「ミドルウェア・ホーム」には、MW_HOMEと入力します。
- 「Oracleホーム・ディレクトリ」には、osbと入力します。
「次へ」をクリックします。
「インストール・タイプ」画面で、「カスタム」を選択して「次へ」をクリックします。
「インストールするコンポーネント」画面で、「Oracle Service Bus IDE」と「Oracle Service Bus Examples」の選択を解除します。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。
製品ホーム位置画面でデフォルトを受け入れて、次へをクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
「インストール完了」画面で「終了」をクリックします。

注意:

第5.14.4項「SOAとOSBのドメインを作成するためのSOAHOST1でのOracle Fusion Middleware構成ウィザードの実行」の説明に従って構成ウィザードを実行する前に、Oracle Fusion Middlewareが最新バージョンになるように、最新のOracle Fusion Middlewareパッチ・セットおよびその他の既知のパッチがMiddlewareホームに適用されていることを確認してください。

5.14.3 SOAHOST1のVIP1とVIP3およびSOAHOST2のVIP2とVIP4の有効化

SOAドメインは、SOAおよびOSBの管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのSOAマシン上でこれらのホスト名それぞれに対してVIPマッピングを有効にして(SOAHOST1ではVIP1とVIP3、SOAHOST2ではVIP2とVIP4)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーとhosts解決のいずれかで)正しく解決する必要があります。

仮想IPの構成の詳細は、第12.2.2.3項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。この項には、管理サーバーの例が記載されています。SOAサーバーのサーバー移行の構成の詳細は、第5.14.20項「WLS_SOAサーバーのサーバー移行の構成」を参照してください。

5.14.4 SOAとOSBのドメインを作成するためのSOAHOST1でのOracle Fusion Middleware構成ウィザードの実行

MW_HOME/Oracle_common/common/binディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーおよびOracle SOAとOSBのコンポーネントが格納されるドメインを作成します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースの場合は、すべてのインスタンスが実行されている必要があります。

注意:

同じWebLogic Serverドメイン内では、複数のSOAクラスタは許可されていません。

同じWebLogic Serverドメイン内では、複数のOSBクラスタは許可されていません。

1つのWebLogic Serverドメイン内では、1つのクラスタでSOAとOSBの両方を保持することはできません。

Middlewareホームのoracle_common/common/binディレクトリにある、Oracle Fusion Middlewareの構成ウィザードの場所に、ディレクトリを変更します。
```
SOAHOST1> cd ORACLE_HOME/oracle_common/common/bin
```
Oracle Fusion Middlewareの構成ウィザードを起動します。

Linuxの場合:
```
SOAHOST1> ./config.sh
```
Windowsの場合:
```
SOAHOST1> config.cmd
```
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面で、次を選択します。
- 「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。
- 次の製品を選択します。
  - Basic Weblogic Server Domain - 10.3.6.0 [wlserver_10.3](デフォルトで選択されており、グレーアウトされています)
  - Oracle SOA Suite - 11.1.1.0 [soa](デフォルトで選択されています)
  - Oracle Service Bus OWSM Extension - 11.1.1.6 [osb]
  - Oracle Enterprise Manager - 11.1.1.0 [oracle common](デフォルトで選択されています)
  - Oracle Service Bus - 11.1.1.6 [osb]
  - WebLogic Advanced WebService for JAX-RPC Extension - 10.3.6.0 [wlserver_10.3]
  - Oracle WSM Policy Manager - 11.1.1.0 [oracle_common](SOA Suiteを選択した場合は、デフォルトで選択されています)
  - Oracle JRF Web Services - 11.1.1.0 [oracle_common] (SOA Suiteを選択した場合は、デフォルトで選択されています)
ターゲットの一部を間違って選択解除した場合は、この画面で前述の項目が選択されていることを確認してください。

「次へ」をクリックします。
「ドメイン名と場所の指定」画面で、次のエントリを作成します。
- ドメイン名: soadomain
- ドメインの場所: デフォルトを受け入れます。
- アプリケーションの場所: デフォルトを受け入れます。
「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
- WebLogicドメインの起動モード: 「本番モード」を選択
- JDKの選択: 「Oracle JRockit 160_20_D1.0.1-2124 SDK」を選択
「次へ」をクリックします。

「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。

画面下部の表に表示されるすべてのコンポーネント・スキーマ、SOAインフラストラクチャ、ユーザー・メッセージング・サービス、OWSM MDSスキーマ、SOA MDSスキーマおよびOSB JMSレポート作成プロバイダを選択します。
「コンポーネント・スキーマのRAC構成」については、「GridLinkへ変換」、「RACマルチ・データ・ソースへ変換」または「変換しない」のうち、いずれかのオプションを選択します。

画面に次のデータ・ソースが表示されていることを確認します。表5-14に示されているユーザー名は、RCUからのスキーマ作成で接頭辞にsoahaが使用されていることを想定しています。

Oracle RACおよびMDSリポジトリでのGridLinkデータ・ソースの構成の詳細は、第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」を参照してください。

表5-14 データ・ソースの値の構成

データ・ソース・スキーマ	スキーマ所有者
SOAインフラストラクチャ	SOAHA_SOAINFRA
ユーザー・メッセージング・サービス	SOAHA_ORASDPM
OWSM MDSスキーマ	SOAHA_MDS
SOA MDSスキーマ	SOAHA_MDS
OSB JMSレポート作成プロバイダ	SOAHA_SOAINFRA

「次へ」をクリックします。

「JDBCコンポーネント・スキーマの構成」画面で、次のフィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

マルチ・データ・ソースの場合は、次のフィールドに値を入力します。

図5-48 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面

「図5-48 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面」の説明

GridLinkデータ・ソースの場合は、次のフィールドに値を入力します。

図5-49 「GridLink RACコンポーネント・スキーマの構成」画面

「図5-49 「GridLink RACコンポーネント・スキーマの構成」画面」の説明

ドライバ: RACの場合には、OracleのRACサービス・インスタンス接続用ドライバ(Thin)、バージョン:10、11を選択します。GridLinkの場合は、OracleのGridLink接続用ドライバ(Thin)、バージョン:10以降を選択します。

サービス名 : データベースのサービス名を入力します。GridLinkデータ・ソースの場合は、RACサービス名を小文字で入力し、その後にドメイン名example.comを入力する必要があります。たとえば、<mydbservice>.example.comと入力します。

注意:

ユーザー名接頭辞: スキーマの接頭辞を入力します。表5-14に示されているユーザー名は、RCUからのスキーマ作成で接頭辞としてsoahaが使用されていることを想定しています。
「パスワード」と「パスワードの確認」: スキーマにアクセスするときのパスワードを入力します。

注意:

マルチ・データ・ソースの場合は、「追加」をクリックします。Oracle RACインスタンスの詳細を入力します。

一度に1つのデータ・ソースを選択し、適切な詳細を追加することにより、各スキーマを更新します。

すべてのマルチ・データ・ソース・スキーマ(SOAインフラストラクチャ、ユーザー・メッセージング・サービス、OWSM MDSスキーマ、SOA MDSスキーマおよびOSB JMSレポート作成プロバイダ)について、必ず情報を入力してください。
「次へ」をクリックします。

「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が成功したことを確認します。正常に接続できない場合は、「前へ」をクリックしてエントリを修正します。

すべての接続が正常になったら「次へ」をクリックします。
「オプションの構成を選択」画面で、次を選択します。
- 管理サーバー
- JMS分散宛先
- 管理対象サーバー、クラスタ、およびマシン
- JMSファイル・ストア
「管理サーバーの構成」画面で、次の値を入力します。
- 名前: AdminServer
- リスニング・アドレス: VIP0仮想IPのホスト名を入力します。
- リスニング・ポート: 7001
- SSLリスニング・ポート: N/A
- SSL有効: 選択を解除
「次へ」をクリックします。
JMS分散宛先タイプがUDDに設定されていることを確認します。

「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。

表5-15 管理対象サーバーの構成

名前	リスニング・アドレス	リスニング・ポート	SSLリスニング・ポート	SSL有効
WLS_SOA1	SOAHOST1VHN1	8001	n/a	いいえ
WLS_SOA2	SOAHOST2VHN1	8001	n/a	いいえ
WLS_OSB1	OSBHOST1VHN1	8011	n/a	いいえ
WLS_OSB2	OSBHOST2VHN1	8011	n/a	いいえ

注意:

標準の推奨事項は、個々のWebLogic管理対象サーバー内でカスタム・アプリケーションおよび他のシステムを実行するためのものです。ただし、図5-47で説明しているカスタムWLS管理対象サーバーの作成については、この項では説明しません。

「次へ」をクリックします。

「クラスタの構成」画面で、次のクラスタを追加します。

表5-16 SOAクラスタとOSBクラスタの追加

名前	クラスタ・メッセージング・モード	マルチキャスト・アドレス	マルチキャスト・ポート	クラスタ・アドレス
SOA_Cluster	ユニキャスト	N/A	N/A	SOAHOST1VHN1:8001、SOAHOST2VHN1:8001
OSB_Cluster	ユニキャスト	N/A	N/A	OSBHOST1VHN1:8011、OSBHOST2VHN1:8011

「次へ」をクリックします。

「サーバーのクラスタへの割当」画面で、SOA_Clusterに次のサーバーを割り当てます。
- WLS_SOA1
- WLS_SOA2
OSB_Clusterに次のサーバーを割り当てます。
- WLS_OSB1
- WLS_OSB2
「次へ」をクリックします。

「マシンの構成」画面で、次の操作を行います。

デフォルトとして表示される「LocalMachine」を削除します。
「UNIXマシン」タブをクリックし、次のマシンを追加します。

表5-17 マシンの構成

名前	ノード・マネージャのリスニング・アドレス
SOAHOST1	SOAHOST1のホスト名
SOAHOST2	SOAHOST2のホスト名
OSBHOST1	OSBHOST1のホスト名
OSBHOST2	OSBHOST2のホスト名

その他すべてのフィールドをデフォルト値のままにして、「次へ」をクリックします。

「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。

図5-50 「サーバーのマシンへの割当」画面

「図5-50 「サーバーのマシンへの割当」画面」の説明
- SOAHOST1: AdminServer、WLS_SOA1
- SOAHOST2: WLS_SOA2
- OSBHOST1: WLS_OSB1
- OSBHOST2: WLS_OSB2
「次へ」をクリックします。

「JMSファイル・ストアの構成」画面で、サーバーのフェイルオーバー先として使用可能なすべてのノードからアクセス可能な各ストアのディレクトリの場所を入力します。第5.14.1.3項「共有記憶域に関する前提条件」で推奨されているディレクトリ(次に示す共有デバイス上のディレクトリなど)を使用します。

表5-18 JMSファイル・ストアの構成

名前	ディレクトリ	同期書込みポリシー*
FileStore_auto_1	/u01/app/oracle/admin/soadomain/soacluster/FileStore_auto_1	直接書込み
FileStore_auto_2	/u01/app/oracle/admin/soadomain/soacluster/FileStore_auto_2	直接書込み
SOAJMSFileStore_auto_1	/u01/app/oracle/admin/soadomain/soacluster/SOAJMSFileStore_auto_1	直接書込み
SOAJMSFileStore_auto_2	/u01/app/oracle/admin/soadomain/soacluster/SOAJMSFileStore_auto_2	直接書込み
UMSJMSFileStore_auto_1	/u01/app/oracle/admin/soadomain/soacluster/UMSJMSFileStore_auto_1	直接書込み
UMSJMSFileStore_auto_2	/u01/app/oracle/admin/soadomain/soacluster/UMSJMSFileStore_auto_2	直接書込み
WseeFileStore_auto_1	/u01/app/oracle/admin/soadomain/soacluster/WseeFileStore_auto_1	直接書込み
WseeFileStore_auto_2	/u01/app/oracle/admin/soadomain/soacluster/WseeFileStore_auto_2	直接書込み

* デフォルトの同期書込みポリシー(何も指定されない場合)は「直接書込み」です。

「次へ」をクリックします。

「構成のサマリー」画面で「作成」をクリックします。
ドメインの作成中画面で「完了」をクリックします。

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

管理サーバーに対しては、次の手順を実行します。

次のディレクトリを作成します。

SOAHOST1> mkdir -p ORACLE_BASE/product/fmw/user_
projects/domains/soadomain/servers/AdminServer/security

username=adminuser
password=password

注意:

管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

5.14.6 SOAHOST1での管理サーバーの起動と検証

この項では、SOAHOST1で管理サーバーを起動および検証する手順について説明します。

5.14.6.1 SOAHOST1での管理サーバーの起動

SOAHOST1上の管理サーバーを起動するには、次のコマンドを実行します。

SOAHOST1> cd MW_HOME/user_projects/domains/soadomain/bin

SOAHOST1> ./startWebLogic.sh

5.14.6.2 管理サーバーの検証

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

ブラウザでhttp://vip0:7001/consoleにアクセスします。
管理者としてログインします。
管理対象サーバーとしてWLS_SOA1およびWLS_SOA2が表示されていることを確認します。また、管理対象サーバーとしてWLS_OSB1およびWLS_OSB2が表示されていることを確認します。
SOA_ClusterクラスタおよびOSB_Clusterクラスタが表示されていることを確認します。
Enterprise Manager(http://vip0:7001/em)にアクセスできることを確認します。
http://vip0:7001/sbconsoleでOracle Service Busコンソールにアクセスできることを確認します。

5.14.7 管理サーバーおよび管理対象サーバーWLS_SOAn/WLS_OSBnに対するホスト名の検証の無効化

ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定したら、再度有効化できます。

ホスト名の検証を無効化するには、次の手順を実行します。

管理コンソールで、「サーバー」、「AdminServer」の順に選択します。
「SSL」→「詳細」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ホスト名の検証」を「なし」に設定します。変更を保存およびアクティブ化します。
WLS_SOA1、WLS_SOA2、WLS_OSB1およびWLS_OSB2サーバーに対してこの手順を繰り返します。
管理サーバーを再起動します。

5.14.8 コンポジットのデプロイでのOracle Coherenceの構成

注意:

ユニキャスト通信を使用したクラスタ内通信の有効化

ヒント:

tangosol.coherence.wka<n>システム・プロパティを使用してノードを指定します。<n>は、1から9の数字です。最大9つのノードを指定できます。番号は、1から開始します。連続した番号を指定する必要があり、途切れていてはなりません。また、Oracle Coherenceがtangosol.coherence.localhostシステム・プロパティを使用してクラスタを作成するときに使用するホスト名を指定します。このホスト名は、対応するリスナー・アドレス(VIP1およびVIP2)をマップするSOAサーバーによって使用される仮想ホスト名である必要があります。このプロパティは、管理コンソールの「サーバーの起動」タブ(図5-51)の「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加して設定します。

図5-51 管理コンソールの「サーバーの起動」タブを使用したホスト名の設定

「図5-51 管理コンソールの「サーバーの起動」タブを使用したホスト名の設定」の説明

ホスト名の指定

Oracle Coherenceで使用するホスト名を追加する手順は次のとおりです。

管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの設定ページが表示されます。
「サーバーの起動」タブをクリックします(図5-51を参照)。

「引数」フィールドで、WLS_SOA1とWLS_SOA2について次のように入力します。

WLS_SOA1について、改行を入れず、1行で次のように入力します。

-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost1vhn1

WLS_SOA2について、改行を入れず、1行で次のように入力します。

-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost2vhn1

注意:

WLS_SOA1(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=soahost1vhn1
-Dtangosol.coherence.wka2=soahost2vhn1
-Dtangosol.coherence.localhost=soahost1vhn1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

WLS_SOA2(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=soahost1vhn1
-Dtangosol.coherence.wka2=soahost2vhn1
-Dtangosol.coherence.localhost=soahost2vhn1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

「保存」をクリックして、変更をアクティブ化します。
この変更を適用するには、SOAサーバーを再起動する必要があります。

注意:

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

Oracle Service Busの結果キャッシュが使用するCoherenceインフラストラクチャのデフォルト構成は、マルチキャストです。Oracle Service Busの結果キャッシュでは、ユニキャスト通信を使用することをお薦めします。

Oracle Service Busの結果キャッシュのCoherenceインフラストラクチャに対してユニキャストを有効にするには、次の手順を実行します。

管理コンソールにログインします。「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの設定ページが表示されます。
「サーバーの起動」タブをクリックします。

WLS_OSB1には、次の1行を入力します(改行は入れません)。

-DOSB.coherence.localhost=osbhost1vhn1 -DOSB.coherence.localport=7890 
-DOSB.coherence.wka1= osbhost1vhn1 -DOSB.coherence.wka1.port=7890 
-DOSB.coherence.wka2= osbhost2vhn1 -DOSB.coherence.wka2.port=7890

WLS_OSB2には、次の1行を入力します(改行は入れません)。

-DOSB.coherence.localhost=osbhost2vhn1 -DOSB.coherence.localport=7890 
-DOSB.coherence.wka1= osbhost1vhn1 -DOSB.coherence.wka1.port=7890 
-DOSB.coherence.wka2= osbhost2vhn1 -DOSB.coherence.wka2.port=7890

変更を保存およびアクティブ化します。これらの変更を有効にするには、Oracle Service Busサーバー再起動する必要があります。

5.14.10 B2Bキューの接続宛先識別子の設定

Oracle B2Bは、特定のJMS宛先メンバー・コールを使用します。これらのコールの正常な実行には「宛先識別子の作成」(CDI)の設定が必要になります。CDIを設定する手順は次のとおりです。

管理コンソールにログインします。
「ドメイン構造」ウィンドウで「サービス」ノードを開き、「メッセージング」ノードを開きます。
「JMSモジュール」をクリックしてから、「SOAJMSModule」をクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「dist_B2BEventQueue_auto」→「構成」→「一般」タブ→「詳細」をクリックします。
「宛先識別子の作成」フィールドで、キューの次のjndi名を追加します。
```
jms/b2b/B2BEventQueue
```
これらの手順を繰り返し、次に示すキューの宛先識別子を次のように作成します。
- B2B_OUT_QUEUE: jms/b2b/B2B_OUT_QUEUE
- B2B_IN_QUEUE: jms/b2b/B2B_IN_QUEUE
- B2BBroadcastTopic: jms/b2b/B2BBroadcastTopic
- XmlSchemaChangeNotificationTopic: jms/fabric/XmlSchemaChangeNotificationTopic
「保存」→「変更のアクティブ化」をクリックします。

5.14.11 SOAHOST1でのシステムの起動

この項では、SOAHOST1でノード・マネージャを起動する方法、およびSOAHOST1で管理対象サーバーWLS_SOA1を起動して検証する方法について説明します。

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

SOAHOST1でノード・マネージャを起動するには、次の手順を実行します。

ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。
```
SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
SOAHOST1> ./setNMProps.sh
```
注意:

クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。

ノード・マネージャを起動します。

SOAHOST1> cd WL_HOME/server/bin
SOAHOST1> ./startNodeManager.sh

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

WLS_SOA1管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認するには:

管理コンソールを使用して、WLS_SOA1管理対象サーバーを起動します。
WLS_SOA1を起動すると、次のURLが使用可能になります。
- http://SOAHOST1VHN1:8001/b2b
  - B2Bコンソールへのログインを確認します。
- http://SOAHOST1VHN1:8001/integration/worklistapp
  - ワークリスト・コンソールへのログインを確認します。
- http://SOAHOST1VHN1:8001/wsm-pm
  - ポリシー・バリデータ・リンクを確認します。
- http://SOAHOST1VHN1:8001/soa/composer
- http://SOAHOST1VHN1:8001/soa-infra

5.14.12 pack/unpackユーティリティを使用したSOAHOST2、OSBHOST1およびOSBHOST2へのドメイン構成の伝播

pack/unpackユーティリティを使用して、ドメイン構成をSOAHOST2に伝播する手順は次のとおりです。

次のpackコマンドをSOAHOST1で実行し、テンプレート・パックを作成します。

SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
SOAHOST1> ./pack.sh -managed=true
-domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/
-template=soadomaintemplate.jar 
-template_name=soa_domain_template

次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをSOAHOST2にコピーします
```
SOAHOST1> scp soadomaintemplate.jar
 oracle@node2:ORACLE_COMMON_HOME/common/bin
```

unpackコマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。

SOAHOST2> cd ORACLE_COMMON_HOME/common/bin
SOAHOST2> ./unpack.sh
 -domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/
 -template=soadomaintemplate.jar

注意:

pack/unpackプロシージャを実行した後でFusion Middleware構成ウィザードを実行すると、元のドメインにすでに存在し、「拡張ソースの選択」画面に表示されている製品は、選択されていない状態でグレー表示されます。

packコマンドで作成したテンプレートは、ユーザー作成テンプレートと見なされ、デフォルト・テンプレートとは別に扱われます。ユーザー作成テンプレートは自己完結型で、元のドメインの作成に関連する情報を一切保持しません。

OSBHOST1とOSBHOST2に対しても前述の手順を繰り返します。

5.14.13 第2ノードのXEngineファイルの抽出

B2BのXEngineを第2ノードで有効にするには、次のようにZEngine tarのコンテンツを手動で抽出する必要があります。

SOAHOST2>cd ORACLE_HOME/soa/thirdparty/edifecs
SOAHOST2>tar xzvf XEngine.tar.gz

5.14.14 SOAHOST2、OSBHOST1およびOSBHOST2でのシステムの起動

この項では、SOAHOST2でシステムを起動する手順について説明します。

5.14.14.1 SOAHOST2、OSBHOST1およびOSBHOST2でのノード・マネージャの起動

SOAHOST2、OSBHOST1およびOSBHOST2でノード・マネージャを起動するには、第5.14.11.1項「SOAHOST1でのノード・マネージャの起動」の手順をそれらのノードで繰り返します。

5.14.14.2 管理対象サーバーWLS_SOA2、WLS_OSB1およびWLS_OSB2の起動と検証

管理対象サーバーWLS_SOA2を起動して、正しく構成されていることをチェックする手順は、次のとおりです。

管理コンソールを使用して、WLS_SOA2管理対象サーバーを起動します。起動中はサーバーの出力ファイルでエラーを監視します。
WLS_SOA2が起動すると、次のURLが使用できるようになります。
- http://SOAHOST2VHN1:8001/b2b
  
  B2Bコンソールへのログインを確認します。
- http://SOAHOST2VHN1:8001/integration/worklistapp
  
  ワークリスト・コンソールへのログインを確認します。
- http://SOAHOST2VHN1:8001/wsm-pm
  
  ポリシー・バリデータ・リンクを確認します。
- http://SOAHOST2VHN1:8001/soa/composer
- http://SOAHOST2VHN1:8001/soa-infra

管理対象サーバーWLS_OSB1を起動して、正しく構成されていることをチェックする手順は、次のとおりです。

管理コンソールを使用して、WLS_OSB1管理対象サーバーを起動します。起動中はサーバーの出力ファイルでエラーを監視します。

WLS_OSB1が起動すると、次のURLが使用できるようになります。

http://OSBHOST1VHN1:8011/sbinspection.wsil/

次のようなHTTP応答が表示されます。

<?xml version="1.0" encoding="UTF-8" ?> 
<ins:inspection xmlns:ins="http://schemas.xmlsoap.org/ws/2001/10/inspection/">
<ins:link referencedNamespace="http://schemas.xmlsoap.org/ws/2001/10/inspection/" location="http://OSBHOSTVHN1:8011/sbinspection.wsil?refpath=default">
<ins:abstract>default</ins:abstract> 
<ins:abstract>LinkType: Project</ins:abstract> 
</ins:link>
</ins:inspection>

WLS_OSB2に対してこの手順を繰り返します。

5.14.15 管理サーバーおよび管理対象サーバーWLS_SOAnとWLS_OSBnのOracle HTTP Serverの構成

管理対象サーバーWLS_SOAnを含むSOAクラスタへのOracle HTTP Serverのルーティングを有効にするには、次に示すWebLogicClusterパラメータをクラスタ内のノードのリストに設定します。

WEBHOST1およびWEBHOST2で、ORACLE_BASE/admin/<instance_name>/config/OHS/<component_name>/mod_wl_ohs.confファイルに次の行を追加します。

# WSM-PM
<Location /wsm-pm>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001, SOAHOST2VHN1:8001
</Location>

# SOA soa-infra app
<Location /soa-infra>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# Worklist
<Location /integration/>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# B2B
<Location /b2b>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

<Location /b2bconsole>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# UMS
<Location /sdpmessaging/ >
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>
 
# UMS WS
<Location /ucs/messaging/webservice >
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow/>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# Workflow
<Location /workflow>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

#Required if attachments are added for workflow tasks
 <Location /ADFAttachmentHelper> 
    SetHandler weblogic-handler 
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 
 </Location>

# SOA composer application 
 <Location /soa/composer> 
     SetHandler weblogic-handler 
     WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 
 </Location>

# OSB wsil 
 <Location /sbinspection.wsil*> 
     SetHandler weblogic-handler 
     WebLogicCluster OSBHOST1VHN1:8011,OSBHOST2VHN2:8011 
 </Location>
 
# OSB resource 
 <Location /sbresource*> 
     SetHandler weblogic-handler 
     WebLogicCluster OSBHOST1VHN1:8011,OSBHOST2VHN2:8011
 </Location>

mod_wl_ohs.confファイルと同じディレクトリにあるhttpd.confファイルが次の行を含んでいることを確認します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://soa.mycompany.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>
 
NameVirtualHost *:7777
<VirtualHost *:7777>
    ServerName admin.mycompany.com:80
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit
</VirtualHost>

注意:

soa.mycompany.com:443や7777、admin.mycompany:80、you@youraddressなどの値は、例を示すための値です。実際の環境に基づく値を入力してください。

注意:

Oracle Service Busの各HTTPプロキシ・サービスは、それらに固有のコンテキスト・ルートを公開します。これは、そのプロキシ・サービスのフルパスになります(デフォルト)。たとえば、プロジェクトOrderProcessingのフォルダsubmissionにordersubmit.proxyが存在する場合は、コンテキスト・パスとして/OrderProcessing/submission/ordersubmitが公開されます。これらのURLコンテキストは、各サービスのOracle HTTP Serverに追加する必要があります。

WEBHOST2のOracle HTTP Serverについて同じ手順を実行します。

WEBHOST1とWEBHOST2の両方でOracle HTTP Serverを起動します。

WEBHOST1> ORACLE_BASE/admin/<instance_name>/bin/opmnctl restartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/admin/<instance_name>/bin/opmnctl restartproc ias-component=ohs2

5.14.16 Oracle HTTP Serverを使用したアクセスの検証

管理コンソールで、SOAサーバーのステータスが「実行中」になっていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。別のステータス(「管理」や「失敗」)が表示される場合は、サーバーの出力ログ・ファイルでエラーを確認します。次のURLにアクセスできることを確認します。

http://WEBHOST1:7777/wsm-pm
http://WEBHOST2:7777/wsm-pm
http://WEBHOST1:7777/soa-infra
http://WEBHOST2:7777/soa-infra
http://WEBHOST1:7777/soa/composer
http://WEBHOST2:7777/soa/composer
http://WEBHOST1:7777/integration/worklistapp
http://WEBHOST2:7777/integration/worklistapp
http://WEBHOST1:7777/sdpmessaging/userprefs-ui
http://WEBHOST2:7777/sdpmessaging/userprefs-ui
http://WEBHOST1:7777/b2bconsole
http://WEBHOST2:7777/b2bconsole
http://WEBHOST1:7777/sbinspection.wsil
http://WEBHOST2:7777/sbinspection.wsil

次のURLがロード・バランシング・ルーター・アドレスを使用していることも確認します。

http://soa.mycompany.com:80/wsm-pm
http://soa.mycompany.com:80/soa-infra
http://soa.mycompany.com:80/soa/composer
http://soa.mycompany.com:80/integration/worklistapp
http://soa.mycompany.com:80/sdpmessaging/userprefs-ui
http://soa.mycompany.com:80/b2bconsole
http://soa.mycompany.com:80/sbinspection.wsil

HTTP ServerからSOA_CLusterへのルーティングとフェイルオーバーが適切に機能していることを確認する手順は、次のとおりです。

WLS_SOA2の実行中に、管理コンソールからWLS_SOA1を停止します。
次のURLにアクセスして、適切な機能を検証します。
- WEBHOST1:7777/wsm-pm
- WEBHOST1:7777/soa-infra
- WEBHOST1:7777/soa/composer
- WEBHOST1:7777/integration/worklistapp
- WEBHOST1:7777/sdpmessaging/userprefs-ui
- WEBHOST1:7777/b2bconsole
管理コンソールから、WLS_SOA1を開始します。
WLS_SOA2を停止します。
前述のステップ2のURLにアクセスして、適切な機能を検証します。

HTTP ServerからOSB_Clusterへのルーティングとフェイルオーバーが適切に機能していることを確認する手順は、次のとおりです。

WLS_OSB2の実行中に、管理コンソールからWLS_OSB1を停止します。
次のURLにアクセスして、適切な機能を検証します。
- WEBHOST1:7777/sbinspection.wsil
管理コンソールから、WLS_OSB1を開始します。
WLS_OSB2を停止します。
前述のステップ2のURLにもう一度アクセスして、正しく機能することを検証します。

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

Oracle WebLogic Serverクラスタに対してフロントエンドHTTPのホストとポートを設定する必要があります。

管理コンソールの「チェンジ・センター」セクションで、「ロックして編集」をクリックします。
左側のペインで、「環境」→「クラスタ」を選択します。
「SOA_Cluster」を選択します。
「HTTP」を選択します。

次の値を設定します。

フロントエンド・ホスト: soa.mycompany.com

フロントエンドHTTPポート: 80
フロントエンドHTTPSポート: 空白のまま

注意:

「保存」をクリックします。
変更をアクティブにするには、管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。
OSB_Clusterに対してステップ1 - 7を繰り返します。

すでにサーバーを起動している場合、この変更にはクラスタの管理対象サーバーの再起動が必要であることに注意してください。

注意:

SOAシステムでは、次のようにコールバック・サーバーURLを計算します。

SOAへのリクエストが外部サービスから発行されたものであったり、内部サービスがSOAにリクエストを発行したりした場合、SOAは、クライアントによって指定されているコールバック・サーバーURLを使用します。
外部または内部サービスへのリクエストがSOAから発行されている場合は、SOAが発行元であるため、コールバックURLをSOAリクエストに動的に移入できません。しかし、callbackServerURLが特定参照のバインディング・プロパティに指定されている場合は、callbackServerURLが使用されます。(これは、コンポジットをモデル化するときに設定するか、実行時にOracle Enterprise Managerコンソールからアクセス可能なMBeanを使用して設定できます。)これにより、サービス・コールごとに異なるコールバックURLを割り当てることができます。したがって、外部サービスからのコールバック・サーバーURLは、内部サービスへのコールバック・サーバーURLと異なります。

ただし、callbackServer URLがその参照のバインディング・プロパティに指定されていない場合、SOAシステムは、soa-infra-configに指定されているコールバック・サーバーURLを使用します。soa-infra-configにコールバック・サーバーURLが指定されていない場合、システムでは、WLSに指定されているフロントエンド・ホストがコールバック・サーバーURLとして使用されます。WLSにフロントエンド・ホストが指定されていない場合、システムでは、WLS MBean APIで指定されているローカル・ホスト名がコールバック・サーバーURLとして使用されます。

フロントエンドHTTPのホストとポートを設定しない場合、Oracle B2Bからドキュメント定義XSDを取得しようとすると、次のメッセージを受け取ります。

An error occured while loading the document definitions.
java.lang.IllegalArgumentException: Cluster address must be set when
clustering is enabled.

5.14.18 トランザクション・リカバリのためのデフォルトの永続ストアの構成

各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでトランザクション・ログを使用します。クラスタ内のサーバーに対してトランザクション回復サービスの移行機能を利用するためには、サーバーとそのバックアップ・サーバー(WebLogic Serverのフェイルオーバー先として使用可能なノード)で利用可能な場所、可能であればデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)にトランザクション・ログを格納する必要があります。デフォルトの永続ストアを構成する手順は、次のとおりです。

「ドメイン構造」ツリーで、「環境」を開き、「サーバー」を選択します。
変更するサーバーを選択します。
「構成」、「サービス」タブの順に選択します。
「デフォルト・ストア」の「ディレクトリ」フィールドに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。

トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定する必要があります。したがって、入力するディレクトリは、SOA_Clusterの場合はWLS_SOA1とWLS_SOA2の両方から、OSB_Clusterの場合はWLS_OSB1とWLS_OSB2の両方から、それぞれアクセスできる必要があります。このディレクトリは、サーバーが再起動される前に存在している必要があります。

5.14.19 アプリケーションのデプロイ

最初の新しいSOAコンポジット・アプリケーション
旧リビジョン(1.0など)と新リビジョン(2.0など)。旧リビジョンへの影響はありません。最後にデプロイされたリビジョンが、そのコンポジットの新しいデフォルト・リビジョンになります(デプロイメントのこの後の手順で他のリビジョンを指定しない場合にかぎります)。
現在デプロイされているもの(1.0など)とは異なるリビジョンをすでに持っているSOAコンポジット・アプリケーションの複数のSOAコンポジット・アプリケーション・リビジョン(リビジョン2.0、3.0、4.0など)が含まれているバンドル(ZIPファイル)。このオプションを使用すると、リビジョン1.0、2.0、3.0および4.0を同時にデプロイできます。バンドルには様々なコンポジットのリビジョンを含めることもできます。すべてのリビジョンが同一のコンポジット・アプリケーションのリビジョンでなければならないという制約はありません。

注意:

アプリケーションをデプロイする手順は、次のとおりです。

次のいずれかのオプションを使用して、SOAコンポジットのデプロイ・ウィザードにアクセスします。

SOAインフラストラクチャのメニュー	ナビゲータのSOAフォルダ	SOAインフラストラクチャのホーム・ページ	SOAコンポジットのメニュー
「SOAデプロイ」→「デプロイ」を選択します。	「soa-infra」を右クリックします。「SOAデプロイ」→「デプロイ」を選択します。	「デプロイ済コンポジット」タブをクリックします。「コンポジット」表の上にある「デプロイ」をクリックします。	「SOAデプロイ」→「別のコンポジットをデプロイ」を選択します。

「アーカイブの選択」ページが表示されます。

図sca_deploy.gifの説明

「アーカイブまたは展開済ディレクトリ」セクションで、デプロイするSOAコンポジット・アプリケーションのアーカイブを指定します。アーカイブには、デプロイするコンポジットのプロジェクト・ファイルが格納されています(たとえば、単一アーカイブのHelloWorld_rev1.0.jar、または複数アーカイブのOrderBooking_rev1.0.zip)。
「構成プラン」セクションで、アーカイブに含める構成プランのオプションを指定します。構成プランには、異なる環境で使用するURLとプロパティ値を定義できます。構成プランは、プロセスのデプロイメント時に、プロジェクトを別のターゲット環境に適合させるために置換する必要のある値に関するSOAプロジェクトを検索する際に使用されます。
「次へ」をクリックします。
SOAコンポジット・アプリケーション・アーカイブのデプロイ先WebLogic Serverまたはクラスタを選択します。アーカイブは、複数のサーバーおよびクラスタにデプロイできます。
「次へ」をクリックします。
選択内容を確認します。
SOAコンポジット・アプリケーションをデフォルトのリビジョンとしてデプロイするかどうかを選択します。デフォルトのリビジョンは、新しいリクエストを受信するとインスタンス化されます。
「デプロイ」をクリックします。
デプロイメントが完了したら、「閉じる」をクリックします。

5.14.20 WLS_SOAサーバーのサーバー移行の構成

ステップ1: サーバー移行leasing表のユーザーおよび表領域を設定する
ステップ2: 管理コンソールでマルチ・データ・ソースを作成する
ステップ3: ノード・マネージャのプロパティ・ファイルの編集
ステップ4: wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する
ステップ5: サーバー移行ターゲットの構成
ステップ6: サーバー移行をテストする

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

WebLogicユーザー(oracle)に、パスワードなし制限でsudo権限を付与して、/sbin/ifconfig and /sbin/arpingバイナリの実行権限を付与します。

注意:

Windowでは、スクリプト名はwlsifconfig.cmdです。これを実行できるのは、管理者権限を持つユーザーです。

スクリプトがWebLogicユーザー(oracle)によって実行可能であることを確認してください。次の、/etc/sudoers内のエントリの例では、oracleのsudo実行権限を、ifconfigとarpingに対しても付与しています。

Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

サーバー移行のテスト

サーバー移行が適切に機能していることを確認する手順は次のとおりです。

SOAHOST1から次の処理を実行します。

WLS_SOA1管理対象サーバーを強制停止します。

これを行うには、このコマンドを実行します:

SOAHOST1> kill -9 <pid>

pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。

SOAHOST1> ps -ef | grep WLS_SOA1

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了できます。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_SOA1のpidを確認します。

MW_HOME\jrockit_160_<version>\bin\jps -l -v

ノード・マネージャ・コンソールを確認します。WLS_SOA1の浮動IPが無効になっていることを示すメッセージが表示されています。
ノード・マネージャがWLS_SOA1の2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

SOAHOST2から次の処理を実行します。

ローカルのノード・マネージャのコンソールを確認します。ノード1で最後にWLS_SOA1の再起動が試行されてから30秒経過した後、ノード2のノード・マネージャによって、WLS_SOA1の浮動IPが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。
同じIPのSOAサービス・インフラストラクチャ・コンソールにアクセスします。

管理コンソールで移行を検証する手順は、次のとおりです。

管理コンソールにログインします。
左側のペインで、「ドメイン」をクリックします。
「監視」タブ、「移行」サブタブの順にクリックします。

「移行の状態」表に、移行の状態に関する情報が表示されます。

図5-52 管理コンソールの「移行の状態」画面

「図5-52 管理コンソールの「移行ステータス」画面」の説明

注意:

Windowsでは、同一マシン上で複数のサーバーを同時に手動で停止してから、停止したサーバーの1つを別のマシンで起動しようとしても、IPバインドが機能しないことがあります。これは、IPアドレスが削除されていることがnetshによってレポートされていても、元のマシンでそのIPアドレスに対する要求が引き続き保持されているために起こります。

Windowsのコントロール・パネルで、「ネットワーク接続」を選択します。
該当のネットワーク・インタフェースを選択して右クリックし、「プロパティ」を選択します。
「インターネットプロトコル (TCP/IP)」を選択して「プロパティ」ボタンをクリックします。
「詳細設定」を選択します。
該当のIPアドレスを選択して、「削除」ボタンをクリックします。

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

5.14.21 WLS_OSBサーバーのサーバー移行の構成

OSBシステムの高可用性アーキテクチャでは、一部のシングルトン・サービスを障害から保護するためにサーバー移行を利用します。サーバー全体の移行の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

WLS_OSB1管理対象サーバーは、障害発生時にOSBHOST2で再起動するように構成され、WLS_OSB2管理対象サーバーは、障害発生時にOSBHOST1で再起動するように構成されます。このような構成では、WLS_OSB1サーバーおよびWLS_OSB2サーバーは、WLSサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。WLS_OSBn管理対象サーバーのサーバー移行を構成する手順は、次のとおりです。

注意:

第5.14.20項「WLS_SOAサーバーのサーバー移行の構成」の説明に従って、SOAですでに表領域、スキーマのマルチ・データ・ソースおよびデータ・ソースが設定されている場合、OSBクラスタは既存のleasingスキーマとデータ・ソースを再利用できるので、後述のステップ1とステップ2は不要です。かわりに、SOA用に作成されているデータ・ソースとマルチ・データ・ソースを、OSBクラスタにターゲット指定します。

ステップ1: サーバー移行leasing表のユーザーおよび表領域を設定する

leasingという表領域を作成します。

例: SQL*Plusにsysdbaユーザーとしてログオンして、次のコマンドを実行します。

SQL> create tablespace leasing
        logging datafile 'DB_HOMEs/oradata/orcl/leasing.dbf'
        size 32m autoextend on next 32m maxsize 2048m extent management local;

leasingというユーザーを作成し、leasing表領域に割り当てます。

SQL> create user leasing identified by welcome1;

SQL> grant create table to leasing;

SQL> grant create session to leasing;

SQL> alter user leasing default tablespace leasing;

SQL> alter user leasing quota unlimited on LEASING;

leasing.ddlスクリプトを使用してleasing表を作成します。
1. WL_HOME/server/db/oracle/817ディレクトリまたはWL_HOME/server/db/oracle/920ディレクトリにあるleasing.ddlファイルをデータベース・ノードにコピーします。
2. データベースにleasingユーザーとして接続します。
3. leasing.ddlをSQL*Plusで実行します。
```
SQL> @copy_location/leasing.ddl;
```

ステップ2 管理コンソールでマルチ・データ・ソースを作成する

このデータ・ソースが非XAデータ・ソースであることを確認します。
マルチ・データ・ソースの名前の形式は、<MultiDS>-rac0、<MultiDS>-rac1です。
Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。
したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。データ・ソースは、グローバル・トランザクションのサポートを必要としません。
これらのデータ・ソースをクラスタにターゲット指定します。
データソースの接続プールの初期容量が0に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データ・ソース名」→「接続プール」タブをクリックし、「接続数の初期値」フィールドに0を入力します。

マルチ・データ・ソースを作成する手順は、次のとおりです。

管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「データ・ソース」をクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「新規」→「マルチ・データ・ソース」をクリックします。
「名前」として、leasingと入力します。
「JNDI名」として、jdbc/leasingと入力します。
「アルゴリズムとしてフェイルオーバー」(デフォルト)を選択し、「次へ」をクリックします。
「非XAドライバ」(デフォルト)を選択し、「次へ」をクリックします。
「新しいデータ・ソースの作成」をクリックします。
名前として、leasing-rac0と入力します。JNDI名として、jdbc/leasing-rac0と入力します。データベースのタイプとして、oracleと入力します。ドライバのタイプとして、Oracle Driver (Thin) for RAC server-Instance connection Version 10,11と入力します。
「次へ」をクリックします。
「グローバル・トランザクションのサポート」の選択を解除して、「次へ」をクリックします。
leasingスキーマのサービス名、データベース名(racdb1やracdb2などのRACノードのインスタンス名)、ホスト・ポートおよびパスワードを入力します。「次へ」をクリックします。
「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。
データ・ソースをOSBクラスタにターゲット指定します。
データ・ソースを選択して、右の画面に追加します。
「新しいデータ・ソースの作成」をクリックして、Oracle RACデータベースの2つ目のインスタンスについても同じ手順を繰り返します。
2つ目のデータ・ソースをマルチ・データ・ソースに追加します。
変更を保存およびアクティブ化します。

ステップ3: ノード・マネージャのプロパティ・ファイルを編集する

ノード・マネージャとサーバー全体の移行の詳細は、第3.9項「サーバー全体の移行」を参照してください。

nodemanager.propertiesファイルは、WL_HOME/common/nodemanagerディレクトリにあります。サーバー移行が正しく機能するために、この項で説明するプロパティを追加する必要があります。

Interface=eth0

注意:

サブ・インタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0または:1なしに使用されます。ノード・マネージャのスクリプトは、別の:X対応のIPを移動して、追加または削除するものを決定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

このプロパティは、浮動IPのインタフェース名(たとえば、Linuxではeth0)を指定します。

注意:

Windowsの場合、Interfaceには、ネットワーク・インタフェース名を設定する必要があります。例: Interface="Local Area Connection"

指定するインタフェースが、このノードに対するパブリック・インタフェースであることを確認してください。このインタフェースは、複数のホーム・ノード上で浮動IPを有効にできるものでなければなりません。

NetMask=255.255.255.0

このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。このネットマスク(255.255.255.0)は、一例にすぎません。実際の値は、ネットワークにより異なります。
UseMACBroadcast=true

このプロパティでは、ARPパケットの送信時にノードのMACアドレスを使用するかどうか、すなわち、arpingコマンドで-bフラグを使用するかどうかを指定します。

ノード・マネージャの起動後、これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力(ノード・マネージャが起動されているシェル)で確認します。ノード・マネージャの出力は、次のように表示されます。

StateCheckInterval=500

Interface=eth0 (Linux)またはInterface="Local Area Connection" (Windows)

NetMask=255.255.255.0

UseMACBroadcast=true

注意:

この項で説明する手順は、サーバー・プロパティ(起動プロパティ)が適切に設定されていて、ノード・マネージャがリモートでサーバーを起動できる場合には不要です。

nodemanager.propertiesファイルで次のプロパティを設定します。
- StartScriptEnabled
  
  このプロパティをtrueに設定します。
WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行して、OSBHOST1とOSBHOST2でノード・マネージャを起動します。
nodemanager.logファイルで、nodemanager.propertiesファイルへの変更を確認します。

ステップ4: wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する

WebLogicユーザー(oracle)に、パスワードなし制限でsudo権限を付与して、/sbin/ifconfig and /sbin/arpingバイナリの実行権限を付与します。

注意:

Windowsでは、このスクリプトの名前はwlsifconfig.cmdであり、管理者権限を持つユーザーが実行できます。

WebLogicユーザー(oracle)がスクリプトを実行できることを確認します。次の、/etc/sudoers内のエントリの例では、oracleのsudo実行権限を、ifconfigとarpingに対しても付与しています。
```
Defaults:oracle !requiretty 
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
```

ステップ5: サーバー移行ターゲットを構成する

クラスタの移行の構成では、DataSourceForAutomaticMigrationプロパティがtrueに設定されます。クラスタ内の移行でクラスタ移行を構成する手順は次のとおりです。

管理コンソールにログインします。
左側のペインで、「環境」を開き、「クラスタ」を選択します。
移行を構成するクラスタ(OSB_Cluster)を選択します。
「移行」をクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。この場合は、「OSBHOST1」と「OSBHOST2」を選択します。
leasingデータ・ソースを選択します。
「保存」をクリックします。
すべての管理対象サーバーについて、サーバー移行の候補となるマシンを設定します。
1. 管理コンソールの左ペインで、「環境」を展開して「サーバー」を選択します。
2. 移行を構成するサーバーを選択します。
3. 「移行」タブをクリックします。
4. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。WLS_OSB1には「OSBHOST2」を選択します。WLS_OSB2には「OSBHOST1」を選択します。
5. 「サーバーの自動移行を有効化」のチェック・ボックスを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
6. 「保存」をクリックして、変更をアクティブ化します。
7. これらの変更を有効にするには、サーバーとノード・マネージャを再起動する必要があります。

ステップ6: サーバー移行をテストする

サーバー移行が適切に機能していることを確認する手順は次のとおりです。

OSBHOST1から次の処理を実行します。

WLS_OSB1管理対象サーバーを強制停止します。

これを行うには、このコマンドを実行します:

OSBHOST1> kill -9 <pid>

pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。

OSBHOST1> ps -ef | grep WLS_OSB1

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了できます。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_OSB1のpidを確認します。

MW_HOME\jrockit_160_<version>\bin\jps -l -v

ノード・マネージャのコンソールを確認します。WLS_OSB1の浮動IPが無効になっていることを示すメッセージが表示されています。
ノード・マネージャがWLS_OSB1の2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

OSBHOST2から次の処理を実行します。

ローカルのノード・マネージャのコンソールを確認します。ノード1で最後にWLS_OSB1の再起動が試行されてから30秒経過した後、ノード2のノード・マネージャによって、WLS_OSB1の浮動IPが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。
同じIPのsbinspection.wsil urlconsoleにアクセスします。

管理コンソールから移行を検証する手順は、次のとおりです。

管理コンソールにログインします。
左側のペインで、「ドメイン」をクリックします。
「監視」タブ、「移行」サブタブの順にクリックします。

「移行の状態」表に、移行の状態に関する情報が表示されます。

図5-53 管理コンソールの「移行の状態」画面

「図5-53 管理コンソールの「移行ステータス」画面」の説明

注意:

Windowsでは、同一マシン上で複数のサーバーを同時に手動で停止し、その後で別のマシンで、停止したサーバーの1つを起動しようとしても、IPバインドは機能しません。これは、IPアドレスが削除されていることがnetshによってレポートされていても、元のマシンでそのIPアドレスに対する要求が引き続き保持されているために起こります。

Windowsのコントロール・パネルで、「ネットワーク接続」を選択します。
該当のネットワーク・インタフェースを選択して右クリックし、「プロパティ」を選択します。
「インターネットプロトコル (TCP/IP)」を選択して「プロパティ」ボタンをクリックします。
「詳細設定」を選択します。
該当のIPアドレスを選択して、「削除」ボタンをクリックします。

注意:

5.14.22 トポロジのスケーリング

5.14.22.1 トポロジのスケール・アップ(既存のノードへの管理対象サーバーの追加)

この場合は、SOAコンポーネントとOracle Service Busコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードには、既存の管理対象サーバーのMiddlewareホーム、Oracleホーム(SOAとOracle Service Bus)およびドメイン・ディレクトリが含まれます。

新しいWLS_OSBサーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用できます。SOAまたはOracle Service Busのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。

SOAサーバーをスケール・アップするには、第5.13.21.1項「トポロジのスケール・アップ(既存のノードへの管理対象サーバーの追加)」の手順に従ってください。

OSBサーバーのトポロジをスケール・アップするには、次の手順に従ってください。

管理コンソールを使用し、WLS_OSBnのクローンを作成して新しい管理対象サーバーにします。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。

管理対象サーバーのクローンを作成する手順は次のとおりです。
1. 管理コンソールから「環境」→「サーバー」を選択します。
2. クローンを作成する管理対象サーバー(WLS_OSB1など)を選択します。
3. 「クローンの作成」を選択します。
新しい管理対象サーバーにWLS_OSBnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。

この後の手順では、すでにWLS_OSB1を実行しているOSBHOST1に新しいサーバーを追加することを想定しています。
リスニング・アドレスに対して、この新しい管理対象サーバーに使用する仮想ホスト名を割り当てます。このサーバーに対して推奨されている、サーバー移行の使用を計画している場合は、この仮想ホスト名により別のノードに移動できます。この仮想ホスト名は、OSB/SOAドメイン(同じドメインまたは別のドメイン)によって使用されているノードで実行されている他の管理対象サーバーで使用されているものとは異なっている必要があります。

管理対象サーバーのリスニング・アドレスを設定する手順は次のとおりです。
1. 管理コンソールにログインします。
2. 「チェンジ・センター」で、「ロックして編集」をクリックします。
3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
4. 「サーバー」をクリックします。
5. 表の「名前」列で、リスニング・アドレスを更新する管理対象サーバーを選択します。
6. 「リスニング・アドレス」をOSBHOST1VHN1に設定します。「保存」をクリックします。
7. 変更を保存およびアクティブ化します。
この変更は、管理対象サーバーを再起動すると有効になります。
クラスタ・アドレスを更新して、新しいサーバーを追加します。
1. 管理コンソールで「環境」→「クラスタ」を選択します。
2. OSB_Clusterサーバーをクリックします。
3. 「チェンジ・センター」で、「ロックして編集」をクリックします。
4. 新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。例:
```
OSBHOST1VHN1:8011,OSBHOST2VHN1:8011,OSBHOST1VHN2:8011
```

Oracle Service BusにJMSリクエスト/レスポンス機能を使用するビジネス・サービスが1つ以上構成されている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールから次の手順も実行する必要があります。

「チェンジ・センター」で、「作成」をクリックしてセッションを作成します。
プロジェクト・エクスプローラで、JMSリクエスト/レスポンスを使用するビジネス・サービスを検索し、選択します。このタイプのビジネス・サービスは、「サービスのタイプ」としてメッセージング・サービスが表示されます。
「詳細の表示」ページの下部にある「編集」をクリックします。
エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。
「ビジネス・サービスの編集 - サマリー」ページで「保存」をクリックします。
JMSリクエスト/レスポンスを使用する他のビジネス・サービスについて、それぞれ前の手順を繰り返します。
「チェンジ・センター」で、「アクティブ化」をクリックしてセッションを作成します。
管理対象サーバーを再起動します。
管理サーバーを再起動します。

これで、ビジネス・サービスは、拡張されたドメインで操作できるように構成されています。

注意:

JMS MessageID相関スキームを使用するビジネス・サービスの場合、接続ファクトリ設定を編集して、管理対象サーバーをキューにマッピングする表にエントリを追加する必要があります。キューとトピック宛先の構成方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のJMSサーバーのターゲット指定に関する項を参照してください。

Oracle Service Busにクラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスが1つ以上構成されている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールから次の手順も実行する必要があります。
1. 「チェンジ・センター」で、「作成」をクリックしてセッションを作成します。
2. プロジェクト・エクスプローラで、クラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスを検索し、選択します。
3. 「詳細の表示」ページの下部にある「編集」をクリックします。
4. エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。
5. 「プロキシ・サービスの編集 - サマリー」ページで「保存」をクリックします。
6. クラスタ・アドレスを含むJMSエンドポイントを使用する他のプロキシ・サービスについて、それぞれ前の手順を繰り返します。
7. 「チェンジ・センター」で、「アクティブ化」をクリックしてセッションを作成します。
8. 管理対象サーバーを再起動します。
これで、プロキシ・サービスは、拡張されたドメインで操作できるように構成されています。

新しいサーバーのOracle Service Busの結果キャッシュのCoherence構成を更新する手順は次のとおりです。

管理コンソールにログインします。「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの設定ページが表示されます。
「サーバーの起動」タブをクリックします。

WLS_OSBnについて(改行を入れずに1行で)次のように入力します。

-DOSB.coherence.localhost=osbhost1vhnn -DOSB.coherence.localport=7890 
-DOSB.coherence.wka1= osbhost1vhn1 -DOSB.coherence.wka1.port=7890 
-DOSB.coherence.wka2= osbhost2vhn1 -DOSB.coherence.wka1.port=7890

注意:

この構成は、WLS_OSBnの起動時に、サーバーWLS_OSB1とWLS_OSB2が実行されていることを想定しています。これによりWLS_OSBnは、WLS_OSB1またはWLS_OSB2のどちらかによって起動されたCoherenceクラスタに、指定されたWKAアドレスを使用して参加します。また、サーバーWLS_OSB1、WLS_OSB2およびWLS_OSBnをすべて再起動する場合、WLS_OSB1とWLS_OSB2が起動されてからWLS_OSBnが起動されることを確認します。これにより、WLS_OSBnが、WLS_OSB1またはWLS_OSB2のどちらかによって起動されたクラスタに参加できることが保証されます。サーバーの起動順序を考慮する必要のない構成にするには、WLS_OSB1とWLS_OSB2のWKAとしてWLS_OSBnのホストとポートを追加し、さらにWLS_OSBnのWKAとしてWLS_OSBnを追加する必要があります。

変更を保存およびアクティブ化します。この変更を適用するには、Oracle Service Busサーバーを再起動する必要があります。

新しい管理対象サーバーにOSBのレポート作成/内部宛先のJMSサーバーと永続ストアを作成します。

管理コンソールを使用して、新しいwlsbJMSServerの新しい永続ストアを作成し、FileStore_auto_xのような名前を付けます。第5.14.1.3項「共有記憶域に関する前提条件」で推奨されている、このストアの共有記憶域のパスを指定します。

注意:

システムが本番モードの場合、管理対象サーバーが起動する前または起動操作が失敗する前に、第5.14.1.3項「共有記憶域に関する前提条件」で推奨されているディレクトリが存在している必要があります。

ORACLE_BASE/admin/DOMAIN_NAME/cluster_name/jms/wlsbJMSServer_auto_x

OSBの新しいJMSサーバーを作成します(たとえば、wlsbJMSServer_auto_x)。このJMSサーバーに対して、FileStore_auto_xを使用します。wlsbJMSServer_auto_xサーバーを、新たに作成した管理対象サーバー(WLS_OSBn)にターゲット指定します。

新たに作成されたOSB JMSサーバー(wlsbJMSServer_auto_x)が含まれるように、jmsresources OSB JMSモジュールのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「jmsResources」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。jmsResourcesの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。jmsresourcesのサブデプロイメント・モジュールが表示されます。

注意:

宛先のこのサブデプロイメント・モジュール名は、wlsbJMSServerXXXXXXという形式のランダム名です。これは、構成ウィザードにおける最初の2つのサーバー(WLS_OSB1とWLS_OSB2)のJMS構成から生成されます。

サブデプロイメント「wlsbJMSServerXXXXXX」をクリックし、新しいwlsbJMSServer_auto_xサーバーが含まれるようにターゲットを更新します。

新しい管理対象サーバーにOSB JAX-RPCのJMSサーバー、永続ストアおよび宛先を作成します。

注意:

WebLogic JAX-RPC Webサービスの高度な拡張機能では、通常の(非分散)宛先を使用して、ローカルに処理するサービス・リクエストがローカル・メンバーにのみエンキューされることを保証します。

管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、Wsee_rpc_JMSFileStore_Nのような名前を付けます。このストアのパスを指定します。このパスには、第5.14.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定します。

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
```
ORACLE_BASE/admin/DOMAIN_NAME/cluster_name/jms/Wsee_rpc_JMSFileStore_N
```
OSB JAX-RPCの新しいJMSサーバーを作成します(たとえば、OSB_rpc_JMSServer_N)。このJMSサーバーに対して、Wsee_rpc_JMSFileStore_Nを使用します。OSB_rpc_JMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_OSBn)にターゲット指定します。
宛先と新たに作成されたOSB JMSサーバーでWseeJMSModule OSB JMSモジュールを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「WseeJmsModule」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。WseeJmsModuleの「設定」ページが表示されます。ステップdからvを実行して、この手順を完了します。
「チェンジ・センター」で、「ロックして編集」をクリックします。「新規」をクリックします。
「キュー」をクリックします。
「次へ」をクリックします。
キューの名前としてDefaultCallbackQueue-WseeJmsServer_auto_nと入力します。
JNDI名としてweblogic.wsee.DefaultCallbackQueue-WseeJmsServer_auto_nと入力します。
「次へ」をクリックします。
「新しいサブデプロイメントの作成」をクリックします。
デフォルト名を受け入れます。
「OK」をクリックします。
ターゲットとして「OSB_rpc_JMSServer_n」を選択します。
「終了」をクリックします。
変更をアクティブ化します。
次のステップqからuに従って、宛先のローカルJNDI名を更新します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「WseeJmsModuleの設定」ページで、「DefaultCallbackQueue-WseeJmsServer_auto_n」宛先をクリックします。
「一般構成」タブで、「詳細」をクリックします。
ローカルJNDI名をweblogic.wsee.DefaultCallbackQueueに更新します。
変更をアクティブ化します。
DefaultQueue-WseeJmsServer_auto_nキューに対して、JNDI名としてweblogic.wsee.DefaultQueue-WseeJmsServer_auto_nを、ローカルJNDI名としてweblogic.wsee.DefaultQueueを使用して、ステップdからnを繰り返します。

次のように新しいSAFエージェントを作成し、そのターゲットを新しく追加した管理対象サーバーに設定します。

管理コンソールで「サービス」→「メッセージング」→「ストア・アンド・フォワード・エージェント」を開き、新しいSAFエージェントReliableWseeSAFAgent_auto_Nを追加します。

永続ストアWsee_rpc_JMSFileStore_N (OSB JAX-RPC用に作成された永続ストア)を選択します。SAFエージェントのターゲットを新しい管理対象サーバーに設定し、変更をアクティブにします。
新しいサーバーに対してTX永続ストアを構成します。これは、共有記憶域についての推奨事項で示されているように、他のノードから参照できる場所に構成します。

管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OSBn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとOSBHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。

ホスト名の検証を無効化するには、次の手順を実行します。
1. Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
2. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
4. 表の「名前」列で「WLS_OSBn」を選択します。サーバーの「設定」ページが表示されます。
5. 「SSL」タブをクリックします。
6. 「詳細」をクリックします。
7. 「ホスト名の検証」を「なし」に設定します。
8. 「保存」をクリックします。
新しいノードでノード・マネージャがまだ起動されていない場合はそれを起動します。ノード・マネージャを起動するには、次のように、すでに存在しているノードの共有記憶域にあるインストールを使用します。
```
OSBHOSTN> WL_HOME/server/bin/startNodeManager
```
管理コンソールから新しい管理対象サーバーを起動して、テストします。
1. クラスタ内の既存の管理対象サーバーを停止します。
2. 新たに作成した管理対象サーバーWLS_OSBnが起動していることを確認します。
3. 新たに作成した管理対象サーバー上のアプリケーション(http://vip:port/sbinspection.wsil)にアクセスします。

新しい管理対象サーバーに対してサーバー移行を構成します。

注意:

これはスケール・アップ操作であるため、ノード・マネージャ、サーバー移行に対して構成された環境および新しいOSB管理対象サーバーの浮動IPがあらかじめノードに用意されている必要があります。

次の手順を実行してサーバー移行を構成します。

管理コンソールにログインします。
左側のペインで、「環境」を開き、「サーバー」を選択します。
移行を構成する新しい管理対象サーバーの名前を選択します。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。ノードの既存のサーバーと同じ移行ターゲットを選択します。

たとえば、すでにWLS_OSB1が実行されているOSBHOST1上の新しい管理対象サーバーには、OSBHOST2を選択します。すでにWLS_OSB2が実行されているOSBHOST2上の新しい管理対象サーバーには、OSBHOST1を選択します。

移行時に管理対象サーバーを同時に実行できるように、適切なリソースが使用可能になっていることを確認してください。
「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

この新しいサーバーのサーバー移行をテストします。新しいサーバーを追加したノードで次の手順を実行します。

管理対象サーバーWLS_OSBnを停止します。

そのためには、管理対象サーバーのPIDに対してkill -9 <pid>を実行します。ノードのPIDは、ps -ef | grep WLS_OSBnを使用して確認できます。

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを停止できます。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_OSBnのpidを確認します。

MW_HOME\jrockit_160_<バージョン>\bin\jps -l -v

ノード・マネージャ・コンソールを参照します。WLS_OSBnの浮動IPが無効になっていることを示すメッセージが表示されます。
ノード・マネージャがWLS_OSBnの2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーがローカルで再起動されないことを示すメッセージが、ノード・マネージャによってログに記録されます。

注意:

5.14.22.2 トポロジのスケール・アウト(新しいノードへの管理対象サーバーの追加)

トポロジのスケール・アウトでは、OSBで構成された新しい管理対象サーバーを新しいノードに追加します。

SOAサーバーをスケール・アウトするには、第5.13.21.2項「トポロジのスケール・アウト(新しいノードへの管理対象サーバーの追加)」の手順に従ってください。

OSBサーバーのトポロジをスケール・アウトするには、この項の手順に従ってください。

この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。

OSBで構成された管理対象サーバーを実行しているノードがトポロジ内に存在していること。

新しいノードは、WebLogic ServerとOSBインストールの既存のホーム・ディレクトリに必要に応じてアクセスできます(新しいWLS_OSB管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用してください。この場合は、新しい場所にWebLogic ServerやOSBのバイナリをインストールする必要はありませんが、OSBサーバーを同じドメインの他のサーバー(SOAサーバー)を含むマシンにスケーリングしている場合を除き、新しいノードでドメイン構成をブートストラップするためにpackとunpackを実行する必要があります)。

注意:

共有記憶域にインストールが存在しない場合は、第5.14項「Oracle SOAインフラストラクチャとコンポーネント・サービス・エンジンを使用するOracle Service Busの高可用性の構成」の説明に従って、新しいノードにWebLogic Server、SOAおよびOSBをインストールする必要があります。

注意:

ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して、そのノードに共有記憶域内のインストールを追加するには、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、user_home/bea/beahomelistファイルを編集します。次の手順を参照してください。

トポロジをスケール・アウトするには:

新しいノードで、既存のMiddlewareホームをマウントします。これには、OSBとSOA(ホームを共有する場合)インストールおよびドメイン・ディレクトリを含める必要があります。新しいノードが、ドメイン内の他のノードと同様に、このディレクトリにアクセスできることを確認します。
共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するために、次のコマンドを実行します。
```
OSBHOSTn>cd ORACLE_BASE/product/fmw/soa/
OSBHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>
```
Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。
Oracle WebLogic管理コンソールにログインします。
新しいノードに使用する新しいマシンを作成し、このマシンをドメインに追加します。
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。
管理コンソールを使用し、WLS_OSB1をクローニングして新しい管理対象サーバーを作成します。これにWLS_OSBnという名前を付けます。nは新しいマシンに割り当てる番号です。

注意:

これらの手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加することを想定しています。
リスニング・アドレスに対して、この新しい管理対象サーバーに使用する仮想ホスト名を割り当てます。このサーバーに対して推奨されている、サーバー移行の使用を計画している場合は、この仮想ホスト名により別のノードに移動できます。この仮想ホスト名は、OSB/SOAドメイン(同じドメインまたは別のドメイン)によって使用されているノードで実行されている他の管理対象サーバーで使用されているものとは異なっている必要があります。

次の手順を実行して、管理対象サーバーのリスニング・アドレスを設定します。
1. 管理コンソールにログインします。
2. 「チェンジ・センター」で、「ロックして編集」をクリックします。
3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
4. 「サーバー」をクリックします。
5. 表の「名前」列で、リスニング・アドレスを更新する管理対象サーバーを選択します。
6. 「リスニング・アドレス」をOSBHOSTnVHN1に設定します。
7. 「保存」をクリックします。
8. 変更を保存およびアクティブ化します。
変更内容は、管理対象サーバーが再起動されるまでは有効になりません。
クラスタ・アドレスを更新して、新しいサーバーを追加します。
1. 管理コンソールで「環境」→「クラスタ」を選択します。
2. OSB_Clusterサーバーをクリックします。OSB_Clusterの「設定」画面が表示されます。
3. 「チェンジ・センター」で、「ロックして編集」をクリックします。
4. 新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。例:
```
OSBHOST1VHN1:8011,OSBHOST2VHN1:8011,OSBHOSTNVHN1:8011
```

新しい管理対象サーバーにOSBのレポート作成/内部宛先のJMSサーバーと永続ストアを作成します。

管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、OSB_rep_JMSFileStore_Nのような名前を付けます。このストアのパスを指定します。このパスには、第5.14.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定します。

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/OSB_rep_JMSFileStore _N
```
OSBの新しいJMSサーバーを作成します(たとえば、OSB_rep_JMSServer_N)。このJMSサーバーに対して、OSB_rep_JMSFileStore_Nを使用します。OSB_rep_JMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_OSBn)にターゲット指定します。

新たに作成されたOSB JMSサーバーが含まれるように、jmsresources OSB JMSモジュールのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「jmsresources」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。jmsResourcesの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。jmsresourcesのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OSB1とWLS_OSB2)のJMS構成から生成されたwlsbJMSServerXXXXXXという形式のランダム名です。

サブデプロイメント「wlsbJMSServerXXXXXX」をクリックし、ターゲットに新しいOSB_rep_JMSServer_Nサーバーを追加します。

新しい管理対象サーバーにOSB JAX-RPCのJMSサーバー、永続ストアおよび宛先を作成します。

注意:

管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、Wsee_rpc_JMSFileStore_Nのような名前を付けます。このストアのパスを指定します。このパスには、第5.14.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定します。

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
```
ORACLE_BASE/admin/DOMAIN_NAME/cluster_name/jms/Wsee_rpc_JMSFileStore_N
```
OSB JAX-RPCの新しいJMSサーバーを作成します(たとえば、OSB_rpc_JMSServer_N)。このJMSサーバーに対して、Wsee_rpc_JMSFileStore_Nを使用します。OSB_rpc_JMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_OSBn)にターゲット指定します。
宛先と新たに作成されたOSB JMSサーバーでWseeJMSModule OSB JMSモジュールを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「WseeJmsModule」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。WseeJmsModuleの「設定」ページが表示されます。ステップdからvを実行して、この手順を完了します。
「チェンジ・センター」で、「ロックして編集」をクリックします。「新規」をクリックします。
「キュー」をクリックします。
「次へ」をクリックします。
キューの名前としてDefaultCallbackQueue-WseeJmsServer_auto_nと入力します。
JNDI名としてweblogic.wsee.DefaultCallbackQueue-WseeJmsServer_auto_nと入力します。
「次へ」をクリックします。
「新しいサブデプロイメントの作成」をクリックします。
デフォルト名を受け入れます。
「OK」をクリックします。
ターゲットとして「OSB_rpc_JMSServer_n」を選択します。
「終了」をクリックします。
変更をアクティブ化します。
次のステップqからuに従って、宛先のローカルJNDI名を更新します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「WseeJmsModuleの設定」ページで、「DefaultCallbackQueue-WseeJmsServer_auto_n」宛先をクリックします。
「一般構成」タブで、「詳細」をクリックします。
ローカルJNDI名をweblogic.wsee.DefaultCallbackQueueに更新します。
変更をアクティブ化します。
DefaultQueue-WseeJmsServer_auto_nキューに対して、JNDI名としてweblogic.wsee.DefaultQueue-WseeJmsServer_auto_nを、ローカルJNDI名としてweblogic.wsee.DefaultQueueを使用して、ステップdからnを繰り返します。

次のように新しいSAFエージェントを作成し、そのターゲットを新しく追加した管理対象サーバーに設定します。

管理コンソールで「サービス」→「メッセージング」→「ストア・アンド・フォワード・エージェント」を開き、新しいSAFエージェントReliableWseeSAFAgent_auto_Nを追加します。

永続ストアWsee_rpc_JMSFileStore_N (OSB JAX-RPC用に作成された永続ストア)を選択します。SAFエージェントのターゲットを新しい管理対象サーバーに設定し、変更をアクティブにします。

「チェンジ・センター」で、「作成」をクリックしてセッションを作成します。
プロジェクト・エクスプローラで、JMSリクエスト/レスポンスを使用するビジネス・サービスを検索し、選択します。このタイプのビジネス・サービスは、「サービスのタイプ」としてメッセージング・サービスが表示されます。
「詳細の表示」ページの下部にある「編集」をクリックします。
エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。
「ビジネス・サービスの編集 - サマリー」ページで「保存」をクリックします。
JMSリクエスト/レスポンスを使用する他のビジネス・サービスについて、それぞれ前の手順を繰り返します。
「チェンジ・センター」で、「アクティブ化」をクリックしてセッションを作成します。
管理対象サーバーを再起動します。
管理サーバーを再起動します。

これで、ビジネス・サービスは、拡張されたドメインで操作できるように構成されています。

注意:

Oracle Service Busにクラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスが1つ以上構成されている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールから次の手順も実行する必要があります。
1. 「チェンジ・センター」で、「作成」をクリックしてセッションを作成します。
2. プロジェクト・エクスプローラで、クラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスを検索し、選択します。
3. 「詳細の表示」ページの下部にある「編集」をクリックします。
4. エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。
5. 「プロキシ・サービスの編集 - サマリー」ページで「保存」をクリックします。
6. クラスタ・アドレスを含むJMSエンドポイントを使用する他のプロキシ・サービスについて、それぞれ前の手順を繰り返します。
7. 「チェンジ・センター」で、「アクティブ化」をクリックしてセッションを作成します。
8. 管理対象サーバーを再起動します。
これで、プロキシ・サービスは、拡張されたドメインで操作できるように構成されています。

新しいサーバーのOracle Service Busの結果キャッシュのCoherence構成を更新する手順は次のとおりです。

管理コンソールにログインします。「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの設定ページが表示されます。
「サーバーの起動」タブをクリックします。

WLS_OSBnについて(改行を入れずに1行で)次のように入力します。

-DOSB.coherence.localhost=osbhostnvhn1 -DOSB.coherence.localport=7890 
-DOSB.coherence.wka1= osbhost1vhn1 -DOSB.coherence.wka1.port=7890 
-DOSB.coherence.wka2= osbhost2vhn1 -DOSB.coherence.wka1.port=7890

注意:

前述の構成は、WLS_OSBnの起動時に、サーバーWLS_OSB1とWLS_OSB2が実行されていることを想定しています。これによりWLS_OSBnは、WLS_OSB1またはWLS_OSB2のどちらかによって起動されたCoherenceクラスタに、指定されたWKAアドレスを使用して参加できます。また、サーバーWLS_OSB1、WLS_OSB2およびWLS_OSBnをすべて再起動する場合、WLS_OSB1とWLS_OSB2が起動されてからWLS_OSBnが起動されることを確認します。これにより、WLS_OSBnが、WLS_OSB1またはWLS_OSB2のどちらかにより起動されたクラスタに参加できることが保証されます。サーバーの起動順序を考慮する必要のない構成にするには、WLS_OSB1とWLS_OSB2のWKAとしてWLS_OSBnのホストとポートを追加し、さらにWLS_OSBnのWKAとしてWLS_OSBnを追加する必要があります。

変更を保存およびアクティブ化します(この変更を適用するには、Oracle Service Busサーバーを再起動する必要があります)。

次のようにpackコマンドをSOAHOST1で実行し、テンプレート・パックを作成します。

SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
 
SOAHOST1> ./pack.sh -managed=true -domain=MW_HOME/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale

次のコマンドをSOAHOST1で実行し、作成したテンプレート・ファイルをOSBHOSTnにコピーします。

SOAHOST1> scp soadomaintemplateScale.jar oracle@OSBHOSTN:/ ORACLE_BASE/product/fmw/soa/common/bin

次のようにOSBHOSTNでunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。

OSBHOSTN> cd ORACLE_BASE/product/fmw/soa/common/bin
 
OSBHOSTN> ./unpack.sh -domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar

新しいサーバーに対してTX永続ストアを構成します。これは、共有記憶域についての推奨事項で示されているように、他のノードから参照できる場所に構成します。

管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OSBn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとOSBHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。

ホスト名の検証を無効化するには、次の手順を実行します。
1. Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
2. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
4. 表の「名前」列で「WLS_OSBn」を選択します。
  
  サーバーの「設定」ページが表示されます。
5. 「SSL」タブをクリックします。
6. 「詳細」をクリックします。
7. 「ホスト名の検証」を「なし」に設定します。
8. 「保存」をクリックします。
新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。
```
OSBHOSTN> WL_HOME/server/bin/startNodeManager <new_node_ip>
```
管理コンソールから新しい管理対象サーバーを起動して、テストします。
1. クラスタ内の既存の管理対象サーバーをすべて停止します。
2. 新しく作成した管理対象サーバーWLS_OSBnが実行中であることを確認します。新しく作成した管理対象サーバー上のアプリケーション(http://vip:port/sbinspection.wsil)にアクセスします。アプリケーションが機能している必要があります。

新しい管理対象サーバーに対してサーバー移行を構成します。

注意:

この新しいノードでは既存の共有記憶域インストールを使用しているため、ノードではすでに、ノード・マネージャと、ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限などの、サーバー移行用に構成された環境が使用されています。新しいノードには、すでに新しいOSB管理対象サーバーの浮動IPが存在します。

次の手順を実行してサーバー移行を構成します。

管理コンソールにログインします。
左側のペインで、「環境」を開き、「サーバー」を選択します。
移行を構成するサーバー(ハイパーリンクで表示)を、表の「名前」列から選択します。このサーバーの「設定」ページが表示されます。
「移行」タブをクリックします。

「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。

たとえば、すでにWLS_OSB1が実行されているOSBHOST1上の新しい管理対象サーバーには、OSBHOST2を選択します。すでにWLS_OSB2が実行されているOSBHOST2上の新しい管理対象サーバーには、OSBHOST1を選択します。

注意:

新しいサーバーの移行ターゲットには、負荷が最小のマシンを指定することをお薦めします。このノードのリソースが追加の管理対象サーバーの持続に十分対応できるように、必須の容量計画を立てる必要があります。

「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

この新しいサーバーのサーバー移行をテストします。新しいサーバーを追加したノードで次の手順を実行します。

管理対象サーバーWLS_OSBnを停止します。

そのためには、管理対象サーバーのPIDに対してkill -9 <pid>を実行します。ノードのPIDは、ps -ef | grep WLS_OSBnを使用して確認できます。

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了します。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_OSBnのpidを確認します。

MW_HOME\jrockit_160_<バージョン>\bin\jps -l -v

ノード・マネージャ・コンソールに、WLS_OSBnの浮動IPが無効になったことを示すメッセージが表示されることを確認します。
ノード・マネージャがWLS_OSBnの2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。

ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:

5.15 Oracle BAMの高可用性の構成

この項では、BAMに2ノードの高可用性構成を設定する方法を説明します。BAM ServerアプリケーションとBAM Webアプリケーションについても触れます。

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

第5.15.1項「環境の準備: Oracle BAMの高可用性構成の設定前に必要な手順」
第5.15.2項「WEBHOST1へのOracle HTTP Serverのインストール」
第5.15.3項「Oracle Fusion Middlewareホームのインストール」
第5.15.4項「BAMHOST1でのVIP0とVIP1の有効化」
第5.15.5項「WebLogic ServerのOracle BAMドメインを作成するためのBAMHOST1でのOracle Fusion Middleware構成ウィザードの実行」
第 5.15.6項「BAMHOST1での管理サーバー用およびWLS_BAM1用boot.propertiesの作成」
第5.15.7項「BAMHOST1での管理サーバーの起動」
第5.15.8項「サーバーに対するホスト名の検証の無効化」
第5.15.9項「BAM UMS用のJMS永続ストアの構成」
第5.15.10項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」
第5.15.11項「BAMHOST2からのBAM Serverシステムのターゲット指定解除」
第5.15.12項「pack/unpackユーティリティを使用したBAMHOST1からのドメイン構成の伝播」
第5.15.13項「BAMHOST1およびBAMHOST2でのノード・マネージャの起動」
第5.15.14項「Oracle BAMシステムの起動」
第5.15.15項「WLS_BAMサーバーのOracle RACフェイルオーバーの構成」
第5.15.16項「BAMHOST1でBAM Serverを使用するためのBAM Webアプリケーションの構成」
第5.15.17項「Oracle HTTP Serverの管理サーバーおよびWLS_BAMn管理対象サーバーの構成」
第5.15.18項「Oracle HTTP Serverを使用したアクセスの検証」
第5.15.19項「WLS_BAMサーバーのサーバー移行の構成」

構成手順では次のアーキテクチャを対象とします。

注意:

図5-54は、この項の構成手順で作成するアーキテクチャの例を表しています。

図5-54 Oracle BAMの高可用性アーキテクチャ

「図5-54 Oracle BAMの高可用性アーキテクチャ」の説明

図5-54は、Oracle BAM Webアプリケーションを実行する2ノードのクラスタを表しています。一方のノードでは、Oracle BAM Serverも実行されています。Oracle WebLogic Serverは、BAM Webアプリケーションへの受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。ロード・バランサは、システムをフロントエンド処理し、クライアントからのリクエストを2つのHTTP Serverに配布します。Oracle RACデータベースは、メタデータとBAMスキーマを格納します。

5.15.1 環境の準備: Oracle BAMの高可用性構成の設定前に必要な手順

次の各項では、Oracle BAMの高可用性構成を設定する前に必要となる手順について説明します。

5.15.1.1 データベースに関する前提条件

Oracle BAMでは、サポートされているデータベースが存在している必要があります。

http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html

データベースのバージョンを調べるには、次の問合せを実行します。

SQL>select version from sys.product_component_version where product like 'Oracle%';

5.15.1.2 VIPとIPに関する前提条件

アーキテクチャの図で示すような、2つの異なる仮想IPをリスニングするBAMHOST1上の管理サーバーとBAM Serverを、表5-19のように構成します。そのためには、ボックス内の対応するVIPのプロビジョニングと、ネットワーク上のDNSシステムで関連付けられているホスト名が必要です。インストールを実行する前に、各VIPが使用可能であり、BAMHOST1とBAMHOST2からアクセスできることを確認します。

表5-19 仮想ホスト

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

5.15.1.3 データベース・リポジトリのインストールと構成

次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。

Oracle Clusterware

10g リリース2(10.2)については、Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersのインストレーション・ガイドを参照してください。
11g リリース1(11.1)以降については、Oracle Clusterwareインストレーション・ガイドを参照してください。

自動ストレージ管理

10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。
11g リリース1(11.1)以降については、Oracle Clusterwareインストレーション・ガイドを参照してください。
インストーラを実行するときは、「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。

Oracle Real Application Cluster

10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。
11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

データベースの初期化パラメータ

次の初期化パラメータが、必要な値に設定されていることを確認します。これは、リポジトリ作成アシスタントによってチェックされます。

表5-20 必要な初期化パラメータ

パラメータ	必要な値	パラメータ・クラス
`PROCESSES`	300以上	静的

SQL*Plusを使用して初期化パラメータの値をチェックするには、SHOW PARAMETERコマンドを次のように使用します。

SYSユーザーとして、SHOW PARAMETERコマンドを次のように発行します。

SQL> SHOW PARAMETER processes

次のコマンドを使用して初期化パラメータを設定します。

SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE

データベースを再起動します。

注意:

5.15.1.4 Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用したOracle Fusion Middlewareスキーマのロード

Oracle Fusion Middleware BAMのコンポーネントをインストールする前に、11g(11.1.1)Oracle Fusion Middlewareのメタデータ・ストアとBAMスキーマをReal Application Clusterデータベースにインストールします。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。RCUのインストールの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

5.15.1.4.1 RCUの実行

RCUを実行して、Oracle Fusion Middleware 11gに必要なメタデータをインストールします。

次のコマンドを使用してRCUを起動します。
```
RCU_HOME/bin/rcu &
```
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードし、「次へ」をクリックします。
「データベース接続の詳細」画面で、データベースの接続情報を入力します。
- データベース・タイプ: Oracle Databaseを選択します。
- ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合、ホスト名としてVIP名またはノード名の1つを指定します: BAMDBHOST1VIRTUAL
- ポート: データベースのポート番号: 1521
- サービス名: データベースのサービス名を入力します: bamha.mycompany.com
- ユーザー名: SYS
- パスワード: SYSユーザーのパスワードを入力します。
- ロール: SYSDBA
「次へ」をクリックします。
次のような警告メッセージを受信する場合があります。

接続先のデータベースには非UTF8 charsetが含まれています。このデータベースを使用して複数言語のサポートを求める場合、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。
その場合は、「無視」または「停止」をクリックします。
「コンポーネントの選択」画面で「接頭辞の新規作成」を選択し、BAMHAのように、データベース・スキーマに使用する接頭辞を入力します。

後の手順で利用できるように、このスキーマ名を書き留めておきます。
- 次のスキーマを選択します。
  - AS共通スキーマ:
    
    Metadata Services
  - SOAインフラストラクチャ:
    
    Business Activity Monitoring
    
    User Messaging
「次へ」をクリックします。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。
「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。

RCUの使用方法の詳細は、Oracle Fusion Middlewareインストレーションの概念およびリポジトリ作成ユーティリティ・ユーザーズ・ガイドを参照してください。

5.15.1.5 ロード・バランサの仮想サーバー名とポートの構成

この項では、Oracle BAMの高可用性環境をデプロイするためのロード・バランサの前提条件について説明します。

ロード・バランサ

Oracle BAMは、2つのOracle HTTP ServerがWeb層コンポーネントとして含まれた高可用性構成にデプロイされた場合は、ハードウェア・ロード・バランサを使用します。ハードウェア・ロード・バランサには、次の機能が必要です。

仮想ホスト名を介した実サーバー・プールへのトラフィックのロード・バランシング機能: クライアントは、仮想ホスト名を使用して(実ホスト名を使用するかわりに)、サービスにアクセスします。これにより、ロード・バランサは、プール内のサーバーに対するリクエストをロード・バランシングできます。
ポート変換の構成: ロード・バランサには、1つのポートで受信した受信リクエストを別のポートで実行されているサーバー・プロセスにルーティングできるポート変換機能が必要です。たとえば、ポート80で受信したリクエストをポート7777にルーティングできます。
ポート(HTTP/HTTPS)の監視
仮想サーバーとポートの構成: 外部ロード・バランサの仮想サーバー名とポートを構成する機能。さらに、仮想サーバー名とポートは次の要件を満たしている必要があります。
- ロード・バランサには複数の仮想サーバーを構成できる必要があります。各仮想サーバーに対し、ロード・バランサには2つ以上のポートでトラフィック管理を構成できることが必要です。たとえば、通常は、HTTPおよびHTTPSトラフィック用の仮想サーバーとポートでロード・バランサを構成する必要があります。
- 仮想サーバー名をIPアドレスに関連付け、DNSに含める必要があります。クライアントは、仮想サーバー名を介してロード・バランサへアクセスできる必要があります。
ノード障害を検出し、障害が発生したノードへのトラフィックのルーティングを即座に停止する機能。
リソースの監視/ポートの監視/プロセス障害検出: ロード・バランサは、サービスおよびノードの障害を通知などの方法を通じて検出し、障害が発生したノードへの非Oracle Netトラフィックの送信を停止できる必要があります。ロード・バランサに障害の自動検出機能がある場合は、それを使用する必要があります。
フォルト・トレラント・モード: ロード・バランサをフォルト・トラレント・モードに構成することを強くお薦めします。
その他: トラフィックの転送先となるバックエンド・サービスが使用できない場合、コール元のクライアントに即座に戻るようにロード・バランサの仮想サーバーを構成することを強くお薦めします。この構成は、クライアント・マシンのTCP/IP設定に基づいてタイムアウト後にクライアント側で接続を切断する構成よりも推奨されます。
スティッキーなルーティング機能: CookieまたはURLに基づいたコンポーネントへのスティッキーな接続を維持する機能。
SSLアクセラレーション: SSLアクセラレーションは、SSLトランザクションで実行され、プロセッサを集中的に使用する公開鍵暗号化アルゴリズムを、ハードウェア・アクセラレータにオフロードする方法です。

この機能は推奨されますが、必須ではありません。

表5-21は、Oracle BAMの高可用性環境で外部ロード・バランサに使用する仮想サーバー名の例を示しています。

表5-21 BAMの外部ロード・バランサの仮想サーバー名とポート

コンポーネント	仮想サーバー名
Oracle BAM	bam.mycompany.com
WebLogic Server管理コンソール	admin.mycompany.com
Oracle Enterprise Manager Fusion Middleware Control	admin.mycompany.com

仮想サーバー名

この項では、この章で説明する高可用性デプロイメントのために設定が必要な仮想サーバー名について説明します。

bam.mycompany.com

bam.mycompany.comは、ランタイムBAM WebコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして機能する仮想サーバー名です。SSLと非SSLの両方のポートへのトラフィックが構成され、通常、非SSLはSSLにリダイレクトされます。クライアントは、アドレスbam.mycompany.com:443を使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサ上に定義されます。

admin.mycompany.com

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

WEBHOST1にOracle HTTP Serverをインストールする手順は次のとおりです。

サーバーが次の要件を満たしていることを確認します。
- システム、パッチ、カーネルなどの要件が、『Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド』で指定されている要件を満たしています。
- ポート7777が、ノード上のどのサービスによっても使用されていない。このことを確認するには、次のコマンドを実行します。
  
  UNIX:
```
netstat -an | grep LISTEN | grep ":7777"
```
  Windows:
```
netstat -an | findstr "LISTEN" | findstr ":7777"
```
ポートを使用中の場合は、それらのポートを使用可能にします。
UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。

/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。
Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。

UNIXでは、コマンドrunInstallerを実行します。

Windowsでは、setup.exeをダブルクリックします。
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。
「前提条件のチェック」画面で、前提条件がすべて満たされていることを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、場所を次のように設定します。

/u01/app/oracle/product/11.1.1/ohs_1
「次へ」をクリックします。
「コンポーネントの構成」画面で、次の操作を行います。
- 「Oracle HTTP Server」を選択します。
- 「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。
- 「次へ」をクリックします。
「コンポーネントの詳細の指定」画面で、次の値を入力します。
- インスタンス・ホームの場所: /u01/app/oracle/product/11.1.1/ohs_1/instances/ohs_instance1
- インスタンス名: ohs_instance1
- OHSコンポーネント名: ohs1
「次へ」をクリックします。
「ポートの構成」画面で、次の手順を実行します。
- 「構成ファイルを使用してポートを指定」を選択し、インストール・ディスクからユーザーのホームにstaticports.iniテンプレート・ファイルをコピーします(このファイルは/Disk1/stage/Responseディレクトリにあります)。次に、「参照」ボタンを使用して、このファイルを選択します。
- ファイルの表示/編集をクリックして、エディタでstaticports.iniファイルを開きます。
- このファイルのOracle HTTP Serverポートを7777に変更します。
- ファイルを保存します。
「次へ」をクリックします。
「構成サマリー」画面で、選択内容が正しいことを確認して「インストール」をクリックします。
「インストールの進行状況」画面で、次の操作を行います。

UNIXシステムでは、ダイアログ・ボックスが表示され、oracleRoot.shスクリプトを実行するように求められます。コマンド・ウィンドウを開き、表示される指示に従ってスクリプトを実行します。

「次へ」をクリックします。
「構成」画面で、いくつかの構成アシスタントが連続して開始されます。構成アシスタントが終了すると、「構成が完了しました」画面が表示されます。
「構成が完了しました」画面で、「終了」をクリックして終了します。
WEBHOST2に対して手順を繰り返し、WEBHOST1アドレスとWEBHOST2アドレスの両方を含むプールを使用してロード・バランシング・ルーターを構成します。

5.15.2.1 Oracle HTTP Serverの検証

Oracle HTTP Serverが正しく設定されていることを確認するには、ブラウザで次のURLを使用し、サーバーのルートURLコンテキストにアクセスします。

HTTP://WEBHOST1:7777/

Oracle HTTP Serverが正しく設定されている場合は、ブラウザに「Hello World」ページが表示されます。

5.15.3 Oracle Fusion Middlewareホームのインストール

この項では、Oracle WebLogic ServerとOracle Fusion Middleware BAMを実行するアプリケーション層のすべてのノードにOracle Fusion Middlewareをインストールする方法について説明します。

Oracle Fusion Middlewareの、次のコンポーネントをインストールします。

Oracle WebLogic Server(第5.15.3.1項「Oracle WebLogic Serverのインストール」を参照)
Oracle SOA Suite(第5.15.3.2項「Oracle SOA Suiteインストーラを使用したOracle BAMのインストール」を参照)

5.15.3.1 Oracle WebLogic Serverのインストール

アプリケーション層にあるすべてのノードにOracle WebLogic Serverをインストールする手順は次のとおりです。

Oracle WebLogic Serverインストーラを起動します。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。
- 「新しいミドルウェア・ホームを作成する」を選択します。
- 「ミドルウェア・ホーム・ディレクトリ」フィールドで、MW_HOMEと入力します。
- 「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。
「製品とコンポーネントの選択」画面で、「次へ」をクリックします。
「JDKの選択」画面で、「Oracle JRockit 160_20_D1.0.1-2124 SDK」のみを選択して「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。

WL_HOME

「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」の選択を解除して「完了」をクリックします。

5.15.3.2 Oracle SOA Suiteインストーラを使用したOracle BAMのインストール

Oracle BAMは、Oracle SOA Suiteの一部としてインストールされます。11g Oracle SOA Suiteインストーラを使用して、アプリケーション層のすべてのノードに対し、次のように必要なOracle BAMバイナリをインストールします。

Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。

/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。
Oracle FMW 11g SOA Suiteインストーラを起動します。

UNIXの場合:
```
BAMHOST1> runInstaller
```
Windowsの場合:
```
BAMHOST1> setup.exe
```
Oracle FMW 11g SOA Suiteインストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、MW_HOME/jrockit_160_<バージョン>のように入力します。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、次の操作を行います。
- 「MiddleWareホーム」には、MW_HOMEと入力します。
- 「Oracleホーム・ディレクトリ」には、soaと入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
「インストール完了」画面で「終了」をクリックします。

5.15.4 BAMHOST1でのVIP0とVIP1の有効化

5.15.5 WebLogic ServerのOracle BAMドメインを作成するためのBAMHOST1でのOracle Fusion Middleware構成ウィザードの実行

SOAホーム・ディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーとOracle BAMコンポーネントが格納されるドメインを作成します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースの場合は、すべてのインスタンスが実行されている必要があります。

SOA/BAMホーム・ディレクトリにある、Oracle Fusion Middlewareの構成ウィザードの場所に、ディレクトリを変更します。
```
BAMHOST1> cd ORACLE_HOME/common/bin
```
Oracle Fusion Middlewareの構成ウィザードを起動します。

UNIXの場合:
```
BAMHOST1> ./config.sh
```
Windowsの場合:
```
BAMHOST1> config.cmd
```
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」で、「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択して、次の製品を選択します(デフォルトでは、Basic WebLogic Server Domain - 10.3.6.0が選択されています)。
- Oracle Business Activity Monitoring
- Oracle WSM-PM(デフォルトで選択)
- Enterprise Manager
- JRF(デフォルトで選択)
「次へ」をクリックします。
「ドメイン名と場所の指定」画面で、次のエントリを作成します。
- ドメイン名: bamdomain
- ドメインの場所: デフォルトを受け入れます。
- アプリケーションの場所: デフォルトを受け入れます。
「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者が使用するユーザー名とパスワードを入力します。「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
- WebLogicドメインの起動モード: 「本番モード」を選択
- JDKの選択: 「Oracle SDK1.6.0_05」を選択
「次へ」をクリックします。
「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。

図5-55 JDBCコンポーネント・スキーマの構成

「図5-55 JDBCコンポーネント・スキーマの構成」の説明
1. 画面に次のデータ・ソースが表示されていることを確認します。表5-22に示されているユーザー名は、RCUからのスキーマ作成で接頭辞にbamhaが使用されていることを想定しています。
  
  表5-22 データ・ソースの値の構成
  
  データ・ソースユーザー名
  
  BAMDataSource
  
  bamha_orabam
  
  OraSDPMDataSource
  
  bamha_orasdpm
  
  mds-owsm
  
  bamha_mds
2. 「コンポーネント・スキーマのRAC構成」については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択します。単一のデータベース構成の場合は、「変換しない」を選択します。「変換しない」を選択した場合は、ステップ10にスキップします。
3. 「次へ」をクリックします。

「JDBCコンポーネント・スキーマの構成」画面で、次のフィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

マルチ・データ・ソースの場合は、次のフィールドに値を入力します。

図5-56 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面

「図5-56「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面」の説明

GridLinkデータ・ソースの場合は、次のフィールドに値を入力します。

図5-57 GridLink RACコンポーネント・スキーマの構成

「図5-57 GridLink RACコンポーネント・スキーマの構成」の説明

すべてのスキーマを選択した状態で、次のフィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

ドライバ: RACの場合には、OracleのRACサービス・インスタンス接続用ドライバ(Thin)、バージョン:10、11を選択します。GridLinkの場合は、OracleのGridLink接続用ドライバ(Thin)、バージョン:10以降を選択します。

注意:

ユーザー名: スキーマの完全ユーザー名(接頭辞を含む)を入力します。
パスワード: スキーマへのアクセスに使用するパスワードを入力します。

注意:

マルチ・データ・ソースの場合は、「追加」をクリックします。Oracle RACインスタンスの詳細を入力します。

一度に1つのデータ・ソースを選択し、適切な詳細を追加することにより、各スキーマを更新します。

すべてのスキーマ(BAMスキーマのみ、ユーザー・メッセージング・サービスのみ、OWSM MDSスキーマのみ)に情報が入力されていることを確認します。
「次へ」をクリックします。

「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が成功したことを確認します。正常に接続できない場合は、「前へ」をクリックしてエントリを修正します。

すべての接続が正常になったら「次へ」をクリックします。
「オプションの構成を選択」画面で、「管理サーバー」→「管理対象サーバー」→クラスタとマシン→デプロイメントとサービスを選択して、「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
- 名前: AdminServer
- リスニング・アドレス: VIP0
- リスニング・ポート: 7001
- SSLリスニング・ポート: N/A
- SSL有効: 選択を解除
「次へ」をクリックします。

「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。

表5-23 管理対象サーバーの構成

名前	リスニング・アドレス	リスニング・ポート	SSLリスニング・ポート	SSL有効
WLS_BAM1	BAMHOST1VHN1	8001	n/a	いいえ
WLS_BAM2	BAMHOST2(BAM Server WLS_BAM2はサーバー移行を使用しません)	8001	n/a	いいえ

注意:

標準の推奨事項は、個々のWebLogic管理対象サーバー内でカスタム・アプリケーションおよび他のシステムを実行するためのものです。図5-54で説明しているカスタムWLS管理対象サーバーの作成については、ここでは取り上げません。

「次へ」をクリックします。

「クラスタの構成」画面で、次のクラスタを追加します。
- 名前: BAM_Cluster
- クラスタ・メッセージング・モード: unicast
- マルチキャスト・アドレス: N/A
- マルチキャスト・ポート: N/A
- クラスタ・アドレス: 空白のまま
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、BAM_Clusterに次のサーバーを割り当てます。
- WLS_BAM1
- WLS_BAM2
「次へ」をクリックします。
「マシンの構成」画面で、次の操作を行います。
- デフォルトとして表示される「LocalMachine」を削除します。
- 「UNIXマシン」タブをクリックし、次のマシンを追加します。
表5-24 マシンの構成

名前ノード・マネージャのリスニング・アドレス

BAMHOST1

BAMHOST1

BAMHOST2

BAMHOST2

その他すべてのフィールドをデフォルト値のままにして、「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。
- BAMHOST1: AdminServer、WLS_BAM1
- BAMHOST2: WLS_BAM2
「次へ」をクリックします。
「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。
- ユーザー・メッセージングのデプロイメントがBAM_Clusterにのみターゲット指定されていること(usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです)。
- wsm-pmがBAM_Clusterにのみターゲット指定されていること。
- DMSアプリケーションがBAM_Clusterと管理サーバーにターゲット指定されていること。
- oracle.rules.*、oracle.sdp.*、oracle.bam.*の各デプロイメントがBAM_Clusterにのみターゲット指定されていること。
- oracle.wsm.seedpoliciesライブラリがBAM_Clusterにのみターゲット指定されていること。
「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。
- WSMの起動クラスがBAM_Clusterにのみターゲット指定されていること。
- mds-wsm、mds-wsm-rac0およびmds-wsm-rac1が、BAM_ClusterとAdminServerの両方にターゲット指定されていること。
- OrasDPMDatasource、OrasDPMDatasource-rac0およびOrasDPMDatasource-rac1がBAM_Clusterにターゲット指定されていること。
- OWSMの起動クラスがBAM_Clusterにのみターゲット指定されていること、DMSの起動クラスが、BAM_ClusterとAdminServerの両方にターゲット指定されていること、mds-wsm、mds-wsm-rac0およびmds-wsm-rac1が、BAM_ClusterとAdminServerの両方にターゲット指定されていること。
- mds-soa、mds-soa-rac0およびmds-soa-rac1が、BAM_ClusterとAdminServerの両方にターゲット指定されていること。
「構成のサマリー」画面で「作成」をクリックします。
ドメインの作成中画面で「完了」をクリックします。

5.15.6 BAMHOST1での管理サーバー用およびWLS_BAM1用boot.propertiesの作成

この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。BAMHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。

管理サーバーに対しては、次の手順を実行します。

次のディレクトリを作成します。

mkdir ORACLE_BASE/product/fmw/user_projects/domains/bamdomain/servers/AdminServer/security

テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

username=adminuser
password=password

注意:

管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

5.15.7 BAMHOST1での管理サーバーの起動

BAMHOST1上の管理サーバーを起動するには、次のコマンドを実行します。

Linuxの場合:

BAMHOST1> cd MW_HOME/user_projects/domains/bamdomain/bin

BAMHOST1> ./startWebLogic.sh

Windowsの場合:

startWebLogic.cmd

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

ブラウザでhttp://VIP0:7001/consoleにアクセスします。
管理者としてログインします。
管理対象サーバーとしてWLS_BAM1およびWLS_BAM2が表示されていることを確認します。
BAM_Clusterクラスタが表示されていることを確認します。
Enterprise Manager(http://VIP0:7001/em)にアクセスできることを確認します。

5.15.8 サーバーに対するホスト名の検証の無効化

この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成を完了した後で再度有効化します。

ホスト名の検証を無効化するには、次の手順を実行します。

管理コンソールで、「管理サーバー」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
管理コンソールで、「WLS_BAM1」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
管理コンソールで、「WLS_BAM2」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
管理サーバーを再起動して、変更を有効にします。
変更を保存およびアクティブ化します。

5.15.9 BAM UMS用のJMS永続ストアの構成

BAMHOST1とBAMHOST2の両方から参照できるディレクトリに、すべての永続ストアの場所を構成します。これは、サーバーが別のノードに移行されたときにトランザクションを再開できるようにするために必要です。両方のノードで永続ストアの共有場所を使用することで、フェイルオーバーが発生してもメッセージが失われないことが保証されます。

注意:

管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。

「永続ストアの概要」ページが表示されます。
表の「名前」列から永続ストア(ハイパーリンクとして表示)を選択します。

その永続ストアの「設定」ページが表示されます。
「構成」タブで、クラス内の他のサーバーで使用可能な永続記憶域ソリューション(NASやSANなど)の場所を、「ディレクトリ」フィールドに入力します。この場所を指定することで、保留中のJMSメッセージを送信できます。
「保存」をクリックします。
同じ手順をすべての永続ストアに対して実行します。
変更を保存およびアクティブ化します。

5.15.10 トランザクション・リカバリのためのデフォルトの永続ストアの構成

各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

注意:

可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。

デフォルトの永続ストアの場所を設定する手順は次のとおりです。

管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。

「サーバーのサマリー」ページが表示されます。
表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。

選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。
「サービス」タブをクリックします。
ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。

変更を保存およびアクティブ化します。

注意:

トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。このディレクトリは、サーバーを再起動する前にも存在している必要があります。

5.15.11 BAMHOST2からのBAM Serverシステムのターゲット指定解除

BAM内のBAM Serverコンポーネントはシングルトンであるため、サーバー移行に対して構成する前に、WLS_BAMサーバーのいずれかから、そのコンポーネントのターゲット指定を解除する必要があります。解除しないと、2つのアクティブなBAM Serverが使用されることになり、データが異なるための不整合の原因となります。このように、BAM WebアプリケーションはBAMHOST1とBAMHOST2の両方で実行されますが、BAM Serverは、最初はBAMHOST1でのみアクティブになります。

次の手順では、WLS_BAM2からBAM Serverランタイムを削除します。WLS_BAM2からBAM Serverアーティファクトのターゲット指定を解除する手順は次のとおりです。

Oracle WebLogic管理コンソール(http://BAMHOST1VHN0:7001/console)にログインします。
「ドメイン構造」ウィンドウで、「環境」→「サーバー」を選択します。

「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_BAM2」を選択します。

WLS_BAM2の「設定」ページが表示されます。
「デプロイメント」タブをクリックします。
表の「名前」列から「oracle-bam」アプリケーションを選択します。

oracle-bamアプリケーションの「設定」ページが表示されます。
「ターゲット」タブをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。

表5-25の説明に従って、モジュールのターゲットを変更します。

変更を保存およびアクティブ化します。

注意:

表5-25の説明に従って、これらのコンポーネントをすべてターゲット指定する必要があります。ターゲット指定を誤ると、BAMシステムが起動しなくなります。

表5-25 oracle-bamコンポーネントのターゲット・タイプ

コンポーネント	タイプ	ターゲット
oracle-bam(11.1.1)	エンタープライズ・アプリケーション	BAM_Cluster
/oracle/bam	WEBAPP	WLS_BAM1
oracle-bam-adc-ejb.jar	EJB	WLS_BAM1
oracle-bam-ems-ejb.jar	EJB	WLS_BAM1
oracle-bam-eventengine-ejb.jar	EJB	WLS_BAM1
oracle-bam-reportcache-ejb.jar	EJB	WLS_BAM1
oracle-bam-statuslistener-ejb.jar	EJB	WLS_BAM1
OracleBAM	WEBAPP	BAM_Cluster
OracleBAMWS	WEBAPP	BAM_Cluster
sdpmessagingclient-ejb.jar	EJB	WLS_BAM1

5.15.12 pack/unpackユーティリティを使用したBAMHOST1からのドメイン構成の伝播

Pack/Unpackユーティリティを使用して、ドメイン構成をBAMHOST1に伝播する手順は次のとおりです。

次のpackコマンドをBAMHOST1で実行し、テンプレート・パックを作成します。

BAMHOST1> cd ORACLE_COMMON_HOME/common/bin
BAMHOST1> ./pack.sh -managed=true
domain=ORACLE_BASE/product/fmw/user_projects/domains/bamdomain/
-template=bamdomaintemplate.jar 
-template_name=bam_domain_template

unpackコマンドをBAMHOST2で実行し、伝播されたテンプレートを解凍します。

BAMHOST2> cd ORACLE_COMMON_HOME/common/bin
BAMHOST2> ./unpack.sh
 -domain=MW_HOME/user_projects/domains/bamdomain/
 -template=bamdomaintemplate.jar

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

BAMHOST1およびBAMHOST2でノード・マネージャを起動する手順は次のとおりです。

setNMProps.shスクリプトを実行します。このスクリプトはORACLE_COMMON_HOME/common/binディレクトリに格納されています。

このスクリプトによって、ノード・マネージャを起動する前にStartScriptEnabledプロパティがtrueに設定され、管理コンソールからサーバーを起動できるようになります(BAM Serverに必要な環境変数は、ドメイン・ディレクトリのデフォルトの起動スクリプトに設定されています)。
```
BAMHOST1> cd ORACLE_COMMON_HOME/common/bin
BAMHOST1> ./setNMProps.sh
```
注意:

クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。
次のコマンドを実行してノード・マネージャを起動します。
```
BAMHOST1> cd WL_HOME/server/bin
BAMHOST1> ./startNodeManager.sh
```
BAMHOST2のノード・マネージャに対してステップ1と2を繰り返します。

5.15.14 Oracle BAMシステムの起動

BAMHOST1上の管理対象サーバーWLS_BAM1を起動する手順は次のとおりです。

管理対象サーバーWLS_BAM1を起動します。
1. 次のURLを使用して、管理コンソールにログインします。
  
  http://bamhost1vhn0:7001/console
2. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」を選択します。
  
  「サーバーのサマリー」ページが表示されます。
3. 「制御」タブをクリックします。
4. 表の「サーバー」列から「WLS_BAM1」を選択します。
5. 「起動」をクリックします。
http://bamhost1vhn1:9001/OracleBAMにアクセスしてWLS_BAM1のステータスを確認します。
管理対象サーバーWLS_BAM2を起動します。
1. http://bamhost1vhn0:7001/consoleから、管理コンソールにログインします。
2. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」を選択します。
  
  「サーバーのサマリー」ページが表示されます。
3. 「制御」タブをクリックします。
4. 表の「サーバー」列から「WLS_BAM2」を選択します。
5. 「起動」をクリックします。
HTTP://BAMHOST2:9001/OracleBAMにアクセスしてWLS_BAM2の状態を確認します。

管理対象サーバーが次のメッセージで起動に失敗した場合、

Listener refused the connection with the following error:
ORA-12519, TNS:no appropriate service handler found
The Connection descriptor used by the client was <db_connect_string>

データベースのPROCESSES初期化パラメータができるだけ高い値に設定されていることを確認してください。

5.15.15 WLS_BAMサーバーのOracle RACフェイルオーバーの構成

Oracle RACをBAMスキーマのリポジトリとして使用しているときにデータベースで障害が発生した場合のBAMサーバーの動作を、Oracle BAMでカスタマイズできます。このカスタマイズを可能にするプロパティは、アプリケーションに応じて、また各BAMシステムに必要とされる動作に基づいて調整できます。プロパティは、Fusion Middleware Controlのコンソール・システムのMBeanブラウザ、またはOracle BAM固有の対応のXML構成ファイルで構成されます。

データベースに対するOracle BAMのフェイルオーバーをOracle RAC構成で完全に無効化する場合は、Fusion Middleware Controlのコンソール・システムのMBeanブラウザで、BAMサーバーのUseDBFailoverをfalseに設定します。このプロパティのデフォルト値はtrueです。つまり、フェイルオーバーが実行されます。また、データベース・インスタンス障害時のデータベースへのアクセス試行回数(進行中のトランザクションでBAMが再試行する回数)を増減することもできます。再試行回数を調整するには、Fusion Middleware Controlのコンソール・システムのMBeanブラウザでMaxDBNodeFailoverRetriesを変更します。MaxDBNodeFailoverRetriesのデフォルト値は5回です。Oracle BAMに構成可能なプロパティの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

5.15.16 BAMHOST1でBAM Serverを使用するためのBAM Webアプリケーションの構成

BAMHOST1でBAM Serverを使用するためのOracleBamWeb(WLS_BAM1)アプリケーションおよびOracleBamWeb(WLS_BAM2)アプリケーションを構成する手順は次のとおりです。

次のURLで、Oracle Enterprise Manager Fusion Middleware Controlにアクセスします。
```
http://bamhost1vhn0:7001/em
```
ナビゲーション・ツリーの「BAM」を開きます。
「OracleBamWeb(WLS_BAM1)」を右クリックします。
- ポップアップ・メニューの「BAM Webプロパティ」を選択します。
  
  「BAM Webプロパティ」ページが表示されます。
- 次のプロパティを定義します。
  - アプリケーションURLにWEBHOST:7777と入力します。
  - サーバー名にBAMHOST1VHN1と入力します。
- MBeanブラウザを使用して、BAM Serverのリスニング・ポートを変更します。そのためには、次の手順に従ってください。
  - Oracle Enterprise Manager Fusion Middleware Controlにログオンします。
  - 左側のナビゲーション・ツリーでドメイン名を開きます。
  - 左側のナビゲーション・ツリーで「BAM」アイテムを開きます。
  - 右上の「BAM」ドロップダウン・メニューで「MBeanブラウザ」を選択します。
  - 右側で「oracle.bam.web」→「サーバー」→「アプリケーション」→「構成」→「BAMWebConfig」に移動します。
  - 「ServerPort」フィールドのDEFAULT値を9001に置き換えます。
ナビゲーション・ツリーで「OracleBamWeb(WLS_BAM2)」を選択し、同じ手順を繰り返します。

5.15.17 管理サーバーおよび管理対象サーバーWLS_BAMnのOracle HTTP Serverの構成

管理対象サーバーWLS_BAMnを含むBAM_ClusterへのOracle HTTP Serverのルーティングを有効にするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。

WEBHOST1およびWEBHOST2で、ORACLE_BASE/admin/<instance_name>/config/OHS/<component_name>/mod_wl_ohs.confファイルに次の行を追加します。

# WSM-PM
<Location /wsm-pm>
    SetHandler weblogic-handler
    WebLogicCluster bamhost1vhn1:9001,bamhost2:9001
</Location>

# UMS
<Location /sdpmessaging/ >
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>
 
# UMS WS
<Location /ucs/messaging/webservice >
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# BAM Web app
<Location /OracleBAM>
    SetHandler weblogic-handler
    WebLogicCluster bamhost1vhn1:9001,bamhost2:9001
</Location>

# BAM Web Services
<Location /OracleBAMWS>
    SetHandler weblogic-handler
    WebLogicCluster bamhost1vhn1:9001,bamhost2:9001
</Location>

mod_wl_ohs.confファイルと同じディレクトリにあるhttpd.confファイルが、ロード・バランシング・ルーター・アドレスを指す次の行を含んでいることを確認します。

NameVirtualHost *:7777
<VirtualHost *:7777>
    ServerName https://bam.mycompany.com:443
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit
</VirtualHost>

NameVirtualHost *:7777
<VirtualHost *:7777>
    ServerName admin.mycompany.com:80
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit
</VirtualHost>

注意:

このドキュメントに記載されている値(bam.mycompany.com:443, 7777、admin.mycompany:80、you@youraddressなど)は、単なる例です。実際の環境に基づく値を入力してください。

WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

WEBHOST1> ORACLE_BASE/admin/<instance_name>/bin/opmnctl restartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/admin/<instance_name>/bin/opmnctl restartproc ias-component=ohs2

5.15.18 Oracle HTTP Serverを使用したアクセスの検証

管理コンソールでBAMサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中」と表示される場合は、サーバーの状態が「起動済」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。次のURLにアクセスできることを確認します。「WEBHOSTN」には、各Oracle HTTP Serverホストの名前(WEBHOST1、WEBHOST2など)が指定されます。

http://WEBHOST1:7777/wsm-pm
http://WEBHOST2:7777/wsm-pm
http://WEBHOST1:7777/sdpmessaging/userprefs-ui
http://WEBHOST2:7777/sdpmessaging/userprefs-ui
http://WEBHOST1:7777/OracleBAM
http://WEBHOST2:7777/OracleBAM

次のURLがロード・バランシング・ルーター・アドレスを使用していることも確認します。

http://bam.mycompany.com:80/wsm-pm
http://bam.mycompany.com:80/sdpmessaging/userprefs-ui
http://bam.mycompany.com:80/OracleBAM

次の手順に従って、HTTP ServerからBAMクラスタへのルーティングとフェイルオーバーが適切に機能していることを確認します。

WLS_BAM2の実行中に、管理コンソールからWLS_BAM1を停止します。
次のURLにアクセスして、適切な機能を検証します。
- http://WEBHOST1:7777/wsm-pm
- http://WEBHOST1:7777/sdpmessaging/userprefs-ui
- http://WEBHOST1:7777/OracleBAM
管理コンソールから、WLS_BAM1を開始します。
WLS_BAM2を停止します。
前述のステップ2のURLにアクセスして、適切な機能を検証します。

5.15.19 WLS_BAMサーバーのサーバー移行の構成

Oracle BAMの高可用性アーキテクチャは、シングルトン・サービスを障害から保護するためにサーバー移行を利用します。WLS_BAM1管理対象サーバーは、障害発生時にBAMHOST2で再起動するように構成されます。このような構成では、WLS_BAM1は、Oracle WebLogic Server移行によってフェイルオーバーされる特定の浮動IPをリスニングします。WLS_BAM1管理対象サーバーのサーバー移行を構成する手順は次のとおりです。

注意:

サーバー移行が以前SOAに対して構成された場合、BAMシステムでは、同じデータ・ソースとデータベース・スキーマを使用できます。その場合、ステップ1から5は必要でないこともありますが、対応するサーバー移行/リーシング・データソースのターゲットをBAMクラスタに設定する必要があります。

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

ユーザーと表領域を作成する手順は次のとおりです。

leasingという表領域を作成します。たとえば、ユーザーsysdbaでSQL*Plusにログインし、次のコマンドを実行します。

例: SQL*Plusにsysdbaユーザーとしてログオンして、次のコマンドを実行します。
```
SQL> create tablespace leasing
        logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
        size 32m autoextend on next 32m maxsize 2048m extent management local;
```

leasingという名前のユーザーを作成し、leasing表領域に割り当てます。

SQL> create user leasing identified by welcome1;

SQL> grant create table to leasing;

SQL> grant create session to leasing;

SQL> alter user leasing default tablespace leasing;

SQL> alter user leasing quota unlimited on LEASING;

leasing.ddlスクリプトを使用してleasing表を作成します。
1. WL_HOME/server/db/oracleディレクトリにあるleasing.ddlファイルをデータベース・ノードにコピーします。
2. データベースにleasingユーザーとして接続します。
3. leasing.ddlをSQL*Plusで実行します。
```
SQL> @copy_location/leasing.ddl;
```

5.15.19.2 管理コンソールからのGridLinkデータ・ソースまたはマルチ・データ・ソースの作成

このデータ・ソースが非XAデータ・ソースであることを確認します。
Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。
したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。データ・ソースは、グローバル・トランザクションのサポートを必要としません。
これらのデータ・ソースをクラスタにターゲット指定します。
データソースの接続プールの初期容量が0に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データ・ソース名」→「接続プール」タブをクリックし、「接続数の初期値」フィールドに0を入力します。
ONSデーモンがデータベース・サーバーで常に実行中であることを確認します。ONSデーモンをデータベース・サーバーで起動するには、onsctlコマンド(start)を実行します。

GridLinkデータソースの作成

GridLinkデータ・ソースを作成する手順は次のとおりです。

管理コンソールにログインします。
まだ行っていない場合は、管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
「データ・ソースの概要」ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択します。
次の情報を入力します。
1. 「名前」フィールドで、データ・ソースの論理名を入力します。たとえば、gridlinkと入力します。
2. JNDIの名前を入力します。たとえば、jdbc/gridlinkと入力します。
3. 「次へ」をクリックします。
「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」を選択解除します。「次」をクリックします。
「個別のリスナー情報の入力」を選択して、「次へ」をクリックします。

次の接続プロパティを入力します。

サービス名: データベースのサービス名を入力します。RACサービス名を小文字で入力し、その後にドメイン名example.comを入力する必要があります。たとえば、<mydbservice>.example.comと入力します。

注意:

ホスト名: データベースをホストするサーバーのDNS名またはIPアドレス。Oracle GridLinkサービスとインスタンス間の接続の場合、特定のマルチ・データ・ソースの各データ・ソースで同じ名前にする必要があります。
Port: データベース・サーバーが接続リクエストをリスニングするポート。
データベース・ユーザー名: データベース・ユーザー名。たとえば、myDataBaseと入力します。
パスワード: パスワード。たとえば、myPassword1と入力します。
パスワードを確認して、「次へ」をクリックします。

ヒント:

詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。

コンソールにより、完全なJDBC URLが自動的に生成されます。例:

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=left)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=right)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=center)(PORT=1234)))(CONNECT_DATA=(SERVICE_NAME=myService)))

「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。

Oracle WebLogicは、管理サーバーからデータベースへの接続を作成します。接続テストの結果がページの上部に表示されます。テストに失敗した場合は、構成エラーをすべて修正してテストを再試行します。

「次へ」をクリックします。
「ONSクライアント構成」ページで、次の手順を実行します。
- 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。
- 「ONSホストとポート」で、ONSベースのFANイベントを受け取るためにONSデーモンが接続するリスニング・アドレスとリスニング・ポートのカンマ区切りのリストを入力します。単一クライアント・アクセス名(SCAN)アドレスを使用すると、FAN通知にアクセスできます。
- 「次へ」をクリックします。
「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。

「次へ」をクリックします。
「ターゲットの選択」ページで「Dept1_Cluster1」をターゲットとして選択し、「クラスタのすべてのサーバー」を選択します。
「終了」をクリックします。「変更のアクティブ化」をクリックします。

マルチ・データ・ソースの作成

マルチ・データ・ソースを作成するには、次の手順を実行します。

管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「データ・ソース」をクリックします。「JDBCデータ・ソースのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「新規」→「マルチ・データ・ソース」をクリックします。「新しいJDBCマルチ・データ・ソースの作成」ページが表示されます。
「名前」として、leasingと入力します。
「JNDI名」として、jdbc/leasingと入力します。
アルゴリズムとしてフェイルオーバー(デフォルト)を選択します。
「次へ」をクリックします。
ターゲットとして「BAM_Cluster」を選択します。
「次へ」をクリックします。
「非XAドライバ」(デフォルト)を選択します。
「次へ」をクリックします。
「新しいデータ・ソースの作成」をクリックします。
名前として、leasing-rac0と入力します。JNDI名として、jdbc/leasing-rac0と入力します。データベースのタイプとして、oracleと入力します。ドライバのタイプとして、Oracle Driver (Thin) for RAC server-Instance connection Version 10,11と入力します。

注意:

leasing表のマルチ・データ・ソースを作成するときに、名前を<MultiDS>-rac0、<MultiDS>-rac1などの形式で入力します。
「次へ」をクリックします。
「グローバル・トランザクションのサポート」の選択を解除します。
「次へ」をクリックします。
leasingスキーマのサービス名、データベース名(racdb1やracdb2などのRACノードのインスタンス名)、ホスト・ポートおよびパスワードを入力します。
「次へ」をクリックします。
「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。
データ・ソースをBAMクラスタにターゲット指定します。
データ・ソースを選択して、右の画面に追加します。
Oracle RACデータベースの2つ目のインスタンスについて「新しいデータ・ソースの作成」をクリックし、そのターゲットをBAM_Clusterに設定して、Oracle RACデータベースの2つ目のインスタンスについても同じ手順を繰り返します。
2つ目のデータ・ソースをマルチ・データ・ソースに追加します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。

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

nodemanager.propertiesファイルは、WL_HOME/server/binディレクトリにあります。

Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true

Interface=eth0

このプロパティは、浮動IPのインタフェース名(たとえば、Linuxではeth0)を指定します。

注意:

サブ・インタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0も:1も指定しないで使用します。ノード・マネージャのスクリプトは、別の:X対応のIPを移動して、追加または削除するものを決定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

注意:

Windowsの場合、Interfaceには、ネットワーク・インタフェース名を設定する必要があります。例: Interface="Local Area Connection"

NetMask

このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。
UseMACBroadcast

このプロパティでは、ARPパケットの送信時にノードのMACアドレスを使用するかどうか、すなわち、arpingコマンドで-bフラグを使用するかどうかを指定します。

この構成をBAMHOST1とBAMHOST2の2つのノードで実行します。これらのプロパティが適用されていることをノード・マネージャの出力(ノード・マネージャが起動したシェル)で確認します。適用されていないと、移行中に問題が発生する可能性があります。出力は次のように表示されます。

...
StateCheckInterval=500
Interface=eth0 (Linux) or Interface="Local Area Connection" (Windows)
NetMask=255.255.255.0
...

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

wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する手順は次のとおりです。

注意:

Windowsでは、このスクリプトの名前はwlsifconfig.cmdであり、管理者権限を持つユーザーが実行できます。

表5-26に一覧表示されているファイルがPATH環境変数に含まれていることを確認します。

表5-26 PATH環境変数に含める必要のあるファイル

ファイル	格納されているディレクトリ
`wlsifconfig.sh`	`MW_HOME/user_projects/domains/bamdomain/bin/server_migration`
`wlscontrol.sh`	`WL_HOME/common/bin`
`nodemanager.domains`	`WL_HOME//common`

wlsifconfig.shスクリプトに対するsudo構成権限の付与
- パスワード・プロンプトを使用しないで機能するsudoを構成します。
- セキュリティ上の理由から、sudoをwlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する場合は、次の手順を実行します。
  - WebLogicユーザー(oracle)に、パスワードなしのsudo権限を付与し、/sbin/ifconfig and /sbin/arpingバイナリの実行権限を付与します。
  - スクリプトがWebLogicユーザー(oracle)によって実行可能であることを確認してください。次の例は、oracleのsudo実行権限をifconfigとarpingにも付与する/etc/sudoers内のエントリを示しています。
```
Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
```
    注意:
    
    この手順で使用できるsudoとシステム権限はシステム管理者にお問い合せください。

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

クラスタ移行を構成することにより、DataSourceForAutomaticMigrationプロパティがtrueに設定されます。クラスタ内のクラスタ移行を構成する手順は、次のとおりです。

管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。
移行を構成するクラスタ(BAM_Cluster)を、表の「名前」列でクリックします。
「移行」タブをクリックします。「チェンジ・センター」で、「ロックして編集」をクリックします。
「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。この場合は、「BAMHOST1」と「BAMHOST2」を選択します。
自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。
「保存」をクリックします。
サーバー移行の候補マシンを設定します。

このタスクはWLS_BAM1に対して実行する必要があります。
1. 管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。
2. 移行を構成するサーバーを選択します。「移行」タブをクリックします。
3. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。WLS_BAM1には「BAMHOST2」を選択します。
4. 「サーバーの自動移行を有効化」を選択します。
  
  これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
5. 「保存」をクリックして、変更をアクティブ化します。
6. 管理サーバーとWLS_BAM1サーバーを再起動します。

5.15.19.6 サーバー移行のテスト

サーバー移行が適切に機能していることを確認する手順は次のとおりです。

BAMHOST1から次の処理を実行します。

次のコマンドを使用して、管理対象サーバーWLS_BAM1を強制停止します。

BAMHOST1> kill -9 <pid>

pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。

BAMHOST1> ps -ef | grep WLS_BAM1

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了します。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_BAM1のpidを確認します。

MW_HOME\jrockit_160_<バージョン>\bin\jps -l -v

ノード・マネージャ・コンソールに、WLS_BAM1の浮動IPが無効になっていることを示すメッセージが表示されます。
ノード・マネージャがWLS_BAM1の2回目の再起動を試行するのを待ちます。

ノード・マネージャは、この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。

サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

BAMHOST2から次の処理を実行します。

ローカルのノード・マネージャのコンソールを確認します。

ノード1で最後にWLS_BAM1の再起動が試行されてから30秒経過した後、BAMHOST2のノード・マネージャによって、WLS_BAM1の浮動IPが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。
BAMHOST1VHN1/OracleBAM and WEBHOST1:7777/OracleBAMを使用して、Oracle BAMコンソールにアクセスします。

管理コンソールからの検証

管理コンソールで移行を検証する手順は、次のとおりです。

管理コンソールにログインします。左側のコンソールで、「ドメイン」をクリックします。
「監視」タブ→「移行」タブをクリックします。

「移行ステータス」表に、移行の状態に関する情報が表示されます。

注意:

サーバーの移行後に、そのサーバーを元のノード/マシンにフェイルバックする場合は、Oracle WebLogic管理コンソールを使用して、管理対象サーバーを停止してから再起動します。該当するノード・マネージャによって、その管理対象サーバーは最初に割り当てられていたマシン上で起動されます。

5.15.20 BAMシステムに接続するクライアントの構成

BAMアダプタ(RMI)を使用してBAMサーバーにアクセスする場合、接続にはBAMサーバーの仮想ホスト名(BAMHOST1VNH1)を使用する必要があります。SOAPリクエストはHTTPを介して着信するため、この状況でBAMアダプタを使用する場合、ロード・バランシング・ルーター・アドレスを使用する必要があります。

ファイル	格納されているディレクトリ
wlsifconfig.sh	DOMAIN_HOME/bin/server_migration
wlscontrol.sh	WL_HOME/common/bin
nodemanager.domains	WL_HOME/common

データ・ソース	ユーザー名
BAMDataSource	bamha_orabam
OraSDPMDataSource	bamha_orasdpm
mds-owsm	bamha_mds