Cisco ICM Enterprise Edition プリインストール プランニング ガイド Release 7.0(0)
ICM プラットフォームのプラン ニング
ICM プラットフォームのプランニング
発行日;2012/06/14 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 2MB) | フィードバック

目次

ICM プラットフォームのプランニング

必要なサーバの数の決定

ICM プラットフォームの考慮事項

プロセッサ使用率

ページングの要件

Logger の拡張

ディストリビュータ AW のプランニング

ディストリビュータと管理サイト

ディストリビュータ AW およびクライアント AW の要件

Historical Data Server のプランニング

HDS の機能

ICM プラットフォームのプランニング

システムのサイジングに関する推奨事項を確認したら、適切なハードウェア構成を注文し始めることができます。 しかし、まず初めに、何台の ICM ノードが必要になるかを確認する必要があります。

ICM システムで必要になるサーバの数は、セントラル コントローラ、PG、NIC、およびその他のノードの構成で決まります。 たとえば、デュプレックス構成のセントラル コントローラでは、CallRouter と Logger が二重化されるため、追加のサーバが必要になります。

必要なサーバの数の決定

表10-1 に、システムで必要となるサーバの数を決定する方法を示します。 この例のサーバ数は、次の特性を持つ ICM 構成に基づいて決定されたものです。

デュプレックス構成の、地理的に分散しているセントラル コントローラを持つ ICM システム(各セントラル サイトに CallRouter と Logger が存在する)。

セントラル コントローラの一方(セントラル サイト 1)はコール センターにあるため、1 つまたは複数の ACD にサービスを提供する PG が存在する。 耐障害性を得るため、PG がデュプレックス構成(2 つのサーバ)になっている。

この ICM には、3 つのリモート コール センター サイトと 2 つの管理サイトがある。

 

表10-1 サーバ要件の例

サイト
ノードの種類

CallRtr

Lgr

Call/Lgr

DB サーバ1

PG2

AW(HDS を含む)

セントラル サイト 1

1

1

2

1

セントラル サイト 23

1

1

1

リモート コール
センター 1

----------

------

------------

--------------

2

リモート コール
センター 2

----------

------

------------

--------------

2

リモート コール
センター 3

----------

------

------------

 

--------------

2

管理サイト 1

----------

------

------------

 

--------------

---------

1

管理サイト 2

----------

------

------------

 

--------------

---------

1

ノード合計

2

2

 

8

4

注意

--------- この種のサイトでは、これらのサーバはインストールされません。

-この構成ではオプションとして選択されません。

1.ICM ゲートウェイ SQL 構成の場合にだけ必要。

2.そのサイトがコール センターとしてのサービスも行う場合、またはリモート ACD のオプションを使用する場合、セントラル サイトだけにインストールされる。

3.併設デュプレックス構成のセントラル コントローラでは、2 つ目のセントラル サイトは不要です。

ICM プラットフォームの考慮事項

ICM ソフトウェアは Intel Xeon マシンで実行されます。 ICM リリース 7.0 ソフトウェアを実行できるオペレーティング システムは Microsoft Windows Server 2003 です。アップグレードでは、Windows 2000 Server もサポートされる予定です。 『 Cisco Enterprise Contact Routing Bill of Materials(BOM) 』に、サーバ構成の情報とサポートされているサーバ プラットフォームの例が記載されています。 ICM プラットフォームのすべての情報については BOM を参照してください。

リリース 7.0 では、SQL 2000 だけがサポートされています。

プロセッサ使用率

すべての ICM ノードの共通のルールとして、システムで予想される最大コール負荷時のプロセッサ使用率を 60 % 未満に抑えるようにしてください。 これは、コール要求の急増に対応できるようにするとともに、再同期やバックグラウンドでのクリーンアップなどのアクティビティを実行するためのキャパシティを確保するためです。 ICM 以外のソフトウェアが 60 % の最大負荷の一部に含まれる場合もあります。 プロセッサ使用率の値(60 %)は、プラットフォーム上で実行されるすべてのソフトウェアを含めた値です。

使用率の要件のほか、システム上のソフトウェアが 100 ミリ秒より長い連続バーストで ICM ソフトウェアよりも高いまたは同等の優先順位で実行されないようにする必要があります。 ICM ソフトウェアはシステム上で、最低でも 100 ミリ秒ごとの頻度で実行される必要があります。 この要件については、デバイス ドライバやその他のカーネルレベルのソフトウェアがインストールされていない場合や、プロセスまたはスレッドの優先順位が不適切に変更されていない場合には、通常問題にはなりません。

ページングの要件

ICM システムで最も時間が重視されるコンポーネントは CallRouter ノードです。ディスク I/O(ページング)による遅延は許されません。 ICM マシンで発生するディスク I/O は、ログ ファイルへの書き込み時やデータベース I/O 時だけです。データベース I/O は Logger マシンとディストリビュータ AW マシンで発生します。 基本的なルールとして、重要プロセスの作業セット全体がメモリ内に存続できるだけの十分なメイン メモリを搭載するようにします。

RAM およびその他のプラットフォーム要件の最新情報については、『 Cisco Intelligent Contact Management Software Release 7.0(0) Bill of Materials (BOM) 』を参照してください。 ICM BOM は
http://www.cisco.com/univercd/cc/td/doc/product/icm/index.htm で参照できます。

データベース プラットフォーム(Logger、ディストリビュータ AW、ICM ゲートウェイ SQL マシン)には、すべての第 1 レベル インデックス ページをメイン メモリ キャッシュに維持できるだけのメイン メモリが搭載されている必要があります。

Logger の拡張

注文した Logger プラットフォームには、内蔵および外付け SCSI ハード ドライブの組み合せが含まれている場合があります。 コール センター エンタープライズが成長すると、データベース要件も通常高くなります。 より多くのサービス、スキル グループ、およびルートが構成に追加され、一日にルーティングするコール量も増加します。 この結果、セントラル データベースに保存される履歴データの量が増加します。

データベース要件に変更が発生した場合は、ICM ソフトウェアのサポート プロバイダーに連絡し、セントラル データベースのストレージ キャパシティの追加を依頼してください。


) データ ストレージの仕様については、『Cisco Enterprise Contact Routing Bill of Materials(BOM)』を参照してください。


システムのインストール後に次の作業を行って、データベース スペースを増やすことができます。

リモートからデータベース スペースを追加(現在のディスク スペースで間に合う場合)。

システムの稼働中に「ホットプラグ対応」のディスク ドライブを取り付け、ディスクを設定。


) ICM システムの設置稼働後のデータベース スペース管理については、
ICM Administration Guide for Cisco ICM Enterprise Edition』を参照してください。


ディストリビュータ AW のプランニング

現在のコール センター アクティビティをユーザが監視できるように、ICM システムでは、コール センター企業の特定のサイトに配置されたディストリビュータ アドミン ワークステーションに、リアルタイム データが転送されます。図 10-1 に、ICM システムのリアルタイム アーキテクチャを示します。

図 10-1 リアルタイム データ アーキテクチャ

 

リアルタイムのコールおよびエージェント グループの状態データは、各コール センターのアクティビティを常時監視するペリフェラル ゲートウェイからセントラル コントローラに送信されます。 CallRouter はリアルタイム サーバとして機能します。 セントラル コントローラのもう一方のサイドの CallRouter は、バックアップのリアルタイム サーバとして機能します。

CallRouter は、各管理サイトの 1 つまたは複数のディストリビュータ AW にリアルタイム データを提供する役割を担います。 サイト内のクライアント AW は、ディストリビュータ AW との接続を通してリアルタイム データを受け取ります。 これらの AW はローカル データベースを持たず、CallRouter からリアルタイム データを直接受け取るのに必要なディストリビュータ プロセスがないので、クライアント AW と呼ばれます。

ディストリビュータと管理サイト

アドミン ワークステーションは、コール センターまたは別のサイトの、セントラル コントローラの一方または両方のサイドに配置できます。 AW が配置されているサイトは管理サイトと呼ばれます。 各管理サイトには最低 1 つのディストリビュータ AW が必要になります。 リアルタイム データ配信アーキテクチャで耐障害性を確保するには、ディストリビュータ AW を 2 つ使用する必要があります(図 10-1 を参照)。

