4 高可用性

この章では、Oracle Fusion Middlewareの高可用性に関する問題について説明します。

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

4.1項「SOA BPELコンポーネントに関する問題」
4.2項「SOAコア拡張機能に関する問題」
4.3項「自動サービス移行に関する問題」

4.1 SOA BPELコンポーネントに関する問題

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

4.1.1項「completionPersistPolicyにDeferred値を使用するとBPELコンポーネント障害が発生する場合がある」

4.1.1 completionPersistPolicyにDeferred値を使用するとBPELコンポーネント障害が発生する場合がある

SOA BPELコンポーネントでcompletionPersistPolicyポリシーにDeferred値を使用すると、RACフェイルオーバーの際にいくつかのインスタンスに障害が発生する場合があります。障害が発生すると、Error committing transactionというエラーが表示されます。

RACフェイルオーバーは2つのスレッド上のトランザクションの不一致が発生する可能性があるため、アプリケーションにとってインスタンスの状態が重要である場合は、Deferred値の使用を避けるようにします。

4.2 SOAコア拡張機能に関する問題

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

4.2.1項「SOAコア拡張機能の使用時の追加のWebサーバー構成」

4.2.1 SOAコア拡張機能の使用時の追加のWebサーバー構成

フロント・エンドとしてOracle HTTP Serverを使用し、SOAコア拡張機能を高可用性またはエンタープライズ・デプロイメントの一部として構成している場合、次のステップを完了してください。

クラスタ・インストールの前提条件を実行するには、次の手順を実行します。

管理コンソールを開きます。
チェンジ・センターで「変更と再起動の表示」をクリックします。
「再起動チェックリスト」をクリックします。
クラスタの管理サーバーおよびSOAサーバーのどちらも、再起動チェックリストにないことを確認します。
リストされているサーバーがある場合は再起動します。

クラスタにFoundation Packのみをインストールしている場合は、次の手順を実行します。

WebTier_HOME/instances/instances_name/config/OHS/ohs1/mod_wl_ohs.confファイルを開きます。

次のコードを追加します。

<Location /AIA>
SetHandler weblogic-handler
WebLogicCluster <machine1_hostname>:<port>,<machine2_hostname>:<port>
WLLogFile /tmp/web_log.log
</Location>
<Location /AIAValidationSystemServlet> 
SetHandler weblogic-handler 
WebLogicCluster <machine1_hostname>:<port>,<machine2_hostname>:<port>
WLLogFile /tmp/web_log.log
</Location> 
<Location  /MirrorServlet> 
SetHandler weblogic-handler 
WebLogicCluster <machine1_hostname>:<port>,<machine1_hostname>:<port>
WLLogFile  /tmp/web_log.log 
</Location>

Oracle HTTP Serverを再起動します。

SOAクラスタの設定後、次のエントリが追加されます。

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
 SetHandler weblogic-handler 
WebLogicCluster <machine1_hostname>:<port>,<machine2_hostname>:<port>
</Location>
sdpmessaging/

Location属性を/sdpmessaging from /sdpmessaging/userprefs-uiに変更します

4.3 自動サービス移行に関する問題

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

4.3.1項「Oracle User Messaging Service 12c (12.1.3)は自動サービス移行をサポートしない」

4.3.1 Oracle User Messaging Service 12c (12.1.3)は自動サービス移行をサポートしない

高可用性を活用できるエンタープライズ・デプロイメントでは、Oracle BAMを構成して、サーバーに障害が発生した場合に特定のサービスをクラスタ内の別の管理対象サーバーに移行する自動サービス移行を使用することをお薦めしています。

ただし、Oracle BAMが恒常的に負荷の高いUser Messaging Service (UMS)メッセージを生成しているいくつかのシナリオでは、管理対象サーバーの障害によっていくつかのアラート・メッセージがUMSキューにスタックされたままになる可能性があります。これは、現在UMS 12c (12.1.3)は自動サービス移行をサポートしていないためです。

この問題を回避するには、障害が発生したOracle BAM管理対象サーバーを再起動してUMSキューのメッセージをリカバリします。BAMサーバーの障害発生後に適切な容量と負荷持続性を復旧させるには、次の2つのことを行う必要があります。

障害が発生した管理対象サーバーを再起動します。
移行されたサービスを元の管理対象サーバーにフェイルバックします。

詳細は、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の自動サービス移行発生後のOracle BAMサービスのフェイルバックに関する項を参照してください。

BAMサーバーを再起動するとご使用のシステムのリカバリ時間目標(RTO)を満たさなくなる場合は、デフォルトのJMSプロバイダのかわりにアドバンスト・キューイング(AQ) JMSでUMSを構成できます。詳細は、『Oracle User Messaging Serviceの管理』の付録BにあるAQ JMSによるUser Messaging Serviceの構成に関する項を参照してください。