BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA |
![]() |
![]() |
|
![]() |
e-docs > WebLogic Integration > WebLogic Integration ソリューションのデプロイメント > WebLogic Integration の高可用性 |
WebLogic Integration ソリューションのデプロイメント
|
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 環境で使用できる基本コンポーネントは次のとおりです。
永続モードをオンにして WebLogic Integration を実行すると、オブジェクトのインメモリの動的な状態は、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 は ebXML Message Service Specification v1.0 および RosettaNet Implementation Framework v1.1、v2.0 をサポートします。
WebLogic Integration アプリケーションに以前のバージョンの WebLogic Integration で開発された RosettaNet ワークフローが含まれている場合は、WebLogic Integration 7.0 でアプリケーションを実行する前に、それらのワークフローを変更する必要があります。ワークフローの移行に関する詳細については、『WebLogic Integration 移行ガイド』の「 WebLogic Integration 2.1 から WebLogic Integration 7.0 への移行」を参照してください。
自動再起動のための 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. リモート起動するように、管理対象サーバをコンフィグレーションする
まず、クラスタ内の各管理対象サーバを、リモート サーバから起動できるようにコンフィグレーションする必要があります。
管理対象サーバをリモート起動できるようにコンフィグレーションには、次の手順を実行します。
http://edocs.beasys.co.jp/e-docs/wls/docs70/ConsoleHelp/domain_server_config_server-start.html
手順 2. 管理サーバに対して SSL をコンフィグレーションする
管理サーバは、SSL を使用して Node Manager と通信するため、管理サーバに対して SSL をコンフィグレーションする必要があります。次の手順を実行してください。
-Dweblogic.security.SSL.trustedCAKeyStore=WL_HOME¥lib¥cacerts
http://edocs.beasys.co.jp/e-docs/wls/docs70/ConsoleHelp/domain_server_connections_ssl.html
手順 3. Node Manager をコンフィグレーションする
Node Manager を管理対象サーバに対してコンフィグレーションするには、WebLogic Server Administration Console を使用して、マシン作成、そのマシン上での Node Manager に対する属性の指定、そのマシンでリモート起動できるようにコンフィグレーションした管理対象サーバのデプロイなどを行う必要があります。具体的には、以下の手順を実行する必要があります。
手順 4. 自己状態モニタ機能をコンフィグレーションする
この手順では、管理対象サーバの自動状態チェック、および Node Manager によるサーバ状態のチェック頻度をコンフィグレーションする方法について説明します。また、サーバが異常 状態に達した場合、Node Manager が自動的にサーバを停止および起動するかどうかも指定できます。
各管理対象サーバについて、次の手順を実行します。
手順 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 コマンドラインの説明
注意: メモリ不足に陥らないように、常に、Node Manger のヒープ サイズには最小限の 32MB (-Xms32m) を指定してください。
上の表にある情報および Node Manager のコンフィグレーションと実行に関する詳細は、次の URL にある、『WebLogic Server ドメイン管理』、「ノード マネージャによるサーバ可用性の管理」の「ノード マネージャの起動」を参照してください。 マシンの起動時に 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
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 ファイルを適切に編集することで実行できます。
次の手順を実行してください。
注意: JTA および JMS サービスの移行は、2 ステップのプロセスです。WebLogic Integration リソースを移行するときは、まず、JTA サービスを移行してから、JMS サービスを移行することをお勧めします。詳細については、故障ノードから健全なノードへの WebLogic Integration の手動移行を参照してください。
移行可能ターゲットのコンフィグレーションに関する詳細については、以下を参照してください。
注意: オンラインヘルプは、Administration Console からアクセスできます。また、次の URL にもあります。
http://edocs.beasys.co.jp/e-docs/wls/docs70/ConsoleHelp/index.html
次のリストは、サンプルの config.xml ファイルからの抜粋で、移行可能ターゲットのコンフィグレーション方法を示しています。このリストでは、クラスタ化された WebLogic Integration 環境における JMS サーバと JTA 回復サービスの両方に対する移行ターゲットのコンフィグレーションが例示されています。このコンフィグレーション例では、クラスタに、MyServer-1 と MyServer-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 要素に注意してください。
また、MigratableTarget 要素には、ConstrainedCandidateServers に対する、サーバのカンマ区切りリストも格納されています。このリストにあるサーバは、JMS サーバのバックアップとして機能する能力があるとして指定されたものです。ConstrainedCandidateServers のリストには、UserPreferredServer を含める必要があります。WebLogic Server Administration Console では、この規則を義務付けています。
フェイルオーバと回復
この節では、具体的なシナリオにおいて、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]
上のコマンドラインの説明
警告: この節で前に述べたとおり、MIGRATE コマンドで weblogic.Admin を呼び出すときに、ソース サーバが停止していることが大切です。
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 サービスをクラスタ内のターゲット サーバに移行することができます。
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 では、クラスタ内のすべてのノードで同一のデータベースが使用されています。クラスタ内のノードごとに別々のデータベース インスタンスを使用する場合は、データベース ベンダが提供する高可用性やフェイルオーバ ソリューションのあらゆる利点を活用してください。たとえば、データベース クラッシュに備えて、データベースのウォーム スタンバイを利用できる場合もあります。
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |