この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
システムのサイジングに関する推奨事項を確認したら、適切なハードウェア構成を注文し始めることができます。 しかし、まず初めに、何台の ICM ノードが必要になるかを確認する必要があります。
ICM システムで必要になるサーバの数は、セントラル コントローラ、PG、NIC、およびその他のノードの構成で決まります。 たとえば、デュプレックス構成のセントラル コントローラでは、CallRouter と Logger が二重化されるため、追加のサーバが必要になります。
表10-1 に、システムで必要となるサーバの数を決定する方法を示します。 この例のサーバ数は、次の特性を持つ ICM 構成に基づいて決定されたものです。
• デュプレックス構成の、地理的に分散しているセントラル コントローラを持つ ICM システム(各セントラル サイトに CallRouter と Logger が存在する)。
• セントラル コントローラの一方(セントラル サイト 1)はコール センターにあるため、1 つまたは複数の ACD にサービスを提供する PG が存在する。 耐障害性を得るため、PG がデュプレックス構成(2 つのサーバ)になっている。
• この ICM には、3 つのリモート コール センター サイトと 2 つの管理サイトがある。
|
|
||||||
DB サーバ1 |
PG2 |
||||||
セントラル サイト 23 |
|||||||
2.そのサイトがコール センターとしてのサービスも行う場合、またはリモート ACD のオプションを使用する場合、セントラル サイトだけにインストールされる。 |
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 プラットフォームには、内蔵および外付け SCSI ハード ドライブの組み合せが含まれている場合があります。 コール センター エンタープライズが成長すると、データベース要件も通常高くなります。 より多くのサービス、スキル グループ、およびルートが構成に追加され、一日にルーティングするコール量も増加します。 この結果、セントラル データベースに保存される履歴データの量が増加します。
データベース要件に変更が発生した場合は、ICM ソフトウェアのサポート プロバイダーに連絡し、セントラル データベースのストレージ キャパシティの追加を依頼してください。
(注) データ ストレージの仕様については、『Cisco Enterprise Contact Routing Bill of Materials(BOM)』を参照してください。
システムのインストール後に次の作業を行って、データベース スペースを増やすことができます。
• リモートからデータベース スペースを追加(現在のディスク スペースで間に合う場合)。
• システムの稼働中に「ホットプラグ対応」のディスク ドライブを取り付け、ディスクを設定。
(注) ICM システムの設置稼働後のデータベース スペース管理については、
『ICM Administration Guide for Cisco ICM Enterprise Edition』を参照してください。
現在のコール センター アクティビティをユーザが監視できるように、ICM システムでは、コール センター企業の特定のサイトに配置されたディストリビュータ アドミン ワークステーションに、リアルタイム データが転送されます。図 10-1 に、ICM システムのリアルタイム アーキテクチャを示します。
リアルタイムのコールおよびエージェント グループの状態データは、各コール センターのアクティビティを常時監視するペリフェラル ゲートウェイからセントラル コントローラに送信されます。 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 の要件については、『 Cisco Enterprise Contact Routing Bill of Materials(BOM) 』を参照してください。
履歴データは、個々のコール詳細レコードとして保存されるとともに、インターバル レコードとして集計され保存されます。 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 は、複数の 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 で参照できます。