次の図は、アプリケーションローカル OS NIC からデータセンター ネットワーク スイッチング インフラストラクチャへの仮想から物理への通信パスを示しています。

この設計では、アクティブ/アクティブモードで 2 つの VMNIC を使用する 1 つの仮想スイッチを使用します。この設計では、VMware vSwitch のポートグループ VMNIC オーバーライドメカニズムを使用するファブリック インターコネクトを介して、パブリックネットワークとプライベートネットワークのパスの多様性を調整します。この設計では、ファブリック インターコネクトを介する単一パスの損失による両方のネットワークの障害を回避するため、パブリックネットワークとプラットフォームのパスの多様性が必要です。

UCS B ファブリック インターコネクトを備えたコンタクトセンターは次をサポートします。

• エンドホストモードでのファブリック

• イーサネット インターフェイスは 1/10 GB で、ギガビット イーサネット スイッチに接続されている必要があります。

• UCS Manager の vNIC に有効なファブリック フェールオーバー

（注）	アップデート 1 以降、Nexus 1000v および Nexus 1000v を基に下その他シスコ分散仮想スイッチは、ESXi 6.5 との互換性はありません。詳細については、サードパーティ vSwitch の中止に関する VMware の項目を参照してください。

次の図は、UCS C-Series サーバのすべてのソリューション向けリファレンス設計と vSphere vSwitch 設計のネットワーク実装を示しています。

この設計では、アクティブ/スタンバイ構成の仮想マシン ネットワーク インターフェイス コントローラ（VMNIC）インターフェイスの VMware NIC Teaming（負荷分散なし）を使用します。このデバイスは、ネットワークへの代替および冗長ハードウェアパスを使用します。

ネットワーク側の実装は、この設計と異なる場合があります。ただし、冗長性が必要であり、パブリックネットワークとプライベートネットワーク通信の両方に影響を与えるシングル ポイント障害を持つことはできません。

イーサネット インターフェイスは 1/10 GB で、ギガビット イーサネット スイッチに接続されている必要があります。

UCS C シリーズのネットワーキングの詳細については、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/cisco-collaboration-virtualization.html のソリューション向けのシスコ コラボレーション仮想化ページを参照してください。

Unified CCE で採用されているフォールト トレラント アーキテクチャには、2 つの独立した通信ネットワークが必要です。これらのネットワークは、個別の物理ネットワークです。プライベートネットワークでは、コンポーネント間の同期の維持と復元に必要なトラフィックを処理します。また、メッセージ配信システム（MDS）を介したクライアント通信も処理します。（別のパスを使用する）パブリックネットワークは、セントラルコントローラと PG 間のトラフィックを処理します。パブリックネットワークは、フォールトトレランス ソフトウェア向けの代替ネットワークとしても機能し、コンポーネントの障害とネットワークの障害を区別します。高可用性を実現するには、パブリックネットワークに冗長接続を含める必要があります。各接続が異なるキャリアを使用するのが理想です。

Note	パブリックネットワークは、目に見えるネットワークと呼ばれることもあります。

次の図は、Contact Center Enterprise ソリューション向けのネットワークセグメントを示しています。PG とセントラルコントローラの冗長ペアは、地理的に分かれています。

この場合、パブリックネットワークは、セントラルコントローラ、PG、および Administration & Data サーバ間のトラフィックを処理します。パブリックネットワークは、同期制御トラフィックは処理しません。パブリックネットワーク WAN リンクには、PG、Administration & Data サーバをサポートするための適切な帯域幅が必要です。IP ベースのプライオリティキューイングまたは QoS のどちらかをかならず使用して、コンタクトセンター トラフィックが、遅延およびジッターの両方に対して許容可能な許容度内で処理されているかを確認します。

プライベートネットワークは、セントラルコントローラまたは PG の冗長サイド間でトラフィックを処理します。このトラフィックは、主に同期されたデータと制御メッセージによって構成されています。また、トラフィックは、分離された状態から復旧する際に、冗長サイドの再同期に必要な状態転送も伝達します。WAN を使用して展開する場合、プライベートネットワークは、Contact Center Enterprise ソリューションの全体的な応答で重要となります。ネットワークには、厳しい遅延要件があります。したがって、IP ベースのプライオリティキューイングまたは プライベートネットワーク リンク上の QoS のどちらかを使用する必要があります。

必要なフォールトトレランスを実現するには、プライベート WAN リンクがパブリック WAN リンクから完全に独立している必要があります（別々の IP ルータ、ネットワーク セグメントまたはパスなど）。独立した WAN リンクによって、シングルポイント障害が、パブリックネットワークとプライベートネットワーク間で完全に分離されます。ルート済みネットワークを通過するパブリックネットワーク WAN セグメントを展開すると、ネットワーク全体の PG とセントラルコントローラ間のルートの多様性を維持できます。複数のセッションで共通のパス選択肢と共通の障害ポイントが発生するルートは避けてください。

