クラスター内のサーバーはトランザクション・サービスのピア・リカバリーを使用して、障害のあるクラスター・メンバーの未解決の作業を完了できます。
このトピックのステップに従って、クラスター内で障害を起こしたアプリケーション・サーバーのピア・リカバリーに必要なトランザクション・プロパティーを構成します。
始める前に
サーバー間でのトランザクション・ピア・リカバリーを使用可能にするには、参加するサーバー・メンバー間でリソース・プロバイダーの構成を共用する必要があります。
つまり、ピア・リカバリー処理は、同じサーバー・クラスターのメンバー間でなければ実行できません。
1 つのクラスターには、WebSphere® Application Server のバージョンの異なる複数のサーバーを含めることが可能ですが、高可用性の使用可能化、および構成を行う必要があるのは、クラスター内のすべてのサーバーがバージョン 6 以降である場合のみです。
このタスクについて
トランザクションのピア・リカバリーは、ピアの再始動およびリカバリー のサポートに追加されるもので、シスプレックスのピア・システム上で再始動が可能になります。
ピアの再始動およびリカバリーの構成について詳しくは、ピアの再始動およびリカバリーのセットアップを参照してください。
ピア・リカバリーに必要なトランザクション・プロパティーの構成は、クラスターを高可用性サポートを使用するように構成するための全体的なタスクの一部です。
手順
z/OS® プラットフォームでは、アプリケーション・サーバーが ATRSRV マクロを呼び出すことができるように、Resource Access Control Facility (RACF®) を構成します。 ATRSRV マクロにより、サーバーは他のサーバーのトランザクションをコミットおよびバックアウトすることができます。
このプロセスは、ピアの再始動およびリカバリー・サポート (他のサーバーが別のシステム上で始動される) とは異なります。
ATRSRV マクロは、MVS™ リソース・リカバリー・サービス (RRS) によって提供されます。
アプリケーション・サーバーのコントローラー領域の実行に使用されるユーザー ID には、FACILITY クラスの MVSADMIN.RRS.COMMANDS.
gname.
sysname リソースに対する ALTER アクセス権限が必要です。ここで、
gname は RRS ロギング・グループ (通常は、SYSPLEX 名) であり、
sysname はシステム名です。
すべてのロギング・グループおよびシステムにアクセスできるようにするには、リソース名にワイルドカード (例えば、MVSADMIN.RRS.COMMANDS.*) を使用します。
注: コントローラー領域は、許可されたアドレス・スペースとして実行されるので、RACF 構成により明示的にアクセス権限が制限されない限り、このリソース・クラスに対する ALTER アクセス権限を暗黙に所持します。このリソースに対するアクセスを明示的に許可することにより、コントローラー領域の許可状態に依存することはなくなります。
ATRSRV マクロの詳細、および適切な RACF アクセス権の設定について詳しくは、「MVS プログラミング: リソース・リカバリー」(SA88-8582-02) の第 8 章を参照してください。
- クラスター内のサーバーごとに、トランザクション・ログ・ディレクトリー設定を構成します。 管理コンソールまたはコマンドを使用して、
トランザクション・ログ・ディレクトリーの場所を構成することが
できます。 構成は、serverindex.xml ノード・レベル構成ファイルに保管されます。
クラスター内の個々のサーバーは、同じクラスター内の他のサーバーのログ・ディレクトリーにアクセスできる必要があります。
このため、ここを未設定のままにしないでください。
ディレクトリーを設定しない場合、アプリケーション・サーバーは、該当するプロファイル・ディレクトリー内の
デフォルトの場所を想定しますが、この場所は、クラスター内の他のサーバーからアクセスできない可能性があります。
クラスター内の各サーバーも固有トランザクション・ログ・ディレクトリーを持って、複数のサーバーが同じログ・ファイルにアクセスしようとすることを回避する必要があります。
例えば、そのサーバーのログ・ディレクトリー名の一部として、各サーバーの名前を使用します。
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
リカバリー・ログ・ファイルのホスティングに使用されるストレージ・メカニズム (例えば、IBM® Network attached storage (NAS) と共有 SCSI ドライブは使用できますが、単純なネットワーク共有は使用できません) と、そのメカニズムへのアクセス (例えばローカル・エリア・ネットワーク (LAN) 経由) は、そのリカバリー・ログ・サービスがデータをディスクに強制保管する際に使用する、ファイル・ベースの強制操作をサポートしている必要があります。
リカバリー・ログ・ファイルのホスティングに使用されるストレージ・メカニズムおよびそのメカニズムへのアクセス (例えば、NetClient ファイル・システム (QNTC) を使用して、別の IBM i サーバーにログを保管することができ、これにより、Server Message Block (SMB) プロトコルによるリモート・システムでのデータ・アクセスが可能になります) は、リカバリー・ログ・サービスがデータをディスクに強制保管する際に使用するファイル・ベースの強制操作をサポートしている必要があります。
また、基本ファイル・システム内のすべてのフォールト・トレランスを活用するように、リモート・ログ・ファイルへのアクセス・メカニズムを構成します。例えば、
ネットワーク・ファイル・システム (NFS) を使用し、ログ・ファイルが含まれている
リモート・ディレクトリーを (NFS マウント・コマンドの -o hard オプションを使用して) ハード・マウントすると、
NFS クライアントは、NFS サーバーが再び使用可能になるまで、失敗した操作を
再試行します。
トランザクション・ログ・ディレクトリーの構成について詳しくは、アプリケーション・サーバーのトランザクション・プロパティーの構成を参照してください。
注: WebSphere Application Server の以前のバージョンからマイグレーションした場合、以前のバージョンでは、リカバリー・ログ構成が server.xml サーバー・レベル構成ファイルに保管されていることに注意してください。
元のリカバリー・ログ設定を構成する既存のスクリプトを実行した場合や、バージョン 5 のアプリケーション・サーバーを、これ以降のバージョンの WebSphere Application Server にマイグレーションした場合、更新されるのは、server.xml ファイル内の元のトランザクション・ログ・ディレクトリー構成です。
管理コンソールはこの状態を検出し、トランザクション・サービス・パネルが表示されるときに、
構成を保管するようユーザーにプロンプトを出します。
この保存操作によって、変更された構成は serverindex.xml ファイルに保存され、古いフィールドは NULL にリセットします。
既存のスクリプトは、早い段階で、serverindex.xml ファイルを保管先とするように変更してください。 新規のスクリプトも、serverindex.xml ファイルを保管先とする必要があります。
- WebSphere Application Server 管理コンソールのクラスター構成パネルで次のステップを実行して、クラスターの高可用性機能を使用可能にします。
- 管理コンソールで、とクリックします。
- 「Enable failover of transaction log recovery」オプションを選択します。
- 「OK」をクリックします。
クラスターの高可用性機能を使用可能にする方法について詳しくは、サーバー・クラスター設定を参照してください。
- 自動と手動のトランザクション・ピア・リカバリーのいずれかを選択する方法を参照して、使用するトランザクション・ピア・リカバリーの種類を決定します。
- 必要な構成に応じて、以下のいずれかのアクションを実行します。
次のタスク
補正ログのロケーションも構成する必要があります。各サーバーは、固有の補正ログ・ディレクトリーを持つ必要があり、補正ログはトランザクション・ログと同様の方法でアクセス可能である必要があります。