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

Cisco Unified Communications Manager サーバのサイジング

---

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

この章では、Unified CM クラスタを使用した Unified CCE のオペレーションに限定して説明し、実装のための参考デザインを示します。

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

この章では、Unified CCE で使用する Unified CM サーバのサイジングにあたっての、一般的なベスト プラクティスおよびスケーラビリティに関する考慮事項を示します。このドキュメントでスケーラビリティとは、Unified CCE 環境で使用する限りにおいての、Unified CM サーバおよびクラスタのキャパシティを表します。ゲートウェイのサイジングと選択の詳細については、『 Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 』の最新バージョン（ http://www.cisco.com/go/designzone で参照できます）でゲートウェイの情報を参照してください。

この章の新トピック

表 11-1 は、この章の新トピックまたはこのマニュアルの前リリースから大幅な変更があったトピックの一覧です。

クラスタのサイジングの概念

Unified CCE 展開で Unified CM クラスタのサイジングを試みる前に、次の設計タスクを実行する必要があります。

• さまざまなコール フローのタイプを決定します。

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

• コール処理、セルフ サービス、キューイングに Cisco Unified Voice Portal（CVP）と Cisco Unified IP Interactive Voice Response（IP IVR; 音声自動応答装置）のどちらを使用するかを決定します。

• 使用するプロトコルを決定します。

• 冗長性の要件を決定します。

• Unified CCE 展開と Unified CM クラスタを共有する Cisco Unified Communications の他のすべてのカスタマー要件（Cisco Unified IP Phone、非 Unified CCE アプリケーション、ルート パターンなど）を決定します。

これらのタスクを完了すると、必要な Unified CM クラスタを正確にサイジングできます。Unified CM クラスタのサイジングに影響を及ぼす要因は数多くありますが、その一部を次に列挙します。

• オフィスの電話数と電話ごとの Busy Hour Call Attempts（BHCA; 最頻時発呼数）レート

• インバウンドのエージェント電話数と電話ごとの BHCA レート

• Computer Telephony Integration（CTI; コンピュータ テレフォニー インテグレーション）ポート数と各 Voice over IP（VoIP; ボイス オーバー IP）エンドポイントの BHCA レート（コール処理、セルフ サービス、キューイングに CVP を利用するとゼロにすることも可能）

• 音声ゲートウェイ ポート数と各 VoIP エンドポイントの BHCA レート

• アウトバウンドのエージェント電話数、アウトバウンド ダイヤリング モード、電話ごとの BHCA レート

• アウトバウンドのダイヤラ ポート数、アウトバウンド キャンペーン用の IVR ポート数、両方のポートごとの BHCA レート

• モバイル エージェント数とモバイル エージェントごとの BHCA レート

• 音声メール ポート数と各 VoIP エンドポイントの BHCA レート

• VoIP エンドポイントが使用するシグナリング プロトコル

• エージェント コール転送および会議の割合

• ダイヤル プランのサイズと複雑さ（着信番号、回線、パーティション、コーリング サーチ スペース、ロケーション、地域、ルート パターン、トランスレーション、ルート グループ、ハント グループ、ピックアップ グループ、ルート リストなどの数）

• トランスコーディング、会議、暗号化などの機能に必要なメディア リソースの数

• Auto Attendant、CTI Manager、E-911、および Music On Hold などの共存アプリケーションおよびサービス

• Unified CM リリース（サイジングはリリースごとに異なります）

• 必要なハードウェア サーバのモデル（サイジングはハードウェア サーバのモデルごとに異なります）

他の要因がクラスタのサイジングに影響を及ぼす可能性もありますが、リソース消費の点で最も重大なのは上記の要因です。

Unified CM クラスタのサイジングで一般的な手順は、要因ごとにリソース消費量（CPU、メモリ、および I/O）を見積もってから、リソース要件を満たすハードウェアを選択することです。

正確なクラスタのサイジングを試みる前に、上記の要因に関連する情報を収集することが重要です。Unified CCE に関連するこれらの数値の計算を容易にするために、「コール センターのリソース サイジング」の章で説明する Unified CCE Resource Calculator の使用をお勧めします。

次の項では、Cisco Unified CM 展開のサイジング ツールについて説明します。