セントラルコントローラの 1 つのサイドにローカルな PG および Administration & Data サーバは、公共のイーサネットを介してローカルのセントラルコントローラに接続し、公共の WAN リンクを介してリモートのセントラルコントローラに接続します。オプションで、セントラルコントローラ LAN セグメントから分離された PG および Administration & Data サーバにブリッジを展開して、LAN の機能停止に対する保護を強化できます。

Contact Center Enterprise ソリューションでは、すべてのプライベートネットワークで QoS が必要です。パブリックリンクでは、2000 エージェントおよび 4000 エージェントリファレンス設計で QoS を使用できます。12,000 エージェントリファレンス設計のパブリックリンクでは、QoS によってサーバ障害の検出が遅れる可能性があります。

大量の低優先順位のトラフィックが高優先順位のトラフィックの前に来ると、遅延によってフォールトトレランス動作がトリガーされる可能性があります。これらの遅延を回避するには、パブリックネットワークとプライベートネットワーク内の各 WAN リンクに対する優先順位付けスキームが必要です。Contact Center Enterprise ソリューションは、IP ベースの優先順位付けと QoS をサポートします。

低速のネットワークフローでは、単一の大きな（たとえば、1500バイト）パケットが、ネットワーク上で消費する時間は 100 ミリ秒を超える場合があります。この遅延は、1 つ以上のハートビートの明らかな損失の原因となる場合があります。この状況を回避するために、コンタクトセンターは優先順位の低いトラフィックに対して小さい最大伝送ユニット（MTU）を使用します。これにより、より早く優先順位の高いパケットをネットワークに接続できます。（回路の MTU サイズは、PG 設定で構成した回路帯域幅に基づいて計算されます）。

ネットワークに対して間違った優先順位付けをすると、一般的にコールタイムアウトやハートビートの損失の原因となる場合があります。アプリケーションの負荷が増加したり、ネットワーク上に共有トラフィックが配置される時に、問題が増加します。また、遅延条件が極端な場合、送信側でアプリケーション バッファ プールを使い果たすこともあります。

Contact Center Enterprise は、高、中、低の 3 つの優先順位を使用します。QoS を指定しない場合、ネットワークは、送信元および接続先 IP アドレス（別の IP 接続先アドレスに送信される優先順位の高いトラフィック）が特定した 2 つの優先順位のみ認識します。UDP ハートビートに関しては、特定の UDP ポート範囲が特定した 2 つの優先順位のみ認識します。IP ベースの優先順位付けでは、プライオリティキューイングを使用して IP ルータを構成し、優先順位の高い IP アドレスを持つ TCP パケットと他のトラフィックよりも UDP ハートビートを優先します。この優先順位付けスキームを使用する場合、使用可能な帯域幅の合計の 90% が優先順位の高いキューに付与されます。

QoS に対応したネットワークでは、IP アドレスではなく QoS のマーキングに基づいて、パケットに優先順位が付けられた処理（キューイング、スケジューリング、およびポリシー設定）が適用されます。コンタクトセンターは、プライベートおよびパブリック ネットワーク トラフィックに対してレイヤ 3 DSCP のマーキング機能を提供します。トラフィックマーキングは、ネットワークが QoS 認識のため、各ネットワーク インターフェイス コントローラ（NIC）にデュアル IP アドレスを設定する必要がなくなることを意味します。ただし、代わりにネットワークエッジでトラフィックにマークを付けすると、IP アドレスに基づいたアクセス制御リストを使用してパケットを識別するために、デュアル IP 構成が依然として必要です。

Note	Microsoft Windows Packet Scheduler が（PG、セントラルコントローラ トラフィックのみに）有効な場合、レイヤ-2 802.1p のマーキングも可能です。ただし、これはサポートされていません。Microsoft Windows Packet Scheduler は、Unified CCE には適していません。802.1p マーキングは広く使用されておらず、DSCP マーキングが使用可能な場合は、必要ありません。

データトラフィックの適切なネットワーク設計に関しては、http://www.cisco.com/c/en/us/solutions/enterprise/design-zone-borderless-networks/index.html のネットワーク インフラストラクチャおよび Quality of Service（QoS）ドキュメントを参照してください。

UDP ハートビート設計は、パブリックネットワークリンクに障害が発生したかどうかを検出します。ハートビート損失の方向に基づいて、接続の両端から検出を行うことができます。接続の両端は、定期的な間隔（ 400 ミリ秒ごと）でハートビートを反対側に送信します。各端は、他の端から類似したハートビートを探します。どちらかの端がハートビート期間の5倍の期間後にハートビートを受信しない場合、その端に問題が発生したとみなされ、アプリケーションはソケット接続を閉じます。この時点で、閉じられた側から通常、TCP Reset メッセージが生成されます。さまざまな要因によって以下のようなハートビート損失の原因となります。

