Cisco Unified Contact Center Enterprise ソリューション リファレンス ネットワーク デザイン（SRND）Releases 7.0

Cisco Unified CallManager 4.x および 5.x サーバのサイジング

---

この章では、Cisco Unified CallManager クラスタを Unified CCE 環境で使用する場合の考え方、プロビジョニング、および設定について説明します。 Cisco Unified CallManager クラスタを使用すると、Cisco Unified Communications をサポートし、冗長化が容易で、機能の透過性とスケーラビリティを確保できる、音声・データ統合 IP ネットワークのインフラストラクチャ全体に、コール処理を分散するメカニズムを形成できます。

この章では、Cisco Unified CallManager クラスタを使用した Unified CCE のオペレーションに限定して説明し、実装のための参考デザインを示します。 この章を読む前に、Cisco Unified CallManager クラスタの動作の詳細について、次の URL にある Cisco Unified Communications SRND で学習することをお勧めします。

www.cisco.com/go/srnd

この章の情報は、『 Cisco Unified Communications SRND 』で提示した考え方に基づいて構成されています。 Cisco Unified CallManager のコール処理アーキテクチャがサポートするアプリケーションの一種である Unified CC と関連する概念を説明するため、一部に重複する記述もあります。 ただし基本的な概念についてはここでは繰り返しませんので、これらの概念について十分理解した上でこの章を読んでください。

この章では、Unified CCE で使用する Cisco Unified CallManager サーバのサイジングにあたっての、一般的なベスト プラクティスおよびスケーラビリティに関する考慮事項を示します。 このドキュメントでスケーラビリティとは、Unified CCE 環境で使用する限りにおいての、Cisco Unified CallManager サーバおよびクラスタのキャパシティを表します。

Unified CCE におけるコール処理

この章のガイドラインを適用するのに先立って次に示す各項目を決定してください。これらの項目は Cisco Unified CallManager クラスタのスケーラビリティに大きな影響を及ぼします。

• カスタマー コール センター アプリケーションの要件（Unified IP IVR、Unified CVP、アウトバウンド、マルチチャネルなど）を決定します。

• Unified CCE で使用するコール センター リソースおよびデバイスのタイプ（ルート ポイント、CTI ポートなど）を決定します。 これらのリソースの多くは、「コール センターのリソース サイジング」で説明するように、IPC Resource Calculator を使用して計算できます。

–必要な Unified CCE エージェントの数

–必要な Unified IP IVR CTI ポートまたは Unified CVP ポート（あるいはセッション）の数

–CTI ルート ポイント（Unified ICM ルート ポイントおよび IVR ルート ポイント）の数

–GW ポートの数

–上記のすべてのエージェントおよびデバイスに関する Busy Hour Call Attempts（BHCA; 最頻時発呼数）の見積り（およびそれがインバウンドとアウトバウンドのいずれであるか）

–会議コールおよび転送コールの割合

• Cisco Unified Communications の他のすべてのカスタマー要件（Unified IP Phone、非 Unified CC アプリケーション、ルート パターンなど）を決定します。

• 要求される展開モデル（単一サイト型、中央集中型、分散型、WAN 経由のクラスタリング、リモート ブランチを含む中央集中型または分散型）を決定します。

• ネットワーク内のソリューション コンポーネント（ゲートウェイ、エージェント、Unified CVP など）の配置を決定します。

• コール フローおよびコール処理のタイプを決定します。たとえば次のようなタイプがあります。

–単純なコール フロー（IVR コール処理を伴わない IVR セルフサービスまたは直接エージェント転送）

単純なコール フローとは、複数回のコール処理が必要でないコール フローです（IVR セルフサービス、ゲートウェイから直接電話へ着信するコール、内部コールなど）。

–複雑なコール フロー（エージェント転送前の IVR コール処理またはデータベース参照、ルート ポイントへのコール リダイレクション、CTI ルート ポイント、CTI ポート、エージェント間転送および会議、エージェントからスキル グループへの相談または会議）