サイジング ツール

Cisco Unified Communications 展開のキャパシティ プランニング ツールには、Cisco Unified Communications Sizing Tool（Unified CST）および Cisco Unified Communications Manager Capacity Tool があります。これらのツールは、次の URL から入手できます。

http://www.cisco.com/web/partners/sell/technology/ipc/integrated-solutions/customer_contact_center.html

適切なログイン認証が必要です。サイジング ツールは、シスコ社内の従業員とシスコのパートナーが利用できます。

Cisco Unified CM Capacity Tool

Cisco Unified Communications Manager Capacity Tool では、さまざまな情報を使用して、Unified CM クラスタに必要なサーバの最小サイズとタイプを判定します。この項では、Cisco Unified CCE 専用のキャパシティ ツールである Unified CM Capacity Tool への入力を重点的に扱います。Cisco Unified CCE だけの構成でない展開向けの他のキャパシティ ツールの入力の詳細については、『 Cisco Unified Communications SRND 』を参照してください。

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

 

---

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

---

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

キャパシティ ツールを利用する前に、コンタクト センターの入力フィールドに関連する次の情報、ガイドライン、考慮事項を確認してください。

Unified CCE CTI Manager の入力

オプションは、"1 PG / CTI Manager per cluster" および "1 PG / CTI Manager per subscriber" です。詳細については、「Unified CM クラスタへの Agent PG の配置」を参照してください。

Unified CCE エージェントの入力

エージェントの BHCA と平均通話時間は反比例します。Resource Calculator に全エージェントの BHCA の総数とエージェントの平均コール通話時間および平均アフターコール ワーク時間を入力し、必要なエージェントの数を決定します。ただし、キャパシティ ツールにはエージェントごとの BHCA が必要です。この値を計算するには、60（1 時間の分数）をエージェントの平均処理時間（通話時間＋アフターコール ワーク時間）の分数で割る必要があります。たとえば、平均通話時間が 3 分でアフターコール ワーク時間が 1 分のエージェントの BHCA は 15（60/4）です。一般に、エージェントごとの BHCA レートが低ければ、クラスタごとにサポートするエージェントを増やすことができます。

コンタクト センターの多くには、BHCA レート、通話時間、アフターコール ワーク時間の異なるさまざまなエージェント グループがあります。特性の異なる複数のエージェント グループを考慮するには、加重平均を算出します。Cisco Unified CM Capacity Tool のオンライン ヘルプには、加重平均の計算例が掲載されています。

CVP プロンプトとコレクト/キューイングとセルフ サービスの入力

コンタクト センターへのコールが CVP 経由で処理またはキューイングされて Unified CCE エージェントに転送されるとき、コールは H.323 ゲートウェイから着信したのと同じように Unified CM に着信します。このリソース消費量を計算するには 2 つの方法があります。1 つ目の方法は、CVP ポートの概数を入力し、H.323 ゲートウェイ フィールドを空のままにする方法です。CVP ポートの数は Unified CM に影響を与えないため、キャパシティ ツールは CVP ポート入力フィールドにゼロより大きい値があれば CVP が処理またはキューイングに使用されると単純に解釈します。キャパシティ ツールは H.323 の送信を自動的にエージェントのリソース消費の一部と見なします。Unified CM に対して影響を与えるのは選択されたエージェントへのコール転送だけなので、CVP ポートの数が変動してもリソース消費量には影響ありません。

CVP を使用した展開のサイジングでとれる 2 つ目の方法は、CVP 入力フィールドを空のままにして、エージェント数とエージェントごとの BHCA を H.323 DS0 入力フィールドにコピーする方法です。2 つの方法とも、リソース消費量は同じになります。

IP IVR プロンプトとコレクト/キューイングの入力