• ネットワーク障害。

• ハートビート障害を送信するプロセス。

• 送信プロセスを実行している VM のシャットダウン。

• UDP パケットの不適切な優先順位付け。

ハートビートには、複数のパラメータが関連付けられています。一般に、これらのパラメータはシステムのデフォルト値のままにします。これらの値の一部は、接続が確立されると指定されます。その他のパラメータは、Windows レジストリで設定できます。最も重要な値は、次の 2 つです。

• ハートビート間の時間の長さ

• 障害を示す既存しないハートビートの数（現在は、5 にハードコード済み）

冗長コンポーネント間のプライベートハートビート間隔のデフォルト値は、100 ミリ秒です。片側は、回路の障害を検出し、もう一方は、500 ミリ秒後に障害を検出します。セントラルサイトと周辺機器ゲートウェイ間のデフォルトのハートビート間隔は、400 ミリ秒です。この場合、回路障害のしきい値に到達するまでに 2 秒かかります。

Contact Center Enterprise QoSの実装では、TCP キープアライブメッセージ を使用して UDP ハートビートを置き換えます。パブリック ネットワーク インターフェイスは、ハートビートまたはキープアライブメカニズムの一貫性を実行します。ただしプライベート ネットワーク インターフェイスは、キープアライブを実行します。QoS がパブリック ネットワーク インターフェイスで使用可能状態になっている場合は TCP キープアライブメッセージが送信され、使用不可状態の場合は UDP ハートビートが保持されます。

TCP スタックで提供される TCP キープアライブは、非アクティブ状態を検出すると、サーバまたはクライアント側を終了する原因となります。TCP キープアライブ機能は、接続が一定の期間アイドル状態が続いた後、接続を通してプローブパケットを送信します。別側からのキープアライブ応答が聞こえない場合、接続がダウンしたとみなされます。Windows サーバでは、接続ごとにキープアライブパラメータを指定できます。Contact Center Enterprise パブリック接続の場合、キープアライブタイムアウトは、（5 * 400）ミリ秒に設定され、2 秒の障害検出時間と UDP ハートビートが一致します。

QoS が有効になっている状態で TCP キープアライブに移行する理由は次のとおりです。

• コンバージド ネットワークでは、ネットワークの輻輳状態を処理するルータアルゴリズムが、TCP と UDP に異なる影響を与える場合があります。その結果、UDP ハートビートトラフィックで発生する遅延と輻輳により、タイムアウトによる接続障害が発生する可能性があります。

• UDP ハートビートを使用すると、ファイアウォール環境での展開が複雑になります。ハートビート通信への動的ポート配分では、幅広いポート番号を開くことができるので、ファイアウォールのセキュリティが低下します。

Note	コンタクトセンター トラフィックを処理する WAN では、WAN アクセラレータを使用できません。WAN アクセラレータは、障害検出機能を効果的に無効にする信号を送信できます。

ソリューションネットワークがデフォルトゲートウェイの Hot Standby Router Protocol（HSRP）を使用する場合は、次の要件に従います。

• HSRP ホールド時間と関連する処理遅延を、間隔の 5 倍未満（プライベートネットワークでは 100 ミリ秒、パブリックネットワークは 400 ミリ秒）に設定します。このレベルでは、HSRP アクティブルータのスイッチオーバー中にプライベートネットワーク通信が停止しないようにします。

  プライベートまたはパブリックネットワークの停止通知を超えるコンバージェンス遅延があると、HSRP フェールオーバー時間が検出しきい値を超えて、フェールオーバーが発生する可能性があります。HSRP 構成にプライマリおよびセカンダリの指定があり、プライマリパスルータに障害が発生した場合、HSRP は、可能な場合に限り、プライマリパスを復元します。この復元は、2 回目の停止検出につながる場合があります。

  プライベートネットワークの場合は 500 ミリ秒近く、パブリックネットワークの場合は 2 秒に近い HSRP コンバージェンス遅延のあるプライマリおよびセカンダリ指定を使用しないでください。ただし、検出されたしきい値（透過的な HSRP フェールオーバーが発生する結果となります）を下回るコンバージェンス遅延では、優先パス構成は必須ではありません。次のアプローチが理想的です。パスの値とコストが同じ場合は、ルータを対照的に有効化し続けます。ただし、使用可能な帯域幅とコストが 1 つのパスを好む場合は（パスの移行が透過的である）、プライマリパスとルータの指定を推奨します。

• フォールトトレラント設計では、プライベートネットワークは物理的にパブリックネットワークから分離している必要があります。したがって、一方のタイプのネットワークトラフィックを他のネットワーク リンクに対してフェールオーバーするように HSRP を構成しないでください。

• コンタクトセンターの帯域幅の要件は、常に HSRP で保証する必要があります。それ以外の場合、システムの動作は不安定となります。たとえば、ロード共有用に HSRP を構成する場合は、最悪の場合の障害が発生した場合に、存続するリンクに十分な帯域幅が残すようにしなければなりません。

