UCM ( callManager ) のフェールオーバー機能のテスト方法

UCM にはフェールオーバー機能がありますか？（ サンドボックスラボでは、２つの UCM サーバがあります。） もしある場合、現在アクティブな UCM サーバを非アクティブにするにはどうすればよいでしょうか。

CUCM の特定のサービスのフェールオーバーをテストする場合、例えばコールコントロールなど、 CUCM admin Serviceability pages 経由でサービスを無効化（再び有効化）できます。
CUCM VM そのものの電源を落としたり、バーチャルネットワーキング修正の機能はサンドボックスラボのユーザーにはありませんが、ラボ管理者の1人はコメントできるはずです。 CUCM サーバを無効化しても、あなたの使用事例をカバーしない場合、あなたが必要とすることについての詳細と理由を教えてください。代替案をいくつか、もしくはラボの強化が提供できるかもしれません。

私のテストケースは UCM システムフェールオーバー後のもので、以前のコール／会議 ( 失敗以前に作られたもの ) はまだコントロール下にあるか、 JTAPI 経由ではありません。あなたの返信より、ひとつの UCM の全てのサービスを非アクティブ化し、もう一つの UCM の全てのサービスをアクティブ化したが、その後古いコールは制御不能でした。

例えば

１． UCM サーバ１の全てのサービスがアクティブであり、UCM サーバ２の全てのサービスを非アクティブ化する
２. ログインエージェント ( ２つの jabber client ) はそれらの間でコールを行う
３. JTAPI でコールリストを取得する ( defaultPeer.getProvider("{publisher IP}, {subscriber IP};login=....") )
４． サーバ１の全てのサービスの非アクティブ化する
５． サーバ２の全てのサービスをアクティブ化する
６． JTAPI のコールリストを上記ステップ３と同じプロバイダで確認する

ステップ６では、現在のプロバイダのサーバは、サーバ２に変更されましたが、プロバイダからコールリストを取得できませんでした。( 実際、ステップ２で行われたコールはまだ実行中です ) UCM サーバ ( かサンドボックスラボ ) の追加の設定が必要なのですが。

もし理解が正しければ、コールマネジャーサービスのノード１インスタンスは、２つの Jabber インスタンスを登録し、コールセットアッププロセスを提供します。全てのノード１サービスを下げ、ノード２を上げ、下記の複数のことが起きる可能性があります。実際のコール状態とコールハンドリングプロセスはキルされ、ノード１のコールマネジャーにあったコールは消えます。エンドポイントは、オーディオ受信／送信がユーザが手動でコールと Jabber client を停止し、再登録／フェールオーバーの手順を開始するまで続ける ”call survivability mode” に切り替えるでしょう。しかし、ノード１／コールマネジャーがダウンすると実際のコールシグナルが発生するか、リクエスト（転送かホールドかというような）されることができます。 JTAPI アプリのモニタリング ノード１／ CTI-マネジャーは、モニタリングされている各Jabberのデバイスのサービス外イベントを取得します。 JTAPI アプリは、Jabber が手動で呼び出しを終了させ再度登録が発生するまで device-in サービスイベントを受けません。デバイスは、in-service になると最初にアクティブなコールが終了するため、実行中のコールを表示しません。そのため、もしネットワークケーブルをノード１から抜いてノード２に差し替えるとすると最終的な効果はあなたが見えるものと同じだと思います。おそらく、あなたが見たいシナリオはすべての Jabber client とノード１に接続したアプリケーションを持ち、実行中のノード１＆２の全てのサービスをもち、 JTAPI による Jabber から Jabber への monitored コールの開始、そしてノード１／CTI - Manager サービスの無効化により得られるのではないかと思います。ここで、コールはノード１でまだ生きており、 JTAPI アプリでノード１ ／ CTI-Manager からの非接続を検出し、そのプロバイダの全ての機器に out-of-service イベントを送り、フェールオーバーし、ノード2／ CTI-Managerへの再接続を行い、全てのデバイスにin-service イベントを送ります。そして、 JTAPI コールモデルを捉えた "snapshot"イベントを監視されているコールの現在のステータスまで送ります。

１． サーバのノードを変更したとき、 JTAPI プロバイダからオリジナルコールを取得することはできない。
２． サーバのフェールオーバーが発生した際にプロバイダ／デバイス out_of_service/in_service のようなイベントを観察することができる。
３． 新しいサーバが接続されたときに、オリジナルコールの ”snapshot” が取得されることができる
上記より、CUCM フェールオーバーが発生する際に、オリジナルコールは制御不能になりますよね？

CUCM call プロセッシングノードの失敗の場合、実行中のどのコールの状態もなくなります。しかし、コールの参加中のエンドポイントによって、エンドポイントは ” survivability mode " でコールを継続するでしょう。例えば、ユーザが手動でコールを終了するまでオーディオ／ビデオなどのメディアを送信／受信しつづけるなど。 （ エンドポイントはフェールオーバー／割り当てられたバックアップコールの実行中のノードへの再登録ー この時、 JTAPI は再度エンドポイントの in-service/event を開始します。 ）