IVR ポートの BHCA と平均処理時間は反比例します。Unified CCE Resource Calculator に平均コール処理時間を入力します。Resource Calculator はこのコール処理時間がすべてのエージェント コールの開始に適用されるものと見なすため、コール処理用の IVR ポートに対する総 BHCA レートは、エージェント全体の BHCA レートと等しくなります。これらの入力から、Resource Calculator はコール処理とキューイングに必要な IVR ポート数を算出します。ただし、Cisco Unified CM Capacity Tool には IVR ポートごとに BHCA を入力する必要があります。この値を計算するには、60 を平均コール処理時間と Average Speed of Answer（ASA; 平均応答スピード）の合計で割ります。たとえば、IVR ポートのコール処理が平均 45 秒で ASA が 15 秒の場合、IVR ポートのコールごとの平均処理時間は 1 分で、IVR ポートごとの BHCA は 60（60/1）です。コール処理時間や ASA が一定しないサービスがある場合は、加重平均を計算する必要があります。

IP IVR セルフ サービスの入力

IP IVR セルフ サービスの入力フィールドでも、Unified CCE Resource Calculator を使用して、セルフ サービス アプリケーション用の IVR ポート数を決定することができます。ただし、Cisco Unified CM Capacity Tool には、セルフ サービス用の IVR ポートごとに BHCA を入力する必要があります。この値を算出するには、60 をセルフ サービスの平均コール継続時間で割ります。セルフ サービス アプリケーションによって処理時間が異なる場合は、加重平均を算出する必要があります。

CTI ルート ポイントの入力

この入力は、コール センター処理を必要とするコール センターの着信番号の数量です。入力された CTI ルート ポイントの数が、Unified CM リソース消費量に与える影響は最小限です。ICM JTAPI ユーザに関連する CTI ルート ポイントの処理のリソース消費量は、Unified CCE エージェントのリソース消費量に含まれます。IP IVR JTAPI ユーザに関連する CTI ルート ポイントの処理のリソース消費量は、IP IVR ポートのリソース消費量に含まれます。

音声ゲートウェイの入力

音声ゲートウェイの数が Unified CM のリソース消費量に与える影響は最小限ですが、DS0 の数と DS0 ごとの BHCA はリソース消費量に重大な影響を及ぼします。

Unified CCE Resource Calculator は、Cisco Unified CM Capacity Tool への入力に必要な音声ゲートウェイ ポートの数を決定します。ただし、音声ゲートウェイ ポートごとの BHCA を算出するためには、60 を、音声ゲートウェイ ポートを使用するコールの平均コール継続時間で割る必要があります。音声ゲートウェイを使用するコールの平均コール継続時間は、コール処理時間、セルフ サービス アプリケーションの時間、平均キューイング時間、エージェントの通話時間の合計です。たとえば、平均コールのコール処理時間が 60 秒で、120 秒のセルフ サービス、30 秒のキューイング、150 秒のエージェント通話時間が続く場合、音声ゲートウェイ ポートを使用するコールの平均コール継続時間は、360 秒（6 分）です。したがって、音声ゲートウェイ ポートごとの BHCA は 10（60/6）です。ほとんどのコール センターで、平均コール継続時間の算出には加重平均の計算が必要です。Cisco Unified CM Capacity Tool のオンライン ヘルプには、加重平均の例が掲載されています。

転送および会議の割合の入力

転送または会議が他のエージェント宛ての場合、これらのコールをエージェント数およびエージェントごとの BHCA レートで計上してください。

CTI サードパーティ制御回線

電話を保持しているがアクティブではないエージェントも考慮する必要があります。理由は、エージェントがログインしていなくても電話は JTAPI の監視対象になっているからです。このフィールドはこのような状況のために使用します。たとえば、1500 のエージェントが構成され、最大 500 のエージェントが常時同時にログインしているシナリオでは、[Unified CCE Agent Inputs] フィールドに 500 を入力し、[CTI 3rd-Party Controlled Lines] フィールドに 1000 を入力します 。[CTI 3rd-Party Controlled Lines] の 1000 に対しては、Cisco Unified CM Capacity Tool の [BHCA] および [BHT] カラムに 0 を入力します。

他のキャパシティ ツールへの入力

キャパシティ ツールのコンタクト センター セクションの情報に加えて、トランスコーディング、Media Termination Points（MTP; メディア ターミネーション ポイント）、会議リソース、ダイヤル プランに関する情報の入力も重要です。

クラスタのガイドラインおよび考慮事項

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

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

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

