BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA
 ドキュメントのダウンロード   サイト マップ   用語集 
検索

WebLogic Integration ソリューションのデプロイメント

 前 次 目次 索引 PDFで表示  

WebLogic Integration の高可用性

クラスタ化された WebLogic Integration アプリケーションは、スケーラビリティと高可用性を提供します。高可用性を備えたデプロイメントには、ハードウェアやネットワークに障害が発生した場合に備えた回復機能が用意されており、障害発生時にはバックアップ コンポーネントにコントロールを渡す仕組みになっています。

以下の節では、WebLogic Integration デプロイメントのクラスタ化と高可用性について説明します。

 


WebLogic Integration の高可用性について

クラスタが高可用性を発揮するには、サービス障害から回復する能力が必要です。WebLogic Server は、複製された HTTP セッション ステート、クラスタ オブジェクト、およびクラスタ環境でのサーバに固有のサービスに対するフェイルオーバをサポートします。 WebLogic Server によるそのようなフェイルオーバ シナリオの処理に関する詳細は、次の URL にある『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタでの通信」を参照してください。

http://edocs.beasys.co.jp/e-docs/wls/docs70/cluster/features.html

推奨ハードウェアおよびソフトウェア

一般的な WebLogic Integration 環境で使用できる基本コンポーネントは次のとおりです。

クラスタ システムのネットワーク トポロジのプランニングについての論議は、この節で扱う内容の範囲を越えています。Web アプリケーションで、ロード バランサ、ファイアウォール、Web サーバについて、1 つまたは複数の WebLogic Server クラスタを組織化することにより、ロード バランシングとフェイルオーバの機能をフルに活用できる方法の詳細は、次の URL にある『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタ アーキテクチャ」を参照してください。

http://edocs.beasys.co.jp/e-docs/wls/docs70/cluster/planning.html

WebLogic Integration の回復から期待できること

高可用性を備えたデプロイメントは、システム障害の発生に備えて、回復機能を備えています。WebLogic Integration は、自動再起動または手動移行ができるようにコンフィグレーションできます。

注意: XOCP ビジネス プロトコルに基づく WebLogic Integration アプリケーションに対しては、高可用性はサポートされていません。そのようなアプリケーションには、回復機能がありません。

WebLogic Integration を適切にコンフィグレーションすると、そのデプロイメントに対して以下の動作を期待することができます。

 


自動再起動のための WebLogic Integration のコンフィグレーション

クラスタ環境に WebLogic Integration がデプロイされているかどうかにかかわらず、システム クラッシュ、ハードウェアの再起動、サーバの不具合などが原因でシャットダウンしたサーバを自動的に再起動するよう、システムをコンフィグレーションすることができます。

注意: この節の手順はクラスタ環境を対象としていますが、同じ手順で、非クラスタ環境、すなわち、管理サーバと管理対象サーバを 1 つずつデプロイする環境をコンフィグレーションすることも可能です。

Node Manager

この節の手順では、管理対象サーバが配置されているマシン上で Node Manager が実行されている場合に、管理対象サーバを起動するシステムをコンフィグレーションする方法について説明します。Node Manager は、WebLogic Server と同梱の Java プログラムで、管理対象サーバに対して、以下のタスクを実行します。

Node Manager に関する詳細については、次の URL にある『WebLogic Server ドメイン管理』、「ノード マネージャによるサーバの可用性の管理」を参照してください。

http://edocs.beasys.co.jp/e-docs/wls/docs70/admin_domain/nodemgr.html

次の手順を実行して、自動起動するように、WebLogic Integration クラスタをコンフィグレーションします。

手順 1. リモート起動するように、管理対象サーバをコンフィグレーションする

まず、クラスタ内の各管理対象サーバを、リモート サーバから起動できるようにコンフィグレーションする必要があります。

管理対象サーバをリモート起動できるようにコンフィグレーションには、次の手順を実行します。

  1. WebLogic Server Administration Console のナビゲーション ツリーで、自動起動をコンフィグレーションする管理対象サーバを選択します。

  2. [コンフィグレーション] タブ、[リモート スタート] タブの順に選択します。

  3. [リモート スタート] タブに表示されるフィールドに情報を入力します。必要な情報はリモート サーバ固有の情報です。このタブにあるフィールドは、次の URL にある『Adminstration Console オンライン ヘルプ』の「[サーバ] → [コンフィグレーション] → [リモート スタート]」で説明されています。
    http://edocs.beasys.co.jp/e-docs/wls/docs70/ConsoleHelp/domain_server_config_server-start.html

