自動化ネットワーク管理による移動、あるいはオペレーターの操作による移動は、必ずしも望ましいものではありません。 オペレーターの操作では、時間がかかり、エラーが起きやすくなります。 自動化では、障害の適正な検出が必要であり、障害の発生時に予想どおりの正確な コンソール・メッセージが表示されない場合も、エラーが起きやすくなります。
動的 VIPA テークオーバー機能は、この問題に焦点を当てています。ただし、動的 VIPA テークオーバーは、オペレーターによる作業あるいは自動化でできない機能を導入するのではない、ということに注意してください。これは単に、人間によるエラー検出に依存しないようにするか、あるいはお客さまによる自動化のためのプログラミングに依存しないようにするというだけです。動的 VIPA テークオーバーは、TCP/IP スタックによって完全に実行されます。
DVIPA テークオーバーが可能なのは、DVIPA があるスタック上で (VIPADEFINE により) アクティブとして定義され、シスプレックス内の別のスタック上で (VIPABACKUP により) バックアップとして定義されている場合です。DVIPA がアクティブ状態のスタックが終了するか、またはシスプレックス・グループから離れる時点で、バックアップ・スタックが自動的にその DVIPA を活動化して、ルーティング・デーモンに通知します。スタックがシスプレックス・グループを離れる原因となる事項については、シスプレックス問題の検出およびリカバリーを参照してください。
DVIPA テークオーバーを活用するには、DVIPA アドレスにサービスを提供するアプリケーションが、バックアップ・スタックで使用可能でなければなりません。このようなアプリケーションがない場合は、DVIPA はアクティブにされますが、アプリケーションへのクライアント接続は依然として失敗します。 OMPROUTE を使用する場合、GLOBALCONFIG SYSPLEXMONITOR DELAYJOIN の構成をお勧めします。 これにより、OMPROUTE がアクティブになり、テークオーバー・スタックで DVIPA を公示できるまで、DVIPA テークオーバーを遅らせることができます。 DELAYJOIN の動作方法について詳しくは、シスプレックス問題の検出およびリカバリーを参照してください。
DVIPA テークオーバーの間接続を保持するために、TCP/IP スタックには XCF リンクが必要です。DYNAMICXCF オプションを両方のスタックの TCP/IP プロファイルにコーディングする必要があります。
1 次スタックが失敗した場合に、ワークロードをバックアップ・スタック間にどのように分散するかを決める必要があります。単一のスタックをバックアップとして指定し、すべてのワークロードをそこに移動することも、あるいは複数のスタックにワークロードを分散させることもできます。最初のケースでは、1 次スタック上に VIPADEFINE ステートメントを指定して構成する必要があるのは、1 つの DVIPA のみであり、バックアップ・スタック上では 1 つの VIPABACKUP のみが必要です。2 番目のオプションでは、VIPADEFINE ステートメントを指定して 1 次スタック上に複数の DVIPA を構成する必要があります。
ワークロードの分散を決定した後、それぞれの 2 次スタックに、これがサポートする DVIPA のための VIPABACKUP ステートメントを指定します。
以下の例は、複数のアプリケーションに対して単一のスタックのバックアップを 実装する方法を示したものです。
Uses VIPADEFINE to define 201.2.10.11
Has a Web server running that binds to INADDR_ANY.
Web client programs use 201.2.10.11 as their destination address.
Has an FTP server running that binds to INADDR_ANY.
FTP client programs use 201.2.10.11 as their destination address.Uses VIPABACKUP to define 201.2.10.11 as backup for stack TCPCS.
Has a Web server running that binds to INADDR_ANY.
Has an FTP server running that binds to INADDR_ANY.上のシナリオでは、スタック TCPCS がダウンすると、スタック TCPCS3 が、Web サーバーと FTP サーバー両方への 新規接続要求をすべて受け取ります。FTP および Web のクライアント・プログラムは、それぞれの宛先アドレスとして 201.2.10.11 を使用し続けますが、これらのクライアント・プログラムの接続先はスタック TCPCS3 になります。
以下の例は、複数のアプリケーションに対して複数スタックのバックアップを使用する方法を 示したものです。
Uses VIPADEFINE to define 201.2.10.11 and 201.2.10.12
Has a Web server running that binds to INADDR_ANY.
Web client programs use 201.2.10.11 as their destination address.
Has an FTP server running that binds to INADDR_ANY.
FTP client programs use 201.2.10.12 as their destination address.
Uses VIPABACKUP to define 201.2.10.11 as backup for stack TCPCS.
Has a Web server running that binds to INADDR_ANY.
Uses VIPABACKUP to define 201.2.10.12 as backup for stack TCPCS.
Has an FTP server running that binds to INADDR_ANY.
上のシナリオでは、スタック TCPCS がダウンすると、201.2.10.11 での Web サーバーへの新規接続は、 スタック TCPCS2 を使用して接続され、201.2.10.12 での FTP サーバーへの新規接続は、スタック TCPCS3 を使用して 接続されます。