• Cisco Media Convergence Server（MCS; メディア コンバージェンス サーバ）-7845 サーバ モデルごとに CTI で監視されるデバイス（たとえば、ログインしているエージェントの電話、ログインしていないエージェントの電話、CTI ルート ポイント、JTAPI 経由の録音アプリケーションで監視される エージェントの電話、CTI サードパーティ コール制御を使用するデスク電話モードのソフト クライアントなど）を 2,500 まで設定できます。つまり、クラスタごとの CTI で監視されるデバイスの最大数は 10,000 となります。Cisco Unified CM 7.1(2) より、CTI のキャパシティの上限が増え、Cisco MCS-7845-H2 ではサーバごとに 3,375 の CTI デバイス、クラスタごとに 13,500 のデバイスがサポートされます。これらのキャパシティは、個々の展開に応じて変化する可能性があります。展開はすべて、Cisco Unified CM Capacity Tool または Cisco Unified Communications Sizing Tool でサイジングする必要があります。また、Unified CM Capacity Tool または Unified Communications Sizing Tool に入力された CTI で監視または制御されるデバイスの BHCA は、1 秒あたりの平均コールの変動またはピークが小さく（20% 未満）、一貫性のあるコールの着信レートを反映している必要があります。

• IP IVR の展開で、各 Unified CM クラスタ（4 つのプライマリ サーバと 4 つのバックアップ サブスクライバ サーバ）は最大で約 2,000 の Unified CCE エージェントをサポートできます。この制限では、BHCA コール負荷およびすべての設定済みデバイスは、1:1 の冗長性を持たせて、8 つのコール処理サーバに均等に割り振られるものと想定します（冗長構成については、「Unified CM の冗長性」を参照してください）。8 つの Unified CM サーバ（MCS-7845 ハイパフォーマンス サーバ）はそれぞれ最大 250 エージェントをサポートします。フェールオーバーの際は、プライマリ サーバが最大 500 のエージェントをサポートします。これらのキャパシティは、個々の展開に応じて変化する可能性があります。展開はすべて、Cisco Unified CM Capacity Tool または Unified Communications Sizing Tool でサイジングする必要があります。Unified CM Capacity Tool または Unified Communications Sizing Tool の出力に従うと、展開によっては、サブスクライバ ノードのペアごとに 500 またはクラスタごとに 2,000 を超えるエージェントがサポートされることもあります。

• Unified CM 7.0 および Unified CVP（非 IP IVR）を使用する展開で、各 Unified CM クラスタ（4 つのプライマリ サーバと 4 つのバックアップ サブスクライバ サーバ）は最大で約 4,000 の Unified CCE エージェントをサポートできます。この制限では、BHCA コール負荷およびすべての設定済みデバイスは、1:1 の冗長性を持たせて、8 つのコール処理サーバに均等に割り振られるものと想定します（冗長構成については、「Unified CM の冗長性」を参照してください）。8 つの Unified CM サーバ（MCS-7845-H2 またはそれ以降のハイパフォーマンス サーバ）はそれぞれ最大 500 エージェントをサポートします。フェールオーバーの際は、プライマリ サーバが最大 1,000 のエージェントをサポートします。これらのキャパシティは、個々の展開に応じて変化する可能性があります。展開はすべて、Cisco Unified CM Capacity Tool または Unified Communications Sizing Tool でサイジングする必要があります。

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

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

• エージェント電話が 150 台を超える場合は、2 つ以上のサブスクライバ サーバと、TFTP とパブリッシャの複合サーバ 1 つが必要です。ロードバランス オプションは、パブリッシャがバックアップ コール処理サブスクライバのときは使用できません。

• 複数のプライマリ サブスクライバを必要とする構成の場合は、各サブスクライバ ノードのエージェント数が均等になるように配分します。この構成は、BHCA がすべてのエージェントにわたって一定であることを前提とします。

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

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

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

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

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

• 可能であれば、ハードウェアベースの会議リソースを使用することをお勧めします。ハードウェア会議リソースはより費用効果の高いソリューションを提供し、Unified CM クラスタ内でのスケーラビリティにも優れています。

• Unified CCE ペリフェラル ゲートウェイ（PG）JTAPI ユーザに関連付けられた CTI ルート ポイントはすべて、その Unified CCE PG と通信する CTI Manager インスタンスを実行しているサブスクライバ ノードに登録するよう設定します。