手順 2. 管理サーバに対して SSL をコンフィグレーションする

管理サーバは、SSL を使用して Node Manager と通信するため、管理サーバに対して SSL をコンフィグレーションする必要があります。次の手順を実行してください。

  1. 次の行を管理サーバの startWeblogic コマンド ファイルに追加します。
    -Dweblogic.security.SSL.trustedCAKeyStore=WL_HOME¥lib¥cacerts 

    このコマンドラインで WL_HOME は、WebLogic Server がインストールされたディレクトリを表します。たとえば、WebLogic Platform をデフォルト ディレクトリにインストールした場合は、WL_HOMEC:¥bea70¥weblogic700¥server です。

  2. democert.pemdemokey.pem、および ca.pem ファイルを BEA_HOME¥weblogic700¥common¥templates¥domains¥wls.jar からドメインのルート ディレクトリに追加します。

  3. WebLogic Server Administration Console のナビゲーション ツリーで、管理サーバを選択します。

  4. [接続] タブ、[SSL] タブの順に選択します。

  5. [SSL] タブにある各フィールドに、次の URL にある『Adminstration Console オンライン ヘルプ』の「[サーバ] → [接続] → [SSL]」の説明に従って情報を入力します。
    http://edocs.beasys.co.jp/e-docs/wls/docs70/ConsoleHelp/domain_server_connections_ssl.html

    democert.pemdemokey.pem および ca.pem の各ファイルは、手順 2 でドメインのルート ディレクトリにコピーしたサンプル ファイルで、初めて操作で使用できます。それらのファイルは、Administration Console で SSL のコンフィグレーションを行う際、以下のフィールドで使用できます。[サーバ証明書ファイル名]、[サーバ キーのファイル名]、[信頼性のある CA ファイル名]

手順 3. Node Manager をコンフィグレーションする

Node Manager を管理対象サーバに対してコンフィグレーションするには、WebLogic Server Administration Console を使用して、マシン作成、そのマシン上での Node Manager に対する属性の指定、そのマシンでリモート起動できるようにコンフィグレーションした管理対象サーバのデプロイなどを行う必要があります。具体的には、以下の手順を実行する必要があります。

  1. Administration Console のナビゲーション ツリーで [マシン] を選択します。

    [マシン] が右ペインに表示され、ドメインで定義されているすべてのマシンがリストされています。

  2. [新しい Machine のコンフィグレーション] (UNIX マシンをコンフィグレーションしている場合は[新しい UnixMachine のコンフィグレーション]) をクリックします。

    ダイアログ ボックスが右ペインに表示され、新しいマシンのコンフィグレーションに関連付しているタブがリストされています。

  3. [名前] 属性フィールドに新しいマシンの名前を入力し、[作成] をクリックして、指定した名前のマシン インスタンスを作成します。

  4. [ノード マネージャ] タブで、Node Manager の接続属性と認証属性(Node Manager が接続をリスンするアドレスとポート)を定義します。address:port のデフォルト値は localhost:5555 です。[適用] をクリックして変更を実装します。

  5. [サーバ] タブで、このマシンに配置される管理対象サーバ(手順 1. リモート起動するように、管理対象サーバをコンフィグレーションするでリモート起動できるようにコンフィグレーションした管理対象サーバ)を特定します。

    [Available] カラムからサーバ名を選択し、適切な矢印をクリックしてそのサーバを[Chosen] カラムに移動することにより、このマシンに割り当てるサーバを既存サーバから選択することもできます。

  6. [適用] をクリックして変更を実装します。

    これで、新しいマシン エントリによって、このマシン上で実行されている Node Manager との接続、およびこのマシンに配置されている WebLogic Server インスタンスの特定という、2 つの目的に必要な属性が指定されました。

手順 4. 自己状態モニタ機能をコンフィグレーションする

この手順では、管理対象サーバの自動状態チェック、および Node Manager によるサーバ状態のチェック頻度をコンフィグレーションする方法について説明します。また、サーバが異常 状態に達した場合、Node Manager が自動的にサーバを停止および起動するかどうかも指定できます。

各管理対象サーバについて、次の手順を実行します。

  1. WebLogic Server Administration Console のナビゲーション ツリーで、手順 1. リモート起動するように、管理対象サーバをコンフィグレーションするで自動起動をコンフィグレーションした管理対象サーバを選択します。

  2. [コンフィグレーション] タブ、[状態モニタ] タブの順に選択します。

  3. 次の情報を入力します。