複雑なコール フローとは、複数回のコール リダイレクトや元のコールの処理を伴うコール フローです（たとえば、セントラル ルート ポイントへの着信コールを CTI ルート ポイントにリダイレクトしてから、コール処理のために Unified IP IVR にリダイレクトし、続いてエージェントなどの別のターゲットに転送またはリダイレクトするコール フローなど）。 このように元のコールを複数のセグメントで処理する場合、単純なコール処理に比べてより多くのサーバ リソースが消費されます。そのため、特定のサーバでサポートできるエージェントおよび BHCA の数が減少する場合があります。

Unified CC におけるクラスタリングのガイドライン

次のガイドラインは、Unified CCE で使用するすべての Cisco Unified CallManager クラスタに適用されます。

（注） クラスタには複数のサーバ プラットフォームを混在させることができますが、移行やアップグレードのとき以外は混在させないことを強くお勧めします。 すべてのプライマリ サーバとフェールオーバー バックアップ サーバのペアは、同じタイプにする必要があります。 クラスタ内のすべてのサーバでは、同じリリースとサービス パックの Cisco Unified CallManager ソフトウェアを実行する必要があります。

• Cisco Unified CallManager サービスは、1 つのクラスタ内で最大 8 つのサーバ（バックアップ サーバを含む）上で有効にできます。 さらに、TFTP、パブリッシャ、保留音などの機能に特化した専用サーバであれば、このクラスタに追加できます。

• バッテリ バックアップ式ライト キャッシュ（BBWC）が搭載された MCS-7845 サーバ 1 台あたりでは、JTAPI で監視されるデバイス（エージェントの電話機、CTI ルート ポイントまたは CTI ポート）を最大 2,500 台まで設定でき、BHCA を最大で 15,000 に設定できます。 つまり、クラスタあたりでは、JTAPI で監視されるデバイスを最大 10,000 台まで設定でき、BHCA を最大で 60,000 に設定できます。 BHCA の最大値を算出するにあたっては、繁忙時に 1 秒あたり 4.16 コールが一定の割合で到達すると仮定しており、1 秒あたりの平均コールの変動またはピークは小さい（20 % 未満のピーク、つまり 1 秒あたり 5 コール未満）と仮定しています。

• 1 つの Cisco Unified CallManager クラスタ（4 つのプライマリ サーバと 4 つのバックアップ サブスクライバ サーバ）は、最大で 2,000 の Unified CC エージェントをサポートできます。 この制限では、BHCA コール負荷およびすべての設定済みデバイスは、1:1 の冗長性を持たせて、8 つのコール処理サーバに均等に割り振られるものと想定します（冗長構成については「CallManager の冗長性」を参照してください）。 8 つの Cisco Unified CallManager サーバ（BBWC をインストールした MCS-7845 ハイパフォーマンス サーバ）はそれぞれ最大 250 エージェントをサポートします。 フェールオーバーの際は、プライマリ サーバが最大 500 のエージェントをサポートします。 これらのキャパシティは、個々の構成（コール フローが単純か複雑かなど）に応じて変化する可能性があります。キャパシティは、Cisco Unified CallManager Capacity Tool で確認できます（「Cisco Unified CallManager Capacity Tool」を参照してください）。

• デバイス（電話、保留音、ルート ポイント、ゲートウェイ ポート、CTI ポート、JTAPI ユーザ、および CTI Manager を含む）は、パブリッシャ上に配置または登録しないでください。 パブリッシャにデバイスが登録されている場合、コール処理および CTI Manager の稼働状況が Cisco Unified CallManager 上の管理作業の影響を受けます。

• パブリッシャをフェールオーバーまたはバックアップ コール処理サーバとして使用しないでください。ただし、エージェント電話が 50 台未満である場合や、ミッション クリティカルな環境または本稼働環境ではない場合はこの限りではありません。 Cisco MCS-7825 のサーバ タイプが Unified CC の展開でサポートされる最小のサーバです。 逸脱がある場合は、Cisco Bid Assurance によるケースごとの確認が必要です。