• Cisco Unified CM Capacity Tool および Unified Communications Sizing Tool は現在、各サーバに対する CTI Manager の影響を別途測定することはしません。ただし、実際には、CTI Manager プロセスを実行しているサブスクライバ ノードには追加の負荷がかかります。Cisco Unified CM Capacity Tool および Unified Communications Sizing Tool によってレポートされるリソース消費は、これらのノードに基づきます。その他の Cisco Unified CM ノードでの実際のリソース消費は、これよりも若干少なくなる可能性があります。

• ICM PG JTAPI ユーザに関連付けられたデバイスは、コール センター エージェントによって使用されていなくても、エージェント デバイスとしてカウントされます。これは、その電話がエージェントによって使用されているかどうかにかかわらず、PG にはその電話のデバイス状態変更がすべて通知されるためです。クラスタのスケーラビリティを向上させるため、コール センター エージェントが通常使用する可能性が低いデバイスは、ICM PG JTAPI ユーザに関連付けないことをお勧めします。

• 多数の IVR ポートが必要な展開では、IP IVR の代わりに Unified CVP を使用することをお勧めします。IP IVR ポートを使用すると、Unified CM でのコール処理に大きな負荷がかかりますが、Unified CVP ではそのようなことはありません。したがって、Unified CCE 展開に CVP を含めると、より多くのエージェントを投入して、クラスタあたりの BHCA レートを向上させることができます。展開はすべて、Cisco Unified CM Capacity Tool または Unified Communications Sizing Tool でサイジングする必要があります。

• 展開に複数の IP IVR を含める場合は、コール処理をクラスタ内でバランスよく分散させるために、IP IVR サーバを異なるサブスクライバ ノード上の異なる CTI Manager に関連付けることをお勧めします。

• Unified CM の CPU リソース消費は、有効なトレース レベルによって変化します。Unified CM でトレース レベルを [Default] から [Full] に変更すると、高負荷時に CPU 消費が著しく増大する可能性があります。トレース レベルを [Default] から [No tracing] に変更すると、高負荷時に CPU 消費が著しく減少する可能性がありますが、この設定はお勧めできません。また、Cisco Technical Assistance Center でもこの設定はサポートされません。

• 通常は、Unified CM クラスタのすべてのサーバを同一の LAN または Metropolitan Area Network（MAN; メトロポリタン エリア ネットワーク）に配置します。あるクラスタのすべてのメンバを同一の VLAN またはスイッチに配置することは、お勧めしません。

• クラスタが IP WAN を介して構築されている場合は、IP WAN を介したクラスタリングに固有のガイドラインに従ってください。これについては、このガイドの「IPT：WAN 経由のクラスタリング」、および次の URL にある『 Cisco Unified Communications Solution Reference Network Design (SRND) 』ガイドの「 Clustering Over the IP WAN 」で説明しています。

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

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

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

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

Unified CM のクラスタリングに関するガイドラインについては、次の URL にある『 Cisco Unified Communications Solution Reference Network Design (SRND) 』を参照してください。

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

Unified CM サーバ

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

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

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

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

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

Unified CM 展開をサイジングするには、Cisco Unified CM Capacity Tool または Unified Communications Sizing Tool を使用する必要があります。このツールは、各種プラットフォームに必要な Unified CM サーバの数を示します。

Unified CM サブスクライバが 1 つしかない Unified CM 展開は、ミッションクリティカルなコンタクト センター展開や、エージェント数が 150 を超える展開では避けてください。 表 11-2 に、Unified CM サブスクライバ サーバを 1 つだけ配置し、Unified CM パブリッシャをバックアップとして使用するシステムでのエージェントの最大数を示します。

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

Unified CM の冗長性

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

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

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

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

図 11-1 に、これら 2 つのオプションを示します。この図に示されているのはコール処理サブスクライバだけであり、パブリッシャ、TFTP、Music on Hold（MoH）、その他のサーバは示されていません。その他のクラスタ展開および冗長化オプションの詳細については、http://www.cisco.com/go/designzone にある『 Cisco Unified Communications Solution Reference Network Design (SRND) Guide 』の最新バージョンを参照してください。

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