手順 5. Node Manager を起動する

Node Manager は、手動起動、OS プロンプトからの java コマンドの実行、自動起動、またはスクリプトの実行によって起動できます。

Node Manager 起動コマンドの構文

Node Manager を起動する java コマンドの構文は次のとおりです。

java [java_property=value ...] -D[nodemanager_property=value]
-D[server_property=value] weblogic.nodemanager.NodeManager

警告: Node Manager は、管理対象サーバを手動で起動する場合と同じディレクトリから起動する必要があります。

上の java コマンドラインの説明

表4-1 nodemanager_property コマンドライン引数の値

Node Manager プロパティ

説明

デフォルト値

weblogic.nodemanager.

certificateFile

SSL 認証に使用される証明書ファイルへのパスを指定する。

./config/democert.pem

weblogic.nodemanager.

javaHome

このマシン上の管理対象サーバを起動するために Node Manager が使用する Java のホーム ディレクトリを指定する。

なし

weblogic.nodemanager.

keyFile

Administration Server との SSL 通信に使用されるプライベート キー ファイルへのパス。

./config/demokey.pem

weblogic.nodemanager.

keyPassword

キー ファイルの暗号化プライベート キーにアクセスするために使用されるパスワード。

password

weblogic.ListenAddress

Node Manager が接続要求をリスンするアドレス。この引数により、weblogic.nodemanager.listenAddress は非推奨になる。

localhost

weblogic.ListenPort

Node Manager が接続要求数をリスンする TCP ポートの番号。この引数により、weblogic.nodemanager.listenPort は非推奨になる。

5555

weblogic.nodemanager.

nativeVersionEnabled

Solaris、HP-UX 以外の UNIX システムでは、Node Manager を非ネイティブ モードで実行するために、このプロパティは false に設定する。

true

weblogic.nodemanager.

reverseDnsEnabled

信頼されているホストのファイルへのエントリに DNS 名(IP アドレスではなく)を含めるかどうか指定する。

false

weblogic.nodemanager.

savedLogsDirectory

Node Manager がログ ファイルを格納するディレクトリへのパスを指定する。Node Manager は、savedLogsDirectory に、NodeManagerLogs という名前のサブディレクトリを作成する。

./NodeManagerLogs

weblogic.nodemanager.

sslHostNameVerificationEnabled

Node Manager がホスト名検証を実行するかどうか決定する。

false

weblogic.nodemanager.

startTemplate

UNIX システムに限り、このプロパティは、管理対象サーバの起動に使用するスクリプト ファイルへのパスを指定する。

./nodemanager.sh

weblogic.nodemanager.

trustedHosts

Node Manager が使用する、信頼されているホストのファイルへのパスを指定する。

./nodemanager.hosts

weblogic.nodemanager.

weblogicHome

WebLogic Server インストールのホスト ディレクトリを指定する。このディレクトリ名は、コンフィグレーション済みのルート ディレクトリのないサーバの、-Dweblogic.RootDirectory のデフォルト値として使用される。

なし


 

表4-2 server_property コマンドライン引数の値

サーバ プロパティ

説明

デフォルト値

bea.home

現在のマシン上の管理対象サーバが使用する BEA ホーム ディレクトリを指定する。

現在のマシン上の管理対象サーバが使用する BEA ホーム ディレクトリを指定する。

java.security.policy

管理対象サーバが使用する セキュリティ ポリシー ファイルへのパスを指定する。

none

weblogic.security.SSL.trustedCAKeyStore

信頼性のある認証局の証明書が格納されている KeyStore へのパスを指定する。

java.security.keyStore


 

上の表にある情報および Node Manager のコンフィグレーションと実行に関する詳細は、次の URL にある、『WebLogic Server ドメイン管理』、「ノード マネージャによるサーバ可用性の管理」の「ノード マネージャの起動」を参照してください。

http://edocs.beasys.co.jp/e-docs/wls/docs70/admin_domain/nodemgr.html

マシンの起動時に Node Manager を起動する

プロダクション環境では、Node Manager は、マシンの起動時に自動的に起動する必要があります。そのような起動方法は、UNIX システム用のスタートアップ スクリプトを記述することによって、または Node Manager を Windows システム用の Windows サービスとし設定することによって、保証することができます。これらのタスクの実行方法の詳細については、次の URL にある『WebLogic Server ドメイン管理』、「ノード マネージャによるサーバ可用性の管理」を参照してください。