• エージェント電話が 50 台を超える場合は、2 つ以上のサブスクライバ サーバと、TFTP とパブリッシャの複合サーバ 1 つが必要です。

• 複数のプライマリ サブスクライバを必要とする構成の場合は、各クラスタ ノードのエージェント数が均等になるように配分します。 この設定により、すべてのエージェントの BHCA が均一になります（処理される平均 BHCA がすべてのノードでほぼ等しくなります）。

• 同様に、すべてのゲートウェイ ポートと Unified IP IVR CTI ポートを、クラスタ ノード間で均等になるように配分します。

• 複数の Unified ICM JTAPI ユーザ（CTI Manager）と複数のプライマリ サブスクライバが必要な場合は、同一の Unified ICM JTAPI ユーザ（サードパーティ アプリケーション プロバイダー）が監視するすべてのデバイス（Unified ICM ルート ポイントやエージェント デバイスなど）を、できる限り同一のサーバにグループ化して構成します。

• CTI Manager はコール処理サブスクライバだけで有効になる必要があります。したがって、1 つのクラスタで最大 8 つの CTI Manager を使用できます。 最大の耐性、パフォーマンス、および冗長性を提供するには、クラスタ内のさまざまな CTI Manager 間で CTI アプリケーションのロード バランスを調整することをお勧めします。 CTI Manager のベスト プラクティスについては、次の URL にある『 Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) 』を参照してください。

www.cisco.com/go/srnd

• クラスタに Unified CC と一般的なオフィスの Unified IP Phone を混在させている場合は、できる限り、タイプごとに独立したサーバにグループ化して構成します（必要なサブスクライバ サーバが 1 つしかない場合を除く）。 たとえば、クラスタのキャパシティが許す限り、すべての Unified CC エージェントとこれらに関連付けられたデバイスおよびリソース（ゲートウェイ ポートや CTI ポートなど）を持つ Cisco Unified CallManager サーバ（群）と、すべての一般的なオフィスの Unified IP Phone とこれに関連付けられたデバイス（ゲートウェイ ポートなど）を持つ Cisco Unified CallManager サーバ（群）を別々に配置します。 Cisco Unified CallManager Capacity Tool では、すべてのデバイスがクラスタ内で均等に配分されているものと想定されているので、特定のデバイス構成が設定されているプライマリ CCM サーバごとに、このツールを複数回実行する必要があります。 この場合は、1:1 の冗長構成を採用することを強くお勧めします（詳細については、「CallManager の冗長性」を参照してください）。

• 通常は、Cisco Unified CallManager クラスタからのすべてのサーバを同一の LAN または MAN に配置します。 あるクラスタのすべてのメンバを同一の VLAN またはスイッチに配置することは、お勧めしません。

• クラスタが IP WAN を介して構築されている場合は、IP WAN を介したクラスタリングに固有のガイドラインに従ってください。これについては、このガイドの「IPT： WAN 経由のクラスタリング」、および次の URL にある『 Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) 』ガイドの「 Clustering Over the IP WAN 」で説明しています。

www.cisco.com/go/srnd

• MCS-7845 またはそれに相当するサーバでは、トレース ファイルの場所を必ず F: ドライブに設定してください。 この設定は Cisco Unified CallManager のサービス パラメータで行います。 CTI のトレース ファイルの場所は、デフォルトでは C: ドライブ アレイに指定されています。 この設定が、ディスク I/O リソースへの影響が最も少ない設定です。

Cisco Unified CallManager と Unified CC がサポートするリリースに関する最新情報については、次の URL にある『 Cisco Unified CallManager Compatibility Matrix 』の最新バージョンを参照してください。

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/ccmcomp.htm

Cisco Unified CallManager のクラスタリングに関するガイドラインについては、次の URL にある『 Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) 』を参照してください。

www.cisco.com/go/srnd

Unified CC を使用した Cisco Unified CallManager プラットフォームのキャパシティ プランニング