図 11-2 では、表示されている 5 つのオプションのすべてが 1:1 のサブスクライバの冗長化を実現しています。オプション 1 は、サポートされている任意のバージョンの Unified CM で 150 未満の Unified CCE エージェントをサポートするクラスタに使用します。オプション 2 から 5 までは、段階的に大きなクラスタを示します。この図に示す N は、Unified CM 7.0 と Unified CVP（IP IVR ではない）を含む展開では、1000 です。IP IVR を含む展開では、500 です。その他のタイプの展開では、Cisco Unified CM Capacity Tool または Unified Communications Sizing Tool を使用します。どのタイプの展開でも、正確なサーバ数は、選択されたハードウェア プラットフォームまたは必要となるハードウェア プラットフォームによって異なり、Cisco Unified CM Capacity Tool または Unified Communications Sizing Tool によって決定されます。

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

Unified CM のロード バランシング

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

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

50/50 のロード バランシングを設計するには、まずロード バランシングを行わない状態のクラスタのキャパシティを計算し、次にこの負荷を、デバイスと呼量に基づいてプライマリおよびバックアップ サブスクライバに配分します。プライマリまたはバックアップの障害に備えて、プライマリおよびセカンダリ サブスクライバの総負荷が 1 つのサブスクライバの総負荷を超えないようにします。たとえば、Unified CVP と Unified CM 7.0 以降を配置している場合、MCS-7845 サーバの総負荷の上限は 1,000 Unified CCE エージェントです。この場合、1:1 の冗長ペアでは 2 つのサブスクライバに 500 エージェントずつ負荷を分割できます。システムの耐障害性を確保するため、サブスクライバ ペアに対する Unified CCE エージェント電話、Unified IP Phone、CTI などの負荷が、いずれも 1 つのサブスクライバ サーバの負荷の上限を超えないようにしてください。

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

セカンダリ TFTP サーバやゲートキーパーなどの一般的なコール処理の詳細については、次の URL にある『 Cisco Unified Communications Solution Reference Network Design (SRND) 』ガイドを参照してください。

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

Unified CM クラスタへの Agent PG の配置

Agent PG は、次のいずれかの方法で Unified CM クラスタに配置できます。

• 1 つ目の方法では、Cisco Unified CM サブスクライバ ノードのペアごとに Agent PG を配置します。この場合は、各 Unified CM サブスクライバ ノードで CTI Manager サービスが実行され、各 Agent PG はその対応する Unified CM サブスクライバ ペアで実行されている CTI Manager に接続します。次の図は、4 つのプライマリ Unified CM サブスクライバが必要で、4 つのバックアップ Unified CM サブスクライバが 1:1 の冗長性で配置されている例を示しています。

• もう 1 つの方法では、Cisco Unified CM クラスタ全体に対して Agent PG を 1 つ配置します。この展開タイプでは、CTI Manager を実行する Cisco Unified CM サブスクライバ ノードのペアが 1 つ必要です。エージェント電話の登録は、すべての Cisco Unified CM サブスクライバ ノード（CTI Manager サービスを実行している Unified CM サブスクライバを含む）に及びます。次の図は、4 つのプライマリ Unified CM サブスクライバが必要で、4 つのバックアップ Unified CM サブスクライバが 1:1 の冗長性で配置されている例を示しています。

このモデルの利点の 1 つは、PG のサーバ数を減らせることです。その他に、Unified CM クラスタ全体に対して Peripheral Interface Manager（PIM; ペリフェラル インターフェイス マネージャ）が 1 つだけ存在するという利点もあります。これにより、多数の Unified CM サブスクライバにまたがるチームを作成し、たとえばスーパーバイザが Unified CM クラスタ内の任意の Unified CM サブスクライバ ノードに登録されているエージェント電話を監視することが可能となります。ただし、この展開タイプでは、Unified CM クラスタのリソース使用率が若干高くなる可能性があります。特定の展開における Unified CM サーバのサイジングには、Cisco Unified CM Capacity Tool または Unified Communications Sizing Tool を使用します。