プライベートネットワークの障害時、コンタクトセンターはすぐに 各サイドまたは両側が分離対応の運用に移行する状態になります。分けられた運用は、ルータがプライベートネットワークの回復を検出するまで継続されます。ルータと PG の冗長ペアは再同期し、通常運用を再開します。

ルータ A がペア対応側、ルータ B がペア無効側とします。プライベートネットワークに障害が発生すると、ルータ A は次のように動作します。

• ルータ A に多数のデバイスがある場合、デバイスは分離対応運用に移行し、トラフィックの処理を続けます。

• ルータ A にデバイスが多数存在しない場合、デバイスは分非離対応運用に移行し、トラフィックの処理を停止します。

プライベートネットワークに障害が発生すると、ルータ B は次のように動作します。

• ルータ B にデバイスが多数存在しない場合、デバイスは分非離対応運用に移行し、トラフィックは処理されません。

• ルータ B にデバイスが多数存在する場合は、テスト状態になります。ルータ B は、パブリックネットワークを介してルータ A に接続するために、PG が有効になっていると指示します。次に、ルータ B は次のように応答します。

  • PG がルータ A に接続して状態を確認できる場合、ルータ B は分離対応状態に移行し、トラフィックの処理を開始します。このケースでは、ルータ A とルータ B の両方が分離対応状態で実行される可能性があります。

  • PG がルータ A に接続して、ルータ A が非分離無効状態である場合、ルータ B は分離対応状態に移行し、トラフィックの処理を開始します。

  • PG がルータ A に接続して、ルータ A が分離無効状態である場合、ルータ B は非分離対応状態に移行し、トラフィックの処理を停止します。

ルータのフェールオーバー処理中は、存続するルータが分離状態になるまで、ルータのルート要求がキューに入ります。ルータの障害が、VRU またはエージェントにすでの到達している進行中のコールには影響しません。

ルータがアイドル状態になっている場合、対応する Logger がシャットダウンされます。各 Logger は、割り当てられているルータのみと通信します。プライベートネットワーク接続が復元され、分離状態のルータの Logger は、そのデータを使用して、別の Logger を再同期します。プライベートネットワーク接続が、Config_Message_Log テーブルの 14 日の保持期間前にバックアップされた場合、システムは自動で Logger 構成データベースを再同期します。また、プライベートネットワーク接続が 14 日の保持期間以上ダウンしたままの場合、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-maintenance-guides-list.html の「 アドミニストレーション ガイド」で説明のある Unified ICMDBA アプリケーションを使用して Logger 上で構成データを再同期する必要があります。

PG の各冗長ペアでは、有効な PG と無効な PG があります。システムの開始時点で、最初に接続された PG が有効な PG になります。ただし、プライベートネットワークでの障害発生後、冗長ペアの中で最大の重みを持つ PG が有効な PG になります。もう 1 つの PG が無効な PG になります。

一般的に、高可用性ネットワークには、パブリックネットワーク用の冗長なチャネルが含まれます。一方のチャネルに障害が発生すると、もう一方のチャネルにシームレスに引き継がれます。2 つのサブコンポーネント間のすべてのチャネルに障害が発生した場合、コンタクトセンターはパブリックネットワークの障害を検知します。

Note	冗長的なパブリックネットワーク無しのコンタクトセンターでは、1 つのチャネルで障害が発生した場合に、コンタクトセンターで障害を検出します。

コンタクトセンターによるパブリックネットワーク障害への対応は、サイト数、機能数、サイトのリンク方法によって異なります。次の項では、より一般的または重要なシナリオについて説明します。

パブリックネットワークとプライベートネットワークの一部に別々に障害が発生した場合、エージェントとコールへの影響が限定される場合があります。ただし、両方のネットワークに同時に障害が発生した場合、システムの機能は制限されます。この障害は、壊滅的です。このような障害は、組み込みバックアップと復元力を備えた慎重な WAN 設計によって回避できます。

サイト内の両方のネットワークで同時に障害は発生すると、サイトはシャットダウンされます。

2 つのサイト間のパブリックネットワークとプライベートネットワークで同時に障害が発生した場合、システムは次の方法で応答します。

1. 両方のルータが過半数のデバイスをチェックします。各ルータは、ルータに過半数のデバイスがある場合は分離有効モードになり、ルータに過半数のデバイスがない場合は分離無効モードになります。

2. PG は、必要に応じて自動的にデータ通信をローカルルータに再調整します。アクティブルータに接続できない PG は非アクティブになります。

3. Unified CM のサブスクライバは、障害を検出し、ローカルのコール処理と呼制御に影響を与えずに、ローカルで機能し続けます。

4. パブリック WAN リンクを介するアクティブな音声パスメディアを送信する進行中のコールは、リンクで障害が発生します。コールで障害が発生すると、PG は、そのコールに対して TCD レコードを作成します。

