製品が代替システムで再始動できるようにするには、すべてのシステム (オリジナル・システムとリカバリー対象のシステム) に以下の前提条件をインストールしてから、ARM ポリシーを再構成してピアの再始動とリカバリーを可能にする必要があります。
始める前に
非推奨の機能 (Deprecated feature): ピアの再始動およびリカバリー (PRR) の機能は推奨されません。
トランザクション・リカバリーに対するピアの再始動およびリカバリーではなく、
トランザクション・サービス・サブコンポーネントに対する統合高可用性サポートを使用する必要があります。トランザクション・サービス・サブコンポーネントに対する統合高可用性サポート、および障害のあるアプリケーション・サーバーで処理されているトランザクションのピア・リカバリー用にこのサポートを構成する方法について詳しくは、トピック『
WebSphere Application Server でのトランザクション・サポート』を参照してください。
depfeat
また、再始動を実行する必要のあるすべてのシステムが、同じ RRS ログ・グループの一部である必要があります。
- z/OS® バージョン
1.2 以上
- BCP APAR OA01584
- RRS APAR OA02556 および OA2556
- WebSphere® Application Server バージョン 5 以上
これらすべてのシステムに前提条件サービス・アップデートをインストールしても、同じ場所で再始動するだけであれば、現在稼働中の環境の妨げになることはありません。ただし、このサービスがインストールされていない場合、コントローラーが戻れなくなる可能性があります。OTS は、代替システムで再始動を試み、失敗します。これが発生した場合に RRS により解決されない UR が存在すると、コントローラーは、代替システムで RRS がキャンセルされるまでホーム・システムで再始動できません。OTS と RRS について詳しくは、「 z/OS MVS™ プログラミング:
リソース・リカバリー」を参照してください。
ピアの再始動およびリカバリーを使用する場合は、これらの機能の前提条件に従う必要はありません。代わりに、システムは同じ場所での再始動機能を使用します。
以下の製品は、すべて RRS をサポートします。上にリストされた前提条件がすべて正しくインストールされている場合、これらの製品は個々にピアの再始動およびリカバリーもサポートします。
- DB2® バージョン 7 以上
- IMS™ バージョン 8 以上
- CICS® バージョン 1.3 以上
- MQSeries® バージョン 5.2 以上
上記の製品のほかに、多くの JTA XAResource Managers を製品ピアの再始動およびリカバリー支援に使用することができます。
代替システムでの再始動のサポートについては、JTA XAResource Manager の資料を参照してください。
トラブルの回避 (Avoid trouble): シスプレックスの ARM ポリシーをセットアップする場合、両方のシステムに同じレベルのアプリケーション・サーバーがインストールされているようにしてください。
例えば、
WebSphere Application Server バージョン 5.1 を実行しているアプリケーション・サーバーを使用して、
WebSphere Application Server バージョン 6.0.1 を実行しているアプリケーション・サーバーのピアの再始動およびリカバリーを実行することはできません。
gotcha
ピアの再始動およびリカバリーを使用する前に、以下を行ってください。
- ロケーション・サービス・デーモンおよびノード・エージェントが、リカバリーに使用するすべてのシステムで既に実行されていることを確認します。実行されていない場合、リカバリーするシステムは、ロケーション・サービス・デーモンおよびノード・エージェントが実行されていないシステムでリカバリーを試みます。この場合、サーバーは始動に失敗し、リカバリーは失敗します。
クライアントは、システムが最大能力で稼働している場合に、パフォーマンスに影響が出ます。代替システムのメモリー
および CPU への影響を最小限にとどめるため、エンタープライズ Bean および Web コンテナーは、ピアの再始動モードで稼働している
サーバーでは再始動されませんつまり、リカバリー中の状態のアプリケーション・サーバーは、到着する作業を受け入れることができなくなります。
このタスクについて
前提条件がインストールされた後、
構成済みでないシステムでサーバーを開始すると、暗黙的にピアの再始動およびリカバリー・モードになります。XA パートナー・ログを構成して非共有 HFS に書き込んだ場合、または
JTA XA Resource Manager を使用している場合、サーバーを始動する前に以下のステップを行う必要があります。
手順
- (非共有 HFS を使用する場合にのみ必要) 非共有 HFS サポートを使用可能にします。 非共有 HFS を使用する場合、シスプレックス内の異なるシステム間で構成設定を複製する必要があります。これは、デプロイメント・マネージャーおよびノード・エージェントにより自動的に行われます。このサポートを使用可能にするには、構成内の各ノード・エージェントをリカバリー・ノードとして設定する必要があります。この変更は、管理コンソールで次のように行います。
- 管理コンソールのナビゲーションで、の順で選択します。
- リストからノード・エージェントを選択します。
- 「追加プロパティー」セクションで「ファイル同期サービス」を選択します。
- 「追加プロパティー」セクションで、を選択します。
- 「」を選択します。
- 「名前」に recoveryNode を、「値」に true を入力します。
「説明」フィールドはブランクのままでも構いません。
- 構成内の各ノード・エージェントについてステップ 3 から 7 を繰り返します。
- 構成を保存します。
- (JTA XAResource Managers を使用する場合にのみ必要) 代替システムで適当なログおよびクラスが使用可能であることを確認します。 ピアの再始動およびリカバリーを使用し、アプリケーションが JTA XAResource Managers にアクセスする予定の場合は、代替システムで該当するログおよびクラスが使用可能になっているようにしてください。
- 製品の変数 TRANLOG_ROOT で共有 HFS をポイントします。 TRANLOG_ROOT 変数は、セル内のすべてのシステムが書き込み可能な共有 HFS をポイントする必要があります。
XA パートナー・ログはここに保管され、代替システムがこのログを読み取りおよび更新できるようにする必要があります。
- 管理コンソールで、「server_name」とクリックします。
- 「コンテナー・サービス」の下の「トランザクション・サービス」をクリックします。
- 共有 HFS のディレクトリーを、「トランザクション・ログ・ディレクトリー」フィールドに入力します。
- セル内のすべてのシステムで読み取り可能な
HFS の各 JTA XAResource Manager ごとに、ドライバー
(つまり、JDBC Driver、JMS プロバイダー、または JCA リソース・アダプターなど) を保管します。 例えば、コネクターがデータベースの JDBC Driver の場合、ドライバーは、シスプレックス内のすべてのシステムがアクセス可能な読み取り専用の HFS に保管されます。これにより、代替システムはりソースの保存済みクラスパスを読み取り、再始動中にこれを再構成することができます。
JTA XAResource Manager へのアクセスに使用するコネクターが、リカバリーで使用するすべてのシステムで読み取り可能な HFS に保存されていない場合、アプリケーション・サーバーが代替システムで再始動する際に、行う XA リカバリー作業がないと表示されるか、JTA XAResource Manager との通信に必要なクラスをロードすることができなくなります。
- 未確定単位を解決します。
リカバリー中、手操作による介入を行い未確定単位を解決する必要のある場合があります。この手操作による介入には、RRS パネルを使用する必要があります。