このトピックでは、アプリケーション・サーバーのトランザクションに関連する局面を、
これらのサーバーの可用性を最適化する目的で構成するための、いくつかの考慮事項と実行可能なアクションについて説明します。
このタスクについて
これは、トランザクションのより迅速な完了またはリカバリーに役立ちます。
アプリケーション・サーバーのトランザクション関連プロパティーを変更した後で、
サーバーを再始動する必要があります。
アプリケーション・サーバーのトランザクションに関連する局面を、
可用性を最適化する目的で構成するには、
以下のステップを実行します。
- トランザクション・ログ・ファイルを、
RAID 装置のような、高可用性ファイル・システム上の高速ディスクに保管します。 トランザクション・ログは、すべてのグローバル・トランザクションからアクセス可能であり、
クラッシュ時のトランザクション・リカバリーに使用できるようにしておく必要があります。
したがって、ログ・ファイルが書き込まれるディスクは、
RAID 装置のような高可用性ファイル・システム上に配置する必要があります。
ディスクのパフォーマンスも、トランザクションのパフォーマンスに直接影響します。
一般に、グローバル・トランザクションは、2 つのディスク書き込みを実行します。
1 つはトランザクション結果が認識されたときの準備フェーズ後の書き込み (この情報は強制的にディスクに書き込まれます) であり、
もう 1 つはトランザクション完了時の追加のディスク書き込みです。
したがって、トランザクション・ログは使用可能な最高速のディスクに書き込まれ、
ネットワークにマウントされた装置は使用しません。
- ハードウェア・ディスク・ミラーリングまたはデュアル・ポート・ディスクを使用して、
トランザクション・ログ・ファイルをミラーリングします。 ログ・ファイルがミラーリングされている、あるいはリカバリー可能な場合、
それらを障害の発生したサーバーの再始動時に使用したり、
あるいは別のマシンとそこで始動する別のサーバーに移動して、リカバリーを実行することができます。
ハードウェア・ディスク・ミラーリングやデュアル・ポート・ディスクは、
WebSphere 管理コンソールを使用してトランザクション・ログに適切なファイル・システム・ディレクトリーを指定することにより、使用できます。
- アプリケーション・サーバーに、
トランザクション・ログ・ディレクトリーの最適なロケーションを指定します。
デフォルトでは、アプリケーション・サーバーは、インストール済み
WebSphere Application Server のサブディレクトリー (サブディレクトリーの名前はサーバー名と同じ) にトランザクション・ログ・ファイルを配置します。
例えば、
server1 という名前のアプリケーション・サーバーのデフォルト・ディレクトリーは、次のとおりです。
/IBM/WebSphere/AppServer/profiles/profile_name/tranlog/server1
サーバーに Transaction Log Directory プロパティーを設定すると、アプリケーション・サーバーのトランザクション・ログ・ディレクトリーの固有のロケーションを指定することができます。トランザクション・ログのディレクトリーが
アプリケーション・サーバーの開始時に作成されなかった場合は、ディレクトリー構造が作成されます。
注: トランザクション・ログ・ディレクトリーを変更する場合、
できるだけ早く変更を適用してアプリケーション・サーバーを再始動し、
アプリケーション・サーバーを再始動するまでの問題発生のリスクを最小限にする必要があります。例えば、問題が発生して (トランザクションが実行途中の状態で) サーバーがエラーを生じた場合、
このサーバーが次に始動するときには新規のログ・ディレクトリーが使われるため、
古いログ・ディレクトリーに記録される実行途中のトランザクションを自動的に解決できなくなります。
- 複数のアプリケーション・サーバーが、
ログ・ファイルの同一のセットを並行して使用できるようにはしないでください。 トランザクション・ログはグローバル・トランザクションの状態をサーバー内に記録するため、
ログが失われたり壊れたりした場合に、障害前に準備が完了していたトランザクションは、
リソースを未確定状態のままにして、他のユーザーやサーバーによるリソースへの更新や
アクセスを防ぐことができます。
これらのトランザクションは、
影響を受けたリソース・マネージャーのトランザクションをコミットまたはロールバックして、
手動で解決しなければならない場合があります。
障害が起こったサーバーは、コールド・スタートすることができます。
そうすると、空のトランザクション・ログが新規に作成されます。
ログ・ファイルがミラーリングされている、
またはリカバリー可能な場合は、それらを障害の発生したサーバーの再始動時に使用したり、
あるいは、関連タスクで説明するように、
代替マシンおよびそこで始動する別のサーバーに移動してリカバリーを実行することができます。
複数のアプリケーション・サーバーが、
同一のログ・ファイルのセットを並行して使用できるようにしてはなりません。
個々のサーバーがそれぞれ他のサーバーが記録した情報を破壊してしまうため、
ログ・ファイルは破損し、以降リカバリー目的で使用できなくなってしまいます。
- 始動のたびに同じ listen ポート・アドレスを使用するように、
アプリケーション・サーバーを構成します。
複数のアプリケーション・サーバー間で分散トランザクションを
実行している場合 (例えば、WebSphere 以外の EJB や Corba サーバーなど) は、
トランザクション・ログに保管されているリモート・オブジェクト参照を、リカバリー時に発信サーバーに
リダイレクトする必要があります。
トランザクション・リカバリーが完了できるように、
リモート・オブジェクト参照のリダイレクトを処理する必要があります。
これが必要なのは、例えば、アプリケーション・サーバーが WebSphere Application Server
上にデプロイされていて、WebSphere 以外の EJB または Corba サーバーで分散トランザクションを実行している場合です。
特に、アプリケーション・サーバーのデフォルトの再始動アクションは、サーバーがシャットダウンしたときの
ポートとは異なる listen ポート・アドレスを使用します。このため、トランザクション・リカバリーを完了することができません。この問題を解決するためには、始動時に常に同じ listen ポート・アドレスを使用するようにアプリケーション・サーバーを構成する必要があります (管理コンソールに追加できる ORB サービス設定の ORB プロパティー com.ibm.CORBA.ListenerPort を参照)。
トランザクションに関連する別のアプリケーション・サーバーにリカバリー中にアクセスできるようにするには、それらのサーバーにも同じ構成変更を行う必要があります。