5. WAN トポロジを介したクラスタリングでは、各側の Unified CM サブスクライバはローカルコンポーネントのみにアクセスし動作します。

6. コール ルーティング スクリプトは、周辺機器オンライン ステータス チェックを使用してオフラインのデバイス周辺をルートします。

7. ローカル Unified CM サブスクライバに登録されている電話機とデスクトップを備えたエージェントには影響はありません。電話機とデスクトップの再ホーム中、他のすべてのエージェントは、一部またはすべての機能を失います。正確なシステム設定に応じて、このようなエージェントは、自信がサインアウトされていることを認識できる場合があります。

8. Unified CCE は、無効になったサイドに新規コールをルートしません。ただし、CTI ルートポイントの障害時に標準規格の Unified CM リダイレクトを使用するか、入力音声ゲートウェイの Unified CVP 存続可能性 TCL スクリプトを使用すると、これらのコールをリダイレクトまたは処理できます。

ゲートウェイに障害が発生した場合、コール廃棄には次の条件が適用されます。

• 進行中のコール — PSTN スイッチは、このゲートウェイのすべての T1/E1 トランクへの D-チャネルを失います。アクティブ コールは保存されません。

• 着信通話 — PSTN キャリアは、代替ゲートウェイの T1/E1 に通話を転送します。PSTN スイッチのトランクを保持する必要があり、ダイヤルプランは正しく構成されている必要があります。

ソリューションでコールの存続可能性を計画する場合は、次の点を検討してください。

• 障害時にコールリカバリができないシナリオがあります。

  • 進行中のコールを含むプロセスが停止された場合。たとえば、システム管理者が、コールサーバをシャットダウンし忘れたとします。この場合、CVP サーバは、ライセンスをリリースするためにすべてのアクティブコールを終了します。

  • コール サーバが推奨コール レートを超えた場合。コールサーバで許可されるコールの数には制限があります。ただし、通話料金に強制的な制限はありません。一般に、推奨される毎秒の通話（CPS）を長時間超える場合、一貫性がなく、予測不能な通話の動作が発生します。ソリューションのサイズを正しく設定し、各コール処理コンポーネント全体でコールの負荷を適切に分散します。

• http://www.cisco.com/c/en/us/support/customer-collaboration/unified-customer-voice-portal/products-installation-and-configuration-guides-list.html の Configuration Guide for Cisco Unified Customer Voice Portal に説明のあるコール存続可能性の発信ゲートウェイを構成します。survivability.tcl スクリプトには指示と有用な情報も含まれています。

• Unified CVP の知識がなくてもクリアされた通話を検出できます。

  • Unified CVP は、設定時間（デフォルトでは 120 分）を超える長さの着信コールを 2 分ごとにチェックします。

  • これらのコールについて、Unified CVP は UPDATE メッセージを送信します。メッセージが拒否または送信不能を受信すると、コールがクリアされ、ライセンスがリリースされます。

• CVP SIP サービスが、コールにセッションの期限切れヘッダーを追加することで、エンドポイントは、独自にセッションを更新できます。RFC 4028（セッション ボーダー コントローラのセッションタイマー）には、SIP コールでのセッション切れの使用方法に関する詳細が含まれています。

• フェールオーバー中に、Unified CVP 制御下のコールは、イングレス音声ゲートウェイ存続可能性 TCL スクリプトから処理を行います。このような場合、Unified CCE セントラルコントローラのルーティング ダイアログが停止します。存続可能性スクリプトが通話を別のアクティブ Unified CCE コンポーネントにリダイレクトした場合、通話はレポートや追跡目的で、元の通話とは関係がない状態で、「新規通話」としてシステムに表示されます。

Cisco Unified SIP Proxy（CUSP）は SIP Proxy サーバの実装です。CUSP は、ゲートウェイまたは仮想マシン上で実行される専用の SIP Proxy サーバです。

以下の項では、Contact Center Enterprise ソリューションで CUSP を展開するためのオプションについて説明します。

east-coast.proxy.atmycompany.com
blade 10.10.10.10 priority 1 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.20 priority 2 weight 10 (this blade is in ISR2 on west coast)

west-coast.proxy.atmycompany.com
blade 10.10.10.20 priority 1 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.10 priority 2 weight 10 (this blade is in ISR1 on east coast)

east-coast.proxy.atmycompany.com
blade 10.10.10.10 priority 1 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.20 priority 1 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.30 priority 2 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.40 priority 2 weight 10 (this blade is in ISR2 on west coast)

west-coast.proxy.atmycompany.com
blade 10.10.10.30 priority 1 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.40 priority 1 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.10 priority 2 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.20 priority 2 weight 10 (this blade is in ISR1 on east coast)

次の点は、CUSP の高可用性に影響します。

