この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
システムのパフォーマンスおよびスケーラビリティを最適化するには、Cisco Unified Contact Center Enterprise(Unified CCE)ソリューションを適切にサイジングすることが重要です。 サイジングに関する考慮事項には、ソリューションでサポート可能なエージェント数、Busy Hour Call Attempt(BHCA; 最頻時発呼数)の最大数、および配置をサポートするために必要なサーバの数、タイプ、および設定に影響を与えるその他の変数などがあります。 選択された展開モデルに関係なく、Unified CCE は高度な分散アーキテクチャをベースとしており、キャパシティ、パフォーマンス、およびスケーラビリティに関する問題はソリューション全体だけでなく、ソリューション内の各要素にも適用されます。
この章では、Unified CCE の展開におけるスケーラビリティおよびキャパシティに関する最適な設計方法について説明します。 この章に記載されている設計時の考慮事項、ベスト プラクティス、およびキャパシティは、原則としてテスト結果に基づいて導き出されたものです。それ以外では、テスト データを基にした推定から導き出されています。 この情報の目的は、ユーザが Unified CC ソリューションを適切にサイジングして、プロビジョニングできるようにすることです。
このセクションでは、次の Unified CC のサイジングに関する考慮事項について説明します。
• 「操作条件」
• 「HDS および WebView レポーティング付きの AW ディストリビュータ」
Unified CC の展開のサイジングを行う場合、Cisco Unified Communications コンポーネントはキャパシティ計画での重要な要素です。 多量のコール負荷をサポートするには、複数の Cisco Unified CallManagers およびクラスタなどを適切に設計する必要があります。 Cisco Unified CallManager のキャパシティおよび Cisco Unified Communications コンポーネントのサイジングの詳細については、「Cisco Unified CallManager 4.x および 5.x サーバのサイジング」、および次の URL にある『 Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) 』の最新バージョンを参照してください。
また、さまざまなエージェントおよびスキル グループ キャパシティがあるため、CTI OS および Cisco Agent Desktop サーバの適切なサイジングは、Cisco Unified Communications コンポーネントと組み合わせて検討する必要があります。
最後に、残りの Unified ICM コンポーネントは、高度なスケーラビリティを実現する一方、システム リソースにも作用する特定の設定要素のサイジング変数の影響を受けます。
このセクションに記載されているこれらの要因は、どのような展開計画においても必ず考慮して計画に反映する必要があります。
図8-1、図8-2、および 表8-1 に示されている情報は、Unified CC のすべての実装に等しく適用されるわけではありません。 データは特定のシナリオでのテストに基づくものですが、適用にあたってはあくまでも参考資料として位置付け、この章の他のサイジング情報と同様に変化するという点に注意してください。 サイジングは常に慎重に行い、拡張に備えた計画を立てる必要があります。
(注) サイジングに関する考慮事項は、キャパシティおよびスケーラビリティのテスト データに基づいています。 主要な Unified ICM ソフトウェア プロセスは各サーバ上で動作し、それぞれの CPU、メモリ、およびその他の内部システム リソースの利用状況を計測しました。 共存するソフトウェア プロセスおよび複数の CPU サーバのキャパシティを算出する場合は、合理的な推論が使用されていました。 この情報は、どのような場合には単一サーバ内で複数の Unified ICM ソフトウェア プロセスが共存でき、別のどのような場合には特定のプロセスが専用サーバを必要とするのかを判別するときに役立ちます。表8-1 では、二重化して展開されている 2 つの完全冗長サーバを含む展開シナリオを想定しています。 理論上は、非冗長展開の方が大きなキャパシティを得ることができますが、この理論を検証するための独立したテストは実行されていません。 したがって、シンプレックス展開およびデュプレックス展開に関するサイジング情報については、表8-1 を参照してください。
(注) Cisco Unified Contact Center ソリューションには、現時点でクワッドプロセッサを備えた Cisco MCS Unified CallManager アプライアンスは含まれていません。 次の表に記載されている制限を超えるパフォーマンスが必要な場合は、MCS-40-003-Class の代わりに、市販のクワッドプロセッサ サーバ(GEN-50-00x-Class)を使用できます。最新のサーバ仕様については、次の URL にある『Cisco ICM/IPCC Enterprise and Hosted Editions ハードウェア及びシステムソフトウェア スペック(製品構成表-BOM)Release 7.0(0)』の最新バージョンを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/icm/ccbubom/index.htm.
この章で説明するサイジング情報は、次の操作条件に基づいています。
• エージェントあたり最大 30 の Busy Hour Call Attempts(BHCA; 最頻時発呼数)
• チーム メンバーはエージェントが 90 % とスーパーバイザが 10 % で構成
• コール タイプは、直通が 85 %、コンサルテイティブ転送が 10 %、およびコンサルテイティブ会議が 5 % で構成
• CTI OS サーバに設定するスキル グループ統計情報列のデフォルト数は 17 列
• CTI OS サーバに設定する統計情報エージェント列のデフォルト数は 6 列
• IVR コールごとに平均 5 つの実行 Voice Response Unit(VRU; 音声応答装置)スクリプトを Unified ICM スクリプト内で連続動作
• Extended Call Context(ECC)変数なし
• CTI OS の[Transport Layer Security(TLS)] はオフ
• エージェント数は、ログインしたエージェント数を示しています。
–APG = Agent Peripheral Gateway
図8-1 一般的な Unified CC 展開に必要な最小限のサーバ(CTI OS Desktop の場合)
図8-1 には、次の注が適用されます。
• サイジングは、MCS-40-003-Class サーバおよび「操作条件」にリストされている情報を前提としています。
• Voice Response Unit(VRU; 音声応答装置)、Historical Data Server(HDS)、および Cisco Unified CallManager の各コンポーネントは表示していません。
• 詳細は、「ペリフェラル ゲートウェイおよびサーバ オプション」を参照してください。
(注) この章では、Rogger とセントラル コントローラの 2 つの用語を同じ意味で使用しています。
図8-2 一般的な Unified CC 展開に必要な最小限のサーバ(Cisco Agent Desktop の場合)
図8-2 には、次の注が適用されます。
• サイジングは、MCS-40-003-Class サーバおよび「操作条件」にリストされている情報を前提としています。
• Voice Response Unit(VRU; 音声応答装置)、Historical Data Server(HDS)、および Cisco Unified CallManager の各コンポーネントは表示していません。
• 詳細は、「ペリフェラル ゲートウェイおよびサーバ オプション」を参照してください。
(注) Cisco Agent Desktop(CAD)のキャパシティ数はデスクトップ エージェントだけを前提としています。 CAD Unified IP Phone エージェントを使用するとキャパシティは 50 % 低下します。
|
|
|
|
|
---|---|---|---|---|
アドミン ワークステーション(AW)または Historical Data Server(HDS)と共存できません。 Progger 設定では、MCS-30-003-Class サーバで Cisco Unified Outbound Dialer および CAD はサポートされていません。 共存するダイヤラを使用している場合、 共存する Cisco Agent Desktop サーバおよびダイヤラを使用している場合、MCS-40-003-Class サーバのエージェント数は最大 35 です。 |
||||
|
|
Agent PG の設定オプションの詳細については、図8-3 および図8-4 を参照してください。 VRU ポート数は、[Maximum Agents] 列に示されるサポートされているエージェントの最大数の半数以下である必要があります。 追加の VRU PG を展開すると、収容できる VRU ポート数を増やすことができます。 各 Agent PG 展開オプションの詳細については、「ペリフェラル ゲートウェイおよびサーバ オプション」を参照してください。 |
||
Agent PG のダイヤラをオフにしても、サイジングは向上しません。 この計算を使用して、すべてのエージェントをブレンドできます(すべてのエージェントがアウトバウンド コールを受信できます)。 |
||||
Media Routing(MR; メディア ルーティング)PG を共存させるには、MCS-40-003-Class サーバが必要です。キャパシティ値については、この表の次の行を参照してください。 |
||||
MCS-40-003-Class サーバでは、この表の |
||||
• シングルセッション チャット: 250 のエージェントおよび 250 の発信者 |
||||
エージェント 10 名未満: すべての Cisco Email Manager コンポーネントおよびデータベースが単一サーバ上で共存します(MCS-40-003-Class)。 エージェント 250 名まで: 2 台のサーバ。最初のサーバに Cisco Email Manager AppServer、UI Server、および WebView、2 番目のサーバにデータベース サーバ(プライマリ、LAMBDA、および CIR データベース)。 エージェント 500 名まで: 4 台のサーバ。最初のサーバに Cisco Email Manager AppServer、2 番目のサーバに Cisco Email Manager UI Server(1 番目)および WebView サーバ、3 番目のサーバに Cisco Email Manager UI Server(2 番目)、4 番目のサーバにデータベース サーバ (このシナリオでは、MCS-30-003-Class を 2 番目の UI Server ボックスに使用できます)。 エージェント 1000 名まで: 7 台のサーバ。最初のサーバに Cisco Email Manager AppServer(クワッド プロセッサを推奨)、2 番目のサーバに Cisco Email Manager UI Server(1 番目)および WebView サーバ、3 番目のサーバに Cisco Email Manager UI Server(2 番目)、4 番目のサーバに Cisco Email Manager UI Server(3 番目)、5 番目のサーバに Cisco Email Manager UI Server(4 番目、エージェント数が 750 を超える場合に必要)、6 番目のサーバにデータベース サーバ(プライマリおよび LAMDA)、7 番目のサーバにデータベース サーバ(CIR) (このシナリオでは、 最新のサイジング情報については、次の URL にある『 Cisco ICM/IPCC Enterprise and Hosted Editions ハードウェア及びシステムソフトウェア スペック (製品構成表-BOM) Release 7.0(0) 』の最新バージョンを参照してください。 |
||||
Cisco Unified Customer Voice Portal(Unified CVP)アプリケーション サーバおよび音声ブラウザ |
Unified CVP の最新のサーバ仕様については、次の URL にある『 Cisco Unified Customer Voice Portal Software Release 3.0(0) Bill of Materials 』の最新バージョンを参照してください。 |
|||
最新の Unified IP IVR サーバの仕様については、次の URL にある『 Cisco Unified CCX and Unified IP IVR Configuration and Ordering Tool 』を参照してください。 |
HDS および WebView レポーティング付きの AW ディストリビュータをサイジングするときは、次の制限を確認する必要があります。
• 各 Router/Logger のペアで最大 2 つの HDS 付き AW ディストリビュータをサポートできます。
• WebView は個別のサーバに展開するか、または HDS 付き AW ディストリビュータと共存できます。
• WebView を個別のサーバに展開した場合、構成によっては、HDS 付き AW ディストリビュータごとに最大 4 台の WebView サーバをサポートします。
• 適切なハードウェアおよび構成では、各 WebView サーバで最大 50 のレポーティング ユーザをサポートできます。
• レポーティング ユーザは、次のことを実行するユーザとして定義されます。
–20 秒間隔でリフレッシュする 2 つのリアルタイム レポート
次の表は、レポーティング ユーザをサポートするために必要な HDS 付き AW ディストリビュータの最低数を示します。 レポートの展開によっては、リソースの割り当てを変更すると性能が向上することがあります。
|
||||||||
|
次のサイジング表は System Unified CC には適用されません。System Unified CC は 2 台を超える Historical Data Server をサポートしません。
|
||||||||
|
WebView および HDS サーバの最新のハードウェア仕様については、次の URL にある『 Cisco ICM/IPCC Enterprise and Hosted Editions ハードウェア及びシステムソフトウェア スペック (製品構成表-BOM) Release 7.0(0) 』の最新バージョンを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/icm/ccbubom/index.htm
ハードウェア要件およびキャパシティは、Unified CC 構成の数多くの変数および展開オプションによる影響を受けます。 このセクションでは、主要なサイジング変数と、それが各 Unified CC コンポーネントのキャパシティへ及ぼす影響について説明します。 また 表8-3 には、サイジング変数およびその影響が要約されています。
最頻時発呼数は重要なメトリックです。 BHCA が増加するとすべての Unified CC コンポーネントの負荷も増加し、特に Cisco Unified CallManager、Unified IP IVR、および Cisco Unified CallManager PG ではこの負荷が著しく増大します。 エージェントのキャパシティ値では、各エージェントの 1 時間ごとの最大コール数を 30 と想定しています。 エージェントごとに 1 時間あたり 30 を超えるスキル グループが必要な場合は Agent PG がサポートするエージェントの最大数も減少するため、ケースバイケースで対処する必要があります。
Cisco Unified CallManager クラスタを含むほとんどの Unified CC サーバ コンポーネントのパフォーマンスに影響を与える重要なもう 1 つのメトリックは、エージェント数です。 Cisco Unified CallManager コンポーネントのパフォーマンスに関するエージェントの影響については、「Cisco Unified CallManager 4.x および 5.x サーバのサイジング」を参照してください。
エージェントごとのスキル グループ数(システムあたりのスキルの総数とは無関係です)は、CTI OS サーバ、Agent PG、および Unified ICM Router や Logger に重大な影響を与えます。 エージェントごとのスキル グループ数は可能な限り 5 以下に制限し、未使用のスキル グループがもしあれば定期的に削除してシステム パフォーマンスの低下を防いでください。 また、統計情報の更新頻度の値を増やして、CTI OS サーバへの影響を管理することもできます。 表8-2 は、エージェントあたりのスキル グループ数が Unified CC システムのキャパシティに与える影響の例を示します。 表8-2 の値は、「操作条件」のセクションに示す情報に基づいています。
|
|
|
---|---|---|
スーパーバイサとチーム メンバーの数も、CTI OS サーバのパフォーマンスに影響を与える可能性があります。 エージェントとスーパーバイザを複数のチームに配布し、各スーパーバイザ モニタには少数のエージェントだけを展開することをお勧めします。
(注) スーパーバイザは、すべて同じペリフェラルで構成されている自分のチーム内のエージェントだけをモニタできます。
CTI OS モニタ モード アプリケーションが CTI OS サーバのパフォーマンスに影響を与えることがあります。 CTI OS がサポートするサーバ ペアあたりのモニタ モード アプリケーションは 2 つだけです。 指定されたフィルタによっては、CPU 使用率への影響によって Agent PG のパフォーマンスが低下する場合があります。
スキル グループ統計の更新間隔が、CTI OS サーバのパフォーマンスに影響を与えることもあります。 更新間隔に、デフォルト値の 10 秒より低い値を設定しないでください。
ほとんどの Unified CC サーバ コンポーネントのパフォーマンスに影響を与える重要なもう 1 つのメトリックは、コール タイプです。 転送および会議の数が増加するとシステムの負荷も増加し、キャパシティの合計は減少します。
Unified IP IVR はコールをキューに格納し、エージェントがコールに応答するまでアナウンスによる応答を行います。 サイジングを行う場合は、IVR がすべてのコールを最初に処理(コール処理)してから短いキューイング期間後に発信者をエージェントに転送するのか、またはエージェントがコールを最初に処理し、すべてのエージェントが使用中の場合の未応答のコールだけを IVR のキューに格納するのかの選択が重要になります。 この質問に対する回答に応じてさまざまな IVR サイジング要件が決定され、Unified ICM Router/Logger と Voice Response Unit(VRU; 音声応答装置)PG のパフォーマンスに影響が生じます。 必要な VRU ポート数を判断するには、Cisco IPC Resource Calculator を使用します (詳細は、「Cisco Unified CC Resource Calculator」を参照)。
Unified ICM スクリプトが複雑になったり個数が増えたりすると、Unified ICM Router および VRU PG のプロセッサやメモリのオーバーヘッドが著しく増加します。 この場合、実行 VRU スクリプトの再生間の遅延時間も影響を受けます。
リアルタイム レポーティングはデータベース アクセスを引き起こすため、Logger、Progger、および Rogger 処理に重大な影響を与えることがあります。 Logger、Progger、および Rogger のレポーティング オーバーヘッドを軽減するには、アドミン ワークステーション(AW)または Historical Data Server(HDS)にそれぞれ個別のサーバを提供する必要があります。
データベース クエリーなどの機能によって IVR スクリプトの複雑さが増すと、IVR サーバおよび Router の負荷も増大します。 Unified IP IVR で複雑なスクリプト、複雑なデータベース クエリー、またはトランザクションベース処理を使用する場合、パフォーマンスを特徴付ける有効な方法またはベンチマークは存在しません。 複雑な IVR 構成はラボまたはパイロット展開でテストし、さまざまな BHCA におけるデータベース クエリー応答時間、IVR サーバ、PG、Router のプロセッサおよびメモリに対する影響を判別することをお勧めします。
Unified IP IVR セルフサービス アプリケーション
展開された Unified IP IVR がセルフサービス アプリケーションにも使用される場合は、セルフサービス アプリケーションの負荷が Unified CC の負荷に追加されるため、 表8-1 に記載されているサイジング要件として考慮する必要があります。
サードパーティ データベースおよび Cisco Resource Manager の接続
すべての Unified CC ソリューション コンポーネントと外部デバイスまたはソフトウェアとの接続を慎重に調べて、ソリューションに対する全体的な影響を判別します。 Cisco Unified CC ソリューションは柔軟性が高くカスタマイズ可能ですが、複雑になる場合があります。 コンタクト センターは、ミッション クリティカルで収益に直結する、顧客と直接に対話するオペレーションとなることがしばしばです。 したがって、適切な経験および Unified CC に関する認定を取得しているシスコ パートナー(または Cisco Advanced Services)と、Unified CC ソリューションを設計することをお勧めします。
Extended Call Context(ECC; 拡張コール コンテキスト)
ECC を使用すると、PG、Router、Logger、およびネットワーク帯域幅に影響を与えます。 ECC は、さまざまな方法で設定および使用できます。 キャパシティに関する影響は設定した ECC によって異なるため、ケースバイケースで処理する必要があります。
Unified ICM Peripheral Gateway(PG; ペリフェラル ゲートウェイ)は、Cisco Unified CallManager サーバ、Unified IP IVR、またはその他のサードパーティ Automatic Call Distributor(ACD; 自動着呼分配装置)や Voice Response Unit(VRU; 音声応答装置)から着信したメッセージを Unified ICM で送信および認識される共通の内部形式メッセージに変換します。 反対に、ペリフェラル デバイスで送信および認識できるよう Unified ICM メッセージも変換します。
Peripheral Interface Manager(PIM; ペリフェラル インターフェイス マネージャ)は PG で動作するソフトウェア プロセスであり、メッセージの変換および制御を実行します。 Unified CC ソリューションに含まれている各ペリフェラル デバイスは、PG および PIM に接続する必要があります。
図8-3 および図8-4 に、CTI OS および Cisco Agent Desktop と Agent PG を併用した場合のさまざまな設定オプションを示します。 表8-3 に、PG および PIM のサイジングに関する推奨事項を示します。
図8-3 CTI OS を使用した場合の Agent PG の設定オプション
図8-4 Cisco Agent Desktop を使用した場合の Agent PG の設定オプション
|
|
---|---|
指定したサーバが 表8-1 に記載されているエージェントおよび VRU ポートの上限に従う場合は、サーバごとに最大 2 タイプの PG を使用できます。 |
|
Cisco Unified CallManager または Unified IP IVR から離れた場所に PG を展開できるかどうか |
|
次の URL にある『 Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) 』を参照してください。 |
|
Cisco Agent Desktop のコンポーネントおよびアーキテクチャの詳細については、「エージェント デスクトップおよびスーパーバイザ デスクトップ」を参照してください。
Cisco Agent Desktop CTI オプションのサーバ キャパシティは、エージェントの総数、Switched Port Analyzer(SPAN; スイッチド ポート アナライザ)のモニタリングおよびレコーディングを使用するかどうか、および同時レコーディング数によって変わります。
このセクションでは、次のインストール可能な Cisco Agent Desktop Server コンポーネントのサイジングに関するガイドラインについて説明します。
• 「Cisco Agent Desktop 基本サービス」
• 「Cisco Agent Desktop VoIP モニタ サービス」
• 「Cisco Agent Desktop 録音再生サービス」
Cisco Agent Desktop 基本サービスは、Microsoft Windows サービスとして動作する一連のアプリケーション サーバで構成されています。 この基本サービスには、チャット サービス、ディレクトリ サービス、エンタープライズ サービス、Unified IP Phone エージェント サービス、LDAP 監視サービス、ライセンスとリソース マネージャ サービス、録音と統計サービス、同期サービスが含まれます。 また、この基本サービスのサーバと同じコンピュータまたは異なるコンピュータに配置できるアプリケーション サーバもあります。 これらの追加アプリケーションは、VoIP モニタ サービス、録音再生サービスなどです。
単一インストールの場合も冗長インストールの場合も、Cisco Agent Desktop 基本サービスと追加アプリケーション サーバの組み合わせは、Logical Call Center(LCC; 論理コール センター)に相当し、1 つの PG ペアに関連付けられています。 表8-4 に、さまざまな規模の企業に対して単一の LCC がサポートできる最大エージェント数を示します。 示されているよりも多くのエージェントをサポートするには、追加の CAD サービス(LCC)をインストールして PG ペアを追加できます。
|
|
エージェントだけの場合 |
|
---|---|---|---|
VoIP モニタ サービスでは、サイレント モニタリングおよび録音機能を使用できます。 デスクトップ モニタリングの場合、VoIP モニタ サービスは Agent PG のスケーラビリティに関する設計ガイダンスに影響を与えません。 Switched Port Analyzer(SPAN; スイッチド ポート アナライザ)モニタリングを使用した場合は、最大 100 のエージェントに対して VoIP モニタ サービスを Agent PG と共存させることができます。 400 を超えるエージェントに対して Remote Switched Port Analyzer(RSPAN; リモート スイッチド ポート アナライザ)モニタリングおよび録音を使用する必要がある場合は、VoIP モニタ サービスを専用サーバ(MCS-30-003-Class サーバまたは同等サーバ)に展開する必要があります。 専用 VoIP モニタ サービスでは、最大 400 のエージェントをサポートできます。
録音再生サービスは、会話の録音データを保存して Supervisor Log Viewer アプリケーションで使用できるようにするものです。
CAD サーバと共存させる場合の録音再生サービスでは、最大で 32 本の会話の同時レコーディングが可能です。 専用の場合の録音再生サービス(プレミアム提供時に使用可能)では、最大で 80 本の会話の同時レコーディングが可能です。 録音再生サービスのキャパシティは使用するコーデックに依存 しません 。
表8-5 に、録音再生サービスのキャパシティの概要を示します。
|
|
---|---|
エンタープライズ ソリューションのサポートおよび保守には、多くの手順と手続きを必要とします。 お客様の環境によって、サポートの手続きも変わります。 システム パフォーマンス モニタリングは、システムの保守に役立つ手続きの 1 つです。 このセクションでは、システムが許容性の範囲内で実行されていることを確認するための Unified CCE のモニタリングについて説明します。 システム モニタリングは、システムを拡張またはアップグレードする場合は特に重要です。 多くのアクティビティを実行する時間には、システムをモニタリングする必要があります。
モニタリングには、次のシステム コンポーネントが不可欠です。
次のリストは、不可欠なシステム コンポーネントの重要なカウンタのいくつかと、そのしきい値を強調表示します。
–%ProcessorTime。このカウンタのしきい値は 60 % です。
–ProcessorQueueLength。この値は(2 ∗(システムの CPU の総数))以下にする必要があります。
–% Committed Bytes。この値は(0.8 ∗(物理メモリの総量))未満を維持する必要があります。
–Memory\Available MByte。この値は 16MB 以上であることが必要です。
–Memory\Pages/sec。このカウンタのしきい値は 10 です。
–Page File %usage。このカウンタのしきい値は 80 % です。
–AverageDiskQueueLength。この値は(1.5 ∗(アレイのディスク総数))未満を維持する必要があります。
–%Disktime。この値は 60 % 未満を維持する必要があります。
–NIC\bytes total/sec。この値は(0.3 ∗(NIC の物理サイズ))未満を維持する必要があります。
–NIC\Output Queue Length。このカウンタのしきい値は 1 です。
–Cisco Unified ICM Router(_Total)\Agents Logged On
–Cisco Unified ICM Router(_Total)\Calls in Progress
–Cisco Unified ICM Router(_Total)\calls /sec
(注) 上記の CPU、メモリ、ディスク、およびネットワークのパフォーマンス カウンタは、展開内のすべてのサーバに適用されます。 推奨するサンプル レートは 15 秒です。
Unified CC コンポーネントを適切にサイジングするには、エージェント数および最頻時発呼数以外の分析が必要です。 各エージェントに複数のスキル グループが対応する設定、多量のコール キューイング、およびその他の要因によって、各コンポーネントの合計キャパシティは変化します。 製品の購入に先立って慎重に計画と検討を実施し、重要なサイジング変数を特定して、最終的にこれらの考慮事項を反映した設計とハードウェア選択を行うことが不可欠です。
正しいサイジングおよび設計を行うと、最大 6,000 のエージェントおよび 180,000 の BHCA に対応する大規模システムを安定して展開することが可能になります。 小規模展開の場合は、慎重な計画に基づいて Unified ICM コンポーネント(Progger、Rogger、Agent PG など)を共存させることにより、コストを削減できます。
設計者は、エージェントごとのスキル グループ数など、サイジング キャパシティに影響を与えるサイジング変数にも注意する必要があります。 製品購入前のフェーズでこれらの変数を確定することは困難である場合がしばしばありますが、初期設計時にこれらの点を考慮することが、特に PG と Progger の共存サーバを展開する場合には重要となります。 新規バージョンでスケーラビリティが改善される予定ですが、現在の Cisco Agent Desktop モニタ サーバでは、モニタリングおよび録音が必要となる場合に 1 台のサーバでモニタリング可能な同時セッション数が制限されます。