Cisco IP Contact Center Enterprise Edition ネットワーク デザイン(SRND) Releases 5.0/6.0
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月5日
章のタイトル： IPCC における Cisco CallManager サーバのサイジング
- IPCC Enterprise におけるコール処理
- IPCC におけるクラスタリングのガイドライン
- IPCC Enterprise と Cisco CallManager Release 3.1 および 3.2
- IPCC Enterprise と Cisco CallManager Release 3.3 以降
- IPCC における Cisco CallManager プラットフォーム キャパシティ プランニング
- Cisco CallManager Capacity Tool
- IPCC Enterprise をサポートする Cisco CallManager サーバ プラットフォーム
- IPCC におけるコール処理の冗長構成
- クラスタの冗長構成
- IPCC におけるロード バランシング
- IPCC アプリケーションが Cisco CallManager のパフォーマンスとスケーラビリティに及ぼす影響
IPCC における Cisco CallManager サーバのサイジング
この章では、Cisco CallManager クラスタを IPCC Enterprise 環境で使用する場合の考え方、プロビジョニング、および設定について説明します。Cisco CallManager クラスタを使用すると、IP テレフォニーをサポートし、冗長化が容易で、機能の透過性とスケーラビリティを確保できる、音声・データ統合 IP ネットワークのインフラストラクチャ全体に、コール処理を分散するメカニズムを形成できます。
この章では、単一および複数のキャンパス環境に複数のクラスタが配置されている場合における IPCC Enterprise のオペレーションに限定して説明し、参考用の実装設計を示します。この章を読む前に、Cisco CallManager クラスタの動作の詳細について、次の URL にある『Cisco IP Telephony Solution Reference Network Design (SRND)』の「Call Processing」の章で学習することをお勧めします。
この章の情報は、『Cisco IP Telephony SRND』で提示した考え方に基づいて構成されています。Cisco CallManager のコール処理アーキテクチャがサポートするアプリケーションの一種である IPCC と関連する概念を説明するため、一部に重複する記述もあります。ただし基本的な概念についてはここでは繰り返しませんので、これらの概念について十分理解した上でこの章を読んでください。
この章では、IPCC Enterprise で使用する Cisco CallManager サーバのサイジングにあたっての、一般的なベスト プラクティスおよびスケーラビリティに関する考慮事項を示します。このドキュメントでスケーラビリティとは、IPCC Enterprise 環境で使用する限りにおいての、Cisco CallManager サーバおよびクラスタのキャパシティを表します。
IPCC Enterprise におけるコール処理
この章のガイドラインを適用するのに先立って次に示す各項目を決定してください。これらの項目は Cisco CallManager クラスタのスケーラビリティに大きな影響を及ぼします。
•
カスタマー コール センター アプリケーションの要件（IP IVR、ISN、アウトバウンド、マルチチャネルなど）を決定します。
• IPCC Enterprise で使用するコール センター リソースおよびデバイスのタイプ（ルート ポイント、CTI ポートなど）を決定します。
–必要な IP IVR CTI ポートまたは ISN ポート（あるいはセッション）の数
–CTI ルート ポイント（ICM ルート ポイントおよび IVR ルート ポイント）の数
–上記のすべてのエージェントおよびデバイスに関する Busy Hour Call Attempts（BHCA; 最頻時発呼数）の見積り（およびそれがインバウンドとアウトバウンドのいずれであるか）
• 要求される配置モデル（単一サイト型、中央集中型、分散型、WAN を介したクラスタ化、リモート ブランチを含む中央集中型または分散型）を決定します。
• ネットワーク内のソリューション コンポーネント（ゲートウェイ、エージェント、ISN など）の配置を決定します。
• コール フローおよびコール処理のタイプを決定します。たとえば次のようなタイプがあります。
–単純なコール フロー（IVR コール処理を伴わない IVR セルフサービスまたは直接エージェント転送）
単純なコール フローとは、複数回のコール処理が必要でないコール フローです（IVR セルフサービス、ゲートウェイから直接電話へ着信するコール、内部コールなど）。
–複雑なコール フロー（エージェント転送前の IVR コール処理またはデータベース参照、ルート ポイントへのコール リダイレクション、CTI ルート ポイント、CTI ポート、エージェント間転送および会議、エージェントからスキル グループへの相談または会議）
複雑なコール フローとは、複数回のコール リダイレクトや元のコールの処理を伴うコール フローです（たとえば、セントラル ルート ポイントへの着信コールを CTI ルート ポイントにリダイレクトしてから、コール処理のために IP IVR にリダイレクトし、続いてエージェントなどの別のターゲットに転送またはリダイレクトするコール フローなど）。このように元のコールを複数回のセグメントで処理する場合、単純なコール処理に比べてより多くの CPU リソースが消費されます。
IPCC におけるクラスタリングのガイドライン
次のガイドラインは、IPCC Enterprise で使用するすべての Cisco CallManager クラスタに適用されます。
（注） クラスタには複数のサーバ プラットフォームを含めることができますが、同一クラスタ内で実行される Cisco CallManager はリリースおよびサービス パックを統一する必要があります。パブリッシャ サーバにはサブスクライバ サーバと同等以上の能力が必要です（表6-2 を参照してください）。
• デバイス（電話、保留音、ルート ポイント、ゲートウェイ ポート、CTI ポート、JTAPI ユーザ、および CTI マネージャを含む）は、パブリッシャ上に配置または登録しないでください。パブリッシャにデバイスが登録されている場合、コール処理および CTI マネージャの稼働状況が Cisco CallManager 上の管理作業の影響を受けます。
• パブリッシャをフェールオーバーまたはバックアップ コール処理サーバとして使用しないでください。ただし、エージェント電話が 50 台未満である場合や、ミッション クリティカルな環境または本稼働環境ではない場合はこの限りではありません。Cisco MCS-7825H-3000 がサーバの最小要件です。逸脱がある場合は、Cisco Bid Assurance によるケースごとの確認が必要です。
• エージェント電話が 50 台を超える場合は、2 つ以上のサブスクライバ サーバと、TFTP とパブリッシャの複合サーバ 1 つが必要です。
• 複数のプライマリ サブスクライバを必要とする構成の場合は、各クラスタ ノードのエージェント数が均等になるように配分します。これにより、すべてのエージェントの BHCA が均一になります（処理される平均 BHCA がすべてのノードでほぼ等しくなります）。
• 同様に、すべてのゲートウェイ ポートと IP IVR CTI ポートを、クラスタ ノード間で均等になるように配分します。
• 複数の ICM JTAPI ユーザ（CTI マネージャ）と複数のプライマリ サブスクライバが必要な場合は、同一の ICM JTAPI ユーザ（サードパーティ アプリケーション プロバイダー）が監視するすべてのデバイス（ICM ルート ポイントやエージェント デバイスなど）を、できる限り同一のサーバにグループ化して構成します。
• クラスタに IPCC と一般的なオフィス IP 電話を混在させている場合は、できる限り、タイプごとに独立したサーバにグループ化して構成します（必要なサブスクライバ サーバが 1 つしかない場合を除く）。たとえば、クラスタのキャパシティが許す限り、すべての IPCC エージェントとこれらに関連付けられたデバイスおよびリソース（ゲートウェイ ポートや CTI ポートなど）を持つ Cisco CallManager サーバ（群）と、すべての一般的な IP 電話とこれに関連付けられたデバイス（ゲートウェイ ポートなど）を持つ Cisco CallManager サーバ（群）を別々に配置します。この場合は、1:1 の冗長構成を採用することを強くお勧めします（詳細については、「IPCC におけるコール処理の冗長構成」を参照してください）。
• 通常は、Cisco CallManager クラスタからのすべてのサーバを同一の LAN または MAN に配置します。あるクラスタのすべてのメンバを同一の VLAN またはスイッチに配置することは、お勧めしません。
• クラスタが IP WAN を介して構築されている場合は、IP WAN を介したクラスタリングに固有のガイドラインに従ってください。これについては、このガイドの「WAN 経由のクラスタリング」、および次の URL にある『Cisco IP Telephony Solution Reference Network Design (SRND)』ガイドの「Clustering Over the IP WAN」で説明しています。
Cisco CallManager のクラスタリングに関するガイドラインについては、次の URL にある『Cisco IP Telephony Solution Reference Network Design (SRND)』を参照してください。
IPCC Enterprise と Cisco CallManager Release 3.1 および 3.2
次のガイドラインは Cisco CallManager リリース 3.1 および 3.2 に適用されます。Cisco CallManager と IPCC がサポートするリリースに関するより詳しい情報は、次の URL にある『Cisco CallManager Compatibility Matrix』を参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/ccmcomp.htm
• 1 つの CallManager クラスタ内には、CallManager Service を使用して最大で 6 つのコール処理サーバ（4 つのプライマリ サーバと 2 つのバックアップ サーバ）を配置できます。Trivial File Transfer Protocol（TFTP）、データベース パブリッシャ、保留音などの機能に特化した専用サーバであれば、このクラスタに追加できます。
• 4 つのプライマリ サーバのバランスを均等にした場合、Computer Telephony Integration（CTI）接続またはアソシエーションを 1 つのサーバにつき最大 800、つまり 1 つのクラスタにつき最大 3200 構成できます。この最大数には、IPCC エージェント電話、IP IVR CTI ポート、CTI ルート ポイント、およびその他の CTI デバイスが含まれます。
• 1 つの H.323 デバイスがサポートできる H.323 コール数は、Cisco CallManager Release 3.1 で最大 500、Cisco CallManager Release 3.2 で最大 1000 です。
• Cisco CallManager Release 3.1 または 3.2 のデフォルト トレース設定はそれ以降のリリース（Cisco CallManager Release 3.3 以降）の設定と異なっており、通常はディスク I/O への影響がより少ない設定です。Cisco CallManager Release 3.3 以降にアップグレードするときは、インストールされた MCS-7800 シリーズサーバに最大レートのエージェント キャパシティを処理する能力があることを確認してください。Battery-Backed Write Cache（BBWC; バッテリ バックアップ式ライト キャッシュ）イネーブラ キットを追加できないサーバは、BBWC をインストールした同等のサーバに比べてキャパシティが半分になります（キャパシティはプロセッサ速度やメモリなどの他のサーバ リソースによっても制約されるので、BBWC をインストールすればエージェント キャパシティが 2 倍になるわけではありません。BBWC には、ディスク I/O コンテンションを減少させ、CPU がより高いトランザクション負荷を処理できるようにする効果があります）。
• Cisco CallManager および Signal Distribution Layer（SDL）のトレース ファイルは、デフォルトでプライマリ ドライブ上にあります。このトレース ファイルはセカンダリである F ドライブ アレイに指定し直す必要があり、CTI のデフォルト トレース ファイル位置は C ドライブ アレイに指定する必要があります。これが、ディスク I/O リソースへの影響が最も少ない設定です。
IPCC Enterprise と Cisco CallManager Release 3.3 以降
次のガイドラインは Cisco CallManager リリース 3.3 以降に適用されます。
• CallManager サービスは、1 つのクラスタ内で最大 8 つのサーバ（バックアップ サーバを含む）上で有効にできます。TFTP、パブリッシャ、保留音などの機能に特化した専用サーバであれば、このクラスタに追加できます。
• すべてのサーバのバランスを均等にした場合、構成できる CTI 接続またはアソシエーションの数は、Battery-Backed Write Cache（BBWC; バッテリ バックアップ式ライト キャッシュ）がインストールされていない標準サーバ（ 表6-2 を参照）1 つあたり 800、つまりクラスタ 1 つあたり最大 3200、制御できるデバイスの数は CTI アプリケーションあたり最大 2000 です（Cisco MCS-7835 サーバが必要です）。
• すべてのサーバのバランスを均等にした場合、構成できる CTI 接続またはアソシエーションの数は、Battery-Backed Write Cache（BBWC; バッテリ バックアップ式ライト キャッシュ）がインストールされた MCS-7845H または同等のハイパフォーマンス サーバ（ 表6-2 を参照）1 つあたり最大 2500、つまりクラスタ 1 つあたり最大 10,000、制御できるデバイスの数は CTI アプリケーションあたり最大 2500 です。この最大数には、Cisco CallManager で構成した IPCC エージェント電話、IP IVR CTI ポート、CTI ルート ポイント、およびその他のサードパーティ アプリケーション CTI デバイスが含まれます。
• 1 つの Cisco CallManager クラスタ（4 つのプライマリ サーバと 4 つのバックアップ サブスクライバ サーバ）は、最大で 2,000 の IPCC エージェントと 60,000 の BHCA をサポートできます。BHCA は、1:1 の冗長性を持たせて、8 つのコール処理サーバに均等に割り振ります（冗長構成については「IPCC におけるコール処理の冗長構成」を参照してください）。8 つの Cisco CallManager(BBWC をインストールした MCS-7845H ハイパフォーマンス サーバ）がそれぞれ最大 250 エージェント、合計 7,500 の BHCA をサポートします。フェールオーバーの際は、プライマリ サーバが最大 500 のエージェントと 15,000 の BHCA をサポートします。これらのキャパシティは、個々の構成（コール フローが単純か複雑かなど）に応じて変化する可能性があります。キャパシティは、Cisco CallManager キャパシティ ツールで確認できます（「Cisco CallManager Capacity Tool」を参照してください）。
IPCC における Cisco CallManager プラットフォーム キャパシティ プランニング
Cisco CallManager には、IP 電話、IP IVR ポート、ボイスメール ポート、CTI(TAPI/JTAPI)デバイス、ゲートウェイや、トランスコーディングやコンファレンシングなどの DSP リソースなどの、さまざまなタイプのデバイスを登録できます。これらのデバイスのそれぞれについて、登録サーバ プラットフォームのリソースが必要になります。
必要なリソースにはメモリ、プロセッサ、I/O などがあります。トランザクション（通常はコールの形を取ります）の際には、各デバイスが消費するサーバ リソースがさらに増大します。標準の IP 電話のように 1 時間あたりのコール処理量が 6 回のデバイスの方が、IPCC エージェント電話、ゲートウェイ ポート、IP IVR ポートのように 1 時間あたりのコール処理量が 30 回のデバイスよりも、消費するリソースは少なくなります。
以前の Cisco CallManager ソフトウェア リリースでは、システムのキャパシティを計算するため、デバイスの重み付け、BHCA 乗数、ダイヤル プランの重み付けを利用したさまざまなスキームを使用していました。より正確なシステム プランニングを実現するため、これらのシンプルなスキームに代わってキャパシティ ツールが導入されました。キャパシティ プランニング ツールは、現在のところシスコの従業員だけが利用できます。
（注） システムがこのドキュメントのガイドラインを満たしていない場合、またはシステムを複雑にする（IP テレフォニーと IPCC を他のアプリケーションと混在させる）ことを検討している場合は、Cisco CallManager クラスタの適切なサイジングについて、シスコのシステム エンジニアまでお問い合せください。
Cisco CallManager Capacity Tool
Cisco CallManager Capacity Tool では、さまざまな情報を使用して、システムに必要なサーバの最小サイズとタイプを判定します。必要な情報には、IP 電話、ゲートウェイ、メディア リソースなどのデバイスの、タイプおよび数が含まれます。また、デバイス タイプごとに、平均最頻時発呼数 （BHCA）と平均最頻時トラフィック利用率も必要です。たとえば、すべての IPCC 電話から 1 時間あたり平均 25 回のコールが生成され、1 回のコール時間が平均 2 分の場合、BHCA が 25、利用率が 0.83 になります（1 時間に 2 分間のコールが 25 回、つまり 50 分なので、50/60 = 0.83）。 表6-1 に、Capacity Tool への入力例を示します。
|
|
|
トラフィック利用率 |
|---|---|---|
|
|
||
|
|
||
キャパシティ ツールには、デバイス情報に加え、ルート パターンやトランスレーション パターンなどのダイヤル プランに関する情報も入力する必要があります。
IPCC に関する入力項目には、エージェント、ゲートウェイ ポート用の Internet Service Node（ISN）または IP IVR ポート、転送および会議に使用されるコールの割合などがあります。
すべての項目を入力すると目的とするサーバ タイプのプライマリ サーバの必要数が計算され、必要なキャパシティが単一クラスタを超える場合にはクラスタの数も計算されます。
キャパシティ ツールは、デバイスの重み付け、BHCA 乗数、コール タイプ、およびダイヤル プランの重み付けを利用する計算方法に代わるものです。キャパシティ ツールは、現在のところシスコの従業員だけが利用できます。詳細については、シスコの担当者に問い合せてください。
IPCC Enterprise をサポートする Cisco CallManager サーバ プラットフォーム
表6-2 は、IPCC Enterprise とともに Cisco CallManager クラスタにおいて使用できるサーバのタイプとその主要な特性を示します。
|
|
|
|
|---|---|---|
最大で 500 エージェントまでのすべてのミッション クリティカルなコール センターに推奨 |
1 つの Cisco CallManager サーバでサポートできる IPCC Enterprise エージェントの最大数は、サーバ プラットフォームによって異なります（ 表6-3 を参照してください）。
|
|
|
|
|
|---|---|---|---|
• |
はい 4 |
||
• |
はい 5 |
||
• |
|||
• |
いいえ4 |
||
• |
|||
• • |
表6-3 には次の注釈が適用されます。
• エージェント キャパシティは、Cisco CallManager Release 3.3 以降、フェールオーバー モードで計算しています。
• IPCC エージェントの最大数は、Cisco CallManager Release 3.3 以降では 500、Cisco CallManager Release 3.2 以前では 250 です。
• 高アベイラビリティでないプラットフォーム 1 台でサポートされる最大の IPCC エージェント数は 50 です。冗長サーバが構成されている場合、この値は適用されません。
• Cisco MCS-7845I-3000 は、Cisco CallManager をサポートできる MCS プラットフォームではありません。ただし、同等の IBM サーバ（IBM x345、3.06 GHz デュアル CPU）は、OS 2000.2.6 を使用したソフトウェア専用プラットフォームとして IPCC の配置をサポートできます。
• Cisco MCS-7815I-2000 サーバは、Cisco IP テレフォニーの配置だけをサポートできる Cisco CallManager プラットフォームです。IPCC Enterprise の配置はサポートしませんが、試験ラボでの用途やデモ セットアップにはこのサーバを使用できます。
• 新しい MCS-7835H および MCS-7845H サーバ プラットフォームのキャパシティは、 表6-3 の値と同一です。
サポートされるプラットフォームと具体的なハードウェア構成については、次のオンライン ドキュメントを参照してくたさい。
http://www.cisco.com/en/US/products/hw/voiceapp/ps378/prod_brochure_list.html
この項で示したキャパシティは、通常の稼働時の設定で期待されるパフォーマンスを確保するための、設計ガイドラインです。コール処理に直接関係しない機能を無効にしたり縮小したりすることによってパフォーマンスを改善することも可能です。逆にこうした機能を追加した場合はシステムのコール処理能力が影響を受ける場合があります。そのような機能としては、トレーシング、呼詳細レコード（CDR）、複雑性の高いダイヤル プラン、コール フロー、サーバに共存するその他のサービスなどが含まれます。複雑性の高いダイヤル プランとしては、複数回線着信表示、多数のパーティション、コーリング サーチ スペース（CSS）、ルート パターン、トランジション、ルート グループ、ハント グループ、ピックアップ グループ、ルート リスト、大量の自動転送、複数サービスの共存、その他の共存アプリケーションなどがあります。こうした機能を使用した場合、Cisco CallManager サーバのメモリ リソースが大量に消費される可能性があります。パフォーマンスを向上させるには、承認済みの対応メモリをプラットフォームでサポートされる最大容量まで増設してください。
Cisco CallManager クラスタに、多数のゲートウェイ、ルート パターン、トランスレーション パターン、およびパーティションを含む非常に大規模なダイヤル プランが設定されている場合、Cisco CallManager サービスを最初に起動する際の初期化に非常に時間がかかることがあります。デフォルトの時間内にシステムが初期化されない場合は、サービス パラメータを調整することによって許容される初期化時間を延長できます。サービス パラメータの詳細については、Cisco CallManager Administration でサービス パラメータに関するオンライン ヘルプを参照してください。
IPCC におけるコール処理の冗長構成
Cisco CallManager と IPCC のすべてのバージョンで、次の冗長構成を選択できます。
• 2:1 ó プライマリ サブスクライバ 2 つに対して、バックアップ サブスクライバ 1 つ。
• 1:1 ó プライマリ サブスクライバ 1 つに対して、バックアップ サブスクライバ 1 つ。
1:1 の冗長構成では、アップグレードの際にクラスタが影響を受ける時間をフェールオーバー時間だけに限定できます。
Cisco CallManager Release 3.3 以降では最大 8 つのサブスクライバ（Cisco CallManager サービスを有効にしたサーバ）がサポートされるため、1 つのクラスタ内に 4 つのプライマリ サブスクライバと 4 つのバックアップ サブスクライバを構成できます。
1:1 の冗長構成では、次に示す手順でクラスタをアップグレードできます。
ステップ 2 専用 TFTP サーバおよび Music on Hold（MoH; 保留音）サーバをアップグレードします。
ステップ 3 すべてのバックアップ サブスクライバをアップグレードします。50/50 のロード バランシングを設定している場合、この手順を実行すると一部のユーザが影響を受けます。この手順の間、バックアップ サブスクライバでは Cisco CallManager サービスが停止され、デバイスがプライマリ サブスクライバに移動します。
ステップ 4 プライマリ サブスクライバをそれぞれのバックアップ系にフェールオーバーした後、プライマリ サブスクライバの Cisco CallManager サービスを停止します。Cisco CallManager サービスが停止されると、プライマリ サブスクライバのすべてのユーザがバックアップ サブスクライバに移動します。CTI マネージャも停止され、これによって Peripheral Gateway（PG; ペリフェラル ゲートウェイ）のサイドが切り替わり、該当するノードのエージェントが短時間停止されます。
ステップ 5 プライマリ サブスクライバをアップグレードし、Cisco CallManager サービスを再び有効にします。
このアップグレード方法では、バージョンの異なる Cisco CallManager ソフトウェアを実行中にサブスクライバ サーバにデバイスが登録される時間を、フェールオーバー時間だけに限定できます。この特徴が重要な意味を持つのは、サブスクライバ間通信を行う Intra-Cluster Communication Signaling（ICCS）プロトコルがソフトウェアのバージョンの違いを検出して、該当するサブスクライバへの通信をシャットダウンする可能性があるためです。この手順を操作することによりコール処理用クラスタが分割される可能性がありますが、SQL および LDAP レプリケーションは影響を受けません。
2:1 の冗長構成を採用した場合は、クラスタ内のサーバ数を抑制できますが、アップグレード中に停止が発生する可能性があります。このスキームは IPCC にはお勧めしません。ただしシステムへの要求においてコール処理の停止が重大な問題とならない場合には、このスキームも選択肢の 1 つになります。
2:1 の冗長構成では、次に示す手順でクラスタをアップグレードできます。Cisco CallManager サービスがパブリッシャ データベース サーバで実行されていない場合は、次の順序でサーバをアップグレードします。
ステップ 1 パブリッシャ データベース サーバをアップグレードします。
ステップ 2 Cisco TFTP サーバがパブリッシャ データベース サーバから独立して存在する場合は、Cisco TFTP サーバをアップグレードします。
ステップ 3 Cisco CallManager 関連のサービス（Music on Hold、Cisco IP Media Streaming Application など）だけが実行されるサーバを、1 つずつアップグレードします。サーバのアップグレードは必ず一度に 1 つ行ってください。これらのサーバで Cisco CallManager サービスが実行されていないことを確認してください。
ステップ 4 バックアップ サーバを 1 つずつアップグレードします。
（注） アップグレード中にバックアップ サーバをオーバーサブスクライブすることは、お勧めできません。アップグレード中は、バックアップ サーバに登録する IPCC エージェント数を 500 以下にすることを強くお勧めします。アップグレードは、ピーク時を避けて呼量の少ない時間帯に実施することを強くお勧めします。
ステップ 5 Cisco CallManager サービスが実行される各プライマリ サーバをアップグレードします。 サーバは 1 つずつアップグレードしてください。2 番目のプライマリ サブスクライバのアップグレード中、このサーバに登録されたユーザおよびエージェントが短時間停止されます。同様に、4 番目のプライマリ サブスクライバのアップグレード中も、このサーバに登録されたユーザおよびエージェントが短時間停止されます。
クラスタの冗長構成
図6-1 ～図6-5 は、Cisco CallManager で IPCC コール処理の冗長性を確保するための典型的なクラスタ構成です。
図6-4 IPCC Enterprise における 1:1 の冗長性構成（Cisco CallManager Release 3.3 以降、ロード バランシング 50/50、BBWC をインストールしたハイパフォーマンス サーバの場合）
（注） MCS-7845H-2.4 アドバンスト サーバには BBWC がインストールされていません。BBWC は別途注文する必要があります。
図6-5 オフィスと IPCC の電話の混成システムにおける 1:1 の冗長性構成（Cisco CallManager Release 3.3 以降、ロード バランシング 50/50、MCS-7845H-3000 ハイパフォーマンス サーバの場合）
IPCC におけるロード バランシング
1:1 の冗長構成を採用するもう 1 つの利点は、プライマリとバックアップのサーバ ペアのデバイスのバランスを調整できることです。通常は（2:1 の冗長構成と同様に）プライマリ サーバが利用不可能にならない限り、バックアップ サーバにデバイスは登録されません。
ロード バランシングを行うと、Cisco CallManager 冗長グループおよびデバイス プール設定を使用してプライマリ サーバからセカンダリ サブスクライバに最大で半分のデバイス負荷を移すことができます。これにより、いずれかのサーバが利用できなくなった場合の影響を半分に減らすことができます。
50/50 のロード バランシングを設計するには、まずロード バランシングを行わない状態のクラスタのキャパシティを計算し、次にこの負荷を、デバイスと呼量に基づいてプライマリおよびバックアップ サブスクライバに配分します。プライマリまたはバックアップの障害に備えて、プライマリおよびセカンダリ サブスクライバの総負荷が 1 つのサブスクライバの総負荷を超えないようにします。たとえば、MCS-7845H-3000 サーバの総負荷の上限は 500 IPCC エージェントです。この場合、1:1 の冗長ペアでは 2 つのサブスクライバに 250 エージェントずつ負荷を分割できます（500 エージェントの構成は図6-2 を参照してください）。フェールオーバーでアクティブなサーバが 1 つになる状況に備えて、冗長系にかかる IPCC エージェント電話、IP 電話、CTI などの負荷が、いずれも 1 つのサーバの負荷の上限を超えないようにしてください。
セカンダリ TFTP サーバやゲートキーパーなどの一般的なコール処理の詳細については、次の URL にある『Cisco IP Telephony Solution Reference Network Design (SRND)』を参照してください。
IPCC アプリケーションが Cisco CallManager のパフォーマンスとスケーラビリティに及ぼす影響
Cisco CallManager システムのパフォーマンスは、次を含む多くの要因に影響されます。
• これらのデバイスが処理する負荷（BHCA）。コール レートが上昇するにつれて、Cisco CallManager サーバで消費される CPU リソースも増大します。
• 平均コール時間 － 平均コール時間が長いほど最頻時コール完了レートが下がり、CPU 使用率が低下します。
• 次に示すサービスの Cisco CallManager 構成への追加
• アプリケーション コール フローの複雑さ（コール フローの複雑さについては「IPCC Enterprise におけるコール処理」を参照してください）
CPU 消費はコール フローのタイプによって異なります。単純なコール フローに比べて、複雑なコール フローでは CPU 消費がはるかに大きくなります。
• テストの結果によると、H323 ゲートウェイによる IP IVR を使用した複雑なコール フロー（コール処理の後エージェントに転送）では、ISN（H.323 ゲートウェイ）を使用した同じコール フローに比べて CPU 使用率が上昇します。このような差が生じるのは、ISN ではコール処理の前にコールが Cisco CallManager にルーティングされる必要がなく、コールがエージェントに転送されるときだけ、Cisco CallManager が関与するためです（単純なコール処理）。ただし、ISN ゲートウェイはパフォーマンス要件が高くなります（詳細については「ISN コンポーネントのサイジング」を参照してください）。
• 同様に、Media Gateway Control Protocol（MGCP）ゲートウェイによる IP IVR を使用した複雑なコール フローでは、ISN（H.323 ゲートウェイ）を使用した同じコール フローに比べて CPU 使用率が上昇します。このような差が生じるのは、ISN におけるコール ルーティング方法が異なること（前の段落を参照）、および H.323 ゲートウェイ プロトコルでは MGCP よりも多くの CPU リソースが使用されることが原因です。
• ISN 構成を使用し、コール フローを単純にし、着信レート（BHCA）を低減すれば、
Cisco CallManager クラスタあたり 2,000 を超えるエージェントをサポートできる可能性があります。システム要件に適したサイジングについては、シスコのシステム エンジニアにご相談ください。
Cisco CallManager の CPU リソース消費は、有効なトレース レベルによって変化します。Cisco CallManager でトレース レベルを［既定値］から ［最大レベル］に変更すると、高負荷時に CPU 消費が著しく増大する可能性があります（トレース レベルを［既定値］から［トレースなし］に変更すると、高負荷時に CPU 消費が著しく減少する可能性がありますが、この設定はお勧めできません。また、Cisco Technical Assistance Center でもこの設定はサポートされません）。デフォルトのトレースによる CPU 消費は、負荷、Cisco CallManager のリリース、インストールされたアプリケーション、コール フローの複雑さなどによって異なります。
• メモリ消費とディスク I/O リソース（バッテリ バックアップ式ライト キャッシュ）
複数のプライマリ Cisco CallManager サーバを使用する場合は、すべてのリソースをできるだけ均等に配分することが重要です。リソースのバランスを取ることにより、他のサーバのために 1 つのサーバに過大な負荷がかかることを防止できます。
フィードバック