フェールオーバー後の自動再配信(集信側)の留意点
(1) フェールオーバー後の自動再配信(集信側)の対象となる条件
以下のすべての条件を満たす場合は、フェールオーバー後に自動再配信(集信側)されます。
集信側履歴の完了コードが「591」
配信側がHULFT Ver.6以降で、表5.4 の条件に一致する
配信側HULFTのOS |
終了コード |
|
---|---|---|
完了コード |
詳細コード |
|
UNIX/Linux |
250 |
591 |
Windows |
450 |
591 |
Mainframe |
16 |
591 |
IBM i |
700 |
591 |
配信側HULFTは、Ver.6以降でもOSやリビジョンによってフェールオーバー後の自動再配信(集信側)対象外の場合もあります。対象のバージョンおよびリビジョンについては、「アドミニストレーション マニュアル」を参照してください。
配信側「自動再配信リトライ回数(*1)」が“0”より大きい場合
*1 |
: |
自動再配信リトライ回数は、異常が発生した場合、自動再配信を試みる回数です。ネットワークエラーによる自動再配信の回数と、集信側フェールオーバー発生による自動再配信の回数を合わせたものです。 |
すべての条件を満たさない場合は、フェールオーバー後の自動再配信(集信側)は実行されません。配信側HULFTで再配信待ちとなります。
(2) フェールオーバーにかかる時間の設定
フェールオーバー後の自動再配信(集信側)は、配信側HULFTに自動再配信(集信側)を依頼通知することで実行されます。
ここでは、配信側のOSがUNIXの場合を例に説明します。
配信側は集信側からフェールオーバー後の自動再配信(集信側)の対象となるエラーコードを受け取ると、システム動作環境設定で指定した「ソケット接続リトライ待ち時間」(自動再配信待ち状態の時間)待ってから自動再配信(集信側)を開始します。
接続できない場合は、さらに最大で「ソケット接続リトライ待ち時間」×「ソケット接続リトライ回数」だけ待ちます。
配信側が自動再配信(集信側)を行う場合に待つ最大時間は、以下になります。
(自動再配信待ち状態の時間)+(ソケット接続リトライ待ち時間)×(ソケット接続リトライ回数)
最大時間を過ぎると、配信側でソケットエラーとなり自動再配信されません。
そのため、フェールオーバーにかかる時間をあらかじめ測定した上で、配信側のソケット接続リトライ待ち時間とソケット接続リトライ回数を設定してください。
<設定例>
クラスタ環境下にある集信側HULFT(クラスタ対応)で、フェールオーバーが発生してから集信が起動できるまでの平均時間が2分(120秒)の場合
配信側HULFT(UNIXの場合)の設定
-
「ソケット接続リトライ待ち時間」 :30(秒)(=自動再配信待ち状態の時間)
-
「ソケット接続リトライ回数」 :5(回)
配信側が自動再配信(集信側)を行う場合に待つ最大時間
= 30+30×5
= 180
このように、「配信側が自動再配信(集信側)を行う場合に待つ最大時間」 > 「フェールオーバーが発生してから集信が起動できるまでの平均時間」となるように設定することをお勧めします。
OSごとにシステム動作環境設定で設定する、待ち時間とリトライ回数を設定する項目名が違います。以下に示します。
配信側HULFTのOS |
待ち時間の項目名 |
リトライ回数の項目名 |
---|---|---|
UNIX/Linux |
ソケット接続リトライ待ち時間 |
ソケット接続リトライ回数 |
Windows |
コネクションリトライ間隔 |
コネクションリトライ回数 |
Mainframe |
自動再配信時、集信多重度オーバー時のリトライ間隔 |
接続エラー時リトライ回数 |
IBM i |
コネクションリトライ間隔 |
コネクションリトライ回数 |