• プロキシ サーバ レコード ルートを使用しない— このオプションは、プロキシサーバのパフォーマンスに影響し、「シングルポイント障害」を発生させます。このオプションはオンにしないでください。

  RecordRoute ヘッダーが入力されていない場合、着信コールが Unified CVP コールサーバに到達すると、シグナリングが CUSP をバイパスします。ルーティングのその時点から、シグナリングは発信元デバイスから CVP コールサーバに直接実行されます。

• SIP ハートビートがあるアップストリーム要素ルーティング — CUSPは、INVITE または OPTIONS への応答を良い応答として扱います。したがって、CUSP は、応答を受信したときに要素をダウンとしてマークしません。サーバグループのフェールオーバー応答コードリストで応答が構成されている場合、CUSP はグループ内の次の要素にフェールオーバーします。それ以外の場合、CUSP は、最終応答として応答をダウンストリームに送信します。

デバイスの大半は、ルータが無効な状態にするかどうかを決定します。ルータは、冗長ルータとの接続を失ったデバイスの大半を確認します。各ルータは、ルータ自体のデバイスの過半数を決定します。なし、1 つ、または両方のルータが同時にデバイスの過半数を持つことができます。

デバイスの過半数を持つには、ルータが次のいずれかの条件を満たす必要があります。

• ルータはサイド A ルータであり、有効な PG 全体の少なくとも半分と通信できる。

• ルータはサイド B ルータであり、有効な PG 全体の半分以上と通信できる。

Unified CCE Logger および Database サーバは、構成（エージェント ID、スキルグループ、通話の種類）およびスクリプト（コールフロースクリプト）のためにシステムデータベースを維持します。サーバは、通話処理から最近の履歴データも保持します。Logger はローカルルータからデータを受信します。ルータは同期されているので、Logger データも同期されています。

Logger の障害により、コール処理にすぐ影響を与えることはありません。冗長 Logger は、ローカルのルータからの一連の通話データを受信します。システムが Logger の障害を復元した場合は、Logger は自動で、バックアップ Logger からいつオフラインになったのかのすべてのトランザクションを要求します。Logger は、データベースで記録されたエントリの順番をトラックするリカバリキーを維持します。冗長 Logger は、これらキーを使用して欠落しているデータを特定します。

Logger が、Config_Message_Log テーブルの 14 日の保持期間を超えてオフラインになったままの場合、システムは、自動で Logger 構成データベースを再同期しません。システム管理者は、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-maintenance-guides-list.html の『アドミニストレーション ガイド』に説明されている Unified ICMDBA アプリケーションを使用して Logger を手動で再同期できます。手動のプロセスにより、構成データをプライベートネットワーク全体に転送する便利な時間を選択できます。

Logger の複製プロセスは、そのデータを Logger データベースからから Administration および Data サーバ の HDS データベースに送信します。また、複製プロセスでは、Logger が同期された後、Logger データベースが記録する新しい行が自動的に複製されます。

単一のキャンペーン マネージャを使用した Cisco アウトバウンドオプションを使用する展開では、キャンペーン マネージャは、プライマリ Logger だけにロードされます。そのプラットフォームが停止され、Logger がダウンしている場合、任意の発信通話が停止します。

Unified CCE レポート機能は、リアルタイム、5 分間、およびレポート間隔（15 分または 30 分間）のデータを使用して、レポートデータベースを構築します。各 5 分間のレポート間隔の最後に、各 PG はローカルデータを収集し、ルータに送信します。ルータはデータを処理し、データを履歴データストレージ用のローカル Logger に送信します。この Logger は、履歴データを HDS/DDS データベースに複製します。

PG は、5 分間のデータおよびレポート間隔データのバッファリング（メモリおよびディスク上）を提供します。PG は、このバッファされたデータを使用して、ネットワーク応答の低下と、ネットワークサービス復元後のデータの自動再送信を処理します。冗長ペアの両方の PG に障害が発生した場合は、セントラルコントローラに送信されない 5 分間のデータとレポート間隔のデータを失う可能性があります。

エージェントがサインアウトすると、すべてのレポート統計が停止します。エージェントが次にサインインすると、エージェントのリアルタイム統計は 0 から開始します。エージェントデスクトップと、障害が発生した時にエージェントが行っている処理に応じて、一部のフェールオーバーは、エージェントがコンタクトセンターからサインアウトされる原因となります。詳細については、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-user-guide-list.html の「 Cisco Unified ICM/Contact Center Enterprise レポートの概念」を参照してください。

プライベートリンクに障害が発生した場合のフェールオーバー中に、重み付け値によって、有効な PG になる PG が決定します。各側のアクティブコンポーネントの数とタイプによって、PG の加重値が決定されます。各コンポーネントに割り当てられた重み付けは、そのコンポーネントの復元時間と、コンポーネントがダウンした場合のコンタクトセンターの中断を反映します。エージェント PIM は、VRU PIM および CTI サーバよりも重みがあります。コンポーネントの重み付けは構成できません。