Cisco Unified CallManager には、Unified IP Phone、Unified IP IVR ポート、ボイスメール ポート、CTI（TAPI/JTAPI）デバイス、ゲートウェイや、トランスコーディングやコンファレンシングなどの DSP リソースなどの、さまざまなタイプのデバイスを登録できます。 これらのデバイスのそれぞれについて、登録サーバ プラットフォームのリソースが必要になります。

必要なリソースにはメモリ、プロセッサ、I/O などがあります。トランザクション（通常はコールの形を取ります）の際には、各デバイスが消費するサーバ リソースがさらに増大します。 標準の Unified IP Phone のように 1 時間あたりのコール処理量が 6 回のデバイスの方が、Unified CC エージェント電話、ゲートウェイ ポート、Unified IP IVR ポートのように 1 時間あたりのコール処理量が 30 回のデバイスよりも、消費するリソースは少なくなります。

以前の Cisco Unified CallManager ソフトウェア リリースでは、システムのキャパシティを計算するため、デバイスの重み付け、BHCA 乗数、ダイヤル プランの重み付けを利用したさまざまなスキームを使用していました。 Cisco Unified CallManager リリース 4.x および 5.x 以降では、より正確なシステム プランニングを実現するため、これらのシンプルなスキームに代わってキャパシティ ツールが導入されました（「Cisco Unified CallManager Capacity Tool」を参照してください）。キャパシティ プランニング ツールは、現在のところシスコの従業員と Cisco のパートナーだけが利用できます。

（注） システムがこのドキュメントのガイドラインを満たしていない場合、またはシステムを複雑にする（Cisco Unified Communications と Unified CC を他のアプリケーションと混在させる）ことを検討している場合は、Cisco Unified CallManager クラスタの適切なサイジングについて、シスコのシステム エンジニアまでお問い合せください。

Cisco Unified CallManager Capacity Tool

Cisco Unified CallManager Capacity Tool（CCMCT）では、さまざまな情報を使用して、システムに必要なサーバの最小サイズとタイプを判定します。 必要な情報には、Unified IP Phone、ゲートウェイ、メディア リソースなどのデバイスの、タイプおよび数が含まれます。 また、デバイス タイプごとに、平均最頻時発呼数（BHCA）と平均最頻時トラフィック利用率も必要です。 たとえば、Unified CC のすべての電話から 1 時間あたり平均 25 回のコールが生成され、1 回のコール時間が平均 2 分の場合、BHCA が 25、利用率が 0.83 になります（1 時間に 2 分間のコールが 25 回、つまり 50 分なので、50/60 = 0.83）。 表9-1 に、Unified CC の展開に関連した CallManager Capacity Tool の入力パラメータを示します。

（注） Cisco Unified CallManager リリース 4.x および Cisco Unified CallManager 5.x を使用した場合、Cisco Unified CallManager サーバあたりの最大キャパシティは 500 エージェント、Cisco Unified CallManager クラスタ（MCS-7845 クラス）では 2000 エージェントですが（SSCP および SIP エージェント）、リリースおよびエージェント タイプにより消費されるサーバ リソースが異なることに注意してください。 既存の Unified CC を異なるリリースにアップグレードする場合は、ツールを実行して、既存のキャパシティおよび将来利用するキャパシティが確保されているかどうかを確認することを強くお勧めします。

Cisco Unified CallManager Capacity Tool には、デバイス情報に加え、ルート パターンやトランスレーション パターンなどのダイヤル プランに関する情報も入力する必要があります。

Unified CC に関する入力項目には、エージェント（インバウンドとアウトバウンド）、ゲートウェイ ポート用の Cisco Unified Customer Voice Portal（Unified CVP）または Unified IP IVR ポート、転送および会議に使用されるコールの割合などがあります。

すべての項目を入力すると、目的とするサーバ タイプのサーバの必要数が計算され、必要なキャパシティが単一クラスタを超える場合にはクラスタの数も計算されます。

Cisco Unified CallManager Capacity Tool は、現在のところシスコの従業員とパートナーだけが、次の URL で利用できます。

http://www.cisco.com/cgi-bin/CT/CCMCT/ct.cgi