http://edocs.beasys.co.jp/e-docs/wls/docs70/admin_domain/nodemgr.html

 


故障ノードから健全なノードに移行するための WebLogic Integration のコンフィグレーション

管理対象サーバに障害が発生して、使用不可能とみなされた場合、サービスを障害の発生した管理対象サーバから、そのクラスタ内の健全なノードに移行することができます。システムを手動移行できるようにコンフィグレーションするには、次の手順を実行します。

クラスタ内であるノードに障害が発生した場合の移行方法の説明は、故障ノードから健全なノードへの WebLogic Integration の手動移行を参照してください。

手順 1. クラスタをコンフィグレーションする

WebLogic Integration リソースが適切に分散されていて、クラスタ ドメインがクラスタ デプロイメントのコンフィグレーションで説明したとおりにコンフィグレーションされていることを確認します。

手順 2. JMS サーバと JTA 回復サービスに対する移行可能ターゲットをコンフィグレーションする

WebLogic Integration デプロイメントの高可用性を達成するには、フェイルオーバ用の JTA サーバと JMS サーバをコンフィグレーションする必要があります。このプロセスでは、JMSサーバおよび JTS 回復サービスに対する移行可能ターゲットのコンフィグレーションも必要です。このタスクは、WebLogic Server Administration Console を使用することで、または config.xml ファイルを適切に編集することで実行できます。

次の手順を実行してください。

  1. クラスタに対して移行可能ターゲットを作成します。

    1. Administration Console のナビゲーション ツリーで Serves ノードを選択します。

    2. コンフィグレーションするクラスタ内に配置されているサーバの名前を選択します。

    3. メイン コンソール ウィンドウで、[Control|Migration Config] を選択します。移行可能ターゲットとして、制約付きサーバ候補の選択に使用できるサーバのリストが表示されます。

    4. [有効] カラムで、クラスタ内の移行可能サービスをホスティングできるすべてのサーバを選択します。矢印を使用してこれらのサーバを [選択した項目] カラムに移動します。

      注意 : 通常は、移行可能サービスの潜在的ホストとして、クラスタ内のすべての管理対象サーバが選択されます。

    5. [適用] をクリックして、移行可能ターゲットに対する変更を有効にします。

      指定したサーバのリストは、MigratableTarget 要素でコンフィグレーションされます。リスト4-1 で、MigratableTarget 要素の ConstrainedCandidateServers 属性を参照してください(ドメイン コンフィグレーションには、管理対象サーバごとに MigratableTarget 要素が 1 つずつある)。

  2. JTA フェイルオーバをコンフィグレーションします。

    1. クラスタ内のすべてのサーバが、サーバのトランザクション ログ ファイルにアクセスできることを確認します。言い換えれば、JTA ログ ファイルは、共用ファイル システムに配置されている必要があります。

    2. Administration Console のナビゲーション ツリーで Servers ノードを選択します。

    3. コンフィグレーションするクラスタ内に配置されているサーバの名前を選択します。

    4. [Control|JTA Migration Config]を選択して、JTA サービスに対して移行可能ターゲットを作成します。移行可能ターゲットとして、制約付きサーバ候補の選択に使用できるサーバのリストが表示されます。

    5. [有効] カラムで、クラスタ内の移行可能サービスをホスティングできるすべてのサーバを選択します。矢印を使用してこれらのサーバを [選択した項目] カラムに移動します。

    6. [適用] をクリックして、新しい移行可能ターゲットに対する変更を有効にします。

注意: JTA および JMS サービスの移行は、2 ステップのプロセスです。WebLogic Integration リソースを移行するときは、まず、JTA サービスを移行してから、JMS サービスを移行することをお勧めします。詳細については、故障ノードから健全なノードへの WebLogic Integration の手動移行を参照してください。

移行可能ターゲットのコンフィグレーションに関する詳細については、以下を参照してください。

次のリストは、サンプルの config.xml ファイルからの抜粋で、移行可能ターゲットのコンフィグレーション方法を示しています。このリストでは、クラスタ化された WebLogic Integration 環境における JMS サーバと JTA 回復サービスの両方に対する移行ターゲットのコンフィグレーションが例示されています。このコンフィグレーション例では、クラスタに、MyServer-1MyServer-2 という 2 つの管理対象サーバが配置されています。