フェールオーバー中に記録されるコールデータは、どのコンポーネントに障害が発生するかによって異なります。障害の状況に応じて、同じコールデータが失われます。ルータは、障害が原因で、アクティブコールへのアクセスを失う場合があります。アクティブコールは依然としてアクティブ状態ですが、ルータは、コールがドロップしたかのように応答します。通常、エージェント PG は、終話コール詳細（TCD）レコードを Unified CCE データベースに作成します。

エージェントにすでに接続されているコールは、フェールオーバー中に続行できます。エージェント PG は、これらのコールが終了すると、そのコールに対して別の TCD レコードを作成します。

このシナリオは、PG サイド A の障害の復元を示しています。

以下の条件がシナリオに適用されます。

• Unified CM サブスクライバ A にはプライマリ CTI Manager があります。

• 冗長性のために、サブスクライバ A に登録されているすべての電話とゲートウェイは、サブスクライバ B をバックアップ サーバとして使用します。

次の図は、PG サイド A での障害と PG サイド B へのフェールオーバーを示しています。すべての CTI Manager サービスと Unified Communications Manager サービスは、引き続き通常通り実行されます。

障害復旧は次のように発生します。

1. PG サイド B が PG サイド A の障害を検出します。

2. PG サイド B は、すべてのダイヤル番号と電話機を登録します。コール処理は PG サイド B を通じて続行されます。

3. 電話機とゲートウェイは登録され、サブスクライバ A で運用可能な状態が続き、フェールオーバーしません。

4. 進行中のコールはエージェントの電話機でアクティブな状態のままですが、エージェントがサインインし直すまで、エージェントは転送のような電話サービスを使用できません。

5. PG サイド B へのフェールオーバー中は、構成に応じて占有されていないエージェントの状態とデスクトップが変化する場合があります。3 者通話のオプションが影響を受ける可能性があります。場合によっては、エージェントはフェールオーバーの完了後にサインインまたは手動で状態を変更する必要があります。

6. 障害からの復旧後、PG サイド B は、アクティブ状態のまま、サブスクライバ B の CTI Manager を使用します。PG がサイド A にフェイルバックしない場合、コールは、PG サイド B で引き続き処理されます。

CTI サーバは、特定の CTI メッセージ（通話の呼び出し中やオフフックイベントなど）について、エージェント PG トラフィックをモニタします。CTI サーバは、これらのメッセージを Cisco Finesse サーバなどの CTI クライアントで利用できるようにします。CTI サーバは、CTI クライアントからのサードパーティ呼制御メッセージ（コールの送信や応答コールなど）も処理します。CTI サーバは、処理のためにエージェント PG を介して Unified CM にこれらのメッセージを送信します。

冗長ペアで CTI OS サーバを展開します。冗長ペアの各半分は、冗長エージェント PG ペアの半分を持つ VM の同身です。アクティブな CTI サーバの障害発生時には、冗長 CTI サーバがアクティブになり、コールイベントの処理を開始します。

Finesse サーバは、CTI サーバのクライアントです。Desktop サーバは、CTI サーバではなく、フェールオーバー中にエージェントの状態を維持します。CTI サーバに障害が発生すると、Finesse はエージェントデスクトップを一部無効にします。場合によっては、フェールオーバーが完了した後にエージェントは再サインインする必要があります。

Note	アクティブな CTI サーバにクライアントが接続されていない場合、事前設定された期間後、メカニズムが強制的にフェールオーバーを実行します。このフェールオーバーは、CTI クライアントがアクティブな CTI サーバに接続するのを妨げる偽の誤った理由を分離します。

音声応答装置（VRU）PG に障害が発生した場合、進行中のコールや Unified CVP にキューに入ったコールはドロップされません。音声ゲートウェイの存続可能性 TCL スクリプトは、使用可能な場合、コールをセカンダリ Unified CVP または SIP ダイヤルプラン内の番号にリダイレクトします。

フェールオーバー後、冗長 VRU PG は、Unified CVP に接続され、新しい通話の処理を開始します。障害が発生した VRU PG サイドが復旧すると、現在実行中の VRU PG がアクティブ VRU PG として稼働し続けます。冗長 VRU PG を使用すると、Unified CVP がアクティブキューポイントとして機能したり、コール処理を提供したりできます。

Administration および Data サーバは、構成およびスクリプト変更を行うシステムにユーザインターフェイスを提供します。サーバは、Web ベースのレポートツールとインターネット スクリプト エディタをホストすることもできます。他の Unified CCE コンポーネントとは異なり、Administration および Data サーバは冗長ペアで動作しません。このサーバの機能に冗長性を提供する場合は、設計にさらに Administration および Data サーバを含めます。ただし、自動フェールオーバーの動作はありません。