Unified CCE をサポートする Cisco Unified CallManager サーバ プラットフォーム

Cisco Unified CallManager クラスタは、スケール、パフォーマンス、および必要な冗長性に応じて、さまざまな種類のサーバを使用できます。 その範囲は、冗長性のないシングルプロセッサ サーバから高度な冗長性を備えたマルチプロセッサ ユニットまで広がります。

Cisco Unified CallManager は、特定のハードウェア プラットフォームだけでサポートされます。 現在サポートされるハードウェア構成については、次の URL にある Cisco MCS 7800 シリーズ Unified CallManager アプライアンスのマニュアルを参照してください。

http://www.cisco.com/go/swonly

サーバ プラットフォームには特定のメモリ要件があります。この要件については、次の URL にある Product Bulletin 2864 の 「Physical Memory Recommendations For Cisco Unified CallManager Version 4.0 and Later」 を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_bulletin0900aecd80284099.html

表9-2 は、Unified CCE を展開するために Cisco Unified CallManager に使用できるサーバのタイプを、主な特性およびエージェントの推奨最大数とともに示しています。

表9-2 には次の注釈が適用されます。

• エージェントの最大キャパシティ（フェールオーバー キャパシティに対するサポートを含みます）は、Cisco Unified CallManager リリース 4.x と 5.x に基づくものです。 サーバあたりのエージェントの最大キャパシティは、使用する展開モデルによって異なる場合があるので、Cisco Unified CallManager Capacity Tool を使用して検証する必要があります。 一部の場合には、これらのエージェントの上限よりも多くのエージェントをサポートできると、キャパシティ ツールに表示される場合があります。 表9-2 に示されている上限に対して例外を設ける場合は、Cisco Bid Assurance の承認を受ける必要があります。

• 2 サーバのクラスタ（パブリッシャをバックアップとして使用します）を導入するときで、クラスタ内の Unified CC エージェントが 50 を超える場合（または Unified CC 以外のユーザが 1250 を超える場合）は、専用のパブリッシャが必要です。 Cisco Unified CallManager Capacity Tool では、この制限を超えることはできません。

• ロードバランス オプションは、パブリッシャがバックアップ コール処理サブスクライバのときは使用できません。

• Unified CCE の展開では Cisco MCS-7815 サーバはサポートされていませんが、試験ラボでの用途やデモ セットアップにはこのサーバを使用できます。 ただし、Cisco MCS-7815 サーバは、Cisco Unified CC ではない Cisco Unified Communications の展開でだけサポートされている Cisco Unified CallManager プラットフォームです。

• 具体的なサーバ メモリの推奨事項については、次の URL にある Product Bulletin 2864 の「 Physical Memory Recommendations For Cisco Unified CallManager Version 4.0 and Later 」を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_bulletin0900aecd80284099.html

サポートされるプラットフォーム、モデル、および具体的なハードウェア構成については、次のオンライン マニュアルを参照してくたさい。

http://www.cisco.com/en/US/products/hw/voiceapp/ps378/prod_brochure_list.html

このセクションで示したキャパシティは、通常の稼働設定で期待されるパフォーマンスを確保するための、設計ガイドラインです。 コール処理に直接関係しない機能を無効にしたり縮小したりすることによってパフォーマンスを改善することも可能です。 逆にこうした機能を追加した場合はシステムのコール処理のキャパシティが影響を受ける場合があります。 そのような機能としては、トレーシング、呼詳細レコード（CDR）、複雑性の高いダイヤル プラン、コール フロー、サーバに共存するその他のサービスなどが含まれます。 複雑性の高いダイヤル プランとしては、複数回線着信表示、多数のパーティション、コーリング サーチ スペース（CSS）、ルート パターン、トランスレーション、ルート グループ、ハント グループ、ピックアップ グループ、ルート リスト、大量の自動転送、複数サービスの共存、その他の共存アプリケーションなどがあります。 こうした機能を使用した場合、Cisco Unified CallManager サーバのメモリ リソースが大量に消費される可能性があります。 パフォーマンスを向上させるには、承認済みの対応メモリをプラットフォームでサポートされる最大容量まで増設してください。