プライマリ ディストリビュータ AW が、リアルタイム データの入手経路であるリアルタイム サーバとのアクティブ接続を維持します。 セカンダリ ディストリビュータ AW もリアルタイム サーバとの接続を維持しますが、この接続は必要時(たとえば、プライマリ ディストリビュータ AW が何らかの理由で使用不可になった場合)以外はアイドルです。 2 つのディストリビュータ AW を配置するサイトでは、最初のディストリビュータが何らかの理由で機能しなくなったときに、もう 1 つのディストリビュータ AW に自動的に切り替わるようにクライアント AW を設定します。

ディストリビュータ AW およびクライアント AW の要件

ディストリビュータ AW がサービスを提供できるクライアント AW の数に一定の制限はありません。 ディストリビュータ AW およびクライアント AW の要件については、『 Cisco Enterprise Contact Routing Bill of Materials(BOM) 』を参照してください。

Historical Data Server のプランニング

履歴データは、個々のコール詳細レコードとして保存されるとともに、インターバル レコードとして集計され保存されます。 Historical Data Server(HDS; 履歴データ サーバ)を含むディストリビュータ AW には、レポーティング クエリーをサポートする履歴データが格納されます。 サイト内のアドミン ワークステーションは、Logger に直接クエリーを実行するのではなく、HDS に履歴データに関するクエリーを実行します(図 10-2 を参照)。

図 10-2 Historical Data Server のアーキテクチャ

 

Historical Data Server を設定するには、履歴データの複製を実行するように Logger を設定する必要があります。 また、リアルタイム ディストリビュータアドミン ワークステーションを HDS として構成することが必要です。 これらの設定が終了したら、リアルタイム ディストリビュータ上に HDS データベースを作成できます。

各クライアント アドミン ワークステーションは、リアルタイム供給情報によって履歴データの入手先を通知されます。 リアルタイム ディストリビュータが Historical Data Server である場合、リアルタイム ディストリビュータは、HDS から履歴データを取得するようクライアントに指示します。 そうでない場合、リアルタイム ディストリビュータは、Logger から履歴データを取得するようクライアントに指示します。

各 Logger では HDS が 2 つまでサポートされます。2 つのサーバを両方ともプライマリ ディストリビュータとして設定することもできますが、1 つをセカンダリ ディストリビュータとして設定することも可能です。 レポーティング要件をサポートするシステムでは、『 Webview インストレーション アドミニストレーション ガイド 』の「プライマリ AW とセカンダリ AW の導入」で考慮事項を確認してから、組織に適した展開方針を決定してください。 リアルタイム ディストリビュータ AW に適用される耐障害性方針は、HDS にも適用されます。 つまり、プライマリ HDS で障害が発生した場合、そのサイトのクライアント アドミン ワークステーションはバックアップの HDS を使用するように自動的に切り替えるようにします。

HDS の機能

HDS は、複数の AW がセントラル データベースにアクセスしてレポートを生成しようとするために発生するセントラル データベースのパフォーマンスの低下を防ぎます。

複数のリモート ディストリビュータ アドミン ワークステーションを含むシステムでは、HDS によって ICM の履歴レポート データがエンド ユーザの近くに置かれることになります。

各 HDS が 1 セットのデータベース テーブルを提供します。 これらのテーブルにはそれぞれデータ保持期間を設定できます。 この機能により、レポーティング機能をサイトごとに柔軟に設定できます。

Historical Data Server には、次のような特徴もあります。

インターネット アプリケーションの活用における、より高い柔軟性

データ マイニングおよびデータ ウェアハウジング アプリケーションへのオープン インターフェイス

他のデータベース テーブルを提供し、HDS と連動させる機能

向上したセキュリティとデータ アクセス機能

HDS アドミン ワークステーションには、強力な CPU と大きなディスク キャパシティおよび RAM を搭載した、ハイエンド向け AW プラットフォームが必要です。 HDS 要件の最新情報については、『 Cisco Intelligent Contact Management Software Release 7.0(0) Bill of Materials (BOM) 』を参照してください。 ICM BOM はhttp://www.cisco.com/univercd/cc/td/doc/product/icm/index.htm で参照できます。