コラボレーション : Cisco Unified Intelligent Contact Management Enterprise

ICM および同期

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

シンクロナイザーは Cisco Intelligent Contact Management(ICM)システムのコア機能の 1 つです。 2 つのシンクロナイザーは相互に通信して、システムの両側で、確実に同じ順序で同じ入力メッセージが見られるようにします。 各シンクロナイザーは、論理的に入力メッセージを受信し、他の Synchronizer に転送します。 常に、1 つのシンクロナイザーはイネーブルで、もう 1 つはディセーブルです。

ルータの場合には、組み合わせられたイネーブルになったステータスを表示できます。 二重にされた周辺機器ゲートウェイ(PG、イネーブルになったシンクロナイザーが入力メッセージの発注を判別する必要があれば)の場合には、ディセーブルにされるそれらがピアとして動作するのを表示できます。

前提条件

要件

次の項目に関する知識があることが推奨されます。

  • ネットワーキングの基本

  • Cisco ICM

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

  • Cisco ICM 4.6 2 以降

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

シンクロナイザー の 状態

可能性のある シンクロナイザー の 状態の説明はここにあります:

接続

これはシンクロナイザーの初期状態です。 シンクロナイザーは専用パス上のリモート シンクロナイザーが付いている接続を確立するように試みます。 接続 タイマはシンクロナイザーが適度な期間(およそ 30 秒)以内の接続を確立することができない場合切れます。

テスト

シンクロナイザーはイネーブルまたはディセーブルになるために専用パス上のリモート シンクロナイザーと通信することができテスト他側プロシージャをかどうか決定するのに使用します。

組み合わせ有効

シンクロナイザーはリモート シンクロナイザーが付いている通信に(組み合わせられる)あり、メッセージの発注を行います(有効に なる)。

組み合わせ無効

シンクロナイザーはリモート シンクロナイザーが付いている通信に(組み合わせられる)ありますが、メッセージの発注を行いません(ディセーブルにされる)。

Isolated-Enabled

この状態では、シンクロナイザーはリモート シンクロナイザーにと(接続されていなかった)通信しないし、メッセージの発注を行います。 事実上、シンクロナイザーは非エラー耐久性があるモードのシステムの側を操作します。

Isolated-Disabled

シンクロナイザーはリモート シンクロナイザーにと(接続されていなかった)通信しないし、メッセージの発注を行いません(ディセーブルにされる)。 事実上、シンクロナイザーはシステムの側のオペレーションを防ぎます。

ルータがこの状態を検知する場合、メッセージは反対側と再調整するべきこの側とのアクティブな接続があるすべての PG に送られます。 MD は Out Of Service 行き、Node Manager によって終了し、再起動するのにルータ mds を(のような、rtr、lgr、agi、incrpnic)使用するすべてのプロセスを引き起こします。

考えられるシナリオ

このセクションは出会うことができる可能 な シナリオをリストします。

ルータがプライベート ネットワーク上の障害から影響を受ける場合はどうしたらいいのですか

専用パス上の通信が切断される時はいつでも設定されたデバイスの大半に接続されるかどうか、シンクロナイザーは両方ともチェックします。 その場合、シンクロナイザーは正常に動作します(たとえば、イネーブルになったシンクロナイザーはイネーブルになっている残り、無効シンクロナイザーはテスト他側(TOS)を呼び出します)。

設定されたデバイスの大半に接続されないことをシンクロナイザーが検出すれば、シンクロナイザーは隔離無効状態にすぐに移り、無効側はまたアクティブな接続のあらゆる PG に他の(アクティブ)側に再接続するためにメッセージを送ります。 この時点で MD は Out Of Service 無効側の行き、プロセスは再起動します。 再始動の後で、TOS プロセスは再度に(ステータスを確認するために一連のキープアライブ パケットはピアに PG によってパブリックネットワークに送信 しました)開始します、従って「フォールト トレランス」のレベルはひどく限られた、遅いが残ります。

プライベート ネットワークが失敗した、無効側が目に見える WAN 上の大半のPG に接続できなければ場合、隔離無効 MD 状態にすぐに移行しました。 この状態で、側はアクティブ行きません間。 それはルーティングのできない考慮されます、従って使用可能な側がダウン状態になっても、この側は回復 するためにプロセスを待っているが、非アクティブに残り、ちょうど反対側をポーリングします。

いくつかの同じようなシナリオは使用可能な側でまた実行される場合があります。 使用可能な側は大半 PG 接続を保持する限り失敗の後でイネーブルになっているとどまるように試みます。 場合、また隔離無効に移ります。 無効側がまた大半のPG の接続を失う場合、二重障害状況は発生します。

表 1 は TOS および操作の結果をリストしたものです。

表 1 – TOS および操作の結果

ルータ Action
ピアは有効に なります ディセーブルにされる滞在- MD は Out Of Service 行きます; lgr および rtr プロセス終了は Node Manager によって、および再起動します。
ピアは無効です become 有効に なりました。
Unreachable become 有効に なりました。
タイムアウト ディセーブルにされる滞在- MD は Out Of Service、lgr および rtr プロセス終了行き、Node Manager によって再起動します。

それがプライベート ネットワーク以外の障害の影響を受けたPG である場合はどうしたらいいのですか

組むべき専用パスの損失があるとき PG は PG ペアを構成する PG 間の専用パスが失われる場合互いに通信できません。 この場合、PG アクティブはその時にアクティブのままになり、他の PG は絶えずプライベート ネットワーク 接続上の専用パスを再確立するように試みルータにピア ステータスをチェックするために TOS 要求を送信 します。 活動ページは絶えず専用パスを再確立することを試みます。

なぜルータの場合には別の対処法があるのか

システムは真剣にプライベート ネットワークがはたらかないか、またはアクティブ PG への接続が失われるとき損なわれます。 もはや時限フェールオーバー応答(ハートビート)がないので、それをシンプレックス システムと考慮して下さい。 アクティブ な 側面がダウン状態になる場合、無効側は PG 接続をチェックしたり、TOS を実行したり、ディセーブルにされるべき反対側および最終的にアクティブ化を見つけるかどれの循環のそのポイントに達するまでアクティブになりません。 全体のプロシージャはルーティングして復元する前に幾つかの分かかる可能性があります。

なぜ、このような現象が発生するのでしょうか。

全面的なアーキテクチャはこれがネットワークに別のラベルを送信できるので、異なる構成情報の 2 人のルータがコールをルーティングする状況を防ぐために調査されます。


関連情報


Document ID: 26300