Cisco Unified CallManager クラスタに、多数のゲートウェイ、ルート パターン、トランスレーション パターン、およびパーティションを含む非常に大規模なダイヤル プランが設定されている場合、Cisco Unified CallManager サービスを最初に起動する際の初期化に非常に時間がかかることがあります。 デフォルトの時間内にシステムが初期化されない場合は、サービス パラメータを調整することによって許容される初期化時間を修正できます。 サービス パラメータの詳細については、Cisco Unified CallManager Administration でサービス パラメータに関するオンライン ヘルプを参照してください。

CallManager の冗長性

Cisco Unified CallManager では、次の 2 つの冗長構成から選択できます。

• 2:1 ó プライマリ サブスクライバ 2 つに対して、バックアップ サブスクライバ 1 つ。

• 1:1 ó プライマリ サブスクライバ 1 つに対して、バックアップ サブスクライバ 1 つ。

コンタクト センターでは電話の使用率が高く、アップグレード時のダウンタイムも長くなるので、Unified CCE を使用した CallManager の展開には、2:1 の冗長構成を使用しないことをお勧めします。

図9-1 に、これら 2 つのオプションを示します。 この図には、コール処理サブスクライバだけが表示され、パブリッシャ、TFTP、または保留音（MoH）などのサーバは表示されていません。 その他のクラスタ展開および冗長化オプションの詳細については、 www.cisco.com/go/srnd にある『 Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) 』の最新バージョンを参照してください。

図9-1 基本的な冗長構成

図9-2 では、表示されている 5 つのオプションのすべてが 1:1 のサブスクライバの冗長化を実現しています。 オプション 1 は Unified CC エージェントが 50 未満のクラスタに使用します。 オプション 2 から 5 までは、段階的に大きなクラスタを示します。 正確なサーバ数は、選択された、または必要となるハードウェア プラットフォームによって異なり、Cisco Unified CallManager Capacity Tool によって決定されます。

図9-2 1:1 の冗長構成のオプション

Cisco Unified CallManager のロード バランシング

1:1 の冗長構成を採用するもう 1 つの利点は、プライマリとバックアップのサーバ ペアのデバイスのバランスを調整できることです。 通常は（2:1 の冗長構成と同様に）プライマリ サーバが利用不可能にならない限り、バックアップ サーバにデバイスは登録されません。

ロード バランシングを行うと、Cisco Unified CallManager 冗長グループおよびデバイス プール設定を使用してプライマリ サーバからセカンダリ サブスクライバに最大で半分のデバイス負荷を移すことができます。 これにより、いずれかのサーバが利用できなくなった場合の影響を半分に減らすことができます。

50/50 のロード バランシングを設計するには、まずロード バランシングを行わない状態のクラスタのキャパシティを計算し、次にこの負荷を、デバイスと呼量に基づいてプライマリおよびバックアップ サブスクライバに配分します。 プライマリまたはバックアップの障害に備えて、プライマリおよびセカンダリ サブスクライバの総負荷が 1 つのサブスクライバの総負荷を超えないようにします。 たとえば、MCS-7845 サーバの総負荷の上限は 500 Unified CC エージェントです。 この場合、1:1 の冗長ペアでは 2 つのサブスクライバに 250 エージェントずつ負荷を分割できます（500 エージェントの構成は図9-2 を参照してください）。 フェールオーバーでアクティブなサーバが 1 つになる状況に備えて、冗長系にかかる Unified CC エージェント電話、Unified IP Phone、CTI などの負荷が、いずれも 1 つのサーバの負荷の上限を超えないようにしてください。

すべてのデバイスとコールの量を、すべてのアクティブ サブスクライバにできるだけ平等に配布することをお勧めします。 たとえば、Unified CC エージェント、CTI ポート、ゲートウェイ、トランク、音声メール ポート、およびその他のユーザおよびデバイスをすべてのサブスクライバに平等に分散することにより、停止の影響を最小限にとどめることができます。

