C 高可用性アーキテクチャとフェイルオーバーの考慮事項
C.1 概要
Oracle B2Bは、Oracle SOAサービス・インフラストラクチャのコンポジット・アプリケーションの一部としてデプロイされます。一部の高可用性の特性は、Oracle B2Bの高可用性デプロイメントに固有のものです。
-
Oracle B2Bのユーザー・インタフェース・アプリケーションは、Oracle WebLogic Serverの各サーバー内で、Oracle SOAサービス・インフラストラクチャ・アプリケーションと同じクラスタの一部として実行されます。
-
Oracle B2Bのサーバーは、パートナ、ドキュメントおよびチャネルの定義を、Oracle RACデータベースを使用するSOAデータベースに保持します。
次の図は、2つのWebLogicサーバーで実行される2ノードのOracle SOA Service Infrastructureクラスタを示しています。
C.2 障害からの保護および予想される動作
この項では、Oracle B2Bの高可用性クラスタのデプロイメントでコンポーネントがどのようにして障害から保護されるかを説明します。また、この項では、コンポーネントの障害が発生した場合の予想される動作についても説明します。
Oracle B2BのUI障害
Oracle B2Bのユーザー・インタフェース・アプリケーションは、ナビゲーションの情報の一部をメモリーに保持します。Oracle B2Bのユーザー・インタフェースを実行する管理対象サーバーの1つで障害が発生すると、ユーザーのリクエストは、アプリケーションを実行しているアクティブな別のWebLogic Serverにリダイレクトされます。Oracle HTTP Serverからの処理中のリクエストは、Oracle HTTP Serverの構成のタイムアウト設定に応じてタイムアウトします。アプリケーションではセッション情報のシリアライズが有効化されていないため、フェイルオーバーには、障害が発生したインスタンスにアクセスしているユーザーの再ログインが必要となります。
Oracle B2Bのユーザー・インタフェースのインメモリー・データはトランザクションではなく、フェイルオーバー時にはいくつかのステップの繰り返しが必要になる場合があります。
ノード障害
ノード障害が発生したり、Oracle WebLogic Serverのローカルのノード・マネージャで、障害の発生した管理対象サーバーの再起動の最大試行回数に達したりした場合には、使用可能なサーバーがデータベース・リース・システム内のタイムスタンプを検証した後、サーバー全体の移行がトリガーされます。他のOracle B2Bエンジンでは、別のチャネルからの新しいメッセージの処理が引き続き可能です。同時に、他のOracle B2Bサーバーは、障害の発生したノードでデータベースに設定されているタイムスタンプのデフォルトのタイムアウト期間(デフォルトは2分)が経過した後、FTP、電子メールまたはファイルなど、シングルトン・チャネルの保留中の操作を再開します。Oracle B2Bのユーザー・インタフェース・アプリケーションでは、Oracle HTTP Serverの構成に応じて、Oracle HTTP Serverからの処理中のリクエストがタイムアウトします。
ノート:
このSOA Suite機能は、Oracle Integration Continuous Availabilityの一部です。Oracle SOA Suite for Middleware Optionsの詳細は、Oracle Fusion Middlewareライセンス情報ユーザーズ・ガイドを参照してください。
C.3 クラスタワイドの構成変更
Oracle B2Bサーバー固有のすべての構成はデータベース内に保持され、構成変更は、WebLogic Serverドメインで実行されるすべてのSOAサーバーに適用されます。したがって、ペイロード・サイズやアウトバウンド・ディスパッチャ数などの構成プロパティはクラスタワイドで適用されるため、Oracle SOAクラスタ内のすべてのインスタンスで使用されることになります。
ファイル、FTPまたは電子メール・トランスポートを高可用性環境で設定するには、FMWコントロールでb2b.HAInstance = trueに設定します。詳細は、「Fusion Middleware ControlでのB2B構成プロパティの設定」を参照してください。さらに、「ロード・バランシング」タブで、SOAJMSModule内のB2BEventQueueConnectionFactoryについて、「サーバー・アフィニティの有効化」の選択を解除します。