コード リスト 4-1 移行可能ターゲットのコンフィグレーション

<JMSServer Name="WLCJMSServer-MyServer-1" 
Store="JMSWLCStore-MyServer-2" Targets="MyServer-1 (migratable)"
TemporaryTemplate="TemporaryTemplate">
<JMSQueue JNDIName="com.bea.b2b.OutboundQueue-MyServer-1"
Name="B2bOutboundQueue-MyServer-2"/>
<JMSQueue ...
:
</JMSServer>
<JMSServer Name="WLCJMSServer-MyServer-2" 
Store="JMSWLCStore-MyServer-2" Targets="MyServer-2 (migratable)"
TemporaryTemplate="TemporaryTemplate">
<JMSQueue JNDIName="com.bea.b2b.OutboundQueue-MyServer-2"
Name="B2bOutboundQueue-MyServer-2"/>
<JMSQueue ...
:
</JMSServer>
...
<MigratableTarget Cluster="MyCluster"
ConstrainedCandidateServers="MyServer-1,MyServer-2"
Name="MyServer-1 (migratable)"
注="システム生成による、サーバに対するデフォルトの移行可能ターゲット。
手動で削除しないこと。"
UserPreferredServer="MyServer-1"/>
<MigratableTarget Cluster="MyCluster"
ConstrainedCandidateServers="MyServer-1,MyServer-2"
Name="MyServer-2 (migratable)"
注="システム生成による、サーバに対するデフォルトの移行可能ターゲット。
手動で削除しないこと。"
UserPreferredServer="MyServer-2"/>

...
<Server Cluster="MyCluster" JTARecoveryService="MyServer-1"
ListenAddress="localhost" ListenPort="7901" Name="MyServer-1"
ServerVersion="7.0.0.0">
<COM Name="MyServer-1"/><ExecuteQueue Name="default" ThreadCount="15"/>
<IIOP Name="MyServer-1"/>
<JTAMigratableTarget Cluster="MyCluster"
ConstrainedCandidateServers="MyServer-1,MyServer-2 Name="MyServer-1"
UserPreferredServer="MyServer-1"/>
</Server>
<Server Cluster="MyCluster" JTARecoveryService="MyServer-2"
ListenAddress="localhost" ListenPort="7901" Name="MyServer-2"
ServerVersion="7.0.0.0">
<COM Name="MyServer-2"/><ExecuteQueue Name="default" ThreadCount="15"/>
<IIOP Name="MyServer-2"/>
<JTAMigratableTarget Cluster="MyCluster"
ConstrainedCandidateServers="MyServer-1,MyServer-2 Name="MyServer-2"
UserPreferredServer="MyServer-2"/>
</Server>

このリストの以下の XML 要素に注意してください。

 


フェイルオーバと回復

この節では、具体的なシナリオにおいて、WebLogic Integration のフェイルオーバと回復機能がどのように動作するか説明します。内容は以下のとおりです。

Administration Server に対するバックアップとフェイルオーバ

管理サーバのクラッシュやその他の障害が発生した場合に迅速なフェイルオーバを実現するために、オリジナルのサーバに障害が発生した場合にただちに使用できる別のマシンに、管理サーバのインスタンスをもう 1 つ作成することもできます。

管理サーバは、コンフィグレーション ファイル(config.xml)、セキュリティ ファイル、アプリケーション ファイルを使用してドメインを運営するため、少なくとも、これらのファイルのコピーを保管しておくことことをお勧めします。そうすることで、管理サーバに障害が発生した場合も、管理対象サーバの機能を中断することなく、別のマシンで管理サーバを安全に再起動できます。

クラスタの管理サーバがクラッシュしても、管理対象サーバは要求の処理を続行します。ただし、管理サーバが回復するまでは、クラスタのコンフィグレーションを変更することはできません。また、新しいデプロイメント活動もできません。たとえば、あるクラスタの管理サーバが実行されていない場合は、新しいノードのクラスタへの追加、新しいアプリケーション ビューのデプロイメント、アプリケーション ビューに関連付けられた接続ファクトリのアンデプロイ、などを実行することはできません。

The WebLogic Integration B2B Console は、管理サーバにのみデプロイすることができます。クラスタ内の管理対象サーバにデプロイされることはありません。したがって、B2B Integration の管理およびモニタ機能は、管理サーバが停止している間は利用できません。たとえば、トレーディング パートナの追加、削除、変更は、管理サーバが回復するまで実行できません。