セカンダリ TFTP サーバやゲートキーパーなどの一般的なコール処理の詳細については、次の URL にある『 Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) 』を参照してください。

www.cisco.com/go/srnd

Cisco Unified CallManager のアップグレード手順

1:1 の冗長構成では、アップグレードの際にクラスタが影響を受ける時間をフェールオーバー時間だけに限定できます。 1:1 の冗長構成では、次に示す手順でクラスタをアップグレードできます。

ステップ 1 パブリッシャ サーバをアップグレードします。

ステップ 2 専用 TFTP サーバおよび Music on Hold（MoH; 保留音）サーバをアップグレードします。

ステップ 3 バックアップ サブスクライバを 1 つずつアップグレードします。 50/50 のロード バランシングを設定している場合、この手順を実行すると一部のユーザが影響を受けます。

ステップ 4 プライマリ サブスクライバをそれぞれのバックアップ系にフェールオーバーした後、プライマリ サブスクライバの Cisco Unified CallManager サービスを停止します。 Cisco Unified CallManager サービスが停止されると、プライマリ サブスクライバのすべてのユーザがバックアップ サブスクライバに移動します。 CTI Manager も停止され、これによって Peripheral Gateway（PG; ペリフェラル ゲートウェイ）のサイドが切り替わり、該当するノードのエージェントが短時間停止されます。

ステップ 5 プライマリ サブスクライバをアップグレードし、Cisco Unified CallManager サービスを再び有効にします。

このアップグレード方法では、バージョンの異なる Cisco Unified CallManager ソフトウェアを実行中にサブスクライバ サーバにデバイスが登録される時間を、フェールオーバー時間だけに限定できます。 この特徴が重要な意味を持つのは、サブスクライバ間通信を行う Intra-Cluster Communication Signaling（ICCS）プロトコルがソフトウェアのバージョンの違いを検出して、該当するサブスクライバへの通信をシャットダウンする可能性があるためです。

2:1 の冗長構成を採用した場合は、クラスタ内のサーバ数を抑制できますが、アップグレード中に停止が発生する可能性があります。 Unified CC を展開する場合には、この構成を使用しないことをお勧めします。ただしシステム要件においてコール処理の停止が重大な問題とならない場合には、この構成も選択肢の 1 つになります。

2:1 の冗長構成では、次に示す手順でクラスタをアップグレードできます。 Cisco Unified CallManager サービスがパブリッシャ データベース サーバで実行されていない場合は、次の順序でサーバをアップグレードします。

ステップ 1 パブリッシャ データベース サーバをアップグレードします。

ステップ 2 Cisco TFTP サーバがパブリッシャ データベース サーバから独立して存在する場合は、Cisco TFTP サーバをアップグレードします。

ステップ 3 Cisco Unified CallManager に関連するサービス（保留音、Cisco IP Media Streaming Application など）だけが実行されるサーバをアップグレードします。 サーバのアップグレードは必ず一度に 1 つ行ってください。 これらのサーバで Cisco Unified CallManager サービスが実行されていないことを確認してください。

ステップ 4 バックアップ サーバを 1 つずつアップグレードします。

（注） アップグレード中にバックアップ サーバをオーバーサブスクライブすることは、お勧めできません。 アップグレード中は、バックアップ サーバに登録する Unified CC エージェント数を 500 以下にしてください。 アップグレードは、ピーク時を避けてコールの量の少ない時間帯に実施してください。

ステップ 5 Cisco Unified CallManager サービスが実行される各プライマリ サーバをアップグレードします。 サーバは 1 つずつアップグレードしてください。 2 番目のプライマリ サブスクライバのアップグレード中、このサーバに登録されたユーザおよびエージェントが短時間停止されます。 同様に、4 番目のプライマリ サブスクライバのアップグレード中も、このサーバに登録されたユーザおよびエージェントが短時間停止されます。

Unified CC アプリケーションが Cisco Unified CallManager のパフォーマンスとスケーラビリティに及ぼす影響