Unified CM 7.0 以降を使用し、Unified CVP だけを配置する場合は、この展開タイプの別のバリエーションを使用できます（このモデルは IP IVR を配置する場合はサポートされません）。この場合は、1 つの Unified CM クラスタで最大 4,000 のエージェントをサポートできます。2,000 より多くのエージェントを配置する場合は、CTI Manager のペアが最低 2 つ必要です。1 つの Agent PG に 2 つの PIM を装備し、各 PIM に対して、CTI Manager サービスを実行する Unified CM サブスクライバの異なるペアを設定できます。各 PIM に設定できるエージェント数は最大で 2,000 です。エージェント電話の登録は、すべての Cisco Unified CM サブスクライバ ノード（CTI Manager サービスを実行している Unified CM サブスクライバを含む）に及びます。次の図は、4 つのプライマリ Unified CM サブスクライバが必要で、4 つのバックアップ Unified CM サブスクライバが 1:1 の冗長性で配置されている例を示しています。

Unified CM のアップグレード

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

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

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

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

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

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

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

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

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

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

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

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

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

（注） アップグレード中にバックアップ サーバをオーバーサブスクライブすることは、お勧めできません。アップグレード中にバックアップ サーバに登録するエージェント電話の数は、Cisco Unified CM Capacity Tool または Unified Communications Sizing Tool によって示された最大キャパシティを超えないようにしてください。アップグレードは、ピーク時を避けてコールの量の少ない時間帯に実施してください。

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

Cisco Unified Mobile Agent

Cisco Unified CCE 7.1 には、Cisco Unified Mobile Agent という新しい機能が追加されています。Unified Mobile Agent では、コンタクト センターへのコールごとに 2 つの CTI ポートを使用する必要があります。一方の CTI ポートは発信者のエンドポイントを制御し、もう一方の CTI ポートは選択されたエージェントのエンドポイントを制御します。実際の Real-Time Transport Protocol（RTP; リアルタイム転送プロトコル）ストリームはこの 2 つのエンドポイント間を流れます。これら 2 つの CTI ポートを介してブリッジされることはありません。ただし、これら 2 つの CTI ポートを経由してモバイル エージェントへのコールをセットアップする際、（ローカルの Unified CCE エージェントへのコールをセットアップする場合と比べて）Unified CM に追加のコール処理アクティビティが発生します。

モバイル エージェントは基本的に、高品質のブロードバンド接続と Public Switched Telephone Network（PSTN; 公衆電話交換網）電話があれば任意の場所から（エージェント デスクトップを通じて）ログインできますが、それでも論理的には特定の Unified CCE ペリフェラルと Unified CM クラスタに関連付けられています。これは、モバイル エージェントのコールに使用される音声ゲートウェイが、異なる Unified CM クラスタに登録されている場合でも同じです。エージェント デスクトップには、関連付けられている PG および CTI サーバの IP アドレスが設定されます。

Unified CCE 展開における特定の Unified CM ノードおよびクラスタのサイジングには、Cisco Unified CM Capacity Tool または Unified Communications Sizing Tool を使用する必要があります。Unified CM クラスタをサイジングするときに、同時にログインするモバイル エージェントの最大数を入力します。設定されたモバイル エージェントの数が、同時にログインするモバイル エージェントの最大数より多い場合は、ログインしていないモバイル エージェントに対して設定された CTI ポートのペアを考慮に入れるため、Cisco Unified CM Capacity Tool でこれらのポートに CTI ポート タイプ 1 を指定し、BHCA と BHT を 0 に設定します。これは、ログインしていないローカル エージェント電話を考慮するために、Cisco Unified CM Capacity Tool で CTI サードパーティ制御回線を使用するのと似ています。別の方法として（Cisco Unified Communications Sizing Tool を使用する場合）、すべてのモバイル エージェント（ログインしているモバイル エージェントとログインしていないモバイル エージェント）をこのツールに入力して、モバイル エージェントあたりの BHCA と BHT をそれに応じて調整することもできます。合計の BHCA と BHT が、同時にログインするモバイル エージェントとその実際の BHCA および BHT を考慮した場合と同じになるようにしてください。

Cisco Unified Mobile Agent のアーキテクチャ、展開モデル、および Unified CCE サイジングの詳細については、「Cisco Unified Mobile Agent」の章を参照してください。