18.4.2　アプリケーションフェイルオーバーのシナリオ

シナリオ1：アクティブNNMi管理サーバーに障害が発生した。

アクティブサーバーがハード障害やOS 障害によってOS のシャットダウン処理が行われないで停止した場合です。スタンバイサーバーは相手が停止したことを検知し，アクティブになって自動的にNNMiを起動し，ネットワーク監視は継続されます。元のアクティブサーバーは，起動するとスタンバイとして動作します。

シナリオ2：システム管理者がアクティブなNNMi管理サーバーをシャットダウンまたはリブートした。

アクティブサーバーがOSのシャットダウン処理を行って停止した場合です。スタンバイサーバーは相手が停止したことを検知し，アクティブになって自動的にNNMiを起動し，ネットワーク監視は継続されます。元のアクティブサーバーは，起動するとスタンバイとして動作します。

ただし，NNMi管理サーバーがLinuxオペレーティングシステムの場合は，OSの停止時に終了スクリプトが実行されると，ovstopコマンドが自動的に実行されるため，アプリケーションフェイルオーバーが無効になり，フェイルオーバーが発生しません。

シナリオ3：NNMi管理者がクラスタをシャットダウンした。

クラスタマネージャー（nnmclusterプロセス）が，管理者の操作または何らかの要因で停止した場合です。スタンバイサーバーは相手が停止したことを検知し，アクティブになって自動的にNNMiを起動し，ネットワーク監視は継続されます。

シナリオ4：アクティブNNMi管理サーバーとスタンバイNNMi管理サーバーの間のネットワーク接続に障害が発生した。

両サーバーの通信ができなくなった場合です。クラスタマネージャー（nnmcluster プロセス）の間のハートビート通信ができないため， 次の状態に陥ります。

• アクティブサーバーは相手が停止したと検知し，そのまま動作します。

• スタンバイサーバーも相手が停止したと検知し，アクティブとなってNNMiを起動します。

シナリオ4では，両方のNNMi管理サーバーがアクティブな状態で稼働します。ネットワークデバイスが復旧すると，2つのNNMi管理サーバーは自動的にネゴシエーションしてアクティブサーバーとして稼働するサーバーを決定し，片方のサーバーがスタンバイとなりNNMiを停止します。

なお，両方のサーバーがアクティブになる状態は，クラスタソフトでのHA構成の場合はスプリットブレインと呼ばれる問題が発生します。しかし，アプリケーションフェイルオーバーの場合は仕組みが異なるため，通信障害が回復すると次のように問題なく回復します。

• 通信が回復すると片方がスタンバイサーバーとなり通常の構成に回復します。

• アプリケーションフェイルオーバーのデータベースは，共有ディスクを使用しないで，スタンバイ側がアクティブ側へデータベースの転送を要求してデータベースを同期する方式です。このため，両方のサーバーでNNMiが動作しても整合性に問題は発生しません。

シナリオ5：NNMiのプロセスが停止した。

何らかの要因でクラスタマネージャー（nnmclusterプロセス）以外のNNMiのプロセスが停止しても，フェイルオーバーは発生しません。

クラスタマネージャーのハートビート通信によって相互にサーバーの動作監視をしていますが，自サーバー内のNNMiのプロセスの監視は行っていないため，このような動作となります。

NNMiプロセスが停止した時にフェイルオーバーさせたい場合は，クラスタソフトによるHA構成を使用してください。

シナリオ6：スタンバイサーバーで障害が発生した。

スタンバイサーバー側で，シナリオ1〜3の障害（サーバーダウン，OSの停止またはnnmclusterプロセスの停止）が発生した場合です。この場合，スタンバイサーバーがクラスタ構成のメンバーからは外れますが，アクティブサーバーのNNMiは動作し続け，NNMiによるネットワーク監視は継続できます。