Administration および Data サーバは、リアルタイム ディストリビュータを介したルータからの Unified CCE 全体からリアルタイムでデータのフィードを受けます。同じサイトに Administration および Data サーバがいくつかある場合、1 つの管理者サイトにリアルタイム ディストリビュータを構成できます。管理者サイトには、プライマリ ディストリビュータと 1 つ以上のセカンダリ ディストリビュータがあります。プライマリ ディストリビュータはルータに登録し、ルータからのネットワーク全体でリアルタイムにフィードを受信します。セカンダリ ディストリビュータは、リアルタイム フィードのソースとしてプライマリ ディストリビュータを使用します。この調整により、ルータがサポートするリアルタムフィードの数を軽減し、帯域幅をご存します。

プライマリ リアルタイム デスクトップに障害が発生した場合、次の図で示すとおり、セカンダリ リアルタイム ディストリビュータは、リアルタイムフィードのルータに登録します。プライマリまたはセカンダリ Administration および Data サーバに登録できない管理クライアントは、ディストリビュータがリストアされるまで、タスクを実行できません。

電解によっては、Administration および Data サーバは、 Unified CCMP のインターフェイスもホストします。このような展開では、Administration および Data サーバがダウンした場合、どちらのツールを使用して行われた構成編網もインターフェイスに渡されません。

Live Data サーバは、コールドアクティブまたはスタンバイ モードで動作します。いつでもアクティブにできるのは、1 つの Live Data サーバのみです。もう 1 つの Live Data サーバはスタンバイ状態です。スタンバイの Live Data サーバは、アクティブなサーバのステータスを絶えずモニタしています。アクティブなサーバに障害が発生すると、スタンバイのサーバが引き継ぎ、アクティブになります。障害のあるサーバは、サービスを提供する準備ができたらスタンバイサーバになります。

重み付けアルゴリズムにより、次の 2 つのシナリオでアクティブな Live Data サーバを決定します。

シナリオ 1：両方の Live Data サーバが同時に起動すると、サーバは、ルータと同じデバイスの過半数の計算を使用します。

シナリオ 2：アクティブな Live Data サーバは、一部の PG に対する接続を失う場合があります。スタンバイサーバはその切断を検出します。2 分間アクティブサーバよりも 130% PG多い場合、アクティブステータスを想定するように要求します。スタンバイサーバがアクティブサーバになり、以前アクティブだったサーバがスタンバイサーバになります。

ダイヤラは、カスタマーのレコードの中間ステータスで、キャンペーン マネージャを更新します。これにより、ダイヤラが失敗した場合に、キャンペーン マネージャは次のアクションを追跡できます。

ダイヤラが SIP Invite を送信してカスタマーにコールすると、キャンペーン マネージャにカスタマーレコードの状態更新メッセージが送信されます。その後、キャンペーン マネージャは、[ダイヤリングリスト（DL）（DialingList (DL)] テーブルで、レコードの CallStatus を [ダイヤル済み（Dialed）] 状態に更新します。

また、キャンペーン マネージャは、次のイベントでカスタマーレコードの状態を更新します。

• 通話に成功: キャンペーン マネージャは、カスタマーレコードを [終了（Closed）] 状態に更新します。

• ダイヤラとキャンペーン マネージャ間の接続に失敗：すべての [ダイヤル済み（Dialed）] 状態のレコードは、[ダイヤル済み（Dialed）] 状態のままになります。アクティブ状態レコードが [不明（Unknown）] 状態に変わります。

• ダイヤラと CTI サーバ間の接続に失敗：キャンペーン マネージャは、カスタマーレコードを [終了（Closed）] 状態に更新します。次に、キャンペーン マネージャは、ダイヤラ切断状態を送信すると、すべてのアクティブ状態のレコードは、[不明（Unknown）] 状態となります。[ダイヤル済み（Dialed）] 状態のレコードは、[ダイヤル済み（Dialed）] 状態のままになります。

• ダイヤラと SIP ゲートウェイ（GW）間の接続に失敗：エージェントデスクトップからコールがリリースされると、キャンペーン マネージャは、[終了（Close）] 状態のカスタマー レコード メッセージを受信します。この状況の場合、エージェントデスクトップからコールがリリースされると、すべての [ダイヤル済み（Dialed）] 状態レコードが [終了（Closed）] 状態に変化します。アクティブ状態レコードが [不明（Unknown）] 状態に変わります。

• ダイヤラと MR PIM 間の接続に失敗：キャンペーン マネージャは、接続状態のダイヤラ ステータス メッセージのみを受信します。[終了（Closed）] のカスタマー レコード メッセージを受信したら、レコードが [終了（Closed）] 状態に更新されます。

• キャンペーン マネージャが失敗した場合：すべての [ダイヤル済み（Dialed）] 状態のレコードが、[終了（Closed）] 状態に変わります。アクティブ状態レコードが [不明（Unknown）] 状態に変わります。