WebLogic Integration ソリューションのデプロイメント
|
 |
 |
|
クラスタ化された WebLogic Integration アプリケーションには、スケーラビリティと高可用性が備わります。高可用性デプロイメントには、ハードウェアやネットワークに障害が発生したときの回復処理が備えられており、障害発生時に制御をバックアップ コンポーネントに移行させることができます。
以下の節では、WebLogic Integration デプロイメントのクラスタ化と高可用性について説明します。
高可用性を備えた WebLogic Integration アプリケーションに関する推奨事項およびデータベース固有のコンフィグレーション要件の詳細については、以下の URL にある WebLogic Integration ドキュメントの「デプロイメント」節にある「可用性の維持」を参照してください。
http://edocs.beasys.co.jp/e-docs/wli/docs81/index.html
高可用性を提供するクラスタでは、サービス障害からの回復が可能です。WebLogic Server では、レプリケートされた HTTP セッション ステート、クラスタ化されたオブジェクト、およびクラスタ化環境のサーバに固定されたサービスのフェイルオーバがサポートされます。WebLogic Server でフェイルオーバを処理する方法については、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタでの通信」を参照してください。
一般的な WebLogic Integration 環境で使用できる基本コンポーネントは次のとおりです。
注意 : さまざまなタイプの JDBC ドライバの利用可能性と各ドライバのパフォーマンスに関する考慮事項については、『Administration Console オンライン ヘルプ』の「JDBC データ ソース」の「JDBC データ ソースのコンフィグレーション」を参照してください。
クラスタ システムのネットワーク トポロジのプランニングについての詳細説明は、この節で扱う内容の範囲を越えています。Web アプリケーションで、ロード バランサ、ファイアウォール、Web サーバについて、1 つまたは複数の WebLogic Server クラスタを組織化することにより、ロード バランシングとフェイルオーバの機能をフルに活用する方法は、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタ アーキテクチャ」を参照してください。
クラスタの簡単な表示、http ロード バランサの表示、高可用性データベースとマルチポート ファイル システムについては次の図を参照してください。
デフォルトの WebLogic Integration ドメインのコンフィグレーションでは、JMS サーバに JDBC ストアを使用します。上図の構成のとおり、高可用性のマルチポートのディスクを管理対象サーバ間で共有できる場合には、ファイル ストアを JMS の永続性のために使用することができます。通常、ファイル ストアは JDBC ストアよりも高性能です。
JMS ファイル ストアをコンフィグレーションする方法については、『Administration Console オンライン ヘルプ』の「JMS : コンフィグレーション」の「JMS ストアのタスク」を参照してください。
ソフトウェアまたはハードウェアの問題により、サーバに障害が発生することがあります。以下の節では、障害が起こったときに自動的に発生するプロセスと、手動で行わなければならない手順について説明します。
ソフトウェアの障害が発生すると、ノード マネージャは WebLogic Server を再起動します (再起動するようにコンフィグレーションされている場合)。ノード マネージャの詳細については、『WebLogic Server のコンフィグレーションと管理』の「ノード マネージャの概要」を参照してください。セキュア インストールの回復処理を準備する手順については、『WebLogic Server のコンフィグレーションと管理』の「障害が発生したサーバの回復」の「コンフィグレーションおよびセキュリティ データのバックアップ」を参照してください。
ハードウェアの障害が発生すると、物理マシンの修理が必要になり、長期間使用できなくなることがあります。ハードウェアの障害時には、以下のイベントが発生します。
障害が長引いた場合は、オペレーション可能な別の管理対象サーバに移行することが必要になります。障害の発生したサーバを別の管理対象サーバに手動で移行する場合、以下の操作が必要です。
WebLogic Server の移行の詳細については、WebLogic Server ドキュメントの次のトピックを参照してください。
WebLogic Server の高可用性機能に加え、WebLogic Integration には、WebLogic Integration ソリューションの実装とコンフィグレーション単位での障害回復処理の機能があります。以下の節では、WebLogic Integration の機能に限定した障害と回復処理について説明します。
WebLogic Integration の障害と回復処理の詳細については、『WebLogic Integration ソリューションのベスト プラクティスに関する FAQ』の「WebLogic Integration アプリケーションの回復処理」を参照してください。
RosettaNet と ebXML では、ビジネス プロトコルが異なるため、別々の方法で障害と回復処理を扱います。ただし、いずれのプロトコルも、指定された回数だけ wli.b2b.failedmessage.queue に再試行した後で、配信されなかったメッセージを送信します。エラーになったメッセージに追加の処理が必要な場合は、このキューにカスタム メッセージ リスナを実装できます。
RosettaNet メッセージで配信エラーになった場合、WebLogic Integration プロトコル レイヤはメッセージを再試行しません。代わりに、HttpStatus コードをワークフロー レイヤに戻します。RosettaNet ワークフローは、通常、再試行を処理するように設計されています。
WebLogic Integration Administration Console により、使用している PIP を基にさまざまなトレーディング パートナの再試行の間隔、再試行回数、およびプロセス タイムアウトなどを指定できます。たとえば、RosettaNet は通常、2 時間の間に 3 回再試行します。実際の PIP 通信が存続している場合に 24 時間でタイムアウトになります。これらの設定を変更する詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」の「バインディングの表示と変更」を参照してください。
WebLogic Integration のあるインスタンスから別のインスタンスにメッセージが送信され、送り先のインスタンスに障害が発生している場合、サーバ コンソールに 1 つまたは複数のエラー メッセージが表示され、その後にスタック トレースが表示される場合があります。
ebXML メッセージの再試行は、WebLogic Integration Administration Console、トレーディング パートナ管理の Bulk Loader、またはサードパーティのトレーディング パートナ管理メッセージ Bean を使用して指定できます。ebXML 配信セマンティクスを OnceAndOnlyOnce または AtLeastOnce に設定した場合、メッセージは、再試行回数と再試行間隔で指定した値に従って再試行されます。WebLogic Integration Administration Console を使用して ebXML メッセージの再試行を設定する方法については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」の「プロトコル バインディングの定義」を参照してください。
ebXML プロセスの場合、アクション モードの値をデフォルト以外に設定すると、回復処理と高可用性を確保できます。アクション モードの設定方法については、『Trading Partner Integration の紹介』の「ebXML ソリューションの紹介」の「ebXML ビジネス プロセス」を参照してください。
WebLogic Integration には、Application Integration リソースの高可用性の管理に対する高い柔軟性があります。以下の節では、ソフトウェアやハードウェアの障害時における Application Integration リソースの動作と、自動的にフェイルオーバされないときの回復方法について説明します。
サービスを含むアプリケーション ビューはクラスタ内の複数の管理対象サーバにデプロイされるため、サービスの呼び出しは、ほとんどの場合中断なく継続されます。中断した場合は、WebLogic Server Administration Console を使用して、アプリケーション ビューの EJB とアダプタの対象を有効な管理対象サーバに変更します。
WebLogic Server Administration Console を使用してサービスの対象を変更する方法については、『Administration Console オンライン ヘルプ』の次のトピックを参照してください。
1 台の管理対象サーバに障害が発生した場合でも、そのクラスタの他の管理対象サーバを対象としたイベントは引き続き配信されます。障害が発生した管理対象サーバを対象としたイベントは、次の両方の条件を満たしている場合、引き続き、中断なく配信されます。
イベント接続が、障害の発生した管理対象サーバのみを対象としている場合は、WebLogic Integration Administration Console を使用して、アプリケーション ビューがデプロイされている稼動中の管理対象サーバをイベント接続の対象にします。イベント接続の対象を変更すると、イベント配信が対象の管理対象サーバで再開されます。
注意 : サスペンドされたアプリケーション ビューのイベント接続に加えた変更は、システムにすでに存在するイベントには適用できません。新しいイベント (変更後にトリガされるイベント) のみが、新しいイベント接続の対象に割り当てられます。システムにすでに存在するイベントは、障害の発生した管理対象サーバがオペレーションに戻ったときに、前のイベント接続の対象によって処理されます。
WebLogic Integration Administration Console を使用してイベント接続の対象を変更する方法については、『WebLogic Integration ソリューションの管理』の「Application Integration」の「イベント生成の対象の変更」を参照してください。
EIS インスタンスがエラーになると、すべてのサービス呼び出しとイベント配信が停止します。エラーになった EIS インスタンスへの非同期のサービス要求は、影響を受けたアプリケーション ビューとアダプタ インスタンスがサスペンド状態になるまで失敗します。オペレーション可能な EIS のインスタンスがある場合、影響を受けたアプリケーション ビューとアダプタ インスタンスを編集してオペレーション可能なインスタンスを使用することができます (WebLogic Integration Administration Console を使用して、これらの編集を行います)。オペレーション可能な EIS のインスタンスがない場合には、アプリケーション ビューとアダプタ インスタンスをサスペンド状態から復帰したときに、サービス起動とイベント配信が続行されます。
以下の節では、アプリケーション ビューとアダプタをサスペンド状態にする方法、アプリケーション ビューとアダプタの処理を再開する方法、およびアプリケーション ビューとアダプタ インスタンスの対象を別の EIS インスタンスに変更する方法について説明します。
EIS がエラーになった場合、イベント配信時のサービスの要求と試行は、影響を受けたアプリケーション ビューとアダプタ インスタンスがサスペンド状態になるまでエラーになります。
注意 : サスペンドされたアプリケーション ビューとアダプタ インスタンスへの同時サービス要求は失敗します。サスペンドされたアプリケーション ビューとアダプタ インスタンスへの非同期サービス要求は、キューに入れられ、サスペンドされたアプリケーション ビューとアダプタ インスタンスがオペレーションを再開したときに処理されます。
アプリケーション ビューとアダプタ インスタンスのサスペンドは、自動的に行われるか手動で行います。
WebLogic Integration Administration Console を使用して、アプリケーション ビューの自動サスペンド オプションを有効にする方法については、『WebLogic Integration ソリューションの管理』の「Application Integration」の「アプリケーション ビューの自動サスペンド設定の表示と変更」を参照。
アダプタ インスタンスの自動サスペンド オプションを有効にする方法については、AdapterDeploymentMBeanの「JavaDoc」を参照。
注意 : WebLogic Integration Administration Console では、アダプタに自動サスペンド機能があるかどうかに関係なく、すべてのアダプタの自動サスペンド オプションを有効にすることができます。アダプタが自動サスペンドをサポートしているかどうかについては、アダプタ ベンダに問い合わせてください。DBMS のサンプル アダプタは自動サスペンドをサポートしています。
WebLogic Integration Administration Console を使用して、アプリケーション ビューまたはアダプタ インスタンスをサスペンドする方法については、『WebLogic Integration ソリューションの管理』の「Application Integration」の「アプリケーション ビューまたはアダプタ インスタンスのサスペンドと再開」を参照。
EIS インスタンスのエラーは、EIS のモニタ ツールを使用するか、または WebLogic Integration Administration Console でアプリケーション ビューやアダプタ インスタンスのエラー回数をモニタすることで検出できます。WebLogic Integration Administration Console を使用してエラーをモニタする方法については、『WebLogic Integration ソリューションの管理』の「Application Integration」を参照してください。
EIS インスタンスが再度オペレーション可能になったら、影響のあったアプリケーション ビューとアダプタ インスタンスをサスペンド状態から解除し、サービス要求とイベント配信を再開する必要があります。
WebLogic Integration Administration Console を使用して、アプリケーション ビューとアダプタ インスタンスをデプロイされた状態に戻す方法については、『WebLogic Integration ソリューションの管理』の「Application Integration」の「アプリケーション ビューまたはアダプタ インスタンスのサスペンドと再開」を参照してください。
EIS インスタンスのエラーが長引きそうな場合には、アプリケーション ビューとアダプタ インスタンスで代替のオペレーション可能な EIS インスタンスを指定できます。オペレーション可能な EIS インスタンスを指定しているアダプタ インスタンスがすでにある場合には、エラーの EIS インスタンスをポイントするアプリケーション ビューのイベント接続とサービス接続のプロパティを編集します。これにより、オペレーション可能な EIS インスタンスをサポートするアダプタ インスタンスを設定できます。
WebLogic Integration Administration Console を使用して、アプリケーション ビューのアダプタを変更する方法については、『WebLogic Integration ソリューションの管理』の「Application Integration」の「アプリケーション ビューのイベント接続の変更」と「アプリケーション ビューのサービス接続の変更」を参照してください。
古い EIS を指定しているイベント接続とサービス接続のプロパティを編集し、オペレーション可能な新しい EIS インスタンスを指定するようにプロパティ値を変更することもできます。
イベント接続とサービス接続のプロパティを変更する方法の詳細については、『WebLogic Integration ソリューションの管理』の「Application Integration」の「イベント接続プロパティの表示と変更」と「サービス接続プロパティの表示と変更」を参照してください。
|
|
|
