| Oracle Fusion Middleware高可用性ガイド 11gリリース1（11.1.1） B55898-01 |
|
 戻る |
 次へ |
Oracle Fusion Middleware SOA Suiteは、コンポジット・アプリケーションを設計、デプロイおよび管理するサービス・インフラストラクチャ・コンポーネントの完全なセットを提供します。Oracle Fusion Middleware SOA Suiteにより、サービスの作成、管理、およびコンポジット・アプリケーションやビジネス・プロセスへのオーケストレーションが可能になります。コンポジットを使用すると、様々なテクノロジのコンポーネントを1つのSOAコンポジット・アプリケーションに簡単にアセンブルできます。Oracle Fusion Middleware SOA Suiteは異機種間ITインフラストラクチャに接続するため、企業では段階的にSOAを採用できます。
この章では、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 Fusion Middleware SOA Suiteとコンポーネント
SOAコンポジット・アプリケーションは、SOAランタイムへのデプロイメントの基本単位です。サービス・コンポーネント（BPELプロセス、ビジネス・ルール、ヒューマン・タスクおよびMediatorルーティング・ルール）は、SOAコンポジットの構成要素です。コンポーネントは、デプロイメント時にサービス・エンジンにターゲット指定され、サービスと参照は、バインディング・コンポーネントを使用することで有効になります。実行時には、メッセージはバインディング・コンポーネントによって受信され、サービス・インフラストラクチャによって適切なサービス・エンジンにルーティングされます。
SOAランタイムは、Oracle WebLogic Application Serverなどのアプリケーション・サーバーのコンテキスト内で実行されます。SOAランタイムでは、基盤となるアプリケーション・サーバーのロード・バランシングと高可用性の機能を利用します。
このマニュアルでは、次のSOA Suiteコンポーネントの高可用性について説明しています。
Oracleサービス・インフラストラクチャ
Oracle BPEL Process Manager
Oracle Mediator
Oracle Human Workflow
Oracle JCAアダプタ
Oracle B2B
Oracle Web Service Manager
Oracle User Messaging Service
Oracle Business Activity Monitoring
Oracle SOAサービス・インフラストラクチャは、Oracle Fusion Middleware SOA Suiteを実行するための基盤となるサービスを提供するJava EEアプリケーションです。このJava EEアプリケーションは、Oracle Fusion Middleware SOA Suiteがインストールされると、自動的にデプロイされるランタイム・エンジンです。コンポジット（ソフトウェア・コンポーネント・アーキテクチャの基本のアーティファクト）をOracle SOAインフラストラクチャにデプロイすると、コンポジットの実行に必要なサービスが提供されます。Oracle SOAインフラストラクチャは、コンポジットに対して、デプロイメント、接続およびスレッド管理のサービスを提供します。このようなサービスによって、コンポジットのライフサイクルやランタイム動作が支えられています。
この項では、SOAサービス・インフラストラクチャの高可用性クラスタを設計するために検討する必要のある問題や考慮する必要のある事項を紹介します。この章の後半では、次に示すSOAサービス・インフラストラクチャ関連コンポーネントの問題と考慮事項について同様に説明します。
Oracle BPEL Process Manager（Oracle BPEL PM）
Oracle Mediator
Oracle JCAアダプタ
Oracle Human Workflow
Oracle B2B
Oracle Webサービスの管理とセキュリティ（Oracle WMS）
Oracle User Messaging Service
Oracle Business Activity Monitoring
バックアップとリカバリに関する考慮事項
SOAサービス・インフラストラクチャ・ファイルのバックアップに関する一般情報は、Oracle Fusion Middlewareの管理者ガイドの「バックアップとリカバリの概要」および「環境のバックアップ」を参照してください。
SOAサービス・インフラストラクチャは、Java EEに準拠したアプリケーションであり、Oracle WebLogic Server上で実行されます。SOAサービス・インフラストラクチャによって、コンポジットの実行に必要なサービスが提供されます。コンポジットは、サービス・コンポーネント・アーキテクチャ（SCA）のデプロイメントの基本単位です。SCAアセンブリ・モデルは、XMLファイルに記述されている要素によって定義される一連のアーティファクトで構成されます。
コンポジットは、コンポーネント、ワイヤー、サービスおよび参照で構成されるソフトウェア・パッケージです。たとえば、Oracle BPELプロセスがコンポーネント、インバウンド・アダプタがサービス、アウトバウンド・アダプタが参照となります。ワイヤーはサービス・エンジン間の接続を確立します。
個々のコンポーネントは、Oracle BPEL PMやOracle Mediatorなどの特定サービス・エンジンにターゲット指定されます。Oracle SOAサービス・インフラストラクチャは、SOAデータベースに接続してコンポジット状態を保持し、SOA Oracle Metadata Services（MDS）リポジトリに接続してデプロイメントやバージョン追跡などのコンポジット・メタデータを保持します。これら2つのデータベースは、同一の物理データベースである場合がありますが、使用されるスキーマはそれぞれの目的に応じて異なります。SOAインフラストラクチャは、コンポジットのリモート・デプロイメント用のサーブレットを提供します。リモート・デプロイメント用のメタデータとアーティファクトも、MDSリポジトリに格納されます。MDSリポジトリの詳細は、第4.1.2.1項「MDSリポジトリのためのマルチ・データソースの構成」を参照してください。
また、Oracle SOAサービス・インフラストラクチャ・アプリケーションは、個々のコンポーネントを特定エンジンにターゲット指定し、リクエストがSOAシステムに届いたときにそれらのコンポジットをインスタンス化します。ターゲット指定とインスタンス化が終了すると、Oracle SOAサービス・インフラストラクチャはスレッドとリソースの割当てを制御します。これは、コンポジットが実行されるJVMで行われます。
Oracle SOAサービス・インフラストラクチャは、SOAコンポジット・アプリケーションを、図5-3に示すようにUDDIレジストリに統合します。UDDIレジストリは、公開されているサービスの特定、サービスの呼出しおよびサービス・メタデータの管理のための、標準ベースの基盤を提供します。Oracle SOAサービス・インフラストラクチャは中央のハブでもあり、サービス・エンジンがOracle User Messaging Serviceインフラストラクチャを通じて電子メールやボイスなどの通信チャネルにメッセージを配信する際に使用されます。
SOAサービス・インフラストラクチャは、サービス・コンポーネント・アーキテクチャ内の様々なコンポーネントを支える必須サービスを提供し、コンポーネント間の通信を可能にします。SCAシステム内の各種コンポーネントの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。
Oracle SOAサービス・インフラストラクチャの各種サービスは、soa-infra-wls.earファイルに含まれています。Oracle SOAサービス・インフラストラクチャ・システムで提供されるサービスは、いずれもシングルトンではありません。そのため、Oracle SOAサービス・インフラストラクチャは、完全なアクティブ/アクティブ・モードで実行可能です。SOAサービス・インフラストラクチャのJava EEアプリケーションには、デプロイされているコンポジットの参照と、これらコンポジットのテスト・ページへのリンクを可能にするWebモジュールが含まれています。このWebモジュールでは、関連付けられたURLコンテキストとして/soa-infraを使用しています。このWebモジュールはステートレスであり、特別なセッション・レプリケーション要件はありません。
Oracle SOAサービス・インフラストラクチャ・アプリケーションの他のモジュールでは、プロセスをインスタンス化およびトラッキングするためのタスク制御機能と、ユーザー・メッセージング・システム（UMS）にアクセスするためのクライアント・サービスを提供します。
タスク・サービスは、プロセスのインスタンス化とトラッキングを非同期で制御します。その他にも、Oracle SOAサービス・インフラストラクチャ・システムでは、複数のEJBが使用されます。しかし、EJBはすべてステートレスであり、Oracle SOAクラスタでのステートフル・セッションBeanレプリケーションに要件はありません。これらEJBでのトランザクションの処理は、Oracle WebLogic Serverのトランザクション制御サービスに依存します。Oracle WebLogic Serverコンテナの障害から確実にリカバリできるようにするために、Oracle WebLogic Serverの基本ガイドラインで推奨されている適切なトランザクション・ストアを構成してください。
Oracle SOAコンポジットは次のものから構成されます。
BPELプロセス、Human Workflowタスク、Mediatorルーティング・ルール、Business Rulesなどのコンポーネント
Oracle SOAコンポジット・アプリケーションと外部サービス、アプリケーションおよびテクノロジを接続する、サービスおよび参照。
これらのコンポーネントは、Oracle SOAコンポジット・アプリケーションにアセンブルされます。このアプリケーションは、Oracle SOAアプリケーションの管理とライフサイクルを簡素化するデプロイメントの1つの単位です。
Oracle SOAサービス・インフラストラクチャ・アプリケーションは、起動時に、各種サービス・エンジンを初期化し、MDSリポジトリから既存のコンポジットをロードします。また、個々のコンポーネントを特定エンジンにターゲット指定します。コンポジットがロードされると、システムはリクエストを受信できるようになります。Oracle SOAサービス・インフラストラクチャは、実行時にサービス・コンポーネント間のすべての通信を管理します。サービス・エンジン間でのこのようなコールは、インプロセス・コールです。次の図は、Oracle SOAサービス・インフラストラクチャの起動のシーケンスと処理の手順を表しています。
図5-4 Oracle SOAサービス・インフラストラクチャ・アプリケーションの起動とシャットダウンのライフサイクル
前の項で説明したように、Oracle SOAサービス・インフラストラクチャの各システムは、次のコンポーネントに依存します。
インスタンス・マネージャ・サービスは、ランタイムSOAデータベース・スキーマ（soa-infra）に依存します。
コンポジット・メタデータは、リポジトリとして機能するMDSデータベース・スキーマに格納されます。
クラスタ化された環境での、デプロイメント・コーディネータ・サービスによるシグナルの伝播は、基盤となるCoherenceクラスタに依存します。
Oracle SOAサービス・インフラストラクチャが適切に起動し、実行されるためには、これら3つのすべてのコンポーネントが使用可能である必要があります。
Oracle SOAサービス・インフラストラクチャがデプロイされているOracle WebLogic管理対象サーバーが起動するときに、Oracle SOAサービス・インフラストラクチャ・アプリケーションがデフォルトで起動します。通常は、Oracle SOAサービス・インフラストラクチャやそのコンポーネント自体を停止する必要はありません。一部の操作では、SOAサービス・インフラストラクチャが実行されているOracle WebLogic管理対象サーバーの再起動が必要な場合があります。一部のパッチを適用するときにのみ、アプリケーションを停止させなければならない場合があります。
Oracle WebLogic Server管理コンソールを使用すると、ステータスを確認したり、Oracle WebLogic Serverを起動および停止したりできます。アプリケーションの制御に、WebLogic Server WLSTのコマンドラインも使用できます。また、Oracle Enterprise Manager Fusion Middleware Controlを使用すると、Oracle SOAサービス・インフラストラクチャ・アプリケーションの多数の操作と構成を行えるだけでなく、ステータスを監視することもできます。Oracle SOAサービス・インフラストラクチャ・アプリケーションの監視と制御の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。
Oracle SOAサービス・インフラストラクチャの主な制御機能は、DOMAIN_HOME/ config/soa-infra/configurationディレクトリにあるsoa-infra-config.xmlファイルを使用して構成できます。このファイルでは、次のことを指定できます。
デハイドレーションを処理するためのデータソースJNDI名。
|
注意: このファイルからJNDI名が読み取られると、システムで使用されるデータベースが、WebLogic ServerのJDBSリソース構成内でそれらのJNDI名と一致するデータソースによって決定されます。 |
サーバーおよびコールバックURL。
コールバックURLとは、非同期サービスにおいて、呼び出したサービスへのレスポンスが通知されるように指定されているアドレスのことです。
|
注意: 外部または内部の非同期サービスへのリクエストがSOAから送られると、コールバックURLは次のように、優先度の高い順に決定されます。
|
メッセージ・トラッキング・インフラストラクチャで収集する情報の監査レベル。
これらのオプションは、Oracle Enterprise Manager Fusion Middleware Controlでも使用でき、Oracle SOAサービス・インフラストラクチャのインストールごとに固有です。データソース、JTA構成および永続ストアなど、コンテナ・レベルの他の構成オプションは、WebLogic Serverのドメイン構成の一部として保持され、Oracle WebLogic Serverのコア・インフラストラクチャにより、Oracle WebLogic Serverのクラスタ上で同期化されます。
Oracle SOAサービス・インフラストラクチャとそのコンポーネントにより実行される操作は、SOAサービス・インフラストラクチャが実行されているOracle WebLogic管理対象サーバーによって記録されます。これらのログは、次の場所にあります。
DOMAIN_HOME/servers/WLS_ServerName/logs/WLS_ServerName.log
別のOracle WebLogic Sever管理対象サーバーのログ・ファイルも、Oracle WebLogic Server管理コンソールで使用できます。ログを確認するには、admin_server_host:port/consoleからOracle WebLogic Server管理コンソールにアクセスします。「診断ログ・ファイル」をクリックします。
Oracle 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-6は、2つのOracle WebLogic ServerでOracle SOAサービス・インフラストラクチャの2ノード・クラスタが実行されている様子を示しています。Oracle WebLogic Serverは、それらのサーバーへの受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。
|
注意: この図は、Oracle HTTP Serverやロード・バランサなどの他のエンティティをアドレッシングせずに、Oracle SOAにのみ重点を置き、高可用性について説明しています。 |
図5-6は、この高可用性の構成の持つ次の主要な特性を表しています。
SOAサービス・インフラストラクチャは、Oracle WebLogic Serverクラスタの一部であるOracle WebLogic Server管理対象サーバーで実行されます。Oracle WebLogic Serverクラスタは、JTS構成、データソースおよび永続ストア定義など、Oracle SOAサービス・インフラストラクチャで使用するWebLogic Serverクラスタの共通アーティファクトの構成を同期化します。
Oracle SOAサービス・インフラストラクチャでは、Oracle WebLogic Serverクラスタに対して構成されたフロントエンド・ホストおよびポート情報を、サーバーおよびコールバックURLとして使用します。この情報は、Oracle WebLogic Server管理コンソールで定義されます。この情報を定義するには、「クラスタ」→「SOA_Cluster_Name」→「HTTP/HTTPSフロントエンド・ホスト」→「ポート」を選択します。Oracle SOAサービス・インフラストラクチャが実行されているOracle 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の更新などのシングルトン操作を実行します。
Oracle SOAサービス・インフラストラクチャ・システムでは、Oracle WebLogic Serverクラスタ名をキーとして使用し、デプロイメント・コーディネータ・グループを確認します。WebLogic Serverクラスタ内のすべてのノードがマルチキャストまたはユニキャストで通信可能な場合、デプロイメント・コーディネータ・クラスタは、SOAサービス・インフラストラクチャが実行されているWebLogic Serverクラスタと同じになります。
管理サーバーは、アクティブ/パッシブ・モードで実行されます。APPHOST1で障害が発生したときはいつでも、APPHOST2で管理サーバーを再起動できます。そのため、管理サーバーでは、リスニング・アドレスに仮想IPまたは仮想ホスト名が使用されます。
管理サーバーの仮想IPの構成および高可用性のための管理サーバーの構成の詳細は、第10章「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。
Oracle WebLogic Serverのサーバー全体の移行
SOAサービス・インフラストラクチャは完全なアクティブ/アクティブ・モードで実行可能ですが、アーキテクチャでは一部のSOAコンポーネントを障害から保護するために、Oracle WebLogic Serverの移行機能を使用します。これは、SOAサービス・インフラストラクチャが実行されている各WebLogic管理対象サーバーでは、フェイルオーバー時に別のボックスに移行される仮想IPがリスニングされることを意味します。管理サーバーとEnterprise Managerは、管理対象サーバーではなく、AdminServerで実行されます。
図5-6に示すように、WLS_SOA1はVIP1でリスニングし、WLS_SOA2はVIP2でリスニングします。各管理対象サーバーではフェイルオーバー・リソースに他のノードを使用するため、システムは交差的に構成されます。言い換えれば、WLS_SOA1はAPPHOST2にフェイルオーバーし、WLS_SOA2はAPPHOST1にフェイルオーバーするということになります。2つのSOA管理対象サーバーが同一ノード上で実行されるシナリオを予想して、適切な容量計画を立てる必要があります。サーバー移行機能の詳細は、このガイドの第3章「WebLogic Serverの高可用性」を参照してください。
サーバーの移行後にトランザクションを再開するため、トランザクションとJMSストアを共有記憶域に構成します。サーバー・インフラストラクチャ・インスタンスの1つで障害が発生した場合、他のインスタンスがその共有記憶域から永続ストアを読み取って、トランザクションとJMS操作を再開できます。
メタデータ・ストアは、データベースの障害から保護するために、Oracle RACデータベース内に構成されます。同時に、Oracle RACデータベースには、SOAプロセスの状態情報も格納されます。この例では、どちらのOracle RACデータベースも同一になります。
Oracle SOAサービス・インフラストラクチャ・コンポーネントについて
これらの高可用性の特性は、クラスタにデプロイされるコンポジット・アプリケーションに組み込まれているほとんどのOracle SOAコンポーネントに当てはまります。個々のコンポーネントの特定の2ノード高可用性の特性については、この章の個別のコンポーネントの項を参照してください。
この項では、Oracle SOAの高可用性クラスタのデプロイメントでコンポーネントがどのようにして障害から保護されるかを説明します。また、この項では、コンポーネントの障害が発生した場合の予想される動作についても説明します。
SOAサービス・インフラストラクチャ・システムは、WebLogic Serverインフラストラクチャによってあらゆるプロセス障害から保護されます。
WLS_SOAxサーバーがクラッシュすると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。繰り返し再起動しても失敗する場合、WebLogic Serverインフラストラクチャは、クラスタ内の他のノードへのWLS_SOAxサーバーのサーバー移行を試行します。フェイルオーバーの実行中は、他のSOAサービス・インフラストラクチャ・インスタンスがデプロイメントとコンポジットの更新を主導的に実行し、システム内のサービス・エンジンに必要な基本サービスを提供します。
HTTP Serverからの処理中のリクエストはタイムアウトして、新しいリクエストは他のWLS_SOAxサーバーに送られます。他のノードでサーバーが正常に再起動されると、Oracle HTTP Serverは、サーバーへの受信したリクエストのルーティングを再開します。移行先のサーバーは、再起動中に実行された可能性のある更新をMDSリポジトリから読み取り、デプロイメント・コーディネータ・クラスタを結合して新しい更新をリスニングします。また、共有記憶域にあるトランザクション・ログを基に、保留されていたトランザクションを再開します。
サーバー移行シナリオでは、Oracle BPEL PMやOracle Mediatorなどのサービス・エンジンは、SOAサービス・インフラストラクチャとともにフェイルオーバーされます。サービス・エンジン自体は、他のSOAサービス・インフラストラクチャ・インスタンスに対してリクエストを再発行しません。フェイルオーバーが完了すると、サービス・エンジンは、SOAサービス・インフラストラクチャとともに操作を再開します。
Oracle SOAサービス・インフラストラクチャ・アプリケーションは、リソースへのアクセスの失敗、デプロイメント・コーディネータ・インフラストラクチャが原因で発生するエラー、または管理対象サーバーが実行されているかどうかには関係なく発生する問題が原因で停止する場合があります。そのため、管理者がsoa-infraアプリケーションによって引き起こされるエラーを管理対象サーバーのログで監視することをお薦めします。ログ・ファイルの場所の詳細は、第5.2.1.6項「Oracle SOAサービス・インフラストラクチャのログ・ファイルの場所」を参照してください。
ノード障害が発生した場合、使用可能なサーバーによりデータベース・リース・システム内のタイムスタンプが検証された後、サーバーの移行がトリガーされます。障害が発生したサーバーがデプロイメント・コーディネータ・クラスタ・マスターであった場合、使用可能なサーバーが新しいマスターとなり、SOAサービス・インフラストラクチャはデプロイメントおよびコンポジット・ライフサイクルに対して引き続き使用可能となります。リースのタイムスタンプが検証された後、現在も使用可能なノードのノード・マネージャが、障害が発生した管理対象サーバーで使用されているVIPの移行を試行し、VIPをローカルで再起動します。これは、同一ノードで実行される2つのインスタンスを持つSOAサービス・インフラストラクチャ・アプリケーションに効果的な結果をもたらします。フェイルオーバー・プロセスの詳細は、第3.9項「サーバー全体の移行」を参照してください。
サービス・エンジンは、サービス・インフラストラクチャ・アプリケーションの一部としてコンテナにデプロイされます。このようなサービス・エンジンには、すべてのEARファイルとライブラリ・コールが含まれます。
SOAサービス・インフラストラクチャ・システムは、マルチ・データソースの使用によりデータベースの障害から保護されます。通常、これらのマルチ・データソースは、システムの初期設定時に構成されます（Oracle Fusion Middleware構成ウィザードで、インストール時にマルチプールを直接定義できます）。そして、これらのソースによって、Oracle RACデータベース・インスタンスで障害が発生した場合に、使用可能なデータベース・インスタンスとの接続が再確立されることが保証されるようになります。マルチ・データソースを使用すると、Oracle RACデータベース内の複数のインスタンスへの接続を構成できます。
Oracle RACおよびMDSリポジトリでのマルチ・データソースの構成の詳細は、第4.1.2項「Oracle RACでのマルチ・データソースの使用」を参照してください。
前の項で説明したように、コンポジットのデプロイメントは、SOAサービス・インフラストラクチャによって、中央のMDSリポジトリに格納されます。SOAサービス・インフラストラクチャは、起動するたびにMDSリポジトリおよびSOAストアと同期化して、デプロイメントとプロセスの状態を取得します。デプロイメント・コーディネータ・インフラストラクチャは、コンポジットのデプロイメントと更新の通知をオーケストレートします。新たなデプロイメントまたは更新が実行されると、デプロイメント・コーディネータは、クラスタ内のすべてのメンバーに通知します。デプロイメントが正常に終了したことをクラスタ内のすべてのメンバーが確認すると、マスターはコンポジットの起動通知を送信します。ノードの1つでデプロイメントが失敗すると、他のクラスタにデプロイメントがロールバックされます。デプロイメント・コーディネータ・マスター（WebLogic Serverの管理対象サーバー）のエラーメッセージで、デプロイメントが失敗したノードが示されます。図5-7では、このプロセスについて説明しています。
SOAサービス・インフラストラクチャがコンポジットの更新や再デプロイメントを実行するときに、既存のバージョンに上書きしたり、新バージョン（v+1）を作成したりできます。コンポジットはすべて、コンポジット名とリビジョンに基づいて一意に識別されます。コンポジットにアクセスするクライアントは、デフォルトで、MDSリポジトリ内で識別されるバージョン（Oracle Enterprise Manager Fusion Middleware Controlでも参照可能）をデフォルト・バージョンとして使用します。各バージョンのライフサイクルを個別に管理して、SOAサービス・インフラストラクチャの単一インスタンスであっても、オンラインでコンポジットを再デプロイメントできます。この操作は、次の手順で実行します。
バージョンxをデプロイします。
バージョンxをデフォルトに指定します。
コンポジットの新バージョン（x+1）をデプロイし、再度version xをデフォルトに指定します（これは、ユーザーがデフォルトで新バージョンにアクセスしないようにするために行います）。
テスト・クライアントからコンポジットのバージョン（x+1）を指定し、新バージョンにアクセスしてテストします。
検証が終了したら、x+1をデフォルト・バージョンに指定します。
新クライアントはバージョンx+1にルーティングされ、旧クライアントはバージョンx内で処理を完了します。
前バージョンはデプロイしたままにすることも、アンデプロイすることもできます。進行中のインスタンスのあるコンポジットをアンデプロイすると、それらのインスタンスは失効し、完了しません。コンポジットをアンデプロイメントすることにより、MDSリポジトリからコンポジットが削除されます。
SOAサービス・インフラストラクチャが使用する標準Java EEアーティファクトは、SOAがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データソース、永続ストアおよびJMSモジュールなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、SOAサービス・インフラストラクチャで使用されるライブラリを同期化する役割を持ちます。
単一インスタンスの項で説明したように、SOAサービス・インフラストラクチャ固有の面に関して、WebLogic Serverドメイン・ディレクトリ（通常、1つのノードに1つのドメイン・ディレクトリ）ごとに、soa-infra-config.xmlファイルで個別に構成されます。このファイルは、DOMAIN_HOME/config/soa-infra/configurationディレクトリにあります。
このファイルは、Oracle WebLogic Serverのpackユーティリティを使用するときに作成されるJARファイルに含まれるため、ユーザーがpack/unpackプロシージャを実行してSOAサービス・インフラストラクチャの高可用性を設定するときに、他のノードに伝播されます。ただし、soa-infra-config.xmlに対して現在加えている変更は、他のノードに自動的にレプリケートされません。各ノードで、後から修正する必要があります。SOAシステムのserverURLフィールドやcallbackURLフィールドの更新がその例です。このような修正は、高可用性トポロジ全体におけるすべてのドメイン・ディレクトリ内で、手動で加える必要があります。ユーザーは、soa-infra-config.xmlファイルを直接編集したり、Oracle Enterprise Manager Fusion Middleware Controlを使用して構成を変更したりできます。
Oracle SOA Suiteをクラスタ環境で使用している場合、あるノードの構成プロパティをOracle Enterprise Managerで変更したときには、その変更がすべてのノードに適用される必要があります。構成プロパティは、Oracle Enterprise Managerで、「SOAインフラストラクチャ」メニューの次のオプションを使用して設定します。
「管理」→「システムMBeanブラウザ」
「SOA管理」→任意のプロパティを選択
この項では、高可用性のためのOracle BPEL PMの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。
サービス・エンジンは、SOAコンポジット・アプリケーション内のサービス・コンポーネントのビジネス・ロジックをホストするコンテナです。Oracle BPEL PM、Oracle Human Workflow、デシジョン・サービス、Oracle Mediatorなどの各サービス・コンポーネントは、個別のサービス・エンジン内で実行されます（デシジョン・サービスはビジネス・ルール・サービス・エンジン内で実行されます）。サービス・エンジンはOracle SOAサービス・インフラストラクチャに組み込まれます。Oracle BPEL Processエンジンは、SOAサービス・インフラストラクチャ内で実行され、BPELプロセスを実行可能にするサービス・エンジンです。
BPELプロセスは、個々のサービスのセットをエンドツーエンド・プロセス・フローにアセンブルし、同期および非同期サービスをエンドツーエンドBPELプロセス・フローに展開するための標準を提供します。これにより、プロセスのオーケストレーションや、長期にわたって実行される非同期プロセスの保存が可能になります。
図5-8に示すように、BPELエンジンは、Oracle SOAサービス・インフラストラクチャのステートレスな部分です。BPELエンジンは、SOAサービス・インフラストラクチャ・アプリケーションにより起動し、BPELプロセスの実行に必要な様々な側面を考慮した様々なモジュールを含んでいます。デプロイされたコンポジットにBPELプロセスがある場合、SOAサービス・インフラストラクチャは、BPEL Process Managerを起動して、MetaDataStore（MDS）からコンポーネントを取得します。
BPEL Process Managerは、作業ユニットが格納されているメモリー内論理キューを管理するディスパッチャ・モジュールを使用して、バインディング・コンポーネント（JMS、データベース、Webサーバー）からの受信メッセージを処理します。
BPEL Process Managerエンジンは、Oracle Toplinkに基づいた永続モジュールによって、プロセスの実行状態をSOAデータベースに保存します。監査フレームワークは、プロセスの実行情報をSOAデータベースに格納して、実行中の処理を継続的に監査します。
BPELサービス・エンジンは、SOAサービス・インフラストラクチャのJava EEアプリケーション（soa-infra.ear）内で実行されます。BPELサービス・エンジンではシングルトン・サービスはありません。BPELプロセスに関連するすべての状態がデータベース（デハイドレーション・ストア）に格納され、メモリー内の状態のレプリケーションは必要ありません。
SOAサービス・インフラストラクチャのJava EE EJBで実行される処理は、トランザクション処理され、Oracle WebLogic Serviceのトランザクション制御サービスに依存します。WebLogic Serverコンテナの障害から確実にリカバリできるようにするために、WebLogic Serverの基本ガイドラインで推奨されている適切なトランザクション・ストアを構成してください。また、BPELエンジン・システムにはWebモジュールがないため、BPELをアクティブ/アクティブで実行している場合は、サーブレット・レイヤーにセッション・レプリケーションは必要ありません。
今回リリースされるOracle Fusion Middlewareでは、BPELサービス・コンテナでの非同期メッセージ・ディスパッチは、JMSに依存しません。そのため、分散JMSインフラストラクチャへの依存性はありません。
外部依存性
BPELエンジン・システムは、次のコンポーネントに依存します。
BPELプロセスの状態の永続性については、SOAサービス・インフラストラクチャ・データベース
BPEプロセスのメタデータ・ストアについては、MDSリポジトリ
BPELエンジン・システムが適切に起動し、実行されるためには、どちらのコンポーネントも使用可能である必要があります。
図5-9に示すように、Oracle SOAサービス・インフラストラクチャ・アプリケーションは、起動時に、BPELエンジンを初期化し、MDSリポジトリからコンポジットをロードします。コンポジットにBPELプロセスが含まれる場合は、それら個々のコンポーネントをBPELエンジンにターゲット指定します。プロセスがロードされると、システムはリクエストを受信できるようになります。実行時に、BPELエンジンは、JMS、データベースおよびHTTPなどの様々なチャネルからのリクエストを待機します。
起動とシャットダウンのライフサイクルの詳細は、次のとおりです。
SOAサーバーを起動します。
BPELエンジンを起動します。
SOAサービス・インフラストラクチャによりMDSリポジトリからコンポジットがロードされます。
BPELコンポーネントが、ロードされるBPELエンジンにディスパッチされます。
コンポジット・バインディング・コンポーネントがアクティブになります。
BPELエンジンがリクエストを処理します。
シャットダウン・シグナルがSOAサービス・インフラストラクチャによって受信されます。
SOAサービス・インフラストラクチャは、ロードされているコンポジットのアンデプロイを開始します。
コンポジット・バインディング・コンポーネントが無効化されます。
BPELコンポーネントが、アンロードされるBPELエンジンにディスパッチされます。
BPELエンジンがシャットダウンされます。
リカバリ可能なアクティビティとは、失敗した後にリカバリできるアクティビティのことです。たとえば、ファイル・アダプタを使用して非同期BPELプロセスを開始し、インスタンスの処理中にシステムがクラッシュした場合、サーバーが再起動したときにリカバリを手動で実行して、すべてのメッセージ・レコードを確実にリカバリできます。
BPELプロセスには、呼出しインタフェースに応じて2つのタイプがあります。
一方向: もっとも一般的な非同期ファイア・アンド・フォーゲット・パターン
双方向: 同期リクエスト・レスポンス・パターン
サーバー障害後のリカバリ・セマンティックは、プロセスが同期的に呼び出されるか、非同期的に呼び出されるかによって決まります。次に、呼出しとプロセスのタイプ別の動作を説明します。
同期呼出し（リクエスト）: 同期リクエストでは、サーバー障害時にエラーがクライアントに戻されます。クライアントは、エラー・メッセージを処理して、リクエストの再試行などの適切な措置を講じます。これは、一時プロセスと永続プロセスの両方に対して当てはまります。
|
注意: 永続プロセスでは、メッセージは、特定時点のデハイドレーション・ストアに永続的に保持されます。Enterprise Managerを使用してデハイドレーション・ストアのメッセージをリカバリし、プロセスを再実行することは可能ですが、クライアントにレスポンスは通知されません。そのため、このオプションは推奨されません。すべてのリカバリをクライアントで処理することをお薦めします。 |
非同期呼出し（ポスト）: 非同期呼出しには2タイプあります。1つはプロセスを新しく開始するもので、もう1つは既存プロセスへのコールバックです。コールバックの場合、エンジンは（それが継続操作であることを認識した後）、最初に対話ID、次に相関セット（定義されている場合）により、サブスクライブ・プロセスの解決を試行します。非同期リクエストに関連するメッセージは、クライアント・コールの一部として、デハイドレーション・ストアに永続的に保持されます。永続的に保持される前に障害が発生した場合、クライアントは、エラー・メッセージを受け取るとともに、同期呼出しのエラーの場合と同様の方法でエラーを処理する必要があります。永続的な保持が成功すると、クライアント・コールが戻され、以降の処理がクライアント・コールのコンテキストの外部で実行されます。サーバーの障害が発生した場合は、Enterprise Managerを使用して、非同期に呼び出された一方向プロセスを再起動できます。
BPELエンジンでサポートされている同期モデルと非同期モデルの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』および開発者ガイドを参照してください。
Oracle Fusion Middleware BPELエンジンの主な制御機能は、DOMAIN_HOME/ config/soa-infra/configurationディレクトリにあるbpel-config.xmlファイルで構成されます。このファイルでは、他のプロパティを、次のような側面から指定できます。
ディスパッチャ・スレッドの数
同期プロセスの待機のタイムアウト期間
呼出しが失効するまでの再試行の回数
これらのパラメータの一部は、Oracle Enterprise Manager Fusion Middleware Controlで構成可能です。これらのプロパティは、Oracle Fusion Middleware SOAを実行するWebLogic Serverが属する各WebLogicドメイン・ディレクトリに固有のものです。データソース、JTA構成および永続ストアなど、コンテナ・レベルの他の構成オプションは、WebLogic Serverのドメイン構成の一部として保持され、WebLogic Serverのコア・インフラストラクチャにより、WebLogic Serverのクラスタ上で同期化されます。BPELエンジンの構成の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。
図5-11は、Oracle WebLogic Server管理コンソールを示しています。この管理コンソールでOracle BPEL PMプロパティを構成できます。
Oracle SOA Suiteをクラスタ環境で使用している場合、あるノードの構成プロパティをOracle Enterprise Managerで変更したときには、その変更がすべてのノードに適用される必要があります。構成プロパティは、Oracle Enterprise Managerで、「SOAインフラストラクチャ」メニューの次のオプションを使用して設定します。
「管理」→「システムMBeanブラウザ」
「SOA管理」→任意のプロパティを選択
図5-6は、2つのWebLogic ServerでOracle SOAサービス・インフラストラクチャの2ノード・クラスタが実行されている様子を示しています。Oracle BPEL PMは、Oracle SOAサービス・インフラストラクチャの一部としてデプロイされます。
Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作の詳細は、第5.2.2.1項「Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作」を参照してください。
BPELエンジン・システムは、WebLogic Serverインフラストラクチャによってあらゆるプロセス障害から保護されます。次のプロセス障害に関する考慮事項は、Oracle BPELに適用されます。
管理対象サーバーがクラッシュすると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。サーバー全体の移行が構成されており、繰り返し再起動しても失敗する場合、WebLogic Serverインフラストラクチャは、クラスタ内の他のノードへの管理対象サーバーのサーバー移行を試行します（サーバー移行が構成されている場合）。他のノードでサーバーが再起動されると、Oracle HTTP Serverは、サーバーへの受信したリクエストのルーティングを再開します。移行されたサーバーは、SOAデータベースを読み取って、保留されていた処理を再開し、共有記憶域にあるトランザクション・ログを基にトランザクションを再開します。
管理対象サーバーが正常に起動した後でも、JDBCデータソースやコヒーレンス構成に関連するエラーが原因で、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に表示されるフォルトには次の3タイプがあります。
ビジネス: 処理中の情報に問題がある（データベースで社会保障番号が見つからないなど）ときに発生するアプリケーション固有のフォルト。
システム: データベース・サーバーが完全に使用不可能であったり、Webサービスにアクセス不可能であったりするなどの、ネットワークおよび他のタイプのエラー。
Oracle Web Service Manager（OWSM）: SOAコンポジット・アプリケーション、サービス・コンポーネントまたはバインディング・コンポーネントにアタッチされているポリシーのエラー。
フォルト・リカバリ・ポリシーは設計時に定義します。コンポジットに付属のフォルト・ポリシー・ファイルには、障害発生時に講じる措置が定義されています。フォルト・リカバリの定義および使用方法の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。
インスタンスの欠落
一方向呼出しリクエストのインバウンド・ペイロードは、デハイドレーション・ストアに格納され、現行のグローバル・トランザクションのコンテキストに従ってコミットされます。コール元がすでにグローバル・トランザクションを開始している場合は、コール元がトランザクションをコミットするときに呼出しメッセージが保存され、受信トランザクションがない場合は、新しいトランザクションが開始されて呼出しメッセージがコミットされます。Enterprise ManagerにBPELインスタンスが見つからない場合は、手動リカバリ・コンソールに呼出しメッセージが存在することがあります（リカバリ・コンソールには、未配信のすべての受信メッセージがリストされます）。リカバリ・コンソールで呼出しメッセージが見つからない場合は、コール元のトランザクションのステータスをチェックしてください。
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-12で示すように、Enterprise Managerを使用して再起動できます。
BPELエンジンが使用する標準Java EEアーティファクトは、SOAがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データソース、永続ストアおよびJMSモジュールなどのアーティファクトの自動構成同期化機能を提供します。
単一インスタンスの項で説明したように、BPELエンジン固有の構成は、bpel-config.xmlファイルに格納されます。このファイルは、各管理対象サーバーに関連付けられているドメイン・ディレクトリにあります（通常、1つのノードに1つのドメイン・ディレクトリ）。
この項では、高可用性のためのOracle Mediatorの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。
Oracle Mediatorは、Oracle SOAサービス・インフラストラクチャ内のサービス・エンジンです。各種プロバイダと、サービスやイベントのコンシューマとを仲介するフレームワークを提供します。Mediatorサービス・エンジンは、SOAサービス・インフラストラクチャのJava EEアプリケーションとともに即時実行されます。非同期の相互作用やパラレル・ルーティング・ルールの呼出しにより開始された実行のランタイム状態は、SOAランタイム・データベース内に保持されます。Oracle Mediatorの管理の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。
同期および非同期の相互作用
Oracle Mediatorは、同期および非同期リクエスト・レスポンス相互作用をサポートします。同期相互作用では、リクエストを発行するクライアントは、ブロックされた状態のままでレスポンスを待機します。非同期相互作用では、クライアントはサービスを呼び出しますが、レスポンスを待機しません。非同期相互作用の場合は、タイムアウト期間を指定できます。
順次およびパラレルのメッセージ・ルーティング
Oracle Mediatorでは、メッセージを、順次またはパラレルに宛先にルーティングできます。
順次ルーティングでは、データは1つのトランザクション内で処理されます。
パラレル・ルーティングでは、情報のエンキューに1つのトランザクションが使用され、デキューには別のトランザクションが使用されます。
コンポジットにMediatorコンポーネントが含まれる場合、SOAサービス・インフラストラクチャはこのコンポーネントをMediatorエンジンにターゲット指定してデプロイメントします。Mediatorエンジン・システムで提供されるサービスは、いずれもシングルトンではないため、Oracle Mediatorエンジンは完全なアクティブ/アクティブ・モードで実行可能です。Oracle Mediatorのワーカー・スレッドによるメッセージ処理は、トランザクション処理され、Oracle WebLogic Serverのトランザクション制御サービスに依存します。WebLogic Serverコンテナの障害から確実にリカバリできるようにするために、WebLogic Serverのガイドラインで推奨されている適切なトランザクション・ストアを構成してください。また、Oracle MediatorのエンジンにはステートフルなWebモジュールやステートフルなセッションBeanがないため、Oracle Mediatorをアクティブ/アクティブ・モードで実行するときには、セッション・レプリケーションの構成は一切必要ありません。処理の状態や必要な処理は、Oracle Mediatorによってデータベース内に保持されます。したがって、Oracle Mediatorのデータベースが高可用性に対応している必要があります。そのためには、第5.11.4項「SOAのドメインを作成するためのAPPHOST1でのOracle Fusion Middleware構成ウィザードの実行」の説明に従って、SOAデータソースに対するマルチ・データソースを構成する必要があります。RACおよびMDSリポジトリでのマルチ・データソースの構成の詳細は、第4.1.2項「Oracle RACでのマルチ・データソースの使用」を参照してください。
外部依存性
Oracle Mediatorは、次のコンポーネントに依存します。
Mediatorメッセージおよびメッセージの状態の永続性については、SOAデータベース
コンポジットのメタデータ・ストアについては、MDSリポジトリ
Oracle Mediatorが適切に起動し、実行されるためには、どちらのコンポーネントも使用可能である必要があります。
Oracle SOAサービス・インフラストラクチャ・アプリケーションは、起動時に、Oracle Mediatorエンジンを初期化し、MDSリポジトリからコンポジットをロードします。コンポジットにOracle Mediatorコンポーネントが含まれる場合は、それらのコンポーネントをOracle Mediatorエンジンにターゲット指定します。Mediatorルーティング・ルールは、実行時に、インバウンド・バインディング・コンポーネントや別のサービス・エンジンによって呼び出すことができます。Mediatorエンジンのシャットダウンは、SOAサービス・インフラストラクチャによって開始されます。また、シャットダウン時には、進行中のインスタンスにシグナルが送信され、ロードされていたコンポーネントがアンロードされます。
図5-13は、Oracle Mediatorの起動のライフサイクルを表しています。
サーバー障害後のOracle Mediatorのリカバリ・セマンティックは、クライアントの相互作用のタイプとルーティング・ルールのタイプによって決まります。
Oracle Mediatorは、同期および非同期リクエスト・レスポンス相互作用をサポートします。次に、相互作用のタイプ別の動作を説明します。
同期相互作用: 同期相互作用では、サーバー障害時にエラーがクライアントに戻されます。クライアントは、エラー・メッセージを処理して、リクエストの再試行などの適切な措置を講じます。
非同期呼出し: 非同期呼出しには2タイプあります。1つはルーティング・ルールの実行を新たに開始するもので、もう1つは既存のルールの実行へのコールバックです。コールバックでは、エンジンが相関IDによるサブスクライブ・インスタンスの解決を試行します。コールバックの処理で障害が発生した場合、クライアントは、エラー・メッセージを受け取るとともに、エラーを適切に処理する必要があります。サーバーの障害が発生した場合は、コールバック処理の信頼性を保証するために、クライアント呼出しをトランザクション処理する必要があります。
Oracle Mediatorでは、メッセージを、順次またはパラレルにルーティングできます。サーバーの障害が発生した場合は、パラレルで処理されたメッセージにかぎり、手動リカバリが必要です。次に、ルーティング・ルールのタイプ別の動作を説明します。
順次ルーティング・ルール: 順次ルーティング・ルールでは、ルール全体が1つのトランザクション内で実行されます。サーバーの障害が発生した場合、Mediatorは、基盤となるトランザクション・マネージャにリカバリを依存します。
パラレル・ルーティング・ルール: パラレル・ルーティング・ルールでは、Mediatorは、2つの異なるトランザクションを実行するストア/フォワード・パラダイムを使用します。1つはメッセージを永続的に保持するトランザクション、もう1つはルーティング・ルールを実行するトランザクションです。永続的に保持される前に障害が発生した場合、クライアントは、エラー・メッセージを受け取るとともに、順次ルーティング・ルールと同様の方法でエラーを処理する必要があります。永続的な保持が成功すると、クライアント・コールが戻され、以降の処理がクライアント・コールのコンテキストの外部で実行されます。サーバーの障害が発生した場合、Mediatorは、ContainerIdLeaseRefreshで指定された構成可能な時間間隔が経過した後のサーバーの再起動時に、リカバリを開始します。
Oracle Mediatorエンジンの主な制御機能は、DOMAIN_HOME/config/soa-infra/configurationディレクトリにあるmediator-config.xmlファイルで構成されます。このファイルに指定されている、高可用性を実現するための関連プロパティは、次のとおりです。
パラレル・ルーティング用にロックされる行のバッチ・サイズ
DeferredMaxRowsRetrieved
Oracle Mediatorインスタンス全体のハートビート・メッセージの率
ContainerIdLeaseRefresh
ContainerIdLeaseTimeout
監査レベル
これらのパラメータの一部は、Oracle Enterprise Manager Fusion Middleware Controlで構成可能です。これらのプロパティは、Oracle Fusion Middleware SOAを実行するWebLogic Serverが属する各WebLogicドメイン・ディレクトリに固有のものです。
埋込みサービス・エンジンであるMediatorでは、SOAサービス・インフラストラクチャと同じ高可用性アーキテクチャをいくつか利用します。図5-6は、2つのWebLogic ServerでOracle SOAサービス・インフラストラクチャの2ノード・クラスタが実行されている様子を示しています。Oracle Mediatorは、Oracle SOAサービス・インフラストラクチャのコンポジット・アプリケーションの一部としてデプロイされます。
クラスタ化された構成では、シングルトン・サービスはなく、すべての状態がSOAランタイム・データベースに格納されるため、Oracle Mediatorはアクティブ/アクティブ・モードで実行可能です。
Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作の詳細は、第5.2.2.1項「Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作」を参照してください。
パラレル・ルーティング・ルールの実行時に、Mediatorは、SOAランタイム・データベース内のメッセージのバッチに対する論理ロックを取得します。このロックには、Oracle Mediatorエンジンを一意に識別するコンテナIDへの参照が含まれています。コンテナIDは、起動時に割り当てられます。ユーザーは、DeferredMaxRowsRetrievedを使用してバッチ・サイズを構成できます。前述のように、バッチ・サイズが小さいほど、サーバーの障害が発生したときにリカバリが必要になるロックの行数が少なくなります。
計画外停止が発生した場合は、サーバーの再起動後に、ContainerIdLeaseRefresh間隔で指定された時間だけ待機する必要がありますこれにより、サーバーは実行状態のままインスタンスを完了できます。
マルチノードのクラスタ環境で、非同期メッセージ交換パターンにMediatorが使用されている場合は、リクエストが完了する前にコールバックが返されてきても、Mediatorでコールバックが処理されない可能性があります。こうした現象は、Mediatorによりターゲット・サービスに対して開始されたリクエストが完了するのに長時間かかり、リクエストが完了する前にターゲット・サービスからのコールバックが返されるようなシナリオにおいて発生することがあります。
プロセス障害
Oracle Mediatorは、WebLogic Serverインフラストラクチャによってあらゆるプロセス障害から保護されます。次のプロセス障害に関する考慮事項は、Oracle Mediatorに適用されます。
管理対象サーバーがクラッシュすると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。サーバー全体の移行が構成されており、繰り返し再起動しても失敗する場合、WebLogic Serverインフラストラクチャは、クラスタ内の他のノードへの管理対象サーバーのサーバー移行を試行します（サーバー移行が構成されている場合）。他のノードでサーバーが再起動されると、Oracle HTTP Serverは、サーバーへの受信したリクエストのルーティングを再開します。移行されたサーバーは、SOAデータベースを読み取って、保留されていた処理を再開し、共有記憶域にあるトランザクション・ログを基にトランザクションを再開します。
リソースへのアクセスの失敗、コヒーレンス・インフラストラクチャが原因で発生するエラー、またはMediator Engineが配置されている管理対象サーバーのステータスとは関係なく発生する他の問題が原因で、Mediator Engineが実行されているSOAサービス・インフラストラクチャ・アプリケーションが停止する場合があります。そのため、Oracle SOAサービス・インフラストラクチャ・アプリケーションによって引き起こされるエラーを管理対象サーバーのログで監視することをお薦めします。サーバー・ログの場所の詳細は、第5.2.1.6項「Oracle SOAサービス・インフラストラクチャのログ・ファイルの場所」を参照してください。
サーバーがクラッシュした後のリカバリ時に、Oracle Mediatorは、部分的に処理されたメッセージの再配信を試行します。自動再試行が失敗すると、Oracle Mediatorは、メッセージを手動リカバリできるようにエラー・ホスピタルにエンキューします。
ノード障害
ノード障害が発生した場合、使用可能なサーバーによりデータベース・リース・システム内のタイムスタンプが検証された後、サーバーの移行がトリガーされます。クラッシュしたサーバーがコヒーレンス・クラスタ・マスターであった場合、使用可能なサーバーが新しいマスターとなり、Mediatorエンジンはバインディング・コンポーネントからのメッセージの処理に対して引き続き使用可能となります。リースのタイムスタンプが検証された後、他のノードのノード・マネージャは、障害が発生した管理対象サーバーで使用されているVIPの移行を試行し、VIPをローカルで再起動します。これは、同一ノードで実行される2つのインスタンスを持つMediatorエンジンに効果的な結果をもたらします。
Oracle Mediatorエンジンが使用する標準Java EEアーティファクトは、SOAがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データソース、永続ストアおよびJMSモジュールなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、Oracle Mediatorのエンジンで使用されるライブラリを同期化する役割を持ちます。
単一インスタンスの項で説明したように、Oracle Mediatorエンジン固有の面に関して、WebLogic Serverドメイン・ディレクトリ（通常、1つのノードに1つのドメイン・ディレクトリ）ごとに、mediator-config.xmlファイルで個別に構成されます。このファイルは、DOMAIN_HOME/config/soa-infra/configurationディレクトリにあります。
サーバー障害からのリカバリ時に、特定の状況下で、ルーティング・ルールが進行中のメッセージが、手動リカバリのためエラー・ホスピタルに置かれる場合があります。このようなメッセージは、付録5に示すように、Enterprise Managerを使用してリカバリできます。
Mediatorの障害をデバッグするには、データベース表をチェックして、障害が発生しているコンテナを特定します。Mediatorに障害が発生した時点で処理中だったリクエストを特定するには、まだロック状態になっている行を特定し、ロック解除します。この行はBlobとして格納されているため、ペイロードを確認することもできます。
Mediatorインスタンス・マネージャのポーリング間隔は、すべてのノードで同一である必要があります。使用されているタイムスタンプは、データベースのタイムスタンプです。
データベース内のメッセージは、次のような段階を踏んで処理されます。
準備完了
ロック
完了
エラー
この項では、高可用性のためのOracle Human Workflowの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。
Oracle Human Workflowは、Oracle SOAサービス・インフラストラクチャ内で実行され、インタラクティブなヒューマン・ドリブン・プロセスの実行を可能にするサービス・エンジンです。Human Workflowは、プロセス内外での承認、却下および再割当てのアクションなどの、ヒューマン・インタラクションをサポートします。Human Workflowサービスは、ビジネス・プロセスとのヒューマン・インタラクションを多様な側面から処理する多数のサービスで構成されます。
ヒューマン・タスク・メタデータはすべてメタデータ・サービス（MDS）リポジトリに格納されて、管理されます。Human Workflowエンジンは、SOAサービス・インフラストラクチャ内で実行するサービス・エンジンと、DefaultToDoTaskFlowおよびワークリスト・アプリケーションのための追加のJava EEアプリケーションで構成されます。Human Workflowは、ヒューマン・タスク関連の通知に内部JMS キューを利用します。
Oracle Human Workflowの管理の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。
Human Workflowの起動は、Java EEアプリケーションのロードとサービス・エンジンの初期化という、2つのフェーズから成り立ちます。Java EEアプリケーションは、アプリケーション・サーバーの起動時にロードされます。サービス・エンジンの初期化とシャットダウンは、SOAサービス・インフラストラクチャにより制御されます。初期化後、Human Workflowコンポーネントを持つコンポジットは、SOAサービス・インフラストラクチャによってHuman Workflowサービス・エンジンにターゲット指定されます。
Human Workflowは、他のSOAエンジン（Oracle BPEL PMなど）による呼出しで開始できます。メッセージは、SOAサービス・インフラストラクチャによってエンジンにルーティングされ、ワークフロー・エンジンによってランタイム・スキーマ内に永続的に保持されます。メッセージは、呼出しに関連するクライアント・トランザクションがコミットされた後、ブラウザベースのUIを通じ、管理者アクションに対して使用できるようになります。ユーザー・アクションによるメッセージやランタイム状態の更新は、それぞれ個別のトランザクションです。
ワークフローがトランザクションをコミットするとすぐにBPELに制御が戻され、それとほぼ同時にBPELがトランザクションをコミットします。このウィンドウ間でRACインスタンスが停止すると、フェイルオーバー時にメッセージが再試行され、それがタスクの重複の原因になる場合があります。
Human Workflowの構成パラメータは、ドメイン・ルートのconfig/soa-infra/configurationディレクトリにあるworkflow-config.xmlファイル、workflow-identity-config.xmlファイルおよびworkflow-notification-config.xmlファイルで定義されます。主要な構成パラメータは、次のとおりです。
taskAutoReleaseConfigurations
worklistApplicationURL
HWFMailerConfiguration
Oracle SOA Suiteをクラスタ環境で使用している場合、あるノードの構成プロパティをOracle Enterprise Managerで変更したときには、その変更がすべてのノードに適用される必要があります。構成プロパティは、Oracle Enterprise Managerで、「SOAインフラストラクチャ」メニューの次のオプションを使用して設定します。
「管理」→「システムMBeanブラウザ」
「SOA管理」→任意のプロパティを選択
Human Workflowで使用するタスク詳細アプリケーションのURIは、追加したり削除したりできます。
ヒューマン・タスク・サービス・コンポーネントのタスク詳細アプリケーションのURIを管理する手順は、次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニュー | ナビゲータのSOAフォルダ |
|---|---|
|
|
「コンポーネント・メトリック」表で、ヒューマン・タスク・サービス・コンポーネントを選択します。
「管理」をクリックします。
「管理」ページにタスク詳細アプリケーションのURIが表示されます。
「追加」アイコンをクリックして、URIについて次の詳細情報を指定します。
アプリケーション名
ホスト名
HTTPポート
HTTPSポート（オプション）
URI
「適用」をクリックします。
図5-6は、2つのWebLogic ServerでOracle SOAサービス・インフラストラクチャの2ノード・クラスタが実行されている様子を示しています。Oracle Human Workflowは、Oracle SOAサービス・インフラストラクチャのコンポジット・アプリケーションの一部としてデプロイされます。
Oracle Human Workflowのエンジンでは、トランザクションEJBを使用して永続性を実現し、JMSキューを使用してユーザー通知を格納します。すべての状態がデータベースとJMSキューに格納され、メモリ内セッション状態がリカバリ用にレプリケートされることはありません。そのため、Oracle Human Workflowのサービス・エンジンと関連Java EEアプリケーションは、WebLogicクラスタ上のアクティブ/アクティブ・トポロジで実行されます。サーバーまたはハードウェアがクラッシュした場合に保留中のトランザクションやローカル・キューに格納されているJMSメッセージをリカバリするために、サーバー全体の移行を構成する必要があります。サーバーが再起動されるまで通知は送信されません。
ヒューマン・ワークフローは、ブラウザ・ベースのクライアントで標準Java EEアプリケーションと同じように動作します。メッセージがランタイム・スキーマ内に永続的に保持されると、そのメッセージをワークフローUIを使用して処理できます。トランザクションの途中でサーバーがクラッシュした場合は、リカバリまたはロールバックが正常に実行されるようサーバーをリカバリする必要があります。ヒューマン・ワークフローに関連するエラーのデバッグには、次のロガーが関係します。
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
この項では、高可用性のための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プロトコルは、クラスタ化された環境ではサポートされません。 |
Oracle B2Bは、SOAサービス・インフラストラクチャのJava EEアプリケーションとともに即時実行されます。Oracle B2B UIは、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の高可用性は、ランタイム・データベースの高可用性に依存します。そのため、SOAランタイム・データソースをマルチ・データソースとして構成して、高可用性を確保する必要があります。RACおよびMDSリポジトリでのマルチ・データソースの構成の詳細は、第4.1.2項「Oracle RACでのマルチ・データソースの使用」を参照してください。
Oracle B2Bは、次のコンポーネントに依存します。
Oracle B2Bメッセージおよびメッセージの状態の永続性については、Oracle SOAデータベース
Oracle B2Bのメタデータ・ストアについては、MDSリポジトリ
対応するアダプタが使用されている場合は、FTPおよび電子メール・サーバー
Oracle B2Bが適切に起動し、実行されるためには、SOAデータベースとMDSリポジトリが使用可能である必要があります。
Oracle SOAサービス・インフラストラクチャ・アプリケーションは、起動時にOracle B2Bのエンジンを初期化します。Oracle B2Bメタデータのデプロイメントは、コンポジットがSOAサービス・インフラストラクチャにデプロイされる前に実行されます。Oracle B2Bのエンドポイントは、チャネルとして定義され、エンジンの初期化時に起動されます。構成された各チャネルには、プロトコルに応じて次のような外部依存性があります。
FTPを使用する場合は、適切なFTPサーバーを起動する必要があります。
電子メールを使用する場合は、適切な電子メール・サーバーを起動する必要があります。
HTTP/HTTPSを使用する場合は、B2Bシステムをフロントエンド処理するHTTPサーバーを起動する必要があります。
Oracle B2Bシステムでは、すべての処理が非同期で実行されます。リクエストが到着すると、対応するメッセージがSOAデータベースに挿入されます。保留中の処理のプレースホルダとしてのJMSキューに通知が挿入されます。イベント・ハンドラ・スレッドは、このキューにあるイベントをリスニングして、処理を順次実行します。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、Oracle B2Bのサーバーのメトリックを有効化および無効化できます。これは、Oracle Enterprise Manager Fusion Middleware Controlにより公開される唯一のプロパティです。このプロパティも、DOMAIN_HOME/config/soa-infra/configurationディレクトリのb2b-config.xmlファイルにあります。このファイルには、JTAタイムアウト値を入力することもできます。次に例を示します。
<property>
<name>b2b.jtaTimeout</name>
<value>300</value>
<comment>Set JTA Timeout to 300 seconds.</comment>
</property>
Oracle B2Bのサーバーの構成の多くがSOAデータベースに保持され、Oracle B2Bのユーザー・インタフェース・アプリケーションにより公開されます。Oracle B2B構成の詳細は、『Oracle Fusion Middleware User's Guide for Oracle B2B』を参照してください。
b2b-config.xmlファイルに格納されている特定の構成オプションは、クラスタ上で常に手動で同期化されている必要があります。
Oracle SOA Suiteをクラスタ環境で使用している場合、あるノードの構成プロパティをOracle Enterprise Managerで変更したときには、その変更がすべてのノードに適用される必要があります。構成プロパティは、Oracle Enterprise Managerで、「SOAインフラストラクチャ」メニューの次のオプションを使用して設定します。
「管理」→「システムMBeanブラウザ」
「SOA管理」→任意のプロパティを選択
図5-6は、2つのWebLogic ServerでOracle SOAサービス・インフラストラクチャの2ノード・クラスタが実行されている様子を示しています。Oracle B2Bは、Oracle SOAサービス・インフラストラクチャのコンポジット・アプリケーションの一部としてデプロイされます。次の高可用性の特性は、Oracle B2Bの高可用性デプロイメントに固有のものです。
Oracle B2Bのユーザー・インタフェース・アプリケーションは、Oracle WebLogic Serverの各サーバー内で、Oracle SOAサービス・インフラストラクチャ・アプリケーションと同じクラスタの一部として実行されます。
Oracle B2Bのサーバーは、パートナ、ドキュメントおよびチャネルの定義を、Oracle RACデータベースを使用するSOAデータベースに保持します。
この項では、Oracle B2Bの高可用性クラスタのデプロイメントでコンポーネントがどのようにして障害から保護されるかを説明します。また、この項では、コンポーネントの障害が発生した場合の予想される動作についても説明します。
Oracle B2Bのユーザー・インタフェース・アプリケーションは、ナビゲーションの情報の一部をメモリに保持します。Oracle B2Bのユーザー・インタフェースを実行する管理対象サーバーの1つで障害が発生すると、ユーザーのリクエストは、アプリケーションを実行しているアクティブな別のWebLogic Serverにリダイレクトされます。Oracle HTTP Serverからの処理中のリクエストは、Oracle HTTP Serverの構成のタイムアウト設定に応じてタイムアウトします。アプリケーションではセッション情報のシリアライズが有効化されていないため、フェイルオーバーには、障害が発生したインスタンスにアクセスしているユーザーの再ログインが必要となります。
B2BのUIメモリー内データはトランザクションではなく、フェイルオーバー時にはいくつかの手順の繰り返しが必要になる場合があります。
Oracle 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サービス・インフラストラクチャの障害からの保護および予想される動作」を参照してください。
Oracle B2Bエンジンが使用する標準Java EEアーティファクトは、Oracle SOAサービス・インフラストラクチャがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データソース、永続ストアおよびJMSモジュールなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、Oracle B2Bのエンジンで使用されるライブラリを同期化する役割を持ちます。
複数のノード上で実行されるOracle B2B UIを使用するアクティブ/アクティブ・クラスタでは、クライアントからの複数のリクエスト（同一セッション内）が同一のB2Bノードに送られるように、B2B UIの永続性の設定をフロントエンド処理するロード・バランサを構成する必要があります。
単一インスタンスの項で説明したように、Oracle B2Bサーバーに固有の構成のほとんどは、データベース内に保持され、WebLogic Serverドメインで実行されるすべてのB2Bサーバーに適用できます。したがって、ペイロード・サイズやアウトバウンド・ディスパッチャ数などの構成プロパティはクラスタワイドで適用されるため、Oracle SOAのクラスタ内のすべてのインスタンスで使用されることになります。
DMSメトリックの有効化についてのみ、WebLogic Serverドメイン・ディレクトリごとに、b2b-config.xmlファイルで個別に構成されます。このファイルは、DOMAIN_HOME/config/soa-infra/configurationディレクトリにあります。また、クラスタ上で常に手動で同期化されている必要があります。
ファイル、FTPまたは電子メールのトランスポートを高可用性環境で設定するには、b2b.HAInstanceに各インスタンスを一意の名前で指定します。値にServerNameを使用すると、Oracle B2Bは、HAInstanceNameとしてWebLogic Server名を取得します。
ファイル、FTPまたは電子メールのトランスポートの設定の詳細は、『Oracle Fusion Middleware User's Guide for Oracle B2B』のHA環境におけるファイル、FTPまたは電子メールの設定に関する項を参照してください。
B2Bでのメタデータのデプロイ、パージ、またはインポートにコマンドライン・ユーティリティを使用すると、B2Bシステム内での不整合やエラーが発生する場合があります。B2Bでのアグリーメントのデプロイ、メタデータのパージまたはインポートには、コマンドライン・ユーティリティを使用しないで、B2Bコンソールで使用可能なGUIのみを使用してください。
この項では、Oracle B2Bのアクティブ/アクティブ構成のトラブルシューティングのヒントと有効な解決法について説明します。
B2Bメタデータをクラスタにパージ、インポートまたはデプロイメントするときに、エラーのタイミングとロード・バランシングによって、操作を再試行した場合に発生する可能性の低い例外が発生する場合があります。
この場合に必要なクリーンアップ手順や追加手順はありません。「[java] MDS-02202: メタデータ・オブジェクトのコンテンツ」のようなエラーがデプロイメントで表示されたり、「postTransfer: MDS-00521: ドキュメント読取り時のエラー...」のようなエラーがパージやインポートで表示された場合は、操作を再試行してください。
問題: 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クラスタのフロントエンド・アドレスを設定します。
WebLogic Server管理コンソールの「チェンジ・センター」セクションで、「ロックして編集」をクリックします。
左側のペインで、「ドメイン構造内の環境」ウィンドウを選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。
「WLS_SOA」クラスタを選択します。
「HTTP」を選択します。
次の値を設定します。
フロントエンド・ホスト: soa.mycompany.com
フロントエンドHTTPSポート: 443
フロントエンドHTTPポート: 80
「保存」をクリックします。
変更をアクティブにするには、管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。
サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効化します。
この項では、高可用性のためのOracle WSMの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。
Oracle Web Services Manager（Oracle WSM）は、組織全体で一貫したWebサービスの管理と保護を実現するためのポリシー・フレームワークを提供します。また、セキュリティ、WSRM、MTOMおよびアドレス指定のポリシーをはじめとするWebサービス・ポリシーを構築、施行、実行および監視する機能を提供します。通常、Oracle Web Services Managerは、SOAサービス・インフラストラクチャとともにデプロイされます。
Oracle Web Services Managerは、次のコンポーネントで構成されます。
ポリシー・マネージャは、MDSリポジトリに対して、事前定義済ポリシーやカスタム・ポリシーをはじめとするセキュリティ・ポリシーおよび管理ポリシーの読取りと書込みを実行します。通常は、Oracle SOAサービス・インフラストラクチャの管理対象サーバーにデプロイされます。一方、ポリシー・マネージャは個別の管理対象サーバーにデプロイできます。
ポリシー・マネージャは、ステートレスJava EEアプリケーションです。ステートレス・セッションBeanによって、その機能が公開されます。ポリシー・マネージャは、データを一切キャッシュしません（アクセスの対象は、すべてMDSリポジトリとなります）。
エージェントは、ポリシーの施行、実行、およびランタイム統計の収集を行います。エージェントは、Oracle Fusion Middlewareのすべての管理対象サーバー上で使用できます。また、エージェントが保護するアプリケーションと同じサーバー上で構成されます。
エージェントは、JARファイルのセットで構成され、そのセットが、基盤となるWebサービス・スタックの一部となります。エージェントには、セッションの状態はありません。エージェントは、メモリー内ポリシー・キャッシュを保持し、これがエージェントの起動時に移入されます。JTAまたはJMSは使用しません。
エージェントは、次の2つの部分で構成されます。
ポリシー・アクセス・ポイント（PAP）は、ポリシー・マネージャと対話します。エージェントは、T3（sslが有効な場合はT3s）プロトコル上でのEJBの呼出しによってポリシー・マネージャと通信します。
ポリシー・インターセプタは、Webサービスがデプロイされてアクティブ化されたとき、またはポリシーがEnterprise Managerを使用してWebServiceにアタッチされたときに生成されます。新たなWebサービスがOracle WSMを使用して保護された場合は、各新規Webサービスに対してインターセプタの追加インスタンスが生成されます。インターセプタは、ポリシーを施行します。
メタデータ・ストア・ポリシーは、MDSリポジトリに格納されます。通常は、Oracleデータベースがバックエンドで使用されます。高可用性を確保するため、MDSリポジトリのバックエンドとしてOracle RACデータベースを使用することをお薦めします。
Oracle WSMの構成には、Enterprise Managerが使用されます。Enterprise Managerには、Oracle WSMによって収集された様々なWebサービス・メトリックも表示されます。
Oracle WSMアーキテクチャの詳細は、Oracle Fusion MiddlewareのOracle WSM管理ガイドを参照してください。
Oracle WSMエージェントは、Webサービス・スタック内のOracle Fusion Middlewareのすべての管理対象サーバーで使用可能な.jarファイルのセットです。
ポリシー・マネージャは、wsm-pm.earファイルに格納されます。Oracle WSMで提供されるサービスは、いずれもシングルトンではないため、Oracle WSMエンジンは完全なアクティブ/アクティブ・モードで実行可能です。Oracle WSMサービスは、http://APPHOSTx:port/wsm-pm/validatorで検証できます。このバリデータには、Oracle WSMポリシーが表示されます。
エージェントとOracle Enterprise Managerは、EJBインタフェースを使用してポリシー・マネージャと対話します。Oracle WSMで使用されるEJBはステートレスであり、クラスタ化された環境にデプロイできます。そのため、クラスタ内で状態のレプリケーションを有効化するための要件はありません。
エージェントとポリシー・マネージャを同じ場所に配置する必要はありません。ただし、エージェントが正しく動作するためには、ポリシー・マネージャがドメインの最低1つのノードにデプロイされることが求められます。WSMエージェントには、ドメインにデプロイされているポリシー・マネージャを自動検出する機能があります。
エージェントとポリシー・マネージャは、どちらもJTAまたはJMSメッセージ機能を使用しません。MDSベースのポリシー・ストアも、JTAをサポートしません。
Oracle WSM Policy Managerは、次のコンポーネントに依存します。
ポリシーの格納についてはMDSリポジトリ
Oracle WSMエージェントは、Oracle WSMポリシー・マネージャにのみ依存します。
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 WebLogicのEJBクラスタリングによって実現されます。
管理対象サーバーにWebサービスがデプロイされており、これがOracle WSMによって保護されている場合、エージェントは起動時にいずれのポリシー・マネージャとも通信できず、Webサービスの呼出しが失敗します。
保護されているWebサービスがクライアント・アプリケーションからアクセスされたときに、エージェントは、ポリシー・キャッシュに問い合せて、アプリケーション・ポリシーを施行します。リクエストの認証、暗号化、復号化、認可またはログは、ポリシーに基づいて行われます。これらの操作のいずれについても、エージェントはポリシー・マネージャに接続しません。Oracle WSMによって保護された新しいWebサービスがデプロイされたり、既存のWebサービスに新しいポリシーがアタッチされたたりしたなどの構成の変更がないかぎり、ポリシー・マネージャの実行時の可用性がエージェントの機能に影響することはありません。このような構成の変更があった場合、エージェントは、ポリシー・マネージャに接続して、適切なポリシーを取得する必要があります。初期起動後に接続できない場合は、キャッシュされているポリシーに基づいて動作し続けます。
Oracle WSMエージェントの構成は、policy-accessor-config.xmlに格納されています。このファイルは、DOMAIN_HOME/config/fmwconfigディレクトリにあります。この構成ファイルでは、次のことを指定できます。
ポリシー・マネージャのURL（構成されている場合）。
キャッシュ・リフレッシュ間隔。
時間誤差。クライアントとサーバーのシステム・クロックの誤差を許容します。
これらのオプションは、Oracle Enterprise Manager Fusion Middleware Controlからでも使用でき、Oracle WSMエージェントのインストールごとに固有です。
ポリシー・マネージャは、MDSリポジトリの場所についてもadf-config.xmlに依存します。
MDSリポジトリの場所のデータソースやアプリケーションのターゲット指定など、コンテナ・レベルの他の構成オプションは、Oracle WebLogic Serverのドメイン構成の一部として保持され、Oracle WebLogic Serverのコア・インフラストラクチャにより、Oracle WebLogic Serverのクラスタ上で同期化されます。
図5-6は、2つのWebLogic ServerでOracle SOAサービス・インフラストラクチャの2ノード・クラスタが実行されている様子を示しています。Oracle WSMは、Oracle SOAサービス・インフラストラクチャのコンポジット・アプリケーションの一部としてデプロイされます。次の高可用性の特性は、Oracle WSMの高可用性デプロイメントに固有のものです。
Oracle WSMポリシー・マネージャは、Oracle WSMエージェントと同様にWLS_SOA_INFRAにデプロイされます。さらに、Oracle WSMエージェントにデプロイされるカスタムWebサービスの保護が必要な場合には、Oracle WSMエージェントをすべてのカスタムWLSクラスタで使用できます。
Oracle WSMポリシー・マネージャとエージェントは、WebLogic Serverクラスタの一部であるWebLogic Serverインフラストラクチャの管理対象サーバーで実行されます。WebLogic Serverクラスタは、Oracle SOAサービス・インフラストラクチャ（JDBC）で使用されるWebLogic Serverの共通アーティファクトの構成を同期化します。
Oracle WSMポリシー・マネージャEJBは、WebLogic Serverクラスタのクラスタリングと高可用性の機能を利用します。
Oracle WSMポリシー・マネージャのクラスタ内のインスタンスは、すべて同一のMDSリポジトリを指します。
Oracle WSMポリシーが格納されたMDSリポジトリが、データベースの障害から保護するためにOracle RACデータベース内に構成されます。
OWSMエージェントは、アプリケーションがデプロイされているサーバーと同じ管理対象サーバーにデプロイされるため、サーバーの再起動や移行によりアプリケーションが使用可能になると同時に、再度エージェントが使用可能になります。以降の2つの項では、ポリシー・マネージャのフェイルオーバーについて説明します。
プロセス障害
Oracle WSMコンポーネントは、WebLogic Serverインフラストラクチャによってプロセス障害から保護されます。
管理対象サーバーがクラッシュすると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。サーバー全体の移行が構成されており、繰り返し再起動しても失敗する場合、WebLogic Serverインフラストラクチャは、クラスタ内の他のノードへの管理対象サーバーのサーバー移行を試行します（サーバー移行が構成されている場合）。他のノードでサーバーが再起動されると、Oracle HTTP Serverは、サーバーへの受信したリクエストのルーティングを再開します。第5.7.1.2項「Oracle WSMの起動とシャットダウンのライフサイクル」で説明したように、Oracle WSMエージェントとポリシー・マネージャは、起動ライフサイクルを経て起動されます。
ポリシー・マネージャを実行する管理対象サーバーが再起動または移行される場合、フェイルオーバーはそのサーバーに接続されているエージェントに透過的に実行されます。ポリシー・マネージャは、基盤となるEJBクラスタリングと、Oracle WebLogic Serverのフェイルオーバー・インフラストラクチャを利用します。
ノードの障害が発生した場合、サーバー全体の移行が構成されていないと、Oracle WSMエージェントはポリシー・マネージャの他のインスタンスに透過的にフェイルオーバーします。
サーバー全体の移行が構成されていると、使用可能なサーバーによりデータベース・リース・システム内のタイムスタンプが検証された後、サーバーの移行がトリガーされます。リースのタイムスタンプが検証された後、現在も使用可能なノードのノード・マネージャが、障害が発生した管理対象サーバーで使用されているVIPの移行を試行し、VIPをローカルで再起動します。これは、同一ノードで実行される2つのインスタンスを持つOracle WSMポリシー・マネージャ・アプリケーションに効果的な結果をもたらします。フェイルオーバー・プロセスの詳細は、第3.9項「サーバー全体の移行」を参照してください。このような状況では、エージェントは、同一ノード上で実行される2つのポリシー・マネージャ・インスタンスに対するロード・バランシングを実行します。
ポリシー・マネージャが使用する標準Java EEアーティファクトは、Oracle SOAサービス・インフラストラクチャがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データソースなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、別のOracle WSMコンポーネントで使用されるライブラリの同期化を制御します。
単一インスタンスの項で説明したように、Oracle WSMインスタンス固有の面に関して、WebLogic Serverドメイン・ディレクトリ（通常、1つのノードに1つのドメイン・ディレクトリ）ごとに、policy-accessor-config.xmlファイルおよびadf-config.xmlファイルで個別に構成されます。これらのファイルは、Oracle WebLogic Serverのpackユーティリティを使用するときに作成される.jarファイルに含まれるため、ユーザーがpack/unpackを実行してOracle SOAサービス・インフラストラクチャに高可用性を設定するときに、他のノードに伝播されます。ただし、policy-accessor-config.xmlまたはadf-config.xmlに対して現在加えている変更は、他のノードに自動的にレプリケートされません。つまり、ポリシー・マネージャのURLやキャッシュ・リフレッシュ間隔を更新したときなどに、各ノードを個別に修正する必要があります。このような修正は、高可用性トポロジにかかわるすべてのドメイン・ディレクトリで、手動で行う必要があります。ユーザーは、policy-accessor -config.xmlファイルやadf-config.xmlファイルを直接編集したり、Oracle Enterprise Manager Fusion Middleware Controlを使用して各管理対象サーバーの構成を変更したりできます。
Oracle WSMエージェントは、デプロイされているOracle WSMポリシー・マネージャを自動検出できます。この動作をオーバーライドして、特定のポリシー・マネージャ・インスタンスをポイントするには、policy-accessor-config.xmlファイルを編集します。
この項では、高可用性のためのOracle User Messaging Serviceの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。
Oracle User Messaging Service（Oracle UMS）は、ユーザーと、デプロイされているアプリケーションとの双方向通信を可能にします。電子メール、IM、SMSおよびText-to-Voiceメッセージなど、多様なチャネルに対応しています。Oracle UMSは、Oracle BPEL PM、Oracle Human Workflow、Oracle BAMおよびOracle WebCenterなどのOracle Fusion Middlewareコンポーネントに統合されます。通常、Oracle UMSは、Oracle SOAサービス・インフラストラクチャとともにデプロイされます。
Oracle UMSは、次のコンポーネントで構成されます。
UMSサーバー: Oracle 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-17は、Oracle UMSの単一インスタンス・アーキテクチャのサービスと依存性を表しています。
図5-17 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を使用します。デフォルトでは、UMSは、ファイル・ベースの永続JMSストアを使用するように構成されるため、そのファイルが存在するストレージ・デバイスに依存します。
Java EEアプリケーションと同様、すべてのUMSコンポーネントは、Oracle WebLogic Serverコンテナにより起動します。
UMSサーバーは、起動時に、データベース・リポジトリへの接続を確立するTopLinkセッションを初期化します。その後、UMSサーバーは、Webサービス・エンドポイントでのリスニングを開始します。また、メッセージの送信や配信ステータスの取得などの機能の呼出しにEJBを使用できるようになります。
UMSドライバがクラスタにデプロイされると、ドライバは登録メッセージをローカルUMSサーバーに送信します。UMSサーバーは、登録情報をデータベースに記録し、クラスタ内のすべてのUMSサーバーで使用できるようにします。すると、UMSサーバーは、クラスタ内のすべてのUMSドライバにメッセージをルーティングできるようになります。こうした状況は、新しいドライバがデプロイされたり、構成の変更後に既存のドライバが再起動されたりしたときに起こります。
通常、UMSドライバは、サーバーの起動時に、ドライバが構成されている外部ゲートウェイへの接続を確立します。たとえば、SMPPやXMPPなどの永続的なソケット・レベルの接続です。また、SMTP接続やIMAP接続のように、各リクエストに対して確立され、切断される接続もあります。その後、ドライバは、UMSサーバーへのリモートEJBコールを実行して、ドライバ自体を登録します。
クライアントがデプロイされている管理対象サーバーが起動すると、通常、EJBクライアントは、リモートEJBコールを実行し、UMSサーバーでドライバ自体を登録します。Webサービス・クライアントには明確な登録メカニズムはありません。
UMSクライアントは、UMSサーバーへの連続した短期リクエストを作成します。Webサービス・クライアントは、SOAPまたはHTTPを使用してリクエストを作成します。EJBクライアントは、JMSを使用した対話および管理の初期化と構成を目的とした、サーバーへのリモートEJBコールを実行します。
初期起動と登録の後のUMSのリクエスト・フローは、次のように分類できます。
アウトバウンド・メッセージング: アウトバウンド・メッセージの場合、クライアント・アプリケーションは、ユーザーにメッセージを送信します。クライアント・アプリケーションは、UMSサーバーに対してWebサービス・リクエストを送るか、UMSサーバーの送信JMSキューにメッセージをエンキューします。UMSサーバーは、リクエストを受信し、メッセージの状態を記録して、適切なドライバを選択します。UMSサーバーは、別のアウトバウンドJMSキューにメッセージをエンキューします。対応するドライバは、アウトバウンド・キューをリスニングし、メッセージをデキューして、所定のプロトコルに適した形式に変換し、これを外部ゲートウェイ（SMTPサーバーまたはIMゲートウェイなど）に配信します。
インバウンド・メッセージング: インバウンド・メッセージの場合、エンド・ユーザーは、クライアント・アプリケーションにメッセージを返信したいと考えます。ユーザーは、IMクライアントや電話などのデバイスからメッセージを送信します。メッセージは、外部ゲートウェイからドライバに渡されます。ドライバは、メッセージをUMS形式に適応させて、JMSキューにエンキューします。サーバーは、JMSキューからメッセージをデキューし、メッセージの状態を記録して、アプリケーションの適切なインバウンドJMSキューにメッセージをエンキューします。この後、クライアント・アプリケーションは、メッセージをデキューし、必要に応じて処理を実行します。
UMSサーバーとUMSドライバは、それぞれのXML構成ファイルを持ちます。このファイルは、構成Mbeanのアーティファクトであり、Oracle Fusion MiddlewareのJMXフレームワークを使用して実装されます。構成は、Oracle Enterprise Manager Fusion Middleware Controlを使用して変更できます。
図5-18 Oracle Enterprise Manager Fusion Middleware Controlを使用したOracle User Messaging Serviceの構成
すべてのUMSコンポーネントでは、標準のJava EEデプロイメント・ディスクリプタとOracle WebLogic固有のディスクリプタを使用して、Java EEコンポーネントを構成します。これらのディスクリプタは、Oracle WebLogic Server管理コンソールやWLSTなどの標準Oracle WebLogicツールを使用して構成できます。詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のUMS管理に関する項を参照してください。
Oracle SOA Suiteをクラスタ環境で使用している場合、あるノードの構成プロパティをOracle Enterprise Managerで変更したときには、その変更がすべてのノードに適用される必要があります。構成プロパティは、Oracle Enterprise Managerで、「SOAインフラストラクチャ」メニューの次のオプションを使用して設定します。
「管理」→「システムMBeanブラウザ」
「SOA管理」→任意のプロパティを選択
Oracle SOAサービス・インフラストラクチャの2ノード高可用性の特性の説明は、第5.2.2項「SOAサービス・インフラストラクチャの高可用性アーキテクチャとフェイルオーバーに関する考慮事項」を参照してください。図5-6は、2つのWebLogic ServerでOracle SOAサービス・インフラストラクチャのクラスタが実行されている様子を示しています。Oracle User Messaging Serviceは、Oracle SOAサービス・インフラストラクチャのコンポジット・アプリケーションの一部としてデプロイされます。次の高可用性の特性は、Oracle User Messaging Serviceの高可用性デプロイメントに固有のものです。
すべてのUMSコンポーネントは、Oracle WebLogic Serverクラスタの一部であるOracle WebLogic Serviceインフラストラクチャの管理対象サーバーにデプロイされます。Oracle WebLogic Serverクラスタは、JDBCデータソースなど、UMSで使用されるOracle WebLogic Serverの共通アーティファクトの構成を同期化します。
Oracle UMSコンポーネントは、すべてステートレスです。
UMSのサーバーおよびクライアントのステートレスEJBは、Oracle WebLogic Serverクラスタのクラスタリングと高可用性の機能を利用します。
UMSサーバーは、永続記憶域に関して、共有データベース・リポジトリに依存します。
UMSは、クラスタ・ノード間のロード・バランシングと可用性に関して、JMS分散宛先に依存します。また、障害の発生時には、別のJMSサーバーにフェイルオーバーするために、JMSコネクション・ファクトリの機能に依存します。
ユーザー・メッセージング・プリファレンスのユーザー・インタフェースでは、セッション振分けは必要ありません。基本ロード・バランシングを使用することで、ユーザー・インタフェースは、使用可能な状態に保たれます。セッションの状態はすべて、データベースに永続的に保持され、クラスタ化されたインスタンスにより共有されるため、セッション・ルーティング要件は特にありません。
UMSは、グローバル・トランザクションにはまったく関与しません。
UMSは、Oracle WebLogic Serverのマルチ・データソースを使用して、バックエンドOracle RACデータベースに接続します。
通常、Oracle UMSは、Oracle SOAサービス・インフラストラクチャと同じ管理対象サーバーにデプロイされます。Oracle SOAサービス・インフラストラクチャは、Oracle WebLogic Serverのサーバー全体の移行を使用して、プロセスやノードの障害から保護されます。サーバー全体の移行では、JMS使用時のフェイルオーバー機能も提供されます。
Oracle UMSの障害からの保護および予想される動作の詳細は、第5.2.2.1項「Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作」を参照してください。
この項では、Oracle User Messaging Serviceの高可用性構成のプロセス障害に固有の考慮事項について説明します。
クラッシュが発生すると、ノード・マネージャは、管理対象サーバーの再起動をローカルで試行します。
Oracle UMSコンポーネントのデプロイ先のOracle WebLogic Server管理対象サーバーに対してサーバー全体の移行が構成されており、再起動の回数がしき値を超えた場合、Oracle 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サーバーの「メッセージ・ステータス」ページを使用して手動でメッセージを再送信できます。
UMSは、ファイルベースの標準Java EEデプロイメント・ディスクリプタと、標準JMXフレームワークを使用するJMX構成Mbeanで構成されます。変更は、標準のOracle WebLogic Server Mbeanサーバー・メカニズムにより伝播されます。クラスタワイドの構成機能はありません。そのため、クラスタのすべてのメンバーに対して構成の変更を繰り返す必要があります。
UMSは、標準のJava EEアーティファクトを使用します。このアーティファクトは、Oracle UMSがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogic Serverクラスタは、Oracle WebLogic Serveドメイン全体にわたる、データソースなどのアーティファクトの自動構成同期化機能を提供します。同時に、Oracle WebLogic Serverクラスタは、デプロイメントと、別のOracle UMSコンポーネントで使用さるライブラリの同期化を制御します。
この項では、高可用性のためのOracle JCAアダプタの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。
Oracle JCAアダプタは、サービス・インフラストラクチャが様々なプロトコルを使用してエンドポイントと通信できるようにする、JCAバインディング・コンポーネントです。Oracle JCAアダプタは、JCAリソース（RAR）としてデプロイされるものであり、Oracle SOAサービス・インフラストラクチャの一部ではありません。
Oracle JCAアダプタのランタイム・コンポーネントは、特定のバックエンド・アプリケーションのJ2CA 1.5リソース・アダプタです。Oracle JCAアダプタは、Oracle WebLogic ServerのJ2CAコンテナにデプロイされます。Oracle Fusion Middlewareは、JCAバインディング・コンポーネントによってこれらのJ2CA 1.5アダプタと統合されます。JCAバインディング・コンポーネントは、Webサービス・メッセージをJ2CA相互作用に変換し、またその逆の変換を実行します。そのため、アダプタは、Oracle WebLogic Serverの基盤となるプラットフォームのスケーラビリティと高可用性を完全に利用できます。
図5-19は、Oracle JCAアダプタの単一インスタンス・アーキテクチャのサービスと依存性を表しています。
アダプタのライフサイクルは、Oracle SOAサービス・インフラストラクチャにより制御されます。Oracle JCAアダプタの初期化では、3つの高レベルな手順を実行します。
デプロイメント: Oracle JCAアダプタは、J2CA 1.5リソース・アダプタ（RARファイル）として、インストール時にOracle Fusion Middlewareと同じOracle WebLogic Serverコンテナ内にデプロイされます。アダプタの物理的デプロイメントには、RARファイルの使用と、基盤となるOracle WebLogic Serverまたは中間層プラットフォームとのコネクタとしてのアダプタの登録が必要になります。RARファイルにはra.xmlファイルが含まれます。このファイルには、Oracle WebLogic Serverとリソース・アダプタとの間の規定に関する宣言情報が記述されています。さらに、RARファイルには、weblogic-ra.xmlファイルが含まれています。これは、リソース・アダプタに関するデプロイメント固有の情報が記述されたデプロイメント・ディスクリプタ・ファイルです。
ロード: ロードとは、メモリー内リソースの作成と構成済エンドポイントへの接続の確立のプロセスを表します。Oracle JCAアダプタは、J2CA 1.5リソース・アダプタとして物理的にデプロイされますが、論理的デプロイメントでは、weblogic-ra.xmlファイルを編集して、J2CA 1.5リソース・アダプタのコネクション・ファクトリ・エントリを作成する必要があります。このファイルは、リソース・アダプタ用の、Oracle WebLogic Server固有のデプロイメント・ディスクリプタです。このファイルには、リソース・アダプタのデプロイメント・ディスクリプタで指定されているバックエンド・アプリケーション接続情報、使用されるJava Naming and Directory Interface（JNDI）名、接続プーリング・パラメータ、リソース・プリンシパル・マッピング・メカニズムおよび構成など、リソース・アダプタをOracle WebLogic Serverにデプロイするための構成が含まれています。
アクティブ化: アクティブ化とは、コンポジット内のJCAバインディング・コンポーネント（サービスおよび参照）の開始を表します。リスナーは、コンポジット内のアダプタ構成で参照されるエンドポイントに対して開始されます。
Oracle JCAアダプタは、基盤となるバックエンド操作固有のプロパティをヘッダー・プロパティとして公開して、ビジネス・プロセス内でのこれらの要素の操作を可能にします。基盤となるプロパティは、次のとおりです。
interactionspecプロパティまたはactivationspecプロパティ: これらのプロパティには、リサイクルする（再アクティブ化する）アダプタ・エンドポイントが必要です。
エンドポイント・プロパティ: これらのプロパティの変更はアダプタに通知され、エンドポイントを再起動する必要はありません。
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回処理されます。その結果、出力ディレクトリにファイルが重複して存在する場合があります。
Oracle 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で表示されます。エラー・ハンドラは、エラーの自動処理時に起動され、起動中にペイロードも受け取ります。データベース内でのエラーのペイロードの永続性は、デフォルトで有効になっています。
この項では、Oracle SOAクラスタ上で実行される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と、レガシー・アダプタは、イベント受信のためのバックエンド・アプリケーションへの接続に対するポーリング・モデルをサポートします。リカバリ不能な接続障害が発生した場合、アダプタは旧接続をリサイクルし、Oracle SOAサービス・インフラストラクチャにアラートまたは通知を送ります。インバウンド相互作用の接続エラーはログに記録され、Oracle WebLogic Server管理コンソールで表示できます。
Oracle File AdapterおよびOracle FTP Adapterは、アクティブ/アクティブ・トポロジを使用した高可用性構成が可能です。クラスタ・ベースの高可用性構成は、インバウンドとアウトバウンドの両方の操作でサポートされています。Oracle File AdapterおよびOracle FTP Adapterでは、XAに対応していないため、最低一回のメッセージの配信のみが保証されます。そのため、サーバー・クラッシュからのリカバリ後は、メッセージが重複する可能性があります。
高可用性のための前提条件
Oracle JCAアダプタの高可用性のための前提条件は、次のとおりです。
クラスタ化された構成では、管理対象サーバー上のインバウンド・アダプタが共有ドライブの同一物理ディレクトリを指す必要があります。
接続ファクトリでは、制御ディレクトリに同一の共有フォルダを指定し、それらの名前が一致している必要があります。たとえば、あるコネクション・ファクトリのデプロイメント・ディスクリプタで、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では、必ず1つのノードのみが分散トポロジ内の特定ファイルを処理するようにする必要があります。
アウトバウンド操作: Oracle File AdapterおよびOracle FTP Adapterでは、複数の参照が同一ディレクトリに書き込む場合に、相互に上書きしないようにする必要があります。
クラスタ化されたトポロジでのこれらの動作を保証するため、データベース・ベースのmutexがコーディネータとして使用されます。
次の手順を実行して、Oracle WebLogic Server管理コンソールから、eis/HAFileAdapterに対応するconnection-instance用のOracle File Adapterのデプロイメント・ディスクリプタを変更し、データベース表をコーディネータとして構成します。
Oracle WebLogic Server管理コンソールで、「デプロイメントの概要」の「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: このパラメータには、制御ファイルを格納するディレクトリ構造を設定します。クラスタ内で複数のOracle WebLogic Serverインスタンスが実行されている場合は、共有場所を設定します。
inboundDataSource: このパラメータには、jdbc/SOADataSourceを設定します。これは、高可用性に対応するスキーマがあらかじめ作成されているデータソースです。事前に作成されたスキーマは、MW_HOME/AS11gR1SOA/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sqlにあります。それ以外の場所にスキーマを作成するには、このスクリプトを使用します。別のスキーマを選択する場合は、そのスキーマに応じてinboundDataSourceプロパティを設定します。
outboundDataSource: このパラメータには、jdbc/SOADataSourceを設定します。これは、高可用性に対応するスキーマがあらかじめ作成されているデータソースです。事前に作成されたスキーマは、MW_HOME/AS11gR1SOA/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sqlにあります。それ以外の場所にスキーマを作成するには、このスクリプトを使用します。別の場所にスキーマを作成する場合は、outboundDataSourceプロパティを設定します。
outboundLockTypeForWrite: Oracleデータベースを使用している場合は、このパラメータにoracleを設定します。Oracle File AdapterおよびOracle FTP Adapterは、デフォルトでメモリ内mutexを使用してアウトバウンド書込み操作をロックします。書込み操作を同期化するには、次の値の1つを選択します。
メモリ: Oracle File AdapterおよびOracle FTP Adapterは、メモリ内mutexを使用してファイル・システムへのアクセスを同期化します。
oracle: アダプタは、Oracleデータベース・シーケンスを使用します。
db: アダプタは、事前に作成されたデータベース表（FILEADAPTER_MUTEX）をロック・メカニズムとして使用します。このオプションは、Oracleデータベース・スキーマ以外のスキーマを使用しているときにかぎり使用します。
ユーザー定義: アダプタはユーザー定義のmutexを使用します。ユーザー定義のmutexを構成するには、mutexインタフェースoracle.tip.adapter.file.Mutexを実装し、oracle.tip.adapter.file.mutexという名前の新しいバインディング・プロパテと、アウトバウンド参照用mutexに対して完全修飾されたクラス名の値を構成します。
|
注意: 大きなペイロードの場合は、次の行を追加して、SOA DataSourceのトランザクション・タイムアウトを増やします。
データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトを増やします。 |
Oracle Databaseアダプタは、アクティブ/アクティブ設定での高可用性をサポートします。アクティブ/アクティブ設定では、インバウンド・データベース・アダプタに対して分散ポーリング技術を使用して、同一データが重複して取得されないようにできます。詳細は、アダプタ・ガイドの分散ポーリングのベスト・プラクティス（MarkReservedValue）に関する項を参照してください。他のアダプタと同様、Oracle Databaseアダプタをアクティブ/パッシブ設定内でのシングルトン動作に対して構成することもできます。これにより、アクティブ/パッシブ設定内で実行される、高パフォーマンスなマルチスレッド・インバウンドOracle Databaseアダプタ・インスタンスは、ファンアウト・パターンに従って、クラスタ上の複数のコンポジット・インスタンスを呼び出せます。Oracle Databaseアダプタは、データベース障害時や再起動時にも、高可用性機能をサポートします。DBアダプタは、メッセージを損失することなく、再度メッセージを取得します。フォルト・ポリシーを使用したインバウンド拒否メッセージの処理の詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。
データベースの障害発生時の再起動
Oracle Databaseアダプタは、データベースが停止した場合にも、メッセージを損失することなく、再度メッセージを取得できます。データを損失しないようにするには、データソースがXA対応であり、RAC（マルチ・データソース）用に構成されている必要があります。データソースの高可用性構成の詳細は、付録B「推奨されるマルチ・データソース」を参照してください。
Oracle JMSアダプタは、WebLogic JMS、MQ SeriesおよびOracle AQアダプタをはじめとする複数のプロバイダをサポートします。JMSアダプタは、サーバーのクラッシュ時に、メッセージを損失することなく、必ず1回メッセージを配信します。必ず1回のメッセージ配信が保証されるようにするには、JMS接続ファクトリを、XAをサポートするように構成する必要があります。各種アダプタの接続ファクトリの構成の詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。
Oracle AQでは、XAおよびRAC用にデータソースを構成する必要もあります。データソースの高可用性構成の詳細は、付録B「推奨されるマルチ・データソース」を参照してください。
Oracle JCAアダプタのログは、次のようにして表示できます。
Oracleアプリケーション向けOracle JCAアダプタおよびOracle Adapter: アウトバウンドとインバウンドの両方の相互作用で、ログ・ファイルはsoa-diagnostic.logファイルにリダイレクトされます。server-soa管理対象サーバーにデプロイされるOracle Fusion Middleware 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は、デーモン・ログ、ワークスペース・ログ、サーバー・プロセス・ログなど、様々なタイプのログを生成します。
この項では、高可用性のためのOracle BAMの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。
Oracle BAMは、企業のビジネス・サービスおよびビジネス･プロセスを監視するツールを提供します。これにより、現実のビジネス・プロセスや変化するビジネス・プロセスにマーケット・インジケータを迅速に関係付けたり、ビジネス環境が変化した場合に適切な措置を講じたりできます。Oracle Business Activity Monitoring（Oracle BAM）は、リアルタイムのデータ・フローを表示し、特定の状況においてアラートを送信するルールを定義するダッシュボードの作成に必要なツールやランタイム・サービスを提供します。
図5-20は、Oracle BAMインスタンスの特徴である主要サービスと依存性を表しています。
図5-20 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は、アクティブ・データ・キャッシュ内のデータを管理するためのコマンドライン・インタフェースです。ICommandは、アクティブ・データ・キャッシュのアイテムをエクスポート、インポート、名前変更、クリアおよび削除するためのコマンド・セットを提供します。
BAMアプリケーションは、他のOracle Fusion Middleware SOA Suiteコンポーネントから独立して実行されます。Oracle BAM Webアプリケーションは、BAM Serverとともにデプロイされます。Oracle BAM Serverは、サービスを実装してデータベースに情報を永続的に保持するために、EJBとDAOを使用します。EJBは、すべてステートレスです。ただし、Oracle BAM Serverはシングルトンであり、送られてきたデータを保持して、それをWebアプリケーション・レポートにプッシュするために、アクティブなOracle BAM Serverが1つのみ使用されます。Oracle BAM Serverを障害から保護するために、Oracle 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およびスレッドにより実行される処理は、非トランザクションであるため、Oracle WebLogic Serverの特別なトランザクション・ログ構成は必要ありません。同時に、Oracle BAMはデータベースを集中的に使用するため、データベースの障害に備えたOracle BAMのデータベース・アクセスが重要となります。そのため、第5.12項「Oracle BAMの高可用性の構成」の説明に従って、Oracle BAMデータソースにマルチ・データソースを構成する必要があります。RACおよびMDSリポジトリでのマルチ・データソースの構成の詳細は、第4.1.2項「Oracle RACでのマルチ・データソースの使用」を参照してください。
Oracle BAMエンジン・システムは、Oracle BAMデータおよびレポート・メタデータに関して、Oracle BAMデータベース（Oracle BAMスキーマを含む）にのみ依存します。Oracle BAMシステムが適切に起動し、実行されるためには、データベースが使用可能である必要があります。
図5-21に示すように、WebLogic Serverが起動するときに、Oracle BAM Serverアプリケーションが初期化されます。アクティブ・データ・キャッシュは、起動時にすべてのデータをリポジトリからロードします。レポート・キャッシュは、使用可能なシステムに必要なデータで初期化されます。イベント・エンジンは、データの分析と通知の準備を開始します。Oracle BAM Webアプリケーションは、起動時にOracle BAM Serverのアドレスで構成されます。Oracle BAM Webアプリケーションは、起動時にOracle BAM Serverのアクティブ・データ・キャッシュに接続し、Reports Serverを通じて対応するビューセットを取得します。初期化が終了すると、クライアントからのデータ受信、イベントの呼出し、およびレポートの動的更新が可能になります。
図5-21 Oracle Business Activity Monitoringの起動とシャットダウンのライフサイクル
Oracle BAM Serverは、SOAサービス・インフラストラクチャの他のアプリケーションから独立して動作する1つのアプリケーション、すなわちoracle-bamです。Oracle BAMがインストールされている管理対象サーバーで実行されます。また、Oracle BAMがデプロイされているOracle WebLogic管理対象サーバーによってデフォルトで起動されます。Oracle WebLogic Server管理コンソールを使用すると、Oracle BAM Serverのステータスを確認したり、Oracle BAM Serverを起動および停止したりできます。アプリケーションの制御に、WebLogic Server WLSTのコマンドラインも使用できます。
図5-22 WebLogic Serverを使用したOracle Business Activity Monitoringの起動とシャットダウン
Oracle Enterprise Manager Fusion Middleware Controlを使用すると、BAM Serverの多数の操作と構成を行えるだけでなく、ステータスを監視することもできます。Oracle BAMエンジンの監視と制御の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。
図5-23 Fusion Middleware Controlを使用したOracle Business Activity Monitoringの起動とシャットダウン
BAM Webアプリケーションは、デフォルトでBAM Serverと同じ管理対象サーバーにコロケートされて実行されます。たとえば、BAM ServerとBAM Webアプリケーションは、WebLogic Server Administration Consoleで同一デプロイメントの一部となります。デフォルトでは、これらをBAM Serverと切り離して停止したり管理したりできません。しかし、この後で説明するように、それぞれを個別のコンポーネントにターゲット指定してWebLogic Serverアプリケーションを処理することは可能です。Oracle WebLogic Administration Consoleを使用すると、Oracle BAMを起動および停止できます。WLSTコマンドでも同じことが可能です。
Oracle Enterprise Manager Fusion Middleware Controlのコンソールを使用すると、BAM Webアプリケーションの多数の操作と構成を行えます。
図5-24 Oracle Enterprise Manager Fusion Middleware Control
|
注意: Enterprise ManagerはOracle BAM ServerとOracle BAM Webアプリケーションを個別に起動および停止しますが、停止操作は、実際には両方のコンポーネントに影響します。つまり、Oracle BAM ServerがEnterprise Managerにより停止されると、対応するOracle BAM Webアプリケーションも停止し、その逆も同様です。このことは、起動操作にも当てはまります。 |
Oracle Enterprise Manager Fusion Middleware Controlは、Oracle BAM Serverに関するいくつかの構成オプションを公開します。
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 Fusion Middleware User's Guide for Oracle Business Activity Management』を参照してください。
同様に、Figure 5-26に示すように、Oracle Enterprise Manager Fusion Middleware Controlによって、Oracle BAM Webアプリケーションに対するいくつかのプロパティが公開されます。
図5-26 Oracle Business Activity Monitoringの構成プロパティ
データソースや永続ストアなど、コンテナ・レベルの構成オプションは、WebLogic Serverドメイン構成の一部として保持され、Oracle WebLogic Serverのコア・インフラストラクチャにより、Oracle WebLogic Serverのクラスタ上で同期化されます。Oracle BAMの構成の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。
図5-27は、2つのOracle WebLogic Serverで2ノードのOracle BAMクラスタが実行されている様子を示しています。Oracle WebLogic Serverは、それらのサーバーへの受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。この構成の主要な特性は、次のとおりです。
Oracle BAM Webアプリケーションは、クラスタ化された2つのWebLogic Serveの管理対象サーバー上で実行されます。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の両方（APPHOST1内）を実行するOracle WebLogic Serverを障害から保護します。これにより、シングルトンのOracle BAM Serverが保護されます。Oracle BAM Serverが実行されているWebLogic管理対象サーバーは、フェイルオーバーの発生時に別のノードに移行された仮想IPをリスニングします。仮想IPは、APPHOST2内のOracle BAM WebアプリケーションがOracle BAM Serverへの接続に使用するアドレスです。Oracle BAM Serverと、Oracle BAM Webアプリケーションの2つのインスタンスが、APPHOST2上で実行されるシナリオを考慮し、適切に計画してください。サーバー移行機能の詳細は、第3章「WebLogic Serverの高可用性」を参照してください。
Oracle BAMのデータベースは、データベースの障害から保護するために、Oracle Real Application Cluster（RAC）で構成されます。データベース・インスタンスの障害が発生すると、Oracle BAM Serverは、再接続と操作の再試行を適切に実行します。
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が移行されて管理対象サーバーが再起動すると、APPHOST2内のBAM Webアプリケーションが再接続します。VIP1をリスニングするBAM Webアプリケーションは、サーバー移行が完了すると機能し始めます。このときに、HTTP Serverは、管理対象サーバーへのHTTPリクエストのルーティングを再開します。
BAM Webアプリケーションのみが実行されているWebLogic Serverに影響のある障害は、BAMシステムには影響しません。他のBAM Webアプリケーション（APPOHOST1で実行）は、引き続き使用可能であり、WebLogic Serverのセッション・レプリケーション・クラスタを使用してセッション情報を保持します。フェイルオーバーは、透過的に実行されます。
BAM ServerとBAM Webアプリケーションが実行されているoracle-bamアプリケーションは、リソースへのアクセスの失敗、データベースの読取りエラー、またはデータベースが配置されている管理対象サーバーのステータスには関係なく発生する他の問題が原因で停止する場合があります。そのため、Oracle SOAサービス・インフラストラクチャ・アプリケーションによって引き起こされるエラーを管理対象サーバーのログで監視する必要があります。ログ・ファイルの場所の詳細は、第5.2.1.6項「Oracle SOAサービス・インフラストラクチャのログ・ファイルの場所」を参照してください。
レポートが開かれており、クラスタ内でBAM管理対象サーバーが1つしか起動していず、クラスタ内での追加の管理対象サーバーの起動後に他の操作を何も実行していない場合は、開かれたレポートのフェイルオーバーは正常に終了しません。セッション状態レプリケーションの１回のトリガーでレポートが開かれます。セッション状態レプリケーションは、アクティブ・データの更新ではトリガーされません。
APPHOST2でのノード障害の場合、ノード障害時の動作はプロセス障害のシナリオの場合と同じです。つまり、他のノード内のOracle BAM Webアプリケーションは、引き続き使用可能であり、リクエストを処理できます。セッションは、WebLogic Serverが提供するセッション・レプリケーション・フレームワークによって維持され、他のノードへのフェイルオーバーが透過的に実行されます。
APPHOST1でのノード障害が発生した場合、使用可能なサーバーによりデータベース・リース・システム内のタイムスタンプが検証された後、サーバーの移行がトリガーされます。フェイルオーバーの実行中には、クライアントはデータをシステムに送信できず、必要に応じて送信を再試行します。サーバーに接続しているOracle BAM Webアプリケーションは、VIPが移行されてサーバーが再起動するまで、再接続を試行します。
データベース障害
Oracle BAMデータベース障害の詳細は、第5.2.2.1項「Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作」を参照してください。
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 Fusion Middleware User's Guide for Oracle Business Activity Management』を参照してください。
高可用性の環境に関連する構成オプションの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モニターの設定について、ロード・バランサのベンダーにご確認ください。
この項では、Oracle BPEL PM、Oracle Mediator、Oracle Human WorkflowおよびOracleデシジョン・サービスの他、Oracle B2BおよびOracle User Messaging Serviceなど、Oracle SOAサービス・インフラストラクチャ・システムに含まれるサービス・エンジンの設定手順について説明します。
|
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
図5-28は、この項の構成手順で作成するアーキテクチャの例を表しています。
図5-28は、2つのOracle WebLogic Serverで2ノードのSOAクラスタが実行されている様子を示しています。Oracleサーバーは、受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。カスタムの論理デプロイメントとアプリケーション・デプロイメントには、異なるOracle WebLogic Serverが使用されます。この構成では、メタデータとSOAスキーマの格納にはOracle RACデータベース、トランザクションとJMSストアには共有記憶域を使用しています。仮想IPアドレス（VIP）は、管理サーバーとOracle SOA Server（サーバー移行用）の手動フェイルオーバーに使用されます。このアーキテクチャに含まれるコンポーネントの詳細は、この章の個々のコンポーネントの項を参照してください。
管理サーバーの仮想IPの構成および高可用性のための管理サーバーの構成の詳細は、第10.2.2.3項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。
次の各項では、Oracle SOAサービス・インフラストラクチャの高可用性構成を設定する前に必要となる手順について説明します。
プラットフォーム固有のコマンドの詳細は、『Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド』を参照してください。
Oracle SOAサービス・インフラストラクチャでサポートしているデータベースのバージョンは次のとおりです。
Oracle Database 10g（非XEデータベースについては10.2.0.4以上）
Oracle Database 11g（非XEデータベースについて11.1.0.7以上）
データベースのバージョンを調べるには、次の問合せを実行します。
SQL>select version from sys.product_component_version where product like 'Oracle%';
表5-1に示されているように、それぞれ異なる仮想IPをリスニングする管理サーバーとSOA管理対象サーバーを構成します。そのためには、ノード内の対応するVIPのプロビジョニングと、ネットワーク上のDNSシステムで関連付けられているホスト名が必要です。各VIPが使用可能かつアクセス可能であることを、インストールの実行前に確認してください。
表5-1 仮想ホスト
| 仮想IP | VIPのマップ先 | 説明 |
|---|---|---|
|
VIP0 |
APPHOST1VHN0 |
APPHOST1VHN0は、管理サーバーのリスニング・アドレスであり、管理サーバーの手動フェイルオーバーによりフェイルオーバーする、仮想ホストの名前です。管理サーバー・プロセスが実行されているノード（デフォルトはAPPHOST1）で有効化されます。 |
|
VIP1 |
APPHOST1VHN1 |
APPHOST1VHN1は、WLS_SOA1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_SOA1プロセスが実行されているノード（デフォルトはAPPHOST1）で有効化されます。 |
|
VIP2 |
APPHOST2VHN2 |
APPHOST2VHN1は、WLS_SOA2のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_SOA2プロセスが実行されているノード（デフォルトはAPPHOST2）で有効化されます。 |
障害発生時に適切にリカバリできるようにするため、すべてのノードからアクセスできて、管理対象サーバーで障害が発生した後に操作を再開できる場所に、JMSとトランザクションの両方のログを格納します。そのためには、複数ノードで参照可能な共有記憶域の場所が必要です。表5-2は、共有記憶域の内容を示しています。
表5-2 共有記憶域の内容
| サーバー | データの型 | 共有記憶域のボリューム | ディレクトリ | ファイル |
|---|---|---|---|---|
|
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などのデバイスを使用できます。NASデバイス別のコマンド例を次に示します。この項で指定しているオプションは、実際のオプションと異なる場合があります。
APPHOST1> mount nasfiler:/vol/volX/FMWshared ORACLE_BASE/product/fmw -t nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
本番環境では、Oracle SOA Suiteの高可用性トポロジに外部のLDAPポリシー・ストアが必須です。サポートされているポリシー・ストアの詳細およびLDAPの構成手順は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。
高可用性SOAのデプロイメントでは、各クラスタ・ノードのシステム・クロックを同期することをお薦めします。
次のリストは、この項で使用するディレクトリと変数について説明しています。
ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指します。
MW_HOME: この環境変数および関連するディレクトリ・パスは、Fusion Middleware（FMW）が常駐している場所を指します。
WL_HOME: この環境変数および関連するディレクトリ・パスには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています。
ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Fusion Middleware SOA Suiteがインストールされている場所を指します。
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
WLS_HOME:
MW_HOME/wlserver_10.3
ORACLE_HOME:
MW_HOME/soa
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/
共有記憶域の場所:
ORACLE_BASE/admin/domain_name/soa_cluster_name/ (VOL1 or VOL2)
Oracle Fusion Middleware SOAのコンポーネントをインストールする前に、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ユーザーズ・ガイド』を参照してください。
RCUを実行して、Oracle Fusion Middleware 11gに必要なメタデータをインストールします。
Linuxでは、RCU_Home/binに移動して、次のコマンドを使用します。
./rcu
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードし、「次へ」をクリックします。
「データベース接続の詳細」画面で、データベースの接続情報を入力します。
データベース・タイプ: Oracle Databaseを選択します。
ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合は、VIP名を指定するか、またはノード名のいずれかをホスト名として指定します: SOADBHOST1VIRTUAL
ポート: データベースのポート番号: 1521
サービス名: データベースのサービス名を入力します: soaha.mycompany.com
ユーザー名: SYS
パスワード: SYSユーザーのパスワードを入力します。
ロール: SYSDBA
「次へ」をクリックします。
次のような警告メッセージを受信する場合があります。
接続先のデータベースには非UTF8 charsetが含まれています。このデータベースを使用して複数言語のサポートを求める場合、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。
その場合は、「無視」または「停止」をクリックします。
「コンポーネントの選択」画面で「接頭辞の新規作成」を選択し、SOAHAのように、データベース・スキーマに使用する接頭辞を入力します。
後の手順で利用できるように、このスキーマ名を書き留めておきます。
次のスキーマを選択します。
「AS共通スキーマ」で、「メタデータ・サービス」を選択します。
「SOAサービス・インフラストラクチャ」で、「SOAサービス・インフラストラクチャ」と「ユーザー・メッセージング」を選択します。
「次へ」をクリックします。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加（補助）のスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。
「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。
RCUの使用の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。
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は、RCU専用のMiddlewareホームにインストールします。
RCUのインストールの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
次の初期化パラメータが、必要な値に設定されていることを確認します。この値は、リポジトリ作成アシスタントによってチェックされます。
SQL*Plusを使用して初期化パラメータの値をチェックするには、SHOW PARAMETERコマンドを次のように使用します。
SYSユーザーとして、SHOW PARAMETERコマンドを次のように発行します。
SQL> SHOW PARAMETER processes
次のコマンドを使用して初期化パラメータを設定します。
SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE
データベースを再起動します。
|
注意: パラメータの値を変更する方法は、パラメータが静的か動的かによって異なり、データベースがパラメータ・ファイルとサーバー・パラメータ・ファイルのどちらを使用しているかによっても異なります。パラメータ・ファイルとサーバー・パラメータ・ファイルの詳細、およびパラメータ値の変更方法は、『Oracle Database管理者ガイド』を参照してください。 |
WEBHOST1にOracle HTTP Serverをインストールする手順は次のとおりです。
サーバーが次の要件を満たしていることを確認します。
システム、パッチ、カーネルなどの要件が、『Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド』で指定されている要件を満たしている。
ポート7777が、ノード上のどのサービスによっても使用されていない。このことを確認するには、次のコマンドを実行します。
UNIX:
netstat -an | grep 7777
Windows:
netstat -an | 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スクリプトを実行するように求められます。コマンド・ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成」画面で、いくつかの構成アシスタントが連続して開始されます。構成アシスタントが終了すると、「構成が完了しました」画面が表示されます。
「構成が完了しました」画面で、「終了」をクリックして終了します。
この項では、Oracle WebLogic ServerとOracle Fusion Middleware SOA Suiteを実行するアプリケーション層のすべてのノードにOracle Fusion Middlewareをインストールする手順について説明します。
Oracle Fusion Middlewareの、次のコンポーネントをインストールします。
Oracle WebLogic Server（第5.11.3.1項「Oracle WebLogic Serverのインストール」を参照）
Oracle Fusion Middleware SOA Suite（第5.11.3.2項「Oracle SOA用Oracle Fusion Middlewareのインストール」を参照)
アプリケーション層にあるすべてのノードにOracle WebLogic Serverをインストールする手順は次のとおりです。
UNIXプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。
Oracle WebLogic Serverインストーラを起動します。
UNIXの場合（次の例はLinuxの場合）:
APPHOST1> server103_linux32.bin
Windowsの場合:
APPHOST1> server103_win32.exe
「インベントリ・ディレクトリの指定」画面で、次の操作を行います。
HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです（この場所が推奨されます）。
インストールを実行するユーザーのOSグループを入力します。
「次へ」をクリックします。
createCentralInventory.shをルートとして実行する場合の手順に従います。
「OK」をクリックします。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。
「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、ORACLE_BASE/product/fmwと入力します。
「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。
「製品とコンポーネントの選択」画面で、「次へ」をクリックします。
「JDKの選択」画面で、「JROCKIT SDK1.6.0_05」のみを選択して「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。
ORACLE_BASE/product/fmw/wlserver_10.3
「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」の選択を解除して「完了」をクリックします。
Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。
Oracle Fusion Middleware 11g Oracle SOA Suiteのインストーラを起動します。
UNIXの場合:
APPHOST1> runInstaller
Windowsの場合:
APPHOST1> setup.exe
Oracle Fusion Middleware 11g Oracle SOA Suiteのインストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_05_R27.6.2-20のように入力します。
「インベントリ・ディレクトリの指定」画面で、次の操作を行います。
HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです（この場所が推奨されます）。
インストールを実行するユーザーのOSグループを入力します。
「次へ」をクリックします。
画面の手順に従って、/createCentralInventory.shをルートとして実行します。
「OK」をクリックします。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、次の操作を行います。
「MiddleWareホーム」には、ORACLE_BASE/product/fmwと入力します。
「Oracleホーム・ディレクトリ」には、soaと入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
「インストール 完了」画面で「終了」をクリックします。
SOAホーム・ディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーとOracle SOAコンポーネントが格納されるドメインを作成します。リポジトリをインストールしたデータベースが実行されていることを確認します。RACデータベースの場合は、すべてのインスタンスが実行されている必要があります。
MiddlewareホームのSOAディレクトリにある、Oracle WebLogic Serverの構成ウィザードの場所に、ディレクトリを変更します。
APPHOST1> cd ORACLE_HOME/common/bin
Oracle WebLogic Serverの構成ウィザードを起動します。
Linuxの場合:
APPHOST1> ./config.sh
Windowsの場合:
APPHOST1> config.cmd
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択し、次の製品を選択します。
Oracle SOA Suite - 11.1.1.0 [soa]
Oracle Enterprise Manager - 11.1.1.0 [soa]
Oracle JRF - 11.1.1.0 [soa]（デフォルトで選択）
Oracle WSM Policy Manager 11.1.1.0 [soa]（デフォルトで選択）
「次へ」をクリックします。
「ドメイン名と場所の指定」画面で、次のエントリを作成します。
ドメイン名: soadomain
ドメインの場所: デフォルトを受け入れます。
アプリケーションの場所: デフォルトを受け入れます。
「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
WebLogicドメインの起動モード: 「本番モード」を選択
JDKの選択: 「JROCKIT SDK1.6.0_05」を選択
「次へ」をクリックします。
「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。
画面下部の表に表示されるすべてのコンポーネント・スキーマ、SOAインフラストラクチャ、ユーザー・メッセージング・サービス、OWSM MDSスキーマおよびSOA MDSスキーマを選択します。
「次のパネルで選択したコンポーネント・スキーマをRACマルチ・データ・ソース・スキーマとして構成します。」を選択します。
画面に次のデータソースが表示されていることを確認します。表5-4に示されているユーザー名は、RCUからのスキーマ作成で接頭辞にsoahaが使用されていることを想定しています。
RACおよびMDSリポジトリでのマルチ・データソースの構成の詳細は、第4.1.2項「Oracle RACでのマルチ・データソースの使用」を参照してください。
「次へ」をクリックします。
「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、次のフィールドに値を入力して、RCUでシードされたRACデータベースの接続情報を指定します。
ドライバ: RACサービス・インスタンス接続用Oracleのドライバ（Thin）、バージョン:10、11を選択します。
サービス名: データベースのサービス名を入力します（例: soaha.mycompany.com）。
ユーザー名接頭辞: スキーマの接頭辞を入力します。表5-4に示されているユーザー名は、RCUからのスキーマ作成で接頭辞としてsoahaが使用されていることを想定しています。
「パスワード」と「パスワードの確認」: スキーマにアクセスするときのパスワードを入力します。
「追加」をクリックして、最初のRACインスタンスの詳細を入力します。
一度に1つのデータソースを選択し、適切な詳細を追加することで、各マルチ・データソース・スキーマを更新します。
すべてのマルチ・データソース・スキーマ（SOAインフラストラクチャ、ユーザー・メッセージング・サービス、OWSM MDSスキーマおよびSOA MDSスキーマ）について、必ず情報を入力してください。
「次へ」をクリックします。
「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が正常だったことを確認します。正常でない接続があった場合には、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続が正常になったら「次へ」をクリックします。
「オプションの構成を選択」画面で、次を選択します。
管理サーバー
管理対象サーバー、クラスタ、およびマシン
「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: VIP0仮想IPのホスト名を入力します。
リスニング・ポート: 7001
SSLリスニング・ポート: N/A
SSL有効: 選択を解除
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。
表5-5 管理対象サーバーの構成
| 名前 | リスニング・アドレス | リスニング・ポート | SSLリスニング・ポート | SSL有効 |
|---|---|---|---|---|
|
WLS_SOA1 |
VIP1 |
8001 |
n/a |
いいえ |
|
WLS_SOA2 |
VIP2 |
8001 |
n/a |
いいえ |
|
注意: WLS_SOA1とWLS_SOA2はサーバー移行を使用するため、IPをホスト名でなくリスニング・アドレスとして使用する必要があります。 |
表示されるどのサーバーも削除しないでください。サーバーは変更できます。サーバーを削除して新しいサーバーを追加すると、ターゲット指定が失敗します。
|
注意: 標準の推奨事項は、個々のWebLogic管理対象サーバー内でカスタム・アプリケーションおよび他のシステムを実行するためのものです。図5-28で説明しているカスタムWLS管理対象サーバーの作成については、ここでは取り上げません。 |
「次へ」をクリックします。
「クラスタの構成」画面で、次のクラスタを追加します。
名前: SOA_Cluster
クラスタ・メッセージング・モード: unicast
マルチキャスト・アドレス: N/A
マルチキャスト・ポート: N/A
クラスタ・アドレス: 空白のまま
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、SOA_Clusterに次のサーバーを割り当てます。
WLS_SOA1
WLS_SOA2
「次へ」をクリックします。
「マシンの構成」画面で、次の操作を行います。
デフォルトとして表示される「LocalMachine」を削除します。
「UNIXマシン」タブをクリックし、次のマシンを追加します。
その他すべてのフィールドをデフォルト値のままにして、「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。
APPHOST1: AdminServer、WLS_SOA1
APPHOST2: WLS_SOA2
「次へ」をクリックします。
「WebLogicドメインの確認」画面で、「次へ」をクリックします。
「構成のサマリ」画面で「作成」をクリックします。
「ドメインの作成中」画面で「完了」をクリックします。
|
注意: マルチキャスト・アドレスとユニキャスト・アドレスは、WebLogic Serverクラスタでクラスタ通信に使用されるものとは異なります。SOAでは、2つのエンティティ（WebLogic Serverクラスタと、コンポジットがデプロイされるグループ）の通信プロトコルが異なっていても、コンポジットが単一のWebLogic Serverクラスタのメンバーにデプロイされることが保証されています。 |
この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。
管理サーバーに対しては、次の手順を実行します。
次のディレクトリを作成します。
APPHOST1> mkdir ORACLE_BASE/product/fmw/user_ projects/domains/soadomain/servers/ APPHOST1> mkdir ORACLE_BASE/product/fmw/user_ projects/domains/soadomain/servers/AdminServer/ APPHOST1> mkdir ORACLE_BASE/product/fmw/user _projects/domains/soadomain/servers/AdminServer/security
テキスト・エディタを使用して、前の手順で作成したセキュリティ・ディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。
username=adminuser password=password
|
注意: 管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。 |
この項では、APPHOST1でシステムを起動する手順について説明します。
APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。
APPHOST1> cd ORACLE_BASE/product/fmw/user_projects/domains/soadomain/bin APPHOST1> ./startWebLogic.sh
管理サーバーが適切に構成されていることを確認する手順は次のとおりです。
ブラウザでhttp://vip0:7001/consoleにアクセスします。
管理者としてログインします。
管理対象サーバーとしてWLS_SOA1およびWLS_SOA2が表示されていることを確認します。
SOA_Clusterクラスタが表示されていることを確認します。
Enterprise Manager（http://vip0:7001/em）にアクセスできることを確認します。
この手順が必要になるのは、管理サーバーとノード・マネージャの間にホスト名を検証するための適切な証明書を設定していない場合です。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。
ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定すると、再度有効化できます。
ホスト名の検証を無効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールで、「管理サーバー」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
Oracle WebLogic Server管理コンソールで、「WLS_SOA1」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
変更を保存およびアクティブ化します。
サーバーを再起動します。
APPHOST1でノード・マネージャを起動するには、次の手順を実行します。
ノード・マネージャを起動する前に、ORACLE_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。
SOAHOST1> cd ORACLE_HOME/common/bin SOAHOST1> ./setNMProps.sh
|
注意: クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。 |
ノード・マネージャを起動します。
ORACLE_BASE/product/fmw/wlserver_10.3/server/bin
APPHOST1> ./startNodeManager.sh
APPHOST1で管理対象サーバーWLS_SOA1を起動するためには、soa-createUDD.pyスクリプトを実行する必要があります。このスクリプトは、標準のJMS宛先を、高可用性のロード・バランシングされた共通分散宛先に変換して、システムのスケーラビリティと堅牢さを強化します。
次のように、WLSTをオフラインで使用して、スクリプトを実行します。
環境を設定します。
APPHOST1>. ORACLE_BASE/product/fmw/
user_projects/domains/soadomain/bin/setDomainEnv.sh
soa-createUDD.pyスクリプトを実行します。このスクリプトは、ORACLE_HOME/bin/ soa-createUDD.pyにあります。
APPHOST1> WL_HOME/jrockit_160_05_R27.6.2-20/bin/java weblogic.WLST ORACLE_HOME/bin/soa-createUDD.py --domain_home ORACLE_BASE/product/fmw/user_projects/domains/soadomain/ --soacluster SOA_Cluster
管理サーバーを再起動します。
Oracle WebLogic Server管理コンソールで、次のモジュールが表示されていることを確認します。
SOAJMSModuleUDD
Oracle WebLogic Server管理コンソールで、最初に「ドメイン構造」ウィンドウの「サービス」ノードを開いてから、「メッセージング」ノードを開いて、このモジュールについて確認します。「JMSモジュール」を選択します。表の「名前」列で「SOAJMSMOduleUDDS」（ハイパーリンクとして表示）を選択します。「サブデプロイメント」タブをクリックします。「SOAJMSSubDM」をクリックしてから、「ターゲット」を選択します。
モジュールがSOAJMSServer_auto_1とSOAJMSServer_auto_2にターゲット指定されていることを確認します。
UMSJMSSystemResource
Oracle WebLogic Server管理コンソールで、最初に「ドメイン構造」ウィンドウの「サービス」ノードを開いてから、「メッセージング」ノードを開いて、このモジュールについて確認します。「JMSモジュール」を選択します。表の「名前」列で「UMSJMSSystemResource」（ハイパーリンクとして表示）を選択します。「サブデプロイメント」タブをクリックします。「SOAJMSSubDM」をクリックしてから、「ターゲット」を選択します。
モジュールがUMSJMSServer_auto_1とUMSJMSServer_auto_2にターゲット指定されていることを確認します。
|
注意: ドメインを拡張してOracle BAMを含めるなど、ドメインの拡張後にスクリプトを実行するときは、必ず--extend trueオプションを使用します。
次に例を示します。 MW_HOME/jrockit_160_05__R27.6.2-20/bin/java weblogic.WLST MW_HOME/soa/bin/soa-createUDD.py --domain_home MW_HOME/ user_projects/domains/soadomain --bamcluster BAM_Cluster --extend true |
管理対象サーバーWLS_SOA1を起動して、正しく構成されていることをチェックする手順は、次のとおりです。
Oracle WebLogic Server管理コンソールを使用して、管理対象サーバーWLS_SOA1を起動します。
WLS_SOA1が起動すると、次のURLが使用できるようになります。
http://APPHOST1VHN1:8001/b2b
B2Bコンソールへのログインを確認します。
http://APPHOST1VHN1:8001/integration/worklistapp
ワークリスト・コンソールへのログインを確認します。
http://APPHOST1VHN1:8001/wsm-pm
ポリシー・バリデータ・リンクを確認します。
APPHOST2に対して、WebLogic ServerとOracle SOAのインストール手順を繰り返します。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。これらのパスとドメインが最初のノードに使用したものと同一でない場合には、フェイルオーバーは行なわれません。
次の手順に従い、pack/unpackユーティリティを使用してドメイン構成をAPPHOST2に伝播します。
次のpackコマンドをAPPHOST1で実行し、テンプレート・パックを作成します。
APPHOST1> cd ORACLE_HOME/common/bin APPHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/ -template=soadomaintemplate.jar -template_name=soa_domain_template
次のコマンドをAPPHOST1で実行し、前の手順で作成したテンプレート・ファイルをAPPHOST2にコピーします
APPHOST1> scp soadomaintemplate.jar
oracle@node2:ORACLE_HOME/common/bin
unpackコマンドをAPPHOST2で実行し、伝播されたテンプレートを解凍します。
APPHOST2> cd ORACLE_HOME/common/bin APPHOST2> ./unpack.sh -domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/ -template=soadomaintemplate.jar
|
注意: pack/unpackプロシージャを実行した後でFusion Middleware構成ウィザードを実行するときには、元のドメインにすでに存在し、「拡張ソースの選択」画面に表示される製品は、選択されていず、グレー表示されています。packコマンドで作成されたテンプレートは、ユーザー作成テンプレートと見なされます。このようなテンプレートは、デフォルト・テンプレートとは別のものとして扱われます。ユーザー作成テンプレートは自己完結型で、元のドメインの作成に関連する情報は一切含んでいません。 |
B2BのXEngineを第2ノードで有効にするには、次のようにZEngine tarのコンテンツを手動で抽出する必要があります。
SOAHOST2>cd ORACLE_HOME/soa/thirdparty/edifecs
SOAHOST2>tar xzvf XEngine.tar.gz
この項では、APPHOST2でシステムを起動する手順について説明します。
管理対象サーバーWLS_SOA2を起動し、検証するには、ホスト名の検証を無効化しておく必要があります。ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定すると、再度有効化できます。
ホスト名の検証を無効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールで、「WLS_SOA2」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
APPHOST2でノード・マネージャを起動するには、第5.11.6.4項「APPHOST1でのノード・マネージャの起動」の手順をAPPHOST2で繰り返します。
管理対象サーバーWLS_SOA2を起動して、正しく構成されていることをチェックする手順は、次のとおりです。
Oracle WebLogic Server管理コンソールを使用して、管理対象サーバーWLS_SOA2を起動します。
WLS_SOA2が起動すると、次のURLが使用できるようになります。
http://VIP2:8001/b2b
B2Bコンソールへのログインを確認します。
http://VIP2:8001/integration/worklistapp
ワークリスト・コンソールへのログインを確認します。
http:/VIP2:8001/wsm-pm
ポリシー・バリデータ・リンクを確認します。
管理対象サーバーWLS_SOAnを含む管理サーバーへのOracle HTTP Serverのルーティングを有効にするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定します。
OHS_HOME/instances/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.confファイルに次の行を追加します。
# SOA soa-infra app
<Location /soa-infra>
SetHandler weblogic-handler
WebLogicCluster apphost1vhn1:8001,apphost2vhn1:8001
WLLogFile /tmp/web_log.log
</Location>
# Worklist
<Location /integration/>
SetHandler weblogic-handler
WebLogicCluster apphost1vhn1:8001,apphost2vhn1:8001
WLLogFile /tmp/web_log.log
</Location>
<Location /DefaultToDoTaskFlow/>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8001,SOAHOST2VHN1:8001
</Location>
# B2B
<Location /b2b>
SetHandler weblogic-handler
WebLogicCluster apphost1vhn1:8001,apphost2vhn1:8001
WLLogFile /tmp/web_log.log
</Location>
# UMS prefs
<Location /sdpmessaging/userprefs-ui >
SetHandler weblogic-handler
WebLogicCluster apphost1vhn1:8001,apphost2vhn1:8001
WLLogFile /tmp/web_log.log
</Location>
WEBHOST1上のOracle HTTP Serverを再起動します。
WEBHOST1> OHS_HOME/instances/ohs_instance1/bin/opmnctl restartproc ias-component=ohs1
次のURLを検証し、HTTP ServerからSOA_Clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。
WLS_SOA2の実行中に、Oracle WebLogic Server管理コンソールからWLS_SOA1を停止します。
次のURLにアクセスして、適切な機能を検証します。
WebHost1:7777/soa-infra
WebHost1:7777/b2b
WebHost1:7777/integration/worklistapp
WebHost1:7777/sdpmessaging/userprefs-ui
WebHost1:7777/wsm-pm
Oracle WebLogic Server管理コンソールからWLS_SOA1を起動します。
WLS_SOA2を停止します。
次のURLにアクセスして、適切な機能を検証します。
WebHost1:7777/soa-infra
WebHost1:7777/b2b
WebHost1:7777/integration/worklistapp
WebHost1:7777/sdpmessaging/userprefs-ui
2つのノードから参照できるディレクトリに、すべての永続ストアの場所を構成します。そして、この共有のベース・ディレクトリを使用するように、すべての永続ストアを変更します。
Fusion Middleware管理コンソールで、「サービス」、「永続ストア」、「Persistence_Store_Name」、「ディレクトリ」の順に選択します。
保留されているJMSメッセージを再開できるようにするには、クラスタ内の他のサーバーで使用可能な永続記憶域ソリューション（NAS、SAN）上の場所を指定する必要があります。したがって、入力するディレクトリは、WLS_SOA1とWLS_SOA2の両方にアクセスできる必要があります。このディレクトリは、サーバーが再起動する前に存在していなければなりません。
各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでトランザクション・ログを使用します。クラスタ内のサーバーに対してトランザクション回復サービスの移行機能を利用するためには、サーバーとそのバックアップ・サーバーで利用可能な場所、可能であればデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク（SAN）にトランザクション・ログを格納する必要があります。デフォルトの永続ストアを構成する手順は、次のとおりです。
「ドメイン構造」ツリーで、「環境」を開き、「サーバー」を選択します。
変更するサーバーを選択します。
「構成」、「サービス」タブの順に選択します。
「デフォルト・ストア」の「ディレクトリ」フィールドに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定する必要があります。したがって、入力するディレクトリは、WLS_SOA1とWLS_SOA2の両方にアクセスできる必要があります。このディレクトリは、サーバーが再起動する前に存在していなければなりません。
Oracle WebLogic Serverクラスタに対してフロントエンドHTTPのホストとポートを設定する必要があります。
WebLogic Server管理コンソールの「チェンジ・センター」セクションで、「ロックして編集」をクリックします。
左側のペインで、「環境」→「クラスタ」を選択します。
「WLS_SOA」クラスタを選択します。
「HTTP」を選択します。
次の値を設定します。
フロントエンド・ホスト: webhost1
フロントエンドHTTPポート: 7777
フロントエンドHTTPSポート<: 空白のまま
|
注意: このアドレスが正しく、使用可能であること（HTTPサーバーが起動している）を確認してください。アドレスのhttp://やホスト名の末尾/など、値が誤っていると、仮想IPを使用してもSOAシステムにアクセスできません。 |
「保存」をクリックします。
変更をアクティブにするには、管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。
すでにサーバーを起動している場合、この変更にはクラスタのメンバーの再起動が必要であることに注意してください。
|
注意: SOAシステムは、コールバック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.
コンポジットのデプロイではデフォルトでマルチキャスト通信を使用しますが、SOAの高可用性を実現するためにはユニキャスト通信を使用することをお薦めします。セキュリティ上の理由からマルチキャスト通信を無効化した場合には、ユニキャスト通信を使用します。
|
注意: デプロイメントに使用されるOracle Coherenceフレームワークの構成が不適切な場合、SOAシステムは起動できません。SOAシステムが実行されるネットワーク環境に応じてデプロイメント・フレームワークを適切にカスタマイズする必要があります。この項でこれらから説明する構成をお薦めします。 |
マルチキャスト通信を使用すると、Oracle Fusion Middleware SOAは、コンポジットを動的にデプロイする先のクラスタの全メンバーを検出できます。しかし、ユニキャスト通信では、ノードはこのように他のクラスタ・メンバーを検出することはできません。そのため、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加された新しいノードが既存ノードの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サーバーによって使用される仮想ホスト名である必要があります。このプロパティは、Oracle WebLogic Server管理コンソールの「サーバーの起動」タブ（図5-32）の「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加して設定します。
図5-32 Oracle WebLogic Server管理コンソールの「サーバーの起動」タブを使用したホスト名の設定
ホスト名の指定
Oracle Coherenceで使用するホスト名を追加する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーの概要」ページが表示されます。
表の「名前」列で、サーバーの名前（ハイパーリンクとして表示）をクリックします。選択したサーバーの設定ページが表示されます。
「サーバーの起動」タブをクリックします（図5-32を参照）。
「引数」フィールドで、WLS_SOA1とWLS_SOA2について次のように入力します。
WLS_SOA1について、次のように入力します。
-Dtangosol.coherence.wka1=apphost1vhn1 -Dtangosol.coherence.wka2=apphost2vhn1 -Dtangosol.coherence.localhost=apphost1vhn1
WLS_SOA2について、次のように入力します。
-Dtangosol.coherence.wka1=apphost1vhn1 -Dtangosol.coherence.wka2=apphost2vhn1 -Dtangosol.coherence.localhost=apphost2vhn1
「保存」をクリックして、変更をアクティブ化します。
この変更を適用するには、SOAサーバーを再起動する必要があります。
|
注意: マルチキャスト・アドレスとユニキャスト・アドレスは、WebLogic Serverクラスタでクラスタ通信に使用されるものとは異なります。SOAでは、2つのエンティティ（WebLogic Serverクラスタと、コンポジットがデプロイされるグループ）の通信プロトコルが異なっていても、コンポジットが単一のWebLogic Serverクラスタのメンバーにデプロイされることが保証されています。 |
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コンポジット・アプリケーションのアーカイブを指定します。アーカイブには、デプロイするコンポジットのプロジェクト・ファイルが格納されています（たとえば、単一アーカイブのHelloWorld_rev1.0.jar、または複数アーカイブのOrderBooking_rev1.0.zip）。
「構成プラン」セクションで、アーカイブに含める構成プランのオプションを指定します。構成プランには、異なる環境で使用するURLとプロパティ値を定義できます。構成プランは、プロセスのデプロイメント時に、プロジェクトを別のターゲット環境に適合させるために置換する必要のある値に関するSOAプロジェクトを検索する際に使用されます。
「次へ」をクリックします。
「ターゲットの選択」ページが表示されます。
SOAコンポジット・アプリケーション・アーカイブのデプロイ先WebLogic Serverまたはクラスタを選択します。アーカイブは、複数のサーバーおよびクラスタにデプロイできます。
「次へ」をクリックします。
「確認」ページが表示されます。
選択内容を確認します。
SOAコンポジット・アプリケーションをデフォルトのリビジョンとしてデプロイするかどうかを選択します。デフォルトのリビジョンは、新しいリクエストが着信したときにインスタンス化されます。
「デプロイ」をクリックします。
処理中であることを示すメッセージが表示されます。
デプロイメントが完了したら、「閉じる」をクリックします。
|
関連項目: Oracle JDeveloperでの構成プランの作成とアプリケーションのデプロイについては、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。 |
SOAシステムの高可用性アーキテクチャでは、一部のシングルトン・サービスを障害から保護するためにサーバー移行を利用します。サーバー全体の移行の詳細は、『Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server』を参照してください。
WLS_SOA1管理対象サーバーは、障害発生時にAPPHOST2で再起動するように構成され、WLS_SOA2管理対象サーバーは、障害発生時にAPPHOST1で再起動するように構成されます。このような構成では、WLS_SOA1サーバーおよびWLS_SOA2サーバーは、WLSサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。WLS_SOAn管理対象サーバーのサーバー移行を構成する手順は、次のとおりです。
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表を作成します。
ORACLE_BASE/product/fmw/wlserver_10.3/server/db/oracle/817ディレクトリまたはORACLE_BASE/product/fmw/wlserver_10.3/server/db/oracle/920ディレクトリにあるleasing.ddlファイルをデータベース・ノードにコピーします。
データベースにleasingユーザーとして接続します。
leasing.ddlをSQL*Plusで実行します。
SQL> @copy_location/leasing.ddl;
手順2は、Oracle WebLogic Server管理コンソールからleasing表のマルチ・データソースを作成するためのものです。
マルチ・データソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータソースを、これらのデータソースとグローバルleasingマルチ・データソースの両方について作成します。データソースを作成するときには、次の点に留意してください。
このデータソースが、XAデータソースではないことを確認してください。
マルチ・データソースの名前の形式は、<MultiDS>-rac0、<MultiDS>-rac1です。
「Oracleのドライバ（Thin）バージョン9.0.1、9.2.0、10、11」を使用します。
「グローバル・トランザクションのサポート」、「1フェーズ・コミット」を適用して、データベースのサービス名を指定します。
これらのデータソースをSOAクラスタにターゲット指定します。
マルチ・データソースを作成する手順は、次のとおりです。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノードを開いてから、「JDBC」ノードを開きます。
「マルチ・データ・ソース」をクリックします。「JDBCマルチ・データ・ソースの概要」ページが表示されます。
「新規」をクリックします。「新しいJDBCマルチ・データ・ソースの作成」ページが表示されます。
「ロックして編集」をクリックします。
「新規」をクリックします。
「名前」として、leasingと入力します。
「JNDI名」として、jdbc/leasingと入力します。
「アルゴリズムとしてフェイルオーバー」（デフォルト）を選択します。
「次へ」をクリックします。
「非XAドライバ」（デフォルト）を選択します。
「次へ」をクリックします。
「新しいデータ・ソースの作成」をクリックします。
名前として、leasing-rac0と入力します。JNDI名として、jdbc/leasing-rac0と入力します。データベースのタイプとして、oracleと入力します。ドライバのタイプとして、Oracle Driver (Thin) for RAC server-Instance connection Version 10,11と入力します。
「次へ」をクリックします。
「グローバル・トランザクションのサポート」の選択を解除します。
「次へ」をクリックします。
leasingスキーマのサービス名、データベース名、ホスト・ポートおよびパスワードを入力します。
「次へ」をクリックします。
「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。
データソースをSOAクラスタにターゲット指定します。
データソースを選択して、右の画面に追加します。
「新しいデータ・ソースの作成」をクリックして、RACデータベースの2つ目のインスタンスについても同じ手順を繰り返します。
2つ目のデータソースをマルチ・データソースに追加します。
変更を保存およびアクティブ化します。
ノード・マネージャとサーバー全体の移行の詳細は、第3.9項「サーバー全体の移行」を参照してください。
nodemanager.propertiesファイルは、ORACLE_BASE/product/fmw/wlserver_10.3/common/nodemanagerディレクトリにあります。サーバー移行が正しく機能するために、この項で説明するプロパティを追加する必要があります。
Interface=eth0
このプロパティは、浮動IPのインタフェース名（たとえば、eth0）を指定します。
指定するインタフェースが、このノードに対するパブリック・インタフェースであることを確認してください。このインタフェースは、複数のホーム・ノード上で浮動IPを有効にできるものでなければなりません。
|
注意: Windowsの場合、Interfaceには、ネットワーク・インタフェース名を設定する必要があります。例:Interface="Local Area Connection" |
NetMask=255.255.255.0
このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。このネットマスク（255.255.255.0）は、一例にすぎません。実際の値は、ネットワークにより異なります。
UseMACBroadcast=true
このプロパティでは、ARPパケットの送信時にノードのMACアドレスを使用するかどうか、すなわち、arpingコマンドで-bフラグを使用するかどうかを指定します。
ノード・マネージャの起動後、これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力（ノード・マネージャが起動されているシェル）で確認します。ノード・マネージャの出力は、次のように表示されます。
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true
|
注意: この項で説明する手順は、サーバー・プロパティ（起動プロパティ）が適切に設定されていて、ノード・マネージャがリモートでサーバーを起動できる場合には不要です。 |
nodemanager.propertiesファイルで次のプロパティを設定します。
StartScriptEnabled
このプロパティをtrueに設定します。
ORACLE_BASE/product/fmw/wlserver_10.3/server/binディレクトリにあるstartNodeManager.shスクリプトを実行して、ノード1とノード2でノード・マネージャを起動します。
nodemanager.logファイルで、nodemanager.propertiesファイルへの変更を確認します。
WebLogicユーザー（oracle）に、パスワードなし制限でsudo権限を付与して、/sbin/ifconfig and /sbin/arpingバイナリの実行権限を付与します。
スクリプトがWebLogicユーザー（oracle）によって実行可能であることを確認してください。次の、/etc/sudoers内のエントリの例では、oracleのsudo実行権限を、ifconfigとarpingに対しても付与しています。
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
「クラスタの移行の構成」では、DataSourceForAutomaticMigrationプロパティがtrueに設定されます。クラスタ内の移行でクラスタ移行を構成するには、この項の手順を実行します。
Oracle WebLogic Server管理コンソールにログインします。
左側のペインで、「環境」を開き、「クラスタ」を選択します。
移行を構成するクラスタ（SOA_Cluster）を選択します。
「移行」をクリックします。
「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。この場合は、「APPHOST1」と「APPHOST2」を選択します。
自動移行に使用するデータソースを選択します。この場合は、leasingデータソースを選択します。
「保存」をクリックします。
サーバー移行の候補マシンを設定します。すべての管理対象サーバーに対して設定する必要があります。
そのためには、次の手順に従ってください。
Oracle WebLogic Server管理コンソールの左側のペインで、「環境」を開いて、「サーバー」を選択します。
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。WLS_SOA1には「APPHOST2」を選択します。WLS_SOA2には「APPHOST1」を選択します。
「サーバーの自動移行を有効化」のチェック・ボックスを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックして、変更をアクティブ化します。
サーバー移行が適切に機能していることを確認する手順は次のとおりです。
ノード1から:
WLS_SOA1管理対象サーバーを強制停止します。
そのためには、次の手順を実行します。
APPHOST1> kill -9 <pid>
pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。
APPHOST1> ps -ef | grep WLS_SOA1
|
注意: Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了できます。次に例を示します。
taskkill /f /pid <pid> <pid>は、管理対象サーバーのプロセスIDを表します。 管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_SOAのpidを確認します。 MW_HOME\jrockit_160_05_R27.6.2-20\bin\jps -l -v |
ノード・マネージャ・コンソールを確認します。WLS_SOA1の浮動IPが無効になっていることを示すメッセージが表示されています。
ノード・マネージャがWLS_SOA1の2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード･マネージャによってログに記録されるようになります。
ノード2から:
ローカルのノード・マネージャのコンソールを確認します。ノード1で最後にWLS_SOA1の再起動が試行されてから30秒経過した後、ノード2のノード・マネージャによって、WLS_SOA1の浮動IPが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。
同じIPのSOAサービス・インフラストラクチャ・コンソールにアクセスします。
Oracle WebLogic Server管理コンソールでも、次の手順を実行することで、移行について検証できます。
Oracle WebLogic Server管理コンソールにログインします。
左側のペインで、「ドメイン」をクリックします。
「監視」タブ、「移行」サブタブの順にクリックします。
「移行の状態」表に、移行の状態に関する情報が表示されます。
Oracle WebLogic Server管理コンソールの「移行の状態」画面
|
注意: Windowsでは、同一マシン上で複数のサーバーを同時に手動で停止し、その後で別のマシンで、停止したサーバーの1つを起動しようとしても、IPバインドは機能しません。これは、IPアドレスが削除されていることがnetshによってレポートされていても、元のマシンでそのIPアドレスに対する要求が引き続き保持されているために起こります。
これを解決するには、ipconfigユーティリティまたはWindowsネットワーク構成を使用して、ネットワーク構成をチェックする必要があります。どちらを使用した場合も、仮想IPアドレスまたは浮動IPアドレスのいずれかが、サーバーが停止後も引き続き構成されていることが示されます。その場合は、次の手順に従い、Windowsネットワーク構成を使用して、IPアドレスを削除できます。
|
エンタープライズ・トポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。
この場合は、SOAコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードには、既存の管理対象サーバーのMiddlewareホーム、Oracleホーム（SOA）およびドメイン・ディレクトリが含まれます。
新しいWLS_SOAサーバーを作成するには、既存のインストール（Middlewareホームとドメイン・ディレクトリ）を使用できます。SOAのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。
トポロジをスケール・アップするには、次の手順を実行します。
管理コンソールを使用し、WLS_SOA1のクローンを作成して新しい管理対象サーバーにします。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
管理対象サーバーのクローンを作成する手順は次のとおりです。
管理コンソールから「環境」→「サーバー」を選択します。
クローンを作成する管理対象サーバー（WLS_SOA1など）を選択します。
「クローンの作成」を選択します。
新しい管理対象サーバーにWLS_SOAnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。
この後の手順では、すでにWLS_SOA1を実行しているAPPHOST1に新しいサーバーを追加することを想定しています。
リスニング・アドレスに対して、この新しい管理対象サーバーに使用するホスト名またはホストIPを割り当てます。このサーバーに対して推奨されている、サーバー移行の使用を計画している場合は、VIP（浮動IPとも言う）を割り当てて他のノードに移動できるようにします。VIPは、すでに実行されている管理対象サーバーで使用されているものとは別のものである必要があります。
新しい管理対象サーバーにSOAとUMSのJMSサーバーを作成します。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_Nのような名前を付けます。そして、このストアのパスを指定します。このパスには、第5.11.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.11.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）にターゲット指定します。
新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModuleUDDs」をクリックします（表の「名前」列にハイパーリンクとして表示されています）。SOAJMSModuleUDDsの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。サブデプロイメントSOAJMSSubDMが表示されます。
|
注意: このサブデプロイメント・モジュールは、最初の2つのサーバー（WLS_SOA1およびWLS_SOA2）のJMS構成を、HAトポロジの初期設定に必要な共通分散宛先スクリプト（soa-createUDD.py）で更新することによって生成されます。 |
サブデプロイメント「SOAJMSSubDM」をクリックします。このサブデプロイメントに、SOAJMSServer_Nと呼ばれる、SOAの新しいJMSサーバーを追加します。「保存」をクリックします。
拡張操作の実行中にSOA_Clusterが変更された可能性があるため、UMSJMSSystemResourceをSOA_Clusterにターゲット指定します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックしてから、「ターゲット」タブをクリックします。SOA_Clusterのすべてのサーバーが選択されている（最近作成されたクローンのWLS_SOAnも含めて）ことを確認します。
新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」（表の「名前」列にハイパーリンクとして表示）をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。サブデプロイメントUMSJMSSubDMSOAが表示されます。
|
注意: このサブデプロイメント・モジュールは、最初の2つのサーバー（WLS_SOA1およびWLS_SOA2）のJMS構成を、HAトポロジの初期設定に必要な共通分散宛先スクリプト（soa-createUDD.py）で更新することによって生成されます。 |
サブデプロイメント「SOAJMSSubDM」をクリックします。このサブデプロイメントに、UMSJMSServer_Nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。
新しいサーバーに対してTX永続ストアを構成します。これは、EDGの共有記憶域についての推奨事項で示されているように、他のノードから参照できる場所に構成します。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーを停止します。
新たに作成した管理対象サーバーWLS_SOAnが起動していることを確認します。
新たに作成した管理対象サーバー上のアプリケーション（http://vip:port/soa-infra）にアクセスします。アプリケーションが機能している必要があります。
新しい管理対象サーバーに対してサーバー移行を構成します。
|
注意: これはスケール・アップ操作であるため、ノード・マネージャと、サーバー移行に対して構成された環境が、あらかじめノードに用意されている必要があります。新しいSOA管理対象サーバーの浮動IPも存在している必要があります。 |
次の手順を実行してサーバー移行を構成します。
管理コンソールにログインします。
左側のペインで、「環境」を開き、「サーバー」を選択します。
移行を構成する新しい管理対象サーバーの名前を選択します。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。ノードの既存のサーバーと同じ移行ターゲットを選択します。
たとえば、すでにWLS_SOA1が実行されているAPPHOST1上の新しい管理対象サーバーには、APPHOST2を選択します。すでにWLS_SOA2が実行されているAPPHOST2上の新しい管理対象サーバーには、APPHOST1を選択します。
移行時に管理対象サーバーを同時に実行できるように、適切なリソースが使用可能になっていることを確認してください。
「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
この新しいサーバーのサーバー移行をテストします。新しいサーバーを追加したノードで次の手順を実行します。
管理対象サーバーWLS_SOAnを停止します。
そのためには、管理対象サーバーのPIDに対してkill -9 <pid>を実行します。ノードのPIDは、ps -ef | grep WLS_SOAnを使用して確認できます。
ノード・マネージャ・コンソールを確認します。WLS_SOA1の浮動IPが無効になっていることを示すメッセージが表示されています。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード･マネージャによってログに記録されるようになります。
トポロジのスケール・アウトでは、SOAで構成された新しい管理対象サーバーを新しいノードに追加します。
この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。
SOAで構成された管理対象サーバーを実行しているノードがトポロジ内に存在していること。
新しいノードが、WebLogic ServerとSOAの既存のホーム・ディレクトリにアクセスできること（新しい管理対象サーバーWLS_SOAまたはWLS_WSMを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic ServerやSOAバイナリをインストールする必要はありませんが、packとunpackを実行して、新しいノードでドメイン構成をブートストラップする必要があります）。
|
注意: 共有記憶域にインストールが存在しない場合は、第5.11項「Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」の説明に従って、新しいノードにWebLogic Serverと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インベントリに追加するには、次のコマンドを実行します。
APPHOSTn>cd ORACLE_BASE/product/fmw/soa/ APPHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_05_R27.6.2-20
Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し（別のWebLogicインストールがノード内に存在する場合はそれを編集）、それにORACLE_BASE/product/fmwを追加します。
Oracle WebLogic Server管理コンソールにログインします。
新しいノードに使用する新しいマシンを作成し、このマシンをドメインに追加します。
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。
Oracle WebLogic Server管理コンソールを使用し、WLS_SOA1のクローンを作成して新しい管理対象サーバーにします。このサーバーにWLS_SOAnという名前を付けます。nは番号です。
|
注意: これらの手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加することを想定しています。 |
新しい管理対象サーバーでその管理対象サーバーのリスニング・アドレスに使用するホスト名またはIPを割り当てます。
このサーバーに対してサーバー移行の使用を計画している場合は（推奨）、このアドレスにサーバーのVIP（浮動IPとも言う）を割り当てる必要があります。このVIPは、既存の管理対象サーバーで使用されているものとは別のものである必要があります。
新しい管理対象サーバーにSOAとUMSのJMSサーバーを作成します。
|
注意: これらの手順は、管理対象サーバーWSM_PMのスケール・アウトには不要であり、管理対象サーバーWLS_SOAにのみ必要な手順です。BAM Webアプリケーション・システムのスケール・アップにも必要ありません。 |
SOAとUMSのJMSサーバーを作成する手順は次のとおりです。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し（この後の手順で作成します）、SOAJMSFileStore_Nのような名前を付けます。そして、ストアのパスを指定します。このパスには、第5.11.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定します。
|
注意: このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。 |
SOAの新しいJMSサーバーを作成します（たとえば、SOAJMSServer_N）。このJMSサーバーに対して、SOAJMSFileStore_Nを使用します。SOAJMSServer_Nサーバーを、新たに作成した管理対象サーバー（WLS_SOAn）にターゲット指定します。
新しいUMSJMSServerの新しい永続ストアを作成し、UMSJMSFileStore_Nのような名前を付けます。そして、このストアのパスを指定します。このパスには、第5.11.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）にターゲット指定します。
新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModuleUDDs」（表の「名前」列にハイパーリンクとして表示）をクリックします。SOAJMSModuleUDDsの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。サブデプロイメントSOAJMSSubDMが表示されます。
|
注意: このサブデプロイメント・モジュールは、最初の2つのサーバー（WLS_SOA1およびWLS_SOA2）のJMS構成を、高可用性トポロジの初期設定に必要な共通分散宛先スクリプト（soa-createUDD.py）で更新することによって生成されます。 |
サブデプロイメント「SOAJMSSubDM」をクリックします。このサブデプロイメントに、SOAJMSServer_Nと呼ばれる、SOAの新しいJMSサーバーを追加します。「保存」をクリックします。
拡張操作の実行中にSOA_Clusterが変更された可能性があるため、UMSJMSSystemResourceをSOA_Clusterにターゲット指定します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックしてから、「ターゲット」タブを開きます。SOA_Clusterのすべてのサーバーが選択されている（最近作成されたクローンのWLS_SOAnも含めて）ことを確認します。
新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」（表の「名前」列にハイパーリンクとして表示）をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。サブデプロイメントUMSJMSSubDMSOAが表示されます。
|
注意: このサブデプロイメント・モジュールは、最初の2つのサーバー（WLS_SOA1およびWLS_SOA2）のJMS構成を、HAトポロジの初期設定に必要な共通分散宛先スクリプト（soa-createUDD.py）で更新することによって生成されます。 |
サブデプロイメント「UMSJMSSubDMSOA」をクリックします。このサブデプロイメントに、UMSJMSServer_Nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。
次のようにpackコマンドをAPPHOST1で実行し、テンプレート・パックを作成します。
APPHOST1> cd ORACLE_BASE/product/fmw/soa/common/bin APPHOST1> ./pack.sh -managed=true -domain= ORACLE_BASE/product/fmw/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale
次のコマンドをAPPHOST1で実行し、作成したテンプレート・ファイルをAPPHOSTNにコピーします。
APPHOST1> scp soadomaintemplateScale.jar oracle@APPHOSTN:/ ORACLE_BASE/product/fmw/soa/common/bin
次のようにAPPHOSTNでunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。
APPHOSTN> cd ORACLE_BASE/product/fmw/soa/common/bin APPHOSTN> ./unpack.sh -domain= ORACLE_BASE/product/fmw/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar
新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。
APPHOSTN> ORACLE_BASE/product/fmw/wlserver_10.3/server/bin/startNodeManager <new_node_ip>
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_SOAN管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとAPPHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。
ホスト名の検証を無効化する手順は次のとおりです。
Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーの概要」ページが表示されます。
表の「名前」列で「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
Oracle WebLogic Server管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーをすべて停止します。
新たに作成した管理対象サーバーWLS_SOAnが実行されていることを確認します。
新たに作成した管理対象サーバー上のアプリケーション（http://vip:port/soa-infra）にアクセスします。アプリケーションが機能している必要があります。
第5.11項「Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」の説明に従って、サーバーの起動パラメータとして、適切なコヒーレンスの「既知のアドレス・リスト」を構成します。
新しい管理対象サーバーに対してサーバー移行を構成します。
|
注意: この新しいノードでは既存の共有記憶域インストールを使用しているため、ノードではすでに、ノード・マネージャと、ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限などの、サーバー移行用に構成された環境が使用されています。新しいノードには、すでに新しいSOA管理対象サーバーの浮動IPが存在します。 |
管理コンソールにログインしてサーバー移行を構成する手順は次のとおりです。
左側のペインで、「環境」を開き、「サーバー」を選択します。
移行を構成するサーバー（ハイパーリンクで表示）を、表の「名前」列から選択します。このサーバーの「設定」ページが表示されます。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
|
注意: 新しいサーバーの移行ターゲットには、負荷が最小のマシンを指定します。このノードのリソースが追加の管理対象サーバーの持続に十分対応できるように、必須の容量計画を立てる必要があります。 |
「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
この項では、BAMに2ノードの高可用性構成を設定する方法を説明します。BAM ServerアプリケーションとBAM Webアプリケーションについても触れます。構成手順では次のアーキテクチャを対象とします。
|
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
図5-34 は、この項の構成手順で作成するアーキテクチャの例を表しています。
図5-34は、Oracle BAM Webアプリケーションを実行する2ノードのクラスタを表しています。一方のノードでは、Oracle BAM Serverも実行されています。WebLogic Serverは、BAM Webアプリケーションへの受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。メタデータとBAMスキーマの格納にはOracle RACデータベースが使用されます。
次の各項では、Oracle BAMを使用してOracle SOAサービス・インフラストラクチャの高可用性構成を設定する前に必要となる手順について説明します。
Oracle SOAサービス・インフラストラクチャでサポートしているデータベースのバージョンは次のとおりです。
Oracle Database 10gリリース2（10.2.x）
Oracle Database 11gリリース1（11.1.x）
データベースのバージョンを調べるには、次の問合せを実行します。
SQL>select version from sys.product_component_version where product like 'Oracle%';
アーキテクチャの図で示すような、2つの異なる仮想IPをリスニングするAPPHOST1上の管理サーバーとBAM Serverを、表5-7のように構成します。そのためには、ボックス内の対応するVIPのプロビジョニングと、ネットワーク上のDNSシステムで関連付けられているホスト名が必要です。各VIPが使用可能かつアクセス可能であることを、インストールの実行前に確認してください。
表5-7 仮想ホスト
| 仮想IP | VIPのマップ先 | 説明 |
|---|---|---|
|
VIP0 |
APPHOST1VHN0 |
APPHOST1VHN0は、管理サーバーのリスニング・アドレスであり、管理サーバーの手動フェイルオーバーによりフェイルオーバーする、仮想ホストの名前です。管理サーバー・プロセスが実行されているノード（デフォルトはAPPHOST1）で有効化されます。 |
|
VIP1 |
APPHOST1VHN1 |
APPHOST1VHN1は、WLS_BAM1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_BAM1プロセスが実行されているノード（デフォルトはAPPHOST1）で有効化されます。 |
次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。
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のインストレーション・ガイドを参照してください。
データベースの初期化パラメータ
次の初期化パラメータが、必要な値に設定されていることを確認します。この値は、リポジトリ作成アシスタントによってチェックされます。
SQL*Plusを使用して初期化パラメータの値をチェックするには、SHOW PARAMETERコマンドを次のように使用します。
SYSユーザーとして、SHOW PARAMETERコマンドを次のように発行します。
SQL> SHOW PARAMETER processes
次のコマンドを使用して初期化パラメータを設定します。
SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE
データベースを再起動します。
|
注意: パラメータの値を変更する方法は、パラメータが静的か動的かによって異なり、データベースがパラメータ・ファイルとサーバー・パラメータ・ファイルのどちらを使用しているかによっても異なります。パラメータ・ファイルとサーバー・パラメータ・ファイルの詳細、およびパラメータ値の変更方法は、『Oracle Database管理者ガイド』を参照してください。 |
Oracle Fusion Middleware SOAのコンポーネントをインストールする前に、11g（11.1.1）Oracle Fusion Middlewareのメタデータ・ストアとSOAスキーマをReal Application Clusterデータベースにインストールします。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ（RCU）が用意されています。RCUのインストールの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
RCUを実行して、Oracle Fusion Middleware 11gに必要なメタデータをインストールします。
次のコマンドを使用してRCUを起動します。
RCU_HOME/bin/rcu &
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードし、「次へ」をクリックします。
「データベース接続の詳細」画面で、データベースの接続情報を入力します。
データベース・タイプ: Oracle Databaseを選択します。
ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合は、VIP名を指定するか、またはノード名のいずれかをホスト名として指定します: SOADBHOST1VIRTUAL
ポート: データベースのポート番号: 1521
サービス名: データベースのサービス名を入力します: soaha.mycompany.com
ユーザー名: SYS
パスワード: SYSユーザーのパスワードを入力します。
ロール: SYSDBA
「次へ」をクリックします。
次のような警告メッセージを受信する場合があります。
接続先のデータベースには非UTF8 charsetが含まれています。このデータベースを使用して複数言語のサポートを求める場合、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。
その場合は、「無視」または「停止」をクリックします。
「コンポーネントの選択」画面で「接頭辞の新規作成」を選択し、SOAHAのように、データベース・スキーマに使用する接頭辞を入力します。
後の手順で利用できるように、このスキーマ名を書き留めておきます。
次のスキーマを選択します。
AS共通スキーマ:
Metadata Services
SOAインフラストラクチャ:
Business Activity Monitoring
User Messaging
「次へ」をクリックします。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加（補助）のスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。
「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。
RCUの使用方法の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
WEBHOST1にOracle HTTP Serverをインストールする手順は次のとおりです。
サーバーが次の要件を満たしていることを確認します。
システム、パッチ、カーネルなどの要件が、『Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド』で指定されている要件を満たしている。
ポート7777が、ノード上のどのサービスによっても使用されていない。このことを確認するには、次のコマンドを実行します。
UNIX:
netstat -an | grep 7777
Windows:
netstat -an | 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ドメインの関連付け」は選択しないでください。
「次へ」をクリックします。
「コンポーネント詳細の指定」画面で、次の値を入力します。
インスタンス・ホームの場所: 修正後の値。バグ8199458を参照してください。
インスタンス・ホームの場所: /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スクリプトを実行するように求められます。コマンド・ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成」画面で、いくつかの構成アシスタントが連続して開始されます。構成アシスタントが終了すると、「構成が完了しました」画面が表示されます。
「構成が完了しました」画面で、「終了」をクリックして終了します。
この項では、Oracle WebLogic ServerとOracle Fusion Middleware SOA Suiteを実行するアプリケーション層のすべてのノードにOracle Fusion Middlewareをインストールする方法について説明します。
Oracle Fusion Middlewareの、次のコンポーネントをインストールします。
Oracle WebLogic Server（第5.12.3.1項「Oracle WebLogic Serverのインストール」を参照）
Oracle Fusion Middleware SOA Suite（第5.12.3.2項「Oracle SOAのOracle Fusion Middlewareのインストール」を参照)
アプリケーション層にあるすべてのノードにOracle WebLogic Serverをインストールする手順は次のとおりです。
UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。
Oracle WebLogic Serverインストーラを起動します。
UNIXの場合（次の例はLinuxの場合）:
APPHOST1> server103_linux32.bin
Windowsの場合:
APPHOST1> server103_win32.exe
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。
「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、ORACLE_BASE/product/fmwと入力します。
「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。
「製品とコンポーネントの選択」画面で、「次へ」をクリックします。
「JDKの選択」画面で、「jrockit_160_05_R27.6.2-20」のみを選択して「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。
ORACLE_BASE/product/fmw/wlserver_10.3
「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」の選択を解除して「完了」をクリックします。
アプリケーション層にあるすべてのノードにOracle SOA用Oracle Fusion Middlewareをインストールする手順は次のとおりです。
Oracle Fusion Middleware 11g Oracle SOA Suiteのインストーラを起動します。
UNIXの場合:
APPHOST1> runInstaller
Windowsの場合:
APPHOST1> setup.exe
Oracle Fusion Middleware 11g Oracle SOA Suiteのインストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_05のように入力します。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、次の操作を行います。
「ミドルウェア・ホーム」には、ORACLE_BASE/product/fmwと入力します。
「Oracleホーム・ディレクトリ」には、soaと入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
「インストール 完了」画面で「終了」をクリックします。
管理サーバーの仮想IPの構成および高可用性のための管理サーバーの構成の詳細は、第10.2.2.3項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。
SOAホーム・ディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーとOracle SOAコンポーネントが格納されるドメインを作成します。リポジトリをインストールしたデータベースが稼働していることを確認します。RACデータベースの場合は、すべてのインスタンスが実行されている必要があります。
SOAホーム・ディレクトリにある、Oracle WebLogic Serverの構成ウィザードの場所に、ディレクトリを変更します。
APPHOST1> cd ORACLE_HOME/common/bin
Oracle WebLogic Serverの構成ウィザードを起動します。
UNIXの場合:
APPHOST1> ./config.sh
Windowsの場合:
APPHOST1> config.cmd
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択し、次の製品を選択します。
Oracle Business Activity Monitoring
Oracle WSM-PM（デフォルトで選択）
Enterprise Manager
JRF（デフォルトで選択）
「次へ」をクリックします。
「ドメイン名と場所の指定」画面で、次のエントリを作成します。
ドメイン名: bamdomain
ドメインの場所: デフォルトを受け入れます。
アプリケーションの場所: デフォルトを受け入れます。
「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
WebLogicドメインの起動モード: 「本番モード」を選択
JDKの選択: 「Oracle SDK1.6.0_05」を選択
「次へ」をクリックします。
「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。
画面に次のデータソースが表示されていることを確認します。表5-9に示されているユーザー名は、RCUからのスキーマ作成で接頭辞にsoahaが使用されていることを想定しています。
「次のパネルで選択したコンポーネント・スキーマをRACマルチ・データ・ソース・スキーマとして構成します。」を選択します。
「次へ」をクリックします。
「RACマルチ・データ・ソースの構成」画面で、次のように入力します。
すべてのスキーマを選択した状態で、次のフィールドに値を入力して、RCUからシードされたOracle RACデータベースの接続情報を指定します。
ドライバ: RACサービス・インスタンス接続用Oracleのドライバ（Thin）、バージョン:10、11
サービス名: データベースのサービス名を入力します（例: soaha.mycompany.com）。
ユーザー名: スキーマの完全ユーザー名（接頭辞を含む）を入力します。
パスワード: スキーマにアクセスするときに使用するパスワードを入力します。
ホスト名、インスタンス名およびポートを入力します。
「追加」をクリックします。
Oracle RACインスタンスごとに同じ手順を繰り返します。
「BAMスキーマのみ」を選択し、ユーザー名とパスワード（soaha_orabam/passwd）を入力します。
「User Messaging Serviceスキーマのみ」を選択し、ユーザー名とパスワード（soaha_orasdpm/passwd）を入力します。
「OWSM MDS Schemaスキーマのみ」を選択し、ユーザー名とパスワード（soaha_mds/passwd）を入力します。
「次へ」をクリックします。
「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が正常だったことを確認します。正常でない接続があった場合には、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続が正常になったら「次へ」をクリックします。
「オプションの構成を選択」画面で、「管理サーバー」→「管理対象サーバー」→「クラスタとマシン」→「デプロイメントとサービス」を選択して、「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: VIP0
リスニング・ポート: 7001
SSLリスニング・ポート: N/A
SSL有効: 選択を解除
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。
表5-10 管理対象サーバーの構成
| 名前 | リスニング・アドレス | リスニング・ポート | SSLリスニング・ポート | SSL有効 |
|---|---|---|---|---|
|
WLS_BAM1 |
VIP1（サーバー移行によって移行された仮想IP） |
8001 |
n/a |
いいえ |
|
WLS_BAM2 |
APPHOST2（BAM Server WLS_BAM2はサーバー移行を使用しません） |
8001 |
n/a |
いいえ |
|
注意: 標準の推奨事項は、個々のWebLogic管理対象サーバー内でカスタム・アプリケーションおよび他のシステムを実行するためのものです。図5-34で説明しているカスタムWLS管理対象サーバーの作成については、ここでは取り上げません。 |
「次へ」をクリックします。
「クラスタの構成」画面で、次のクラスタを追加します。
名前: BAM_Cluster
クラスタ・メッセージング・モード: unicast
マルチキャスト・アドレス: N/A
マルチキャスト・ポート: N/A
クラスタ・アドレス: 空白のまま
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、BAM_Clusterに次のサーバーを割り当てます。
WLS_BAM1
WLS_BAM2
「次へ」をクリックします。
「マシンの構成」画面で、次の操作を行います。
デフォルトとして表示される「LocalMachine」を削除します。
「UNIXマシン」タブをクリックし、次のマシンを追加します。
その他すべてのフィールドをデフォルト値のままにして、「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。
APPHOST1: AdminServer、WLS_BAM1
APPHOST2:: WLS_BAM2
「次へ」をクリックします。
「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。
ユーザー・メッセージングのデプロイメントがBAM_Clusterにのみターゲット指定されていること（usermessaging-xmpp、usermessaging-smpp、usermessaging-voicexmlの各アプリケーションはオプション）。
wsm-pmがBAM_Clusterにのみターゲット指定されていること。
DMSアプリケーションがBAM_ClusterとAdminServerにターゲット指定されていること。
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の両方にターゲット指定されていること。
「構成のサマリ」画面で「作成」をクリックします。
「ドメインの作成中」画面で「完了」をクリックします。
BAMのJDBCデータソースに対しては、文キャッシュ・サイズ・パラメータを0に設定する必要があります。これは、構成ウィザードがデータベースの単一インスタンスに対して実行されているときにはデフォルト設定ですが、構成ウィザードがRACデータベースに対して実行されているときには、BAMのJDBCデータソースに対して文キャッシュ・サイズが設定されていません。この場合は、Oracle WebLogic Server管理コンソールを使用して文キャッシュ・サイズを構成する必要があります。
|
注意: Oracle WebLogic Server管理コンソールでBAMデータソースを使用できるようにするには、管理サーバーを再起動し、構成ウィザードを使用して変更をコミットする必要があります。 |
文キャッシュ・サイズを構成する手順は次のとおりです。
「ドメイン構造」ウィンドウで、「サービス」ノードを開きます。
「JDBC」ノードを開き、「データ・ソース」を選択します。「JDBCデータ・ソースの概要」ページが表示されます。
表の「名前」列で「BAMDataSource-rac0」をクリックします。「設定」ページが表示されます。
「接続プール」タブをクリックします。
「文キャッシュ・サイズ」フィールドに0と入力します。
「保存」をクリックします。
同じ手順をBAMDataSource-rac1に対して実行します。
変更を保存およびアクティブ化します。
この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。
管理サーバーに対しては、次の手順を実行します。
次のディレクトリを作成します。
mkdir ORACLE_BASE/product/fmw/user_projects/domains/bamdomain/servers/ mkdir ORACLE_BASE/product/fmw/user_projects/domains/bamdomain/servers/AdminServer mkdir ORACLE_BASE/product/fmw/user_projects/domains/bamdomain/servers/AdminServer/security
テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。
username=adminuser password=password
|
注意: 管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。 |
APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。
Linuxの場合:
APPHOST1> cd ORACLE_BASE/product/fmw/user_projects/domains/bamdomain/bin APPHOST1> ./startWebLogic.sh
Windowsの場合:
startWebLogic.cmd
管理サーバーが適切に構成されていることを確認する手順は次のとおりです。
ブラウザでhttp://VIP0:7001/consoleにアクセスします。
管理者としてログインします。
管理対象サーバーとしてWLS_BAM1およびWLS_BAM2が表示されていることを確認します。
BAM_Clusterクラスタが表示されていることを確認します。
Enterprise Manager（http://VIP0:7001/em）にアクセスできることを確認します。
この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成が完了した後で再度有効化します。
ホスト名の検証を無効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールで、「管理サーバー」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
Oracle WebLogic Server管理コンソールで、「WLS_BAM1」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
Oracle WebLogic Server管理コンソールで、「WLS_BAM2」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
管理サーバーを再起動して、変更を有効にします。
変更を保存およびアクティブ化します。
BAMのJDBCデータソースに対しては、文キャッシュ・サイズ・パラメータを0に設定する必要があります。これは、構成ウィザードがデータベースの単一インスタンスに対して実行されているときにはデフォルト設定ですが、構成ウィザードがRACデータベースに対して実行されているときには、BAMのJDBCデータソースに対して文キャッシュ・サイズが設定されていません。この場合は、Oracle WebLogic Server管理コンソールを使用して文キャッシュ・サイズを構成する必要があります。
|
注意: Oracle WebLogic Server管理コンソールでOracle BAMデータソースを使用できるようにするには、管理サーバーを再起動し、構成ウィザードを使用して変更をコミットする必要があります。 |
文キャッシュ・サイズを構成する手順は次のとおりです。
「ドメイン構造」ウィンドウで、「サービス」ノードを開きます。
「JDBC」ノードを開き、「データ・ソース」を選択します。
「JDBCデータ・ソースの概要」ページが表示されます。
表の「名前」列で「BAMDataSource-rac0」を選択します。
「設定」ページが表示されます。
「接続プール」タブをクリックします。
「文キャッシュ・サイズ」フィールドに0と入力します。
変更を保存およびアクティブ化します。
同じ手順をBAMDataSource-rac1に対して実行します。
APPHOST1とAPPHOST2の両方から参照できるディレクトリに、すべての永続ストアの場所を構成します。これは、サーバーが別のノードに移行されたときにトランザクションを再開できるようにするために必要です。両方のノードで永続ストアの共有場所を使用することで、フェイルオーバーが発生してもメッセージが失われないことが保証されます。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。
「永続ストアの概要」ページが表示されます。
表の「名前」列から永続ストア（ハイパーリンクとして表示）を選択します。
その永続ストアの「設定」ページが表示されます。
「構成」タブで、クラス内の他のサーバーで使用可能な永続記憶域ソリューション（NASやSANなど）の場所を、「ディレクトリ」フィールドに入力します。この場所を指定することで、保留中のJMSメッセージを送信できます。
「保存」をクリックします。
同じ手順をすべての永続ストアに対して実行します。
変更を保存およびアクティブ化します。
各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。
|
注意: 可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク（SAN）を使用します。 |
デフォルトの永続ストアの場所を設定する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーの概要」ページが表示されます。
表の「名前」列で、サーバーの名前（ハイパーリンクとして表示）を選択します。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。
「サービス」タブをクリックします。
ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
変更を保存およびアクティブ化します。
|
注意: トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。このディレクトリは、サーバーを再起動する前にも存在している必要があります。 |
BAM内のBAM Serverコンポーネントはシングルトンであるため、サーバー移行に対して構成する前に、WLS_BAMサーバーのいずれかから、そのコンポーネントのターゲット指定を解除する必要があります。解除しないと、2つのアクティブなBAM Serverが使用されることになり、データが異なるための不整合の原因となります。このように、BAM WebアプリケーションはAPPHOST1とAPPHOST2の両方で実行されますが、BAM Serverは、最初はAPPHOST1でのみアクティブになります。
次の手順では、WLS_BAM2からBAM Serverランタイムを削除します。WLS_BAM2からBAM Serverアーティファクトのターゲット指定を解除する手順は次のとおりです。
Oracle WebLogic Server管理コンソール（http://APPHOST1VHN0:7001/console）にログインします。
「ドメイン構造」ウィンドウで、「環境」→「サーバー」を選択します。
「サーバーの概要」ページが表示されます。
表の「名前」列で「WLS_BAM2」を選択します。
WLS_BAM2の「設定」ページが表示されます。
「デプロイメント」タブをクリックします。
表の「名前」列から「oracle-bam」アプリケーションを選択します。
oracle-bamアプリケーションの「設定」ページが表示されます。
「ターゲット」タブをクリックします。
「ロックして編集」をクリックします。
表5-12の説明に従って、モジュールのターゲットを変更します。
変更を保存およびアクティブ化します。
表5-12 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 |
次の手順に従い、pack/unpackユーティリティを使用してドメイン構成をAPPHOST1から伝播します。
次のpackコマンドをAPPHOST1で実行し、テンプレート・パックを作成します。
APPHOST1> cd ORACLE_HOME/common/bin APPHOST1> ./pack.sh -managed=true domain=ORACLE_BASE/product/fmw/user_projects/domains/bamdomain/ -template=bamdomaintemplate.jar -template_name=bam_domain_template
unpackコマンドをAPPHOST2で実行し、伝播されたテンプレートを解凍します。
APPHOST2> cd ORACLE_HOME/common/bin APPHOST2> ./unpack.sh -domain=ORACLE_BASE/product/fmw/user_projects/domains/bamdomain/ -template=bamdomaintemplate.jar
APPHOST1およびAPPHOST2でノード・マネージャを起動する手順は次のとおりです。
setNMProps.shスクリプトを実行します。このスクリプトはORACLE_HOME/common/binディレクトリに格納されています。
このスクリプトによって、ノード・マネージャを起動する前にStartScriptEnabledプロパティがtrueに設定され、管理コンソールからサーバーを起動できるようになります（BAM Serverに必要な環境変数は、ドメイン・ディレクトリのデフォルトの起動スクリプトに設定されています）。
APPHOST1> cd ORACLE_HOME/common/bin
APPHOST1> ./setNMProps.sh
|
注意: クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。 |
次のコマンドを実行してノード・マネージャを起動します。
APPHOST1> cd ORACLE_BASE/product/fmw//wlserver_10.3/server/bin
APPHOST1> ./startNodeManager.sh
APPHOST2のノード・マネージャに対して手順1と2を繰り返します。
APPHOST1上の管理対象サーバーWLS_BAM1を起動する手順は次のとおりです。
管理対象サーバーWLS_BAM1を起動します。
次のURLを使用して、Oracle WebLogic Server管理コンソールにログインします。
http://apphost1vhn0:7001/console
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」を選択します。
「サーバーの概要」ページが表示されます。
「制御」タブをクリックします。
表の「サーバー」列から「WLS_BAM1」を選択します。
「起動」をクリックします。
http://apphost1vhn1:9001/OracleBAMにアクセスしてWLS_BAM1のステータスを確認します。
管理対象サーバーWLS_BAM2を起動します。
Oracle WebLogic Server管理コンソール（http://apphost1vhn0:7001/console）にログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」を選択します。
「サーバーの概要」ページが表示されます。
「制御」タブをクリックします。
表の「サーバー」列から「WLS_BAM2」を選択します。
「起動」をクリックします。
http://apphost2: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初期化パラメータができるだけ高い値に設定されていることを確認してください。
Oracle RACをBAMスキーマのリポジトリとして使用しているときにデータベースで障害が発生した場合のBAMサーバーの動作を、Oracle BAMでカスタマイズできます。このカスタマイズを可能にするプロパティは、アプリケーションに応じて、また各BAMシステムに必要とされる動作に基づいて調整できます。プロパティは、Fusion Middleware Controlのコンソール・システムのMBeanブラウザ、またはOracle BAM固有の対応のXML構成ファイルで構成されます。
データベースに対するOracle BAMのフェイルオーバーを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管理者ガイド』を参照してください。
APPHOST1でBAM Serverを使用するためのOracleBamWeb（WLS_BAM1）アプリケーションおよびOracleBamWeb（WLS_BAM2）アプリケーションを構成する手順は次のとおりです。
次のURLで、Oracle Enterprise Manager Fusion Middleware Controlにアクセスします。
http:// apphost1vhn0:7001/em
ナビゲーション・ツリーの「BAM」を開きます。
「OracleBamWeb(WLS_BAM1)」を右クリックします。
ポップアップ・メニューの「BAM Webプロパティ」を選択します。
「BAM Webプロパティ」ページが表示されます。
次のプロパティを定義します。
アプリケーションURLにwebhost:7777と入力します。
サーバー名にAPPOST1VHN1と入力します。
ナビゲーション・ツリーで「OracleBamWeb(WLS_BAM2)」を選択し、同じ手順を繰り返します。
正しいBAMServerアドレスを使用するためのADCServerの構成手順は次のとおりです。
次のURLで、Oracle Fusion Middleware Enterprise Manager Consoleにアクセスします。
http://apphost1vhn0:7001/em
ナビゲーション・ツリーの「BAM」を開きます。
「OracleBamServer(WLS_BAM1)」を右クリックします。
ポップアップ・メニューから「システムMBeanブラウザ」を選択します。
システムMBeanブラウザで、「oracle.bam.server」を開きます。これは、アプリケーション定義のMBean内にあります。
「BamServerConfig MBean」をクリックします。
ADCServerName属性に、値としてAPPHOST1VHN1（WLS_BAM1のサーバー・アドレス）を入力して更新します。
ADCServerPort属性に、BAMサーバーが実行しているWLSサーバーのリスニング・ポート（9001）を指定して更新します。
「適用」をクリックします。
WebLogicClusterパラメータをクラスタ内のノードのリストに設定して、管理サーバーと、WLS_BAMn管理対象サーバーのあるWSM-PM_ClusterへのOracle HTTP Serverのルーティングを有効化します。
OHS_HOME/instances/ohs_instance1/config/OHS/ohs1ディレクトリにあるmod_wl_ohs.confファイルに、次の行を追加します。
# BAM Web app
<Location /OracleBAM>
SetHandler weblogic-handler
WebLogicCluster apphost1vn1:9001,apphost2:9001
</Location>
# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster apphost1vn1:9001,apphost2:9001
</Location>
WEBHOST1上のOracle HTTP Serverを再起動します。
WEBHOST1> OHS_HOME/instances/ohs_instance1/bin/opmnctl restartproc ias-component=ohs1
次のURLを検証して、HTTP ServerからSOA_Clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。
WLS_BAM2の実行中に、Oracle WebLogic Server管理コンソールからWLS_BAM1を停止します。
次のURLにアクセスして、適切な機能を検証します。
WebHost1:7777/wsm-pm
WebHost1:7777/OracleBAM
Oracle WebLogic Server管理コンソールからWLS_BAM1を起動します。
WLS_BAM2を停止します。
次のURLにアクセスして、適切な機能を検証します。
WebHost1:7777/wsm-pm
WebHost1:7777/OracleBAM
Oracle BAMの高可用性アーキテクチャは、シングルトン・サービスを障害から保護するためにサーバー移行を利用します。WLS_BAM1管理対象サーバーは、障害発生時にAPPHOST2で再起動できるように構成されます。このような構成では、WLS_BAM1は、Oracle WebLogic Server移行によってフェイルオーバーされる特定の浮動IPをリスニングします。WLS_BAM1管理対象サーバーのサーバー移行を構成する手順は次のとおりです。
ユーザーと表領域を作成する手順は次のとおりです。
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表を作成します。
ORACLE_BASE/product/fmw/wlserver_10.3/server/db/oracleディレクトリにあるleasing.ddlファイルをデータベース・ノードにコピーします。
データベースにleasingユーザーとして接続します。
leasing.ddlをSQL*Plusで実行します。
SQL> @copy_location/leasing.ddl;
Oracle WebLogic Server管理コンソールでleasing表のマルチ・データソースを作成します。
マルチ・データソースの設定プロセスで、これらのデータソースとグローバルleasingマルチ・データソースの両方に対して、各RACデータベース・インスタンスにデータソースを作成します。データソースを作成するときには、次の点に留意してください。
このデータソースが、XAデータソースではないことを確認してください。
マルチ・データソースの名前の形式は、<MultiDS>-rac0、<MultiDS>-rac1などです。
Oracleのドライバ（Thin）バージョン9.0.1、9.2.0、10、11を使用します。
グローバル・トランザクションのサポート、1フェーズ・コミットを適用し、データベースにサービス名を指定します。
これらのデータソースをSOAクラスタにターゲット指定します。
マルチ・データソースの作成
マルチ・データソースを作成するには、次の手順を実行します。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノードを開いてから、「JDBC」ノードを開きます。
「マルチ・データ・ソース」をクリックします。「JDBCマルチ・データ・ソースの概要」ページが表示されます。
「新規作成」をクリックします。「新しいJDBCマルチ・データ・ソースの作成」ページが表示されます。
「ロックして編集」をクリックします。
「新規作成」をクリックします。
「名前」として、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スキーマのサービス名、データベース名、ホスト・ポートおよびパスワードを入力します。
「次へ」をクリックします。
「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。
データソースをSOAクラスタにターゲット指定します。
データソースを選択して、右の画面に追加します。
「新しいデータ・ソースの作成」をクリックして、RACデータベースの2つ目のインスタンスについても同じ手順を繰り返します。
2つ目のデータソースをマルチ・データソースに追加します。
「変更のアクティブ化」をクリックします。
nodemanager.propertiesファイルはORACLE_BASE/product/fmw/wlserver_10.3/server/binディレクトリに格納されています。
Interface=eth0 NetMask=255.255.255.0 UseMACBroadcast=true
Interface=eth0
このプロパティは、浮動IPのインタフェース名（たとえば、eth0）を指定します。
NetMask
このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。
UseMACBroadcast
このプロパティでは、ARPパケットの送信時にノードのMACアドレスを使用するかどうか、すなわち、arpingコマンドで-bフラグを使用するかどうかを指定します。
この構成をAPPHOST1とAPPHOST2の2つのノードで実行します。これらのプロパティが適用されていることをノード・マネージャの出力（ノード・マネージャが起動したシェル）で確認します。適用されていないと、移行中に問題が発生する可能性があります。出力は次のように表示されます。
... StateCheckInterval=500 Interface=eth0 NetMask=255.255.255.0 ...
wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する手順は次のとおりです。
表5-13に一覧表示されているファイルがPATH環境変数に含まれていることを確認します。
wlsifconfig.shスクリプトに対するsudo構成権限の付与
パスワード・プロンプトを使用しないで機能するsudoを構成します。
セキュリティ上の理由から、sudoをwlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する場合は、次の手順を実行します。
WebLogicユーザー（oracle）に、パスワードなしのsudo権限を付与し、/sbin/ifconfig and /sbin/arpingバイナリの実行権限を付与します。
スクリプトがWebLogicユーザー（oracle）によって実行可能であることを確認してください。/etc/sudoers内の次のエントリ例では、oracleのsudo実行権限を、ifconfigとarpingに対しても付与しています。
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
|
注意: この手順で使用できるsudoとシステム権限はシステム管理者にお問い合せください。 |
クラスタ移行を構成することにより、DataSourceForAutomaticMigrationプロパティがtrueに設定されます。クラスタ内にクラスタ移行を構成するには、次の手順を実行します。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。
「クラスタの概要」ページが表示されます。
移行を構成するクラスタ（BAM_Cluster）を、表の「名前」列でクリックします。
「移行」タブをクリックします。
「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。この場合は、「APPHOST1」と「APPHOST2」を選択します。
自動移行に使用するデータソースを選択します。この場合は、leasingデータソースを選択します。
「保存」をクリックします。
サーバー移行の候補マシンを設定します。
このタスクはWLS_BAM1に対して実行する必要があります。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。WLS_BAM1には「APPHOST2」を選択します。
「サーバーの自動移行を有効化」を選択します。
これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックして、変更をアクティブ化します。
管理サーバーとWLS_BAM1サーバーを再起動します。
サーバー移行が適切に機能していることを確認する手順は次のとおりです。
ノード1から:
次のコマンドを使用して、管理対象サーバーWLS_BAM1を停止します。
APPHOST1> kill -9 <pid>
pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。
APPHOST1> ps -ef | grep BAM_SOA1
ノード・マネージャ・コンソールには、WLS_BAM1の浮動IPが無効になっていることを示すメッセージが表示されています。
ノード・マネージャがWLS_BAM1の2回目の再起動を試行するのを待ちます。
ノード・マネージャは、この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。
サーバーが再びローカルで再起動されないことを示すメッセージがノード･マネージャによってログに記録されるようになります。
APPHOST2から:
ローカルのノード・マネージャのコンソールを確認します。
ノード1で最後にWLS_BAM1の再起動が試行されてから30秒経過した後、APPHOST2のノード・マネージャによって、WLS_BAM1の浮動IPが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。
APPHOST1VHN1/OracleBAMとWebHost1:7777/OracleBAMを使用して、Oracle BAMコンソールにアクセスします。
管理コンソールからの検証
次の手順を実行して、管理コンソールで移行を検証できます。
管理コンソールにログインします。
左側のコンソールで、「ドメイン」をクリックします。
「監視」タブ→「移行」タブをクリックします。
「移行の状態」表に、移行の状態に関する情報が表示されます。