Cisco Unified CallManager システムのパフォーマンスは、次を含む多くの要因に影響されます。

• ソフトウェア リリースのバージョン

• 次のような登録デバイスのタイプと数量

–CTI ポート

–ゲートウェイ ポート

–エージェント電話

–ルート ポイント

–CTI Manager

–他の Cisco Unified Communications または CTI アプリケーション

• これらのデバイスによって処理される負荷（BHCA）：コール レートが上昇するにつれて、Cisco Unified CallManager サーバで消費されるリソースも増大します。

• 平均コール時間：平均コール時間が長いほど最頻時コール完了レートが下がり、CPU 使用率など一部のサーバ リソースが低下します。

• 次に示すサービスの Cisco Unified CallManager 構成への追加

–MOH

–トレーシング レベル

• サーバ プラットフォームのタイプおよびモデル

• アプリケーション コール フローの複雑さ（コール フローの複雑さについては「Unified CCE におけるコール処理」を参照してください）

–IVR セルフサービス

–コール処理

–エージェントへのルーティング

–転送および会議

• テストの結果によると、H.323 ゲートウェイによる Unified IP IVR を使用した複雑なコール フロー（コール処理の後エージェントに転送）では、Unified CVP（H.323 ゲートウェイ）を使用した同じコール フローに比べて CPU 使用率が上昇します。 このような差が生じるのは、Unified CVP ではコール処理の前にコールが Cisco Unified CallManager にルーティングされる必要がなく、コールがエージェントに転送されるときだけ、Cisco Unified CallManager が関与するためです（単純なコール処理）。 ただし、Unified CVP ゲートウェイはパフォーマンス要件が高くなります。 Unified CVP の詳細については、次の URL にある『 Cisco Unified Customer Voice Portal Solution Reference Network Design (SRND) 』を参照してください。

http://www.cisco.com/go/srnd

• 同様に、Media Gateway Control Protocol（MGCP; メディア ゲートウェイ コントロール プロトコル）ゲートウェイがあり、かつ Unified IP IVR を使用しているような複雑なコール フローでは、Unified CVP（H.323 ゲートウェイ）を使用する同じコール フローに比べて CPU 使用率の上昇が見られます。 このような差が生じるのは、Unified CVP のコール ルーティング方法（前の段落を参照）、および H.323 ゲートウェイ プロトコルでは MGCP よりも多くの CPU リソースが使用されることが原因です。

• Unified CVP 構成を使用し、コール フロー構成を単純にし、コールの着信レート（BHCA）を低減すれば、Cisco Unified CallManager サブスクライバ サーバあたり 500 を超える Unified CC エージェント、または Cisco Unified CallManager クラスタ（8 サブスクライバ）あたり 2,000 を超えるエージェントをサポートできる可能性があります。 システム要件に適したサイジングについては、シスコのシステムエンジニア（SE）に問い合せるか、Cisco Unified CallManager Capacity Tool を参照してください。

• 有効なトレース レベル

Cisco Unified CallManager の CPU リソース消費は、有効なトレース レベルによって変化します。 Cisco Unified CallManager でトレース レベルを［既定値］から［最大レベル］に変更すると、高負荷時に CPU 消費が著しく増大する可能性があります （トレース レベルを［既定値］から［トレースなし］に変更すると、高負荷時に CPU 消費が著しく減少する可能性がありますが、この設定はお勧めできません。また、Cisco Technical Assistance Center でもこの設定はサポートされません）。 デフォルトのトレースによる CPU 消費は、負荷、Cisco Unified CallManager のリリース、インストールされたアプリケーション、コール フローの複雑さなどによって異なります。

• メモリ消費とディスク I/O リソース（バッテリ バックアップ式ライト キャッシュ）

• 電話の認証および暗号化

複数のプライマリ Cisco Unified CallManager サーバを使用する場合は、すべてのリソースをできるだけ均等に配分することが重要です。 リソースのバランスを取ることにより、他のサーバのために 1 つのサーバに過大な負荷がかかることを防止できます。