管理対象サーバが実行されていても管理サーバが停止している場合は、ドメインの管理は、管理対象サーバの停止や再起動を行うことなく回復できます。

管理対象サーバが実行されている場合の管理サーバの再起動に関する手順の説明は、次の URL にある『WebLogic Server 管理者ガイド』の「WebLogic Server の起動と停止」を参照してください。

http://edocs.beasys.co.jp/e-docs/wls/docs70/adminguide/startstop.html

故障ノードから健全なノードへの WebLogic Integration の手動移行

この節では、コントロールされたフェイルオーバについて説明します。これは、故障ノードからクラスタ内の健全なノードにサービスを移行している間、ソースと送り先のサーバが要求を処理していない状態を指します。

WebLogic Integration を故障ノードから健全なノードに移行する準備

注意: JTA および JMS サービスの移行は、2 ステップのプロセスです。WebLogic Integration リソースを移行するときは、まず、JTA サービスを移行してから、JMS サービスを移行してください。

WebLogic Integration は以下のいずれかの方法で移行できます。

weblogic.Admin コマンドライン ユーティリティを使用する方法

次のコマンドライン(MIGRATE コマンドで weblogic.Admin を呼び出す)を使用して、JMS サービスまたは JTA サービスをクラスタ内のターゲット サーバに移行します。

java weblogic.Admin [-url http://hostname:port]
[-username username]
[-password password]
MIGRATE -jta -migratabletarget (migratabletarget_name|servername)
-destination servername [-sourcedown] [-destinationdown]

上のコマンドラインの説明

weblogic.Admin コマンドライン ツールの詳細については、次の URL にある『WebLogic Server 管理者ガイド』の「WebLogic Server コマンドライン インタフェース リファレンス」を参照してください。

http://edocs.beasys.co.jp/e-docs//wls/docs70/adminguide/cli.html

WebLogic Server Administration Console を使用する方法

weblogic.Admin コマンドライン ツールを使用する代わりに、WebLogic Server Administration Console を使用して、JTS または JMS サービスをクラスタ内のターゲット サーバに移行することができます。

  1. Administration Console のナビゲーション ツリーで Servers ノードを選択します。

  2. クラスタ内のサーバの名前を選択します。

  3. 移行するサービスに合った [移行] タブを選択します。JTA および JMS サービスの移行は、2 ステップのプロセスです。WebLogic Integration リソースを移行するときは、まず、JTA サービスを移行してから、JMS サービスを移行してください。どの [移行] タブを選択するかは、移行するサービスの種類によって決まります。

    警告: ソース サーバが停止していることを確認してください。WebLogic Integration に対するフェイルオーバは、ソース サーバが停止している場合にのみサポートされます。

  4. [Destination Server migratable target list] からサーバを選択します。

  5. [移行] をクリックします。

    手順 2 で選択したサーバで実行されていたサービスは、選択した送り先サーバに移行します。

    移行するサービスは、「手順 3.」での選択によって決まります。[JTA 移行] タブを選択した場合は、JTA サービスのみが、選択したサーバに移行します。[移行] タブを選択した場合は、JMS サービスが選択したサーバに移行します。

Administration Console を使用して、クラスタ内のターゲット サーバに JMS、JTA サービスを移行する方法の詳細については、『Adminstration Console オンライン ヘルプ.』、「サーバ」の「サーバの移行タスク」を参照してください。

データベースの回復

WebLogic Integration は、クラシュしたデータベースの回復は試みません。データベースがクラッシュしたり停止した場合は、WebLogic Integration を再起動する必要があります。

たとえば、WebLogic Integration とデータベースが同じマシン上で実行されていて、そのマシンのプラグが抜けた場合は、WebLogic Integration の回復を試みる前に、データベース回復手順を実行してください。

JMS ストアの回復

サーバ がクラッシュした後は、JMS ストアの移行は不可能です。WebLogic Integration は、JMS ストアに代えて JDBC を使用します。つまり、JDBC を使用して、他のサーバ上に配置されている JMS JDBC ストアにアクセスするのです。WebLogic Integration では、クラスタ内のすべてのノードで同一のデータベースが使用されています。クラスタ内のノードごとに別々のデータベース インスタンスを使用する場合は、データベース ベンダが提供する高可用性やフェイルオーバ ソリューションのあらゆる利点を活用してください。たとえば、データベース クラッシュに備えて、データベースのウォーム スタンバイを利用できる場合もあります。

 

ページの先頭 前 次