この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
Unified CCX サーバ間の最大許容ラウンドトリップ時間(RTT)は、80 ミリ秒です。
(注) | 正確な結果が得られないので、Unified CCX サーバで ping ユーティリティを使用して RTT を確認しないでください。ping は、ベストエフォート型のパケットとして送信されます。WAN トラフィックと同じ QoS 対応パスを使用して転送されません。したがって、遅延を確認するには、Unified CCX サーバに最も近いネットワーク デバイスを使用してください。サーバが接続されているアクセス スイッチを使用するのが理想的です。Cisco IOS は拡張 ping を備えています。この ping は、WAN トラフィックが通過するのと同じ QoS 対応パスで ping パケットが送信されるように、レイヤ 3 タイプのサービス(ToS)ビットを設定できます。拡張 ping によって記録される時間は、ラウンドトリップ時間(RTT)、つまり通信パスを通過して戻るのに要する時間です。詳細については、次の URL にある Cisco IOS のマニュアルを参照してください。 |
WAN 上に HA を配置するには、Unified CCX クラスタ、Unified CM クラスタ、リモート Cisco Finesse ユーザおよび他のオプションのコンポーネントに対して十分な帯域幅をプロビジョニングする必要があります。
次のコンポーネントに必要な帯域幅を把握してください。
Unified CCX クラスタと Unified CM クラスタ
Unified CCX クラスタは、ハイ アベイラビリティ配置の Unified CCX サーバ間で帯域幅を消費します。Unified CCX が通信する CTI Manager を実行している Unified CM がリモートである場合は、Unified CCX によってさらに帯域幅が使用されます。
Unified CCX と共に配置した場合、Unified CM は、サイト間のクラスタ内通信シグナリング(ICCS; Intra-Cluster Communication Signaling)用に非常に大量の帯域幅を消費する可能性があります。これは、クラスタ内通信にはさらに多くのコール リダイレクトと CTI/JTAPI 通信が含まれていることに起因します。
Unified CCX を ACD として配置すると、応答可能なエージェント用のコンタクトをルーティングしてキューに入れることができます。また、IP-IVR として配置してセルフサービスを実行させることもできます。Unified CCX クラスタと Unified CM クラスタの帯域幅要件は、配置タイプによって異なります。
Unified CCX クラスタ |
Unified CM クラスタ |
|||
---|---|---|---|---|
展開タイプ |
Unified CCX サーバ間 |
Unified CCX とリモート Unified CM サーバ間 |
データベース1 |
ICCS |
ACD |
1.2 Mbps |
800 kbps |
1.544 Mbps(T1) |
70 kbps/100 BHCA2 |
IP-IVR |
1.2 Mbps |
200 kbps |
1.544 Mbps(T1) |
100 BHCA あたり 25 kbps |
たとえば、WAN 上の Unified CCX HA 配置に 2 つのサイトがあり、この配置が ACD として使用されている場合を想定してください。サイト 1 には、Unified CCX、1 つの Unified CM パブリッシャ、2 つの Unified CM サブスクライバがあります。サイト 2 には、別の Unified CCX と 2 つの Unified CM サブスクライバがあります。サイト 1 の Unified CCX は、サイト 2 の JTAPI シグナリング用の Unified CM サブスクライバと通信します。ビジー時間中は、1500 コールが Unified CCX に着信し、それらはエージェント用にルーティングされてキューに格納されます。
(注) |
Unified CCX クラスタの場合、必要な帯域幅は次のとおりです。
1.2 Mbps + 800 kbps(0.8 Mbps) = 2 Mbps
Cisco Unified CM クラスタの場合は、Unified CM パブリッシャのリモートとして 2 の Unified CM サブスクライバがあり、BHCA は 1500 です。必要な帯域幅は次のとおりです。
1.544 Mbps × 2 + 70 kbps × 15(1.05 Mbps) = 4.138 Mbps
この配置では、サイト間で合計 6.138 Mbps が必要です。
エージェントおよびスーパーバイザ
WAN 上の HA 配置では、エージェントとスーパーバイザは、操作時にアクティブになっている Unified CCX サーバの場所に応じて、Unified CCX サイトまたはリモート サイトにいます。2 つのサイトのエージェントの最大数を使用して、サイト間のリモート エージェント用の帯域幅をプロビジョニングする必要があります。次の URL にある Cisco Finesse Agent Desktop Bandwidth Calculator を使用して、必要な帯域幅を見積もってください。
オプション コンポーネント
Finesse の帯域幅を計算するには、次の URL にある『Finesse Bandwidth Calculator for Unified Contact Center Express』を参照してください。
一貫した予測可能なエンドツーエンド レベルのサービスを実現するには、ネットワーク上で Quality of Service(QoS)を有効にして正確に設計する必要があります。Unified CCX ソフトウェアはネットワーク パケットをマーキングしないので、ネットワーク エッジ ルータでトラフィックをマーキングしてください。
トラフィック |
推奨する QoS マーキング |
---|---|
JTAPI コール シグナリング |
IP Precedence 3(DSCP 24 または PHB CS3) |
Unified CM ノード間のデータベース レプリケーション3 |
IP Precedence 0(DSCP 0 または PHB BE) |
VoIP の QoS 要件の詳細については、次の URL にある『Enterprise QoS Solution Reference Network Design Guide』を参照してください。
各 Unified CCX サイトに ASR または TTS サーバをローカルに配置します。
次の構成でプライマリおよびセカンダリの両方にローカル Unified CM サーバを使用するように Unified CCX をセットアップします。これが不可能な場合は、少なくともプライマリ Unified CM サーバがローカルである必要があります。
AXL サービス プロバイダー
Unified CM Telephony サブシステムの JTAPI プロバイダー
Resource Manager/Contact Manager サブシステムの JTAPI プロバイダー
(注) | AXL と JTAPI の通信が WAN を介して行われる場合は、特に負荷状況下で、Unified CCX フェールオーバー中にエージェントのログインが大幅に遅延します。 |
CTI ポート グループで、異なるデバイス プール、領域、場所に 2 セットの CTI ポートを割り当てます(一方はマスター エンジン用、もう一方はスタンバイ エンジン用)。
ネットワーク分割の復元後、IDS Informix データベースの、履歴データストア、およびリポジトリ データストアのデータがマージを開始します。このような状況では、WAN 上でデータ トラフィックの混雑が生じることがあります。営業時間外に WAN リンクを復元して、パフォーマンスへの影響を最小限に抑えてください。
WAN を介した VPN トンネリングをサポートしないでください。
Cisco Finesse は、LAN および WAN を介したシングル ノード配置とハイ アベイラビリティ配置の両方でサポートされます。
LAN 配置では、Unified CCX は以下をサポートします。
WAN 上に離れた 2 つのサイト(サイト A とサイト B)があると想定してください。WAN 上の 1 つの Unified CCX HA クラスタは次をサポートします。
詳細については、次の URL で入手可能な『Cisco MediaSense Design Guide』を参照してください。
Unified Communications Manager に到着する Unified CCX ルート ポイント宛の着信コールはすべて、Unified CCX エンジンで受け入れられ、すべての Unified CCX コール処理と、ACD ルーティング サービスが動作可能になります。
(注) | すべてのエージェントは、フェールオーバー中の 5 分以内に再ログインする必要があります。 |
フェールオーバーが発生した場合は、自動ログイン プロセスが完了して、エージェントが手動で状態を「受信可」に設定するまで、ACD サブシステムはエージェントへのコールをルーティングできません。Unified CCX でルーティングされたコールのエージェントにはこれらのコールが継続しているものと表示され、Finesse は自動的にエージェントを再ログインさせます。再ログイン後、エージェントはコール受信を開始できる準備が整ったときに、状態を「受信可」に設定する必要があります。
マスター エンジンがダウンすると、他のノードのエンジンが新しいマスターとして選択されます。前のマスター エンジンで処理中だった、エージェントに未転送のコールは破棄されます。エージェントの再ログイン中に新たに着信したコールは、エージェントがログインするまでキューに格納されます。履歴データは新しいマスター エンジンのローカル データベースに書き込まれます。
アクティブ サーバの HA 障害が検出されると、ACD サブシステムは、アクティブ サーバからスタンバイ サーバに自動的にフェールオーバーできます。すべての ACD 機能は 5 秒以内にスタンバイ サーバ上に復元されます。
HA システムでアクティブ サーバに障害が発生すると、IVR サブシステムが自動的にフェイルオーバーします。
キュー内のコールと IVR コール処理を受信するコールはすべて失われます。すでにエージェントに転送されたコールは保持されます。
アウトバウンドの通常操作で、コンタクト レコードのコールの状態とコールの結果を更新するには、Config Data Store(CDS)が必要です。2 ノードのハイ アベイラビリティ システムに配置する場合、データベースへの書き込み操作を有効にするには、両方のノードで CDS を実行する必要があります。アウトバウンド サブシステムは、パブリッシャ CDS が起動して稼働している限り、動作可能です。ハイ アベイラビリティ環境では、マスター ノードのダイヤラだけがアクティブになります。
コンタクトがダイヤル発信される前に、そのコンタクトがキャンペーン用にインポートされ、フェールオーバーが発生した場合、コンタクトは翌日再試行されます。各キャンペーンに対して再試行可能なコンタクトの数は以下のとおりです。
予約状態ではないプレビュー アウトバウンド コールがエージェントによるコールの受け入れを待っているときに、マスター エンジンがダウンすると、エージェントは自動的にログアウトされ、プレビュー コールはエージェント デスクトップから消えます。フェールオーバー中にマスター エンジンが再起動すると、コンタクト レコードのコールの状態は「不明」に設定されます。フェールオーバー中にマスター エンジンが再起動しなかった場合、キャンペーンが開始され、対応可能なエージェントが現れると、コンタクトがコールされます。
予約状態ではないプレビュー アウトバウンド コールがエージェントによって受け入れられ、コールがカスタマーの電話を呼び出した場合、コールに変化はありません。ただし、エージェントはログアウトされ、電話でしかコール制御機能を使用できなります。
エージェントがプレビュー アウトバウンド コールに対応中に、マスター エンジンがダウンすると、エージェントは自動的にログアウトされ、自動的にログイン状態に戻ります。エージェントの状態は「受信不可」になります。カスタマーがまだコールに対応している場合、エージェントはコール処理を続行しますが、エージェント デスクトップでアウトバウンド固有のオプションを使用できなくなります。
コールがエージェントに転送される前に、エージェントがアウトバウンド キャンペーン用に予約され、マスター エンジンがダウンすると、エージェントは自動的にログアウトされます。ダイヤル発信されるコンタクトが存在し、まだエージェントに接続されている場合、そのコンタクトは終了されます。
エージェントがバウンド コールに対応中に、マスター エンジンがダウンすると、エージェントは自動的にログアウトされ、自動的にログイン状態に戻ります。エージェントの状態は「受信不可」になります。カスタマーがまだコールに対応している場合、エージェントはコール処理を続行しますが、エージェント デスクトップでアウトバウンド固有のオプションを使用できなくなります。
エージェントがアウトバウンド コール対応中に、Cisco Finesse サービスが再起動するか、エージェントがブラウザを終了して再度開くと、60 秒後に自動的にエージェントのログインが行われ、エージェントの状態は「受信不可」になります。カスタマーがまだコールに対応している場合、エージェントはコール処理を続行しますが、エージェント デスクトップでアウトバウンド固有のオプションを使用できなくなります。
接続障害によって「アイランド モード」と呼ばれる状況が発生します。この状況では、(ネットワークのそれぞれの側の)各ノードがマスターシップを引き継ぎ、コールを処理します。各ノードはもう一方の側で障害が発生したかのように動作し、マスター(エンジンおよびデータ ストア コンポーネント)であることを宣言します。すでにマスターであるノードはその状態を継続します。電話機と Finesse をネットワークの同じ側にある Unified CM とサーバに登録する必要があります。この処理は自動的に行われます。フェールオーバー動作は次のとおりです。
アイランド モードの発生が 4 日間以上続いた場合、ノード間のデータベース レプリケーションは中断され、WAN リンクが回復した際に Unified CCX Administration Web インターフェイスから再確立する必要があります。
(注) | バックアップ スクリプトはパブリッシャで実行され、マスターシップを持つデータベースをバックアップします。アイランド モードでは、1 つのノードのみがバックアップされ、他のノードで収集されたデータはバックアップされません。このバックアップには不整合があり、復元するとデータは失われます。 |
ネットワーク接続が回復すると、エンジンのマスターシップのコンバージェンスが発生します。2 つのマスターは共存できないため、ノードの一方がマスターシップを放棄します。そのノードで処理されているアクティブ コールはすべて破棄され、そのノードにログインしているエージェントはログアウトされます。
同様に、コール アクティビティを中断することなく、データ ストアのコンバージェンスが行われます。所定のレプリケーション保存期間内にリンクが回復した場合にのみ、コンバージェンスの実行直後にすべてのデータが複製されます。それ以外の場合は、カスタマーが [データストアコントロールセンター(Datastore Control Center)] ページからレプリケーションを初期化する必要があります。
ヒント | Unified CCX Administration の [データストアコントロールセンター(Datastore Control Center)] ページまたは CLI を使用して、レプリケーションの状態を検査できます。 |
WAN がダウンすると、WAN を介して Unified CM Sub 1 で提供された CTI 機能を使用できなくなります。ノード 2 上のマスター エンジンは、Unified Communications Manager Sub 2 にフェールオーバーします。キュー内のコールはすべて終了されます。エージェントは再ログインする必要はありません。
一部のエージェントは「受信不可」状態のままになります。これは、対応するエージェントの電話が Unified Communications Manager Sub 1 に登録されているからです。電話を強制的に再登録する自動機能はありません。
この状況は、WAN が正常な状態に戻ると修正されます。
ハイ アベイラビリティ配置では、アクティブ サーバの障害を検出でき、非音声サブシステムはアクティブ サーバからスタンバイ サーバに自動的にフェールオーバーできます。未応答のチャットはすべて新しいアクティブ サーバに移動されます。
アクティブなチャット セッションは、ブラウザがスタンバイ サーバにリダイレクトされるまで使用できます。チャット セッションは、リダイレクトの完了後に終了し、「チャットが終了しました(The Chat has Ended)」というメッセージが表示されます。エンジンのフェールオーバー中は、エージェントに「機能が停止しているためチャットと電子メールが一時的にダウンしています(Chat and Email are temporarily down due to Outages)」というメッセージが表示されます。チャットでは、キューに入れられたすべての連絡先が破棄されますが、電子メールでは、キューに再入力されます。
Unified CCX は Web チャットに耐障害性を提供します。HA 配置では、SocialMiner は両方の Unified CCX ノードと通信するように設定されます。SocialMiner に新しいコンタクトが到着すると、両方の Unified CCX ノードに通知されます。
フェールオーバーが発生すると、キューに格納されていた電子メールやエージェントに割り当てられていた電子メールはすべて、キューに再び格納され、エージェントに割り当てられます。
Cisco SocialMiner は、HA 配置オプションをサポートしていません。チャットや電子メールは、SocialMiner がダウンすると使用できなくなります。
(注) | Web チャットおよび電子メールは、アイランド モードのシナリオをサポートしていません。 |
ここでは、Unified CCX のフェールオーバー時における Cisco Finesse のアクションについて説明します。
Cisco Finesse のクライアントは、Cisco Finesse が他のサーバで IN_SERVICE 状態であることを確認しない限り、他のサーバへのリダイレクトを完了しません。その時点までに障害側が復旧した場合、クライアントは自動的にそれに再接続します。
次の表は、ハイ アベイラビリティ配置で発生する可能性がある障害を示しています。
障害シナリオ |
フェールオーバー |
Unified CCX の状態 |
Cisco Finesse サイト A の状態 |
Cisco Finesse サイト B の状態 |
Cisco Finesse クライアントの動作 |
リカバリ |
---|---|---|---|---|---|---|
サイト A とサイト B の間の接続が切断(アイランド モード)。 |
いいえ |
サイト A とサイト B の両方がマスターになります。 |
IN_SERVICE |
IN_SERVICE |
クライアントは両方のサイトに接続して動作できます。 |
接続が再確立されると、Unified CCX はプライマリ ノードをマスターとします。マスター以外のノードに接続しているクライアントはリダイレクトされます。 |
アクティブ ノードがダウン(サイト A)。 |
はい |
サイト B がマスターになります。 |
OUT_OF_SERVICE |
IN_SERVICE |
クライアントはサイト B に接続して動作できます。 |
接続が再確立されると、プライマリ ノードがマスターになります。サイト B ノードに接続しているクライアントは、サイト A にリダイレクトされます。 |
Finesse デスクトップとは異なり、Finesse IP Phone Agent では代替 Finesse サーバに自動的にフェールオーバーしません。障害時にも確実に運用が継続されるようにするために、それぞれが異なる Finesse サーバを指す少なくとも 2 つの Finesse IP Phone サービスを Unified CM に設定する必要があります。
Finesse サーバに障害が発生すると、Finesse IPPA は 5 秒ごとにサーバへの再接続を試行します。3 回試行して Finesse サーバが稼働していない場合、Finesse IPPA はサーバ利用不能メッセージをエージェントに表示します。サービス停止までの合計時間は約 15 秒です。
障害が発生した場合は、Finesse IPPA エージェントの現在の Finesse サービスを終了し、代替 Finesse サーバを指す別の設定済み Finesse サーバに手動でサインインする必要があります。エージェントは、代替 Finesse サービスに正常にサインインした後、通常の動作を再開できます。
2 ノードのハイ アベイラビリティ(HA)セットアップでは、任意のノードに接続してレポートにアクセスできます。接続先のノードがダウンした場合は、他のノードに手動でログインしてレポートにアクセスしてください。これは自動的に行われません。
WAN がダウンすると、ノードはアイランド(island)モードで動作し、両方のノードがそれぞれマスターシップ(エンジンとデータ ストア コンポーネント)を引き継ぎます。ノードのいずれかからレポートにアクセスできます。
(注) | 接続が復元されるまでノード間のデータ レプリケーションは行われないため、レポートでデータの不一致が生じます。 |
Contact Center Enterprise ソリューションには複数の MediaSense レコーディング サーバを設定できます。これらのサーバは、すべてが同時にアクティブになり、自動的に負荷を分散します。サーバのいずれかで障害が発生した場合、着信コールはサーバが復旧するまで送信されません。
サーバで障害が発生した場合は、アクティブ コールの録音がすべて破棄されます。録音が完了しているコールはサーバが復旧するまで使用できません。
MediaSense には、メタデータ データベース サーバの冗長ペアもが含まれています。データベースは同期状態を保ちます。一方のデータベース サーバで障害が発生した場合は、もう一方のサーバが引き続きすべてのイベントを録音します。一方のサーバが復旧すると、データ レプリケーション プロセスによってデータベースが同期状態に戻ります。
Cisco SocialMine はハイ アベイラビリティをサポートしていません。SocialMiner 冗長サーバを導入しないでください。SocialMiner は、Contact Center Enterprise ソリューションの他のコンポーネントと直接統合されません。
SocialMiner は、小規模または大規模な単一サーバのオールインワン展開を使用します。ロード バランシング スプリット データセンター展開を使用することはできません。
スケジュールされたバックアップで SocialMiner VM を 2 番目の場所にバックアップします。その VM が失敗した場合は、バックアップから SocialMiner を復元ができます。
ソリューションでは冗長 ASR/TTS サーバを配置する必要があります。基本的な構成では、VXML ゲートウェイは最初に、すべての着信要求をプライマリ ASR/TTS サーバに渡します。プライマリ サーバに到達できない場合、ゲートウェイはバックアップ サーバに要求を渡します。バックアップ サーバに到達した要求は、その存続期間までサーバに留まります。
ロード バランサを追加することにより、着信する要求を ASR/TTS サーバ全体に分散することができます。
Cisco VVB は、冗長性に対してアクティブおよびバックアップの ASR/TTS サーバを使用しません。VVB には、ラウンドロビン方式でサーバのリストから選択するロード バランシング機能が組み込まれています。
選択した音声サーバが MRCP セッションのセットアップ要求を拒否した場合、VVB はもう一度、別のサーバで MRCP セッションのセットアップを試みます。