Cisco Collaboration Sizing ガイド Cisco プリファード アーキテクチャ（PA）設計リファレンスガイド。

パフォーマンステスト

それぞれの製品は一連の機能を実行し、それぞれの機能はさまざまなリソース（CPU やメモリなど）を利用します。シスコは、さまざまな使用レベルで各機能に対するリソースの使用率を正確に測定できるパフォーマンス テストを定義および実行します。

ほとんどのシステムは、特定の範囲内で線形性を示し、その範囲を超えるとシステムのパフォーマンスが予測不能になります。シスコは、各機能のリソース使用率の線形範囲を識別し、確定するため、各パフォーマンス テストに使用レベルを設定します。各テストの結果は、最小限のデータ ポイントを使用してグラフ化できます。必要に応じて、追加のデータ ポイント（中間ロード レベルで）実際のシステム動作を定義するために取得されます。

グラフの線形セクションの傾斜は、追加作業の各差分のリソース使用状況やコストを定義します。R ² 値を使用して、一致精度を予測します。R ² 値が 1 に近い場合、式はデータとほぼ一致しています。

たとえば、図 1-1 に、単一回線の IP Phone を設定するために必要なメモリを判断するために実行されたテストの結果を示します。Unified CM で 1500、4500、および 7500 の単一回線 IP Phone を設定することで割り当てられるメモリを示しています。グラフは、傾向線の式が線形であり、制御変数（電話機の数）に基づく従属変数（この場合は割り当てられたメモリ）の予測に使用できることを示しています。

この特定の試験では、R ² 値はきわめて 1 に近くなっています。この式から、7,500 台 1 回線の電話の設定で消費されるメモリは約 519,000 Kバイトであり、システム内の追加の設定済み単一回線エンドポイントはそれぞれ 8.91 Kバイトを消費すると計算できます。

図 1-1 1 回線の電話機の設定に必要なメモリ

システム モデリング

シスコは、パフォーマンス テストの結果を使用してシステム モデルを作成します。システム モデルは、指定された機能、エンドポイント、およびモデルへの入力として提供されるトラフィックの構成のセットに対する最大リソース使用率を計算する数学的モデルです。

特定の製品に対するシステム モデルを作成するには、次の手順を実行します。

1. 製品が実行するすべての機能を列挙します。テストする必要がある機能の種類を識別します。たとえば、各コール タイプが使用する測定されたリソースの量は異なります。

2. 対象のリソースを決定します。通常、メモリおよび CPU が含まれます。特定の製品には、システム サイジングに影響を与える追加のリソースが含まれている可能性があります。

3. パフォーマンス テスト（前述の項で説明）を実行し、各機能のリソース使用率を判別します。

4. 機能ごとに、線形範囲を使用してリソース使用率を定義します。

他の要因（ソフトウェア リリース、コールの構成、エンドポイントのタイプなど）がリソース使用率に影響を与える可能性があるため、これらの手順を何度も実行する必要があります。

製品のシステム モデルは、製品によってサポートされている各機能に関する式の集約で構成されます。一部の製品のモデルはかなりシンプルですが、複数の機能、複数のエンドポイント タイプ、および複数のコール タイプをサポートする製品のモデルは非常に複雑になることがあります。

メモリおよび CPU のリソース タイプに関する特定の考慮事項については、次の項で説明します。

メモリ使用量の分析

システム モデルは、異なる使用特性を持つスタティック メモリとダイナミック メモリを区別します。また、オペレーティング システムとその他のプロセス用に予約されているシステム メモリもあります。これらの 3 つのメモリ タイプについては、次の項で説明します。

スタティック メモリ

スタティック メモリはシステムにトラフィックがない場合でも消費されます。スタティック メモリ使用率には、システム設定のデータおよび登録済みエンドポイントのデータが含まれます。スタティック メモリには、ダイヤルプラン（パーティション、トランスレーション パターン、ルート リスト、およびグループなどの項目を含む）の設定も含まれます。また、スタティック メモリには CTI および他のアプリケーションに割り当てられたメモリも含まれます。大規模なシステムでは、スタティック メモリは、主に設定済みエンドポイント数およびダイヤルプランのサイズの関数です。

消費されるメモリの量は、エンドポイントのタイプごとに異なることに注意してください。メモリ使用率は、デバイス プロトコル（SIP または SCCP）、ライン アピアランスの数、セキュリティ機能、およびその他の要因によって異なる場合もあります。これらの要因をそれぞれ測定し、モデルに組み込む必要があります。

ダイナミック メモリ

ダイナミック メモリは、各アクティブ コール（進行中のコール）のメモリ割り当てなどの一時的なアクティビティに使用されます。大規模なシステムでは、ダイナミック メモリは、主に同時発生コール数の関数です。

同時コールの数は、平均コール保留時間（ACHT）に比例します。ACHT が長くなると同時発生アクティブ コール数が大きくなるため、より多くのダイナミック メモリが使用されます。

メモリ使用率は、コールのタイプおよびプロトコル（SCCP および SIP など）によって大きく異なる場合があります。

システム メモリ

システム メモリは、オペレーティング システム（OS）とその他のプロセスやサービス用に予約されています。また、一部のメモリは、一時的な使用率の急激な増加のために予約されている場合があります。システム メモリにより、プラットフォームで動作するアプリケーションで使用可能なメモリ量が減少します。

CPU 使用率の分析

非アクティブなシステムで多少の CPU アクティビティが表示されますが、ほとんどの CPU の使用は、コールのセットアップまたは終了時に発生します。したがって、CPU 使用率の主な決定要因の 1 つは提供されるコール レートです。

CPU 使用率は、コールのタイプによって大きく異なる場合があります。コールは同じサーバ内で発信または終端するか、2 つの異なるサーバまたはクラスタ間で発信または終端できます。また、Unified CM クラスタから発信され、PSTN ゲートウェイまたはトランクで終端することもできます。

CPU 使用率の分析は、Unified CM でのコールの発信と終了のコストの違い、使用中のプロトコル、およびセキュリティ機能が有効かどうかを考慮する必要があります。CPU 使用率は、コンフィギュレーション データベースの複雑さ、および CDR または CMR のどちらが生成されているかなどの要因によっても異なります。

CPU 使用率は、実際のハードウェア プラットフォームによって大幅に異なります。したがって、同じパフォーマンス テストを各製品がサポートされているすべてのサーバに対して繰り返す必要があります。

また、CPU 使用率は、コール転送、会議、およびメディア リソース機能（MTP や保留音）など、CPU 消費が激しいコール操作の影響も受けます。シェアド ラインは、シェアド ラインへの各コールが回線を共有するすべてのエンドポイントに提供されるため、追加の CPU リソースを消費します。

トラフィック エンジニアリング

シスコは、業界標準のトラフィック エンジニアリング モデルを使用してシステムの動的な負荷を見積もります。

トラフィック エンジニアリングは、一連のユーザに対して予測される最大トラフィック レベルを計算する数学的モデルを提供します。特定のトラフィック ロードをサポートするのに必要な共有リソース（PSTN トランクなど）の量がモデルによって決まります。

次の項では、異なるタイプのトラフィックに関して、トラフィック エンジニアリングの考慮事項を説明します。

• 定義
• 音声トラフィック
• コンタクトセンター トラフィック
• ビデオ トラフィック
• 会議およびコラボレーション トラフィック

定義

トラフィック エンジニアリングでは、次の用語を定義します。

同時コール

同時コール数は、特定の時点でアクティブなコールの平均数です。

コール/秒

1 秒間にシステムに着信した新しいコールの試行数および同じ 1 秒間に切断した既存のコール数。この単位は、システムが最繁時に受信することが予測される 1 秒間の平均コール数を定義するために使用できます。（この数は 3600 で割ることによって求められる最繁時のコール数に相当します）。

また、システムが処理する必要があるトラフィックの最大バーストを定義するためにも使用できます。

ピーク時間

24 時間の中でトラフィックが最大となる 1 時間。この時間は、組織とトラフィックのタイプによって異なります。ビジネス音声トラフィックの場合、従来、最繁時は午前中（たとえば、午前 10 時～午前 11）と見なされています。

最繁時呼数（BHCA）

ユーザ BHCA は、ユーザが最繁時にコールを開始または受信する平均数を表します。BHCA は、スライディング 60 分の間に試行されたコールの数として定義されます。この間、最大負荷が所定の 24 時間（BHCA）に発生します。BHCA が高いほど、プロセッサの使用率が高くなります。システム BHCA は、常にユーザ BHCA とユーザ数の積以下です。

図 1-2 に、2 人のユーザが 6 BHCAレートで PSTN コールとクラスタ内コールを混在させた例を示します。電話機 A と電話機 B のユーザが PSTN からコールを送受信し、6 BHCA で相互にコールを受信する場合、システムのサイジング時に考慮する必要があるユーザ BHCA は合計 12 になります。前述のように、この例は 9 つのシステム BHCA に変換されます。これは、3 つの IP-to-IP コール（電話機と電話機 B の間）が、これらの IP-to-IP クラスタ内コールのユーザ BHCA がユーザあたり 3 で、合計 6 BHCAであっても、システムパースペクティブから 3 BHCAとして認識されるためです。

図 1-2 例：PSTN コールとクラスタ内コールが混在するユーザあたり 6 BHCA

平均コール保留時間

ユーザがビジーである平均期間です。たとえば、音声コールの場合、ACHT は、2 者間に開いている通話路がある場合のコール設定とコール終了間の期間です。音声システムのトラフィック エンジニアリングで使用する保留時間の業界平均値は 3 分（180 秒）で、BHCA レートは 4 です。

アーラン

アーランはシステムのトラフィック負荷の測定単位です。アーランを計算するには、1 時間あたりのコール数に平均保留時間（分）を掛け、60 で割ります。リソース要件は、適切なアーランモデルを使用してシステム負荷要件から導出できます。

アーランの数は、同時コールの数と同じです。同時コール数は、1 秒あたりの平均コール数（cps）と平均コール保留時間の積として計算されます。

アーラン B モデル

アーラン B モデルは、指定されたブロッキング ファクタ（コールに使用可能な回線やトランクがない可能性）を持つトラフィック負荷（アーラン単位）を処理するために必要なトランクの数を決定できます。拡張アーラン B モデルには、再試行（ブロックされたコールのため）のモデルが含まれます。再試行の割合は、拡張アーラン B モデルへの追加入力です。アーラン モデルと従来のトラフィック分析の詳細については、次の URL を参照してください。

https://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/voip_solutions/TA_ISD.html

表 1-2 に、トランクの数、ブロック確率、およびトラフィックのアーランの関係を示します。

表 1-2 より、次の情報を確認できます。

• アーラン要件が 20 でブロック係数が 1% の場合、システムには 30 回線が必要です。
• より大きいブロック係数（5% など）を提供するのではなく、より小さいブロック係数（1% など）を提供する必要がある場合は、回線を追加します。

アーラン C モデル

アーラン C モデルは着信コールのキューイングを備えているため、コール センター トラフィックをモデル化に使われます。

バースト トラフィック

トラフィック モデルは、コール試行の負荷（ポワソン着信）がかなり安定していることを前提としています。これは、独立して動作する多数のサブスクライバに対して有効な前提です。ただし、実際のシステムでは、多数のコールが非常に短時間に到着する可能性があります。このようなトラフィック バーストはシステム リソースを急速に消費し、多数のコールがブロックされることがあります。製品によっては、処理できるトラフィック バーストのサイズと期間が指定されている可能性があります。

音声トラフィック

標準音声トラフィックは、最繁時呼数（BHCA）および平均コール保留時間（ACHT）の指定によって特徴付けられます。たとえば、システム BHCA が 200 で平均通話時間が 3 分の場合、システムは合計 600 分間（10 アーラン）使用されます。

共有リソース（PSTN トランク グループなど）の要件（および使用率）を計算するには、ブロック係数も指定する必要があります。たとえば、アーラン値とブロック係数が指定されている場合、アーラン カルキュレータまたはルックアップ テーブルを使用して PSTN ゲートウェイで必要な音声回線を計算できます。

コンタクトセンター トラフィック

コンタクトセンターでは、通常これらのシステムが少数のエージェントまたは自動音声応答（IVR）システムによって処理される大量のコールを処理するため、独特のトラフィック パターンが見られます。コンタクトセンターは、高いリソース使用率を実現するように設計されているため、エージェント、トランク、および IVR システムは業務時間中（通常は 1 日 24 時間）ずっと稼働した状態が続きます。コール キューイングの使用が一般的で（着信コール トラフィックがオペレータの処理能力を超えると、次のオペレータが空くまでコールはキュー内で待機します）、オペレータは通常、自分の勤務時間の間、コンタクト センターに寄せられた電話の応対に専念します。

コンタクトセンターでのコールの平均保留時間は、多くの場合、通常のビジネス コールよりも短くなります。IVR システムの段階で用件が済み、オペレータと通話しない場合が多くなります。これらのコールは、セルフサービス コールと呼ばれます。エージェントの平均保留時間は 3 分（一般業務トラフィックと同じ）であるのに対して、セルフサービス コールの平均保留時間は約 30 秒であることから、コンタクトセンター全体での平均保留時間は一般業務トラフィックよりも短くなります。

コンタクトセンター管理の目標は、リソース（IVR ポート、PSTN トランク、オペレータなど）の使用を最適化するためです。そのため、リソース使用率が高くなります。

コンタクトセンターでは通常、一般的な業務環境よりも着呼率が高くなります。これらの着呼率は、一般業務トラフィックとは異なる時間帯（通常の最繁時ではない時間帯）に異なる理由で最大になります。たとえば、特別な休日パックのテレビ CM を流して申し込み用のフリー ダイヤルを知らせた場合、システムの着呼率は、CM 放送後の約 15 分間にトラフィックのピークを迎えます。この着呼率は、コンタクト センターの平均着呼率を 1 桁上回ることもあります。

前述したように、コンタクトセンターのサイジングは、アーラン C モデルを使用してキューで待機中のコールを考慮します。コンタクトセンターには、自動音声応答（IVR）ポートなどの追加のリソースが必要です。PSTN ゲートウェイをサイジングする場合は、キューでコールが待機する時間を考慮する必要があります。

（注） Cisco Unified Contact Center の導入の詳細については、次の Web サイトで入手可能な 『Cisco Unified Contact Center Enterprise ソリューション設計ガイド』を参照してください。（URL：
https://www.cisco.com/c/ja_jp/support/customer-collaboration/unified-contact-center-enterprise/products-implementation-design-guides-list.html）

ビデオ トラフィック

ポイントツーポイント ビデオ トラフィック（オンネット/非 PSTN）は、着呼率、ピーク使用時、および通話時間が同等の音声トラフィックと類似した特徴を示します。また、コール セットアップおよび終了のシグナリングは、音声コールに類似しています。

ビデオ パケットのペイロードは音声パケットよりもはるかに大きいため、ビデオ トラフィックには、音声をはるかに上回るネットワーク帯域幅が必要です。また、ビデオ トラフィックは、音声よりもバーストが大きくなります。音声パケット サイズは、通常はほぼ一定（使用中のエンコーディング アルゴリズムによって固有）ですが、ビデオ フレームのサイズは、以前のフレームからどれほどの変更があったかに応じて大幅に異なります。その結果、RTP パケット ストリームはトラフィックのバーストを示すことがあります。

ビデオ会議への影響については、次の項で説明します。

会議およびコラボレーション トラフィック

会議トラフィックには、ポイントツーポイントの音声/ビデオ コールとは大きく異なる特性があります。会議トラフィックのトラフィック モデルでは、次の違いを考慮する必要があります。

• コール到達

従来のトラフィック モデルは、最繁時の着信が最繁時全体に渡ってポアソン分布することを前提としています。ただし、ほとんどの参加者は、開始時間から数分以内に会議コールに参加し、ほとんどの会議コールは正時に開始されるようにスケジューリングされています。したがって、着呼率は、時間全体でのポアソン分布ではなく、開始後 0 分の単一のバーストで表されます。

• Peaks

ビジネス音声トラフィックには通常、午前中（10:00 ～ 11:00 AM）と午後（1:00 ～ 2:00 PM）の個別のピークがあります。ただし、会議機能は通常は限られたリソースであるため、会議は、営業日全体により均等に配布され、ピーク時にピークが緩和されます。

• コール時間

平均ビジネス音声コール期間は 3 分です。平均会議時間はほぼ 50 分です（30 分、60 分、さらに長い会議の組み合わせによって異なります）。

• ビデオ会議

ビデオ ストリームの切り替えまたは組み合わせを提供するには、専用装置が必要です。そのため、ビデオ エンドポイントの予期される使用率は、モデルにおける重要な要素です。

会議の導入のサイジングは、主にダイヤルイン間隔と会議参加者の推定数に必要な機能です。たとえば、Cisco Meeting Server（CMS）のサイジングには、次の考慮事項が含まれます。

• 地理的なロケーション：Unified CM のサービスを提供する地域ごとに、会議専用のリソースの確保と異なる帯域幅の検討が必要になります。
• Cisco Meeting Server プラットフォームのタイプの設定（ハードウェアまたはソフトウェア）
• Cisco Meeting Server プラットフォームの容量
• 会議のタイプ：音声またはビデオ（あるいはその両方）。スケジュールされた会議またはスケジュールされていない会議（あるいはその両方）
• 会議のビデオ解像度：ビデオの品質が高い会議ほど多くのリソースを消費します。
• 大規模な会議の要件：オールハンズ ミーティングなど

地域ネットワークの会議メディアをできるだけ多く維持するため、会議リソースは一般に 1 つの地域でのみ使用されます。したがって、サイジングは地域単位で検討することができます。

ネットワーク設計の要因

ソリューション サイジングは、次のネットワーク設計の要因の影響を受けます。

• クラスタ サイズ

主要な設計上の決定項目として、大規模な集中型の Cisco Unified CM クラスタを作成するか、それぞれの主要な場所でクラスタを作成するかどうかがあります。中央クラスタの使用率は高くなる可能性がありますが、クラスタの制限を超えた場合は、2 つめのクラスタを使用せざるを得なくなる可能性があります。

一部のシステムの制限は絶対ではなく、システムで設定された他のサービスのサイズに基づいて動的に変更できます。

• 個々の製品間の相互作用

Unified CM は、ほとんどの Cisco Collaboration 配置において中心的な役割を果たしており、システムの他のコンポーネントによって影響を受けます。たとえば、Cisco WebEx Meetings Server の追加は、短時間の間（会議セッションの開始時）に多数のコール セットアップを集中させる傾向があります。Unified CM によって網羅された他の機能に応じて、追加の Unified CM サーバ ノードが必要になる場合があります。

• サーバ機能

それぞれのタイプのサーバまたはルータは、異なる機能をサポートします。たとえば、より強力なサーバには Cisco Business Edition 6000 プラットフォームまたは Cisco Integrated Services Router（ISR）よりも多くのネットワークポートがある場合があります。

別の例として、Cisco Integrated Service Router（ISR）の各種モデルでは、ホストできるネットワーク モジュールまたは Cisco Unified Computing System（UCS）E シリーズ ブレード サーバのモジュールの数とタイプに制限があります。

• オプションの機能

システム サイジングは、コール詳細レコード（CDR）またはコール管理レコード（CMR）の生成などのオプションを有効にしている場合に影響を受ける可能性があります。

その他のサイジングの要因

次の追加の要因もシステム サイジングに影響します。

• コール タイプの混合

各コール タイプ（同じサブスクライバ ノード内の電話機間のコール、同じクラスタ内の 2 つのサブスクライバ ノード間のコール、2 つのクラスタ間のコール、および PSTN に出入りするコール）によって消費されるリソースには違いがあります。異なるタイプの電話機やゲートウェイからのコールも、プロトコルやビデオなどのサービスによって異なります。

• エンドポイント タイプの混合

サイジングに影響する別の明確な要因の例として、期待される電話機、クライアントおよびユーザの数があります。この場合も、電話機のタイプ、電話機に設定されている回線の数、電話機がセキュア モードであるかどうかなどがシステム サイジングに影響します。

• システム リリース

システム リソースの使用率は、システム リリースに応じて異なることがあります。場合によっては、リリースの新機能によってリソース使用率が増加する原因となる可能性があります。また、ソフトウェアの向上によってリソース使用率が低下する可能性があります。

• 外部アプリケーションの使用

外部アプリケーションは、CTI などのインターフェイスを使用してコール処理エージェントと通信できます。システム サイジングでは、この負荷の影響を考慮する必要があります。

• 予想されるシステムの拡張

システム使用率が来年または再来年に増加することが予測されている場合は、近い将来に破壊的とも言える可能性のあるアップグレードに直面する代わりに、その成長を元のシステムに組み込むことを推奨します。

• 平均およびピーク時の使用時間

システム サイジングが、現実的なピーク使用率の観点に基づいていることを確認します。ピークが過小評価されていると、実際にピーク トラフィックに遭遇した場合に、システムでサービスの低下または機器の障害が発生する可能性があります。

すべての要因およびその変動の可能性により、大規模システム配置の正確なサイジングは複雑な作業です。このため、シスコは次の項で説明するシステム サイジング ツールを使用することを強く推奨します。

Cisco Unified Communications Manager

Cisco Unified Communications Manager（Unified CM）は、Unified Communications 配置のハブです。これは、エンドポイントの制御、コールのルーティング、ポリシーの施行、およびアプリケーションのホストなどの主要な機能を実行します。Unified CM は、PSTN ゲートウェイ、Cisco Unity Connection、Cisco Unified Communications Manager IM and Presence Service、および Cisco Unified Contact Center などの他の Unified Communications 製品に対する連携を提供します。連携機能は、Unified CM のパフォーマンスに影響を与えるため、Unified CM サイジングで考慮する必要があります。

多くの要因が Unified CM のパフォーマンスに影響するため、Unified CM 導入のサイジングで考慮する必要があります。次の項では、これらの要因について説明します。

• 仮想ノードとクラスタの最大数
• 展開オプション
• エンドポイント
• Cisco Collaboration ソフトウェア クライアントとモビリティ
• コール トラフィック
• ダイヤルプラン
• アプリケーションと CTI
• メディア リソース

仮想ノードとクラスタの最大数

サイジング ツールには、次のサーバ ノードとクラスタの最大数が適用されます。これらの値は、Unified CM ソフトウェアのバージョンに応じて異なることがあります。

• 各クラスタは、最大 50,000 台のセキュアまたは非セキュア SCCP または SIP 電話機の設定および登録をサポートできます。
• クラスタ内のエンドポイント数が 1,250 を超えた場合は、専用パブリッシャに加えて 2 つの TFTP サーバ ノードが必要です。
• CTI 接続のサポートが最新のいくつかのリリースで向上し、各クラスタは最大 50,000 の CTI 接続をサポートできます。
• クラスタ内の呼処理サブスクライバの数は、4 つおよびスタンバイ 4 つの合計 8 つの呼処理サブスクライバ ノードを超えることはできません。また、パブリッシャ、TFTP、メディア サーバなどのクラスタ内のサーバ ノードの合計数がクラスタ内の最大許容量である 21 サーバを超えることはできません。
• Unified CM 仮想マシン（VM）または Open Virtualization Archive（OVA）の 3 つの推奨設定は、小規模、中規模、および大規模です。仮想マシンのリソース（vCPU、RAMなど）の量に基づいて、各 OVA サイズは最大平均数のユーザまたはデバイスをサポートします。これは、各ユーザが平均して1台の電話機を持つことを前提としています。そうでない場合、OVA あたりの制限は、Unified CM ノードに登録されたエンドポイントの最大数です。たとえば、大規模プラットフォームの OVA では、ユーザごとに 1 つのデバイスを想定して、最大 12,500 人のユーザをサポートします。ただし、ユーザごとに複数のデバイスを導入する場合は、サポートされるユーザの最大数が削減されます。たとえば、ユーザあたり 2 台のデバイスがある場合、大規模な OVA は最大で 6,250人 のユーザをサポートし、合計で 12,500 台のデバイスをサポートします。この原則は、中規模および小規模の Unified CM プラットフォーム OVA にも同じく適用されます。

展開オプション

次の配置オプションは、システム内のすべての動作に影響する全体的な設定であり、登録されているエンドポイントの数や進行中のコールの数とは無関係です。

データベースの複雑さ

Unified CM のコンフィギュレーション データベースが複雑であると見なされる場合、CPU 使用率はかなり高くなります。データベースが単純か複雑かを判断するメトリックはありません。一般に、10,000 を超えるエンドポイントと数百を超えるダイヤルプラン要素（トランスレーションおよびルート パターン、ハント パイロット、シェアド ラインなど）がある場合、対象となるデータベースは複雑になります。

リージョンおよびロケーションの数

Unified CM クラスタ内のリージョンとロケーションの設定には、データベースとスタティック メモリの両方が必要です。クラスタに定義できるゲートウェイの数は、定義できるロケーションの数にも関係します。 表 1-3 に、一部の Unified CM VM 構成におけるこれらの制限を示します。

クラスタに最大数のロケーションとリージョンを実際に定義できるかどうかは、コーデック マトリクスがどの程度「疎」であるかによって異なります。リージョン間コーデック設定にデフォルト以外の値が多すぎる場合は、リージョンまたはロケーションのためにシステムをフル キャパシティに拡張できません。一般に、デフォルトからの変更は最大数の 10% を超えないようにします。

コール詳細レコードおよびコール管理レコード

コール詳細レコード（CDR）とコール管理レコード（CMR）の生成により、CPU に大きな負荷がかかります。

高可用性

指定した配置に必要なノードの最小数を特定した後、冗長性を提供するために目的の数の追加のサブスクライバ ノードを追加します。

クラスタあたりの仮想サーバ ノード数

通常のクラスタに最大 4 つのサブスクライバ ペアを設定できます。分散型トポロジでは、クラスタが最大数に達していない場合でも複数のクラスタがある場合があります。

集中型トポロジの場合、キャパシティの制限に到達しない限りは通常は 1 つのクラスタがあります。他のシステム制限によって、ノードごとの使用率が制限に達していない場合でも、新しいクラスタを使用せざるを得ない可能性があることに注意してください。

VM 構成とハードウェアプラットフォームの選択

シスコでは、ハイパーバイザにロードできる OVA VM 構成を提供しています。指定する機能はテンプレートごとに異なります。たとえば、大規模プラットフォーム OVA では、最大容量 12,500 のエンドポイントを持つ仮想マシンを定義します。最大 3,750（小規模 OVA）および 10,000 エンドポイント（中規模 OVA）をサポートするように定義されたテンプレートもあります。

Unified CM およびその他の Unified Communications 製品用に正式に定義された VM 構成は、次の Web サイトから入手できます。

https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/collaboration-virtualization-sizing.html

Unified CM の詳細情報については、次の Web サイトから入手できます。

https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-unified-communications-manager.html

Unified CM では、一部の VM 構成をローエンド ハードウェア プラットフォームでサポートしていません。ハードウェア プラットフォームでサポートされている VM 構成を確認するには、次の URL にあるマニュアルを参照してください。

http://www.cisco.com/jp/go/virtualized-collaboration

エンドポイント

エンドポイントの数は、システムでサポートする必要がある全体の負荷の重要な部分です。さまざまなタイプのエンドポイントがあり、タイプごとに Unified CM にかかる負荷は異なります。エンドポイントは次の要素で区別できます。

• デジタル（IP）またはアナログ（アダプタを使用）
• ソフトウェアベースまたはハードウェア
• サポートされるプロトコル（SIP または SCCP）
• エンドポイントでセキュリティが設定されているかどうか
• ダイヤル モード（一括またはオーバーラップ）
• 音声のみ、または音声とビデオ
• トランクやゲートウェイ（SIP、H.323、MGCP）などの他のデバイス

システムで設定されている各エンドポイントは、定義され登録されているだけのシステム リソース（スタティック メモリなど）を使用します。エンドポイントは、コール レートに基づいて CPU とダイナミック メモリを消費します。

エンドポイントは、Unified CM 内で実行されるサービスと対話するアプリケーション（CTI など）を実行することによって、Unified CM にさらに負荷をかけます。

表 1-4 に、さまざまな VM 構成タイプでサポートされるエンドポイントの最大数を示します。これらの値はガイドライン専用であることに注意してください。配置に他のアプリケーションが含まれているために、システムによってはこれらの最大容量をサポートしない場合があります。

ハードウェア要件などの詳細については、次の URL にあるドキュメントを参照してください。

http://www.cisco.com/jp/go/virtualized-collaboration

Cisco Collaboration ソフトウェア クライアントとモビリティ

Cisco Collaboration クライアントは、ユーザのデスクトップや他のアクセス デバイスで実行されるソフトウェア アプリケーションです。モビリティとは、常に組織のネットワーク境界内にいるわけではないモバイル ユーザに対応する一連の機能です。

• Cisco Collaboration ソフトウェア クライアント
• モビリティ

Cisco Collaboration ソフトウェア クライアント

Cisco Collaboration ソフトウェア クライアント向けにソリューションの設計とサイジングを検討する際は、すべてのコンポーネントについて、次のスケーラビリティに関するインパクトを考慮する必要があります。

• クライアントのスケーラビリティ

導入されたプラットフォーム OVA によって、クラスタがサポートできるデバイスの数が決まります。Cisco ソフトウェア クライアントの導入では、クライアント登録とその他の通信のバランスをクラスタ内のすべてのノードで均等にする必要があります。

• IMAP のスケーラビリティ

IMAP または IMAP-Idle の接続数は、音声メッセージング統合プラットフォームが決定します。

• 音声、ビデオ、および Web 会議

クライアントは、ネットワークで提供される会議サービスにアクセスできます。これらのサービスの同時参加者の数をサイジングする場合、これらのユーザを考慮する必要があります。

Cisco Jabber および Cisco Webex クライアント アプリケーションは、デュアルモードまたはタブレット デバイスとしてモバイルデバイス（iPhone、iPad、および Android）で、クライアント サービス フレームワーク（CSF）デバイスとしてデスクトップ（Windows および Mac）でサポートされます。ソフトウェア クライアントを使用した展開のサイジングでは、ユーザがデスクトップ クライアントとモバイル クライアントを任意に組み合わせて使用できることに注意してください。

（注） この説明では、Cisco Jabber および Cisco Webex（Unified CM）モードで展開されている Cisco Webex をCisco ソフトウェア クライアントと呼びます。特に明記されていない限り、説明されている機能はソフトウェア クライアント（Jabber および Webex）の両方に適用されます。

デスクトップ クライアントは、Unified CM でそれぞれが異なるリソースを使用する 2 つのオペレーション モードを提供します。Cisco ソフトウェア クライアントは、ソフトフォン モードで動作する場合、SIP 登録されたエンドポイントとして機能し、システム内のエンドポイントの総数としてカウントされます。ソフトウェア クライアントは、デスクフォン制御モードで動作する場合、CTI エージェントとして機能するため、Unified CM で CTI リソースを使用します。

ユーザは、どちらのモードでも動作するようにクライアントを切り替えることができます。したがって、予想される使用方法に必要なシステム リソースを正しく把握する必要があります。

（注） ユーザがデスクフォン制御モードでデスクトップ クライアントのみを使用している場合、デスクフォン制御は CTI リソースと回線を使用するため、単一のデバイスとしてのみカウントされます。

ソフトウェア クライアント は、Unified CM とインターフェイスで連結します。そのため、ソフトウェア クライアントの音声またはビデオ コールを開始した場合、Unified CM の現在の機能に関する次のガイドラインが適用されます。

• CTI のスケーラビリティ

デスクフォン制御モードでは、ソフトウェア クライアントからのコールは Unified CM の CTI インターフェイスを使用します。したがって、アプリケーションと CTIの項に明記された CTI の制限を遵守してください。Unified CM クラスタのサイジングを行う際は、これらの CTI デバイスを含める必要があります。

• Call admission control

Cisco Jabber クライアントは、Unified CM ロケーションまたは RSVP 経由で、音声またはビデオ コールに対してコール アドミッション制御を適用します。

• コーデックの選択

Cisco ソフトウェア クライアントの音声およびビデオ コールは、Unified CM リージョン設定によるコーデックの選択を利用します。

• Cisco Unified CM ユーザ データ サービス（UDS）

UDS は、Unified CM が提供する包括的なサービス API です。UDS には、Cisco Edge サービス経由で Jabber が連絡先ソースの検索に使用できる連絡先ソース API が用意されています。UDS 連絡先ソースを使用して連絡先を解決すると、システムに追加の負荷がかかります。Webex の場合、連絡先ソースは常に Webex クラウドです。

デスクトップ クライアントの導入では、さらに次の項目について考慮する必要があります。

• デバイス設定

ソフトフォン モードで設定した場合は、Unified CM 呼制御の設定情報のために、デスクトップ クライアントのコンフィギュレーション ファイルが TFTP または HTTP 経由でクライアントにダウンロードされます。さらに、アプリケーション ダイヤル規則やディレクトリ ルックアップ規則があれば、それらも TFTP または HTTP を介して デスクトップ クライアントデバイスにダウンロードされます。

デスクトップ クライアントは Cisco Unified CM Cisco IP Phone（CCMCIP）または UDS サービスを使用してユーザに関連付けられたデバイスについての情報を集め、この情報を使用してデスクフォン制御モードにあるクライアントが制御可能な IP Phone のリストを提供します。ソフトフォン モードのデスクトップ クライアントは、Unified CM への登録のデバイス名を検出するために CCMCIP または UDS サービスを使用します。

• デスクフォン制御モード

デスクフォン制御モードで設定した場合は、IP Phone の制御を可能にするために、ログインと登録の際にデスクトップ クライアントが Unified CM への CTI 接続を確立します。Unified CM は、最大 50,000 個の CTI 接続をサポートします。デスクフォン制御モードで動作する多数のクライアントがある場合は、CTI 接続を CTIManager サービスを実行中の Unified CM サブスクライバ全体に均等に分散させるようにします。このことは、それぞれ異なる CTIManager アドレスのペアを持つ複数の CTI ゲートウェイ プロファイルを作成し、CTI ゲートウェイ プロファイルの割り当てをデスクフォン モードを使用するすべてのクライアントに配分することで実現できます。

• ボイスメール

ボイスメール用に設定されている場合、クライアントは、メールストアとの IMAP または REST 接続を通じてボイスメールを更新および取得します。

• 認証

クライアントのログインと認証は、展開内で設定された方法に基づいて処理されます。オプションには、Jabber の場合は LDAP ベースの認証、Webex の場合は HTTPS Web ベースの認証、両方のクライアントでサポートされるシングルサインオン（SSO）が含まれます。ログイン情報は、ローカル クライアント キャッシュに保存できます。または、OAuth ベースの認証の場合は、更新されたセキュア接続を有効にするためにトークンが保存されます。

• 連絡先の検索

デスクトップ クライアントで使用できる複数のコンタクト ソースがあります。たとえば、UDS サービスは、Jabber クライアントが Unified CM ユーザ データベース内のコンタクトを検索するために使用できます。また、LDAP 統合を Jabber で使用できます。Webex の場合、連絡先の検索は Webex 組織の ID ストアに対して実行されます。いずれの場合も、要求された連絡先がローカル デスクトップ クライアント キャッシュで見つからない場合、連絡先の検索は適切なディレクトリ ソース（LDAP、UDS、または Webex）に対して実行されます。

SAML SSO Cisco Jabber クライアント

Cisco Unified CM は、セキュリティ アサーション マークアップ言語のシングルサインオン（SAML SSO）機能を提供します。これにより、ユーザは一度だけログインして、シスコ コラボレーション ソリューション内のすべてのアプリケーションにアクセスできるようになります。

SAML SSO は、エンドユーザのログイン情報と関連情報を使用して、複数の Unified Communications アプリケーション（Unified CM、Unity Connection、Unified CM IM and Presence など）で利用されるセキュアなメカニズムを提供します。SAML シングルサインオン機能を期待どおりに動作させるには、各クラスタのユーザ数をサポートするようにネットワーク アーキテクチャを拡張する必要があります。

複数のアプリケーション（Unified CM、Unity Connection、Unified CM IM and Presence など）での Unified Communications の導入では、シスコ ソフトウェア クライアントが正常にログインするために、すべての SAML 要求が ID プロバイダー（IdP）で認証される必要があります。

（注） SSO は、SAML を使用したユニファイド コミュニケーションサービスでサポートされます。

SAML SSO ログインを使用するソフトウェア クライアントも、システムのサイジングに含める必要があります。これは、通常の日に同時にシステムにログインするユーザの数が、ユーザのログインにかかる時間に影響する可能性があるためです。これは、システムが一度に処理できる要求数の制限要因によるものです。ソフトウェア クライアント ユーザの現在の最大ログイン レートは、1 秒あたり 2.7 ログイン（1 分あたり約 166 ログイン）または 1 時間以内に 10,000 ログインです。これは、すべてのユーザとデバイスがすべてのノードに均等に分散され、ソフトウェア クライアントがソフトフォン モードであることを前提としています。

Unified CM クラスタのスケーラビリティに影響を与える可能性のある相互依存変数は多数あります（リージョン、ロケーション、ゲートウェイ、メディア リソースなど）。したがって、必要な負荷を処理するためにリソースを使用できるように効率的に展開するには、ユーザ、エンドポイント、およびユーザあたりのコール数を決定することが重要です。

たとえば、5,000 人のユーザをサポートする冗長なサブスクライバ ペアを使用した展開を考える場合、各ペアは 2 台のデバイス（デスクフォンとソフトフォン）に関連付けられています。この導入では、次の数の仮想マシンと VM 構成が必要です（高可用性と冗長性を前提としています）。

• 大規模 OVA または VM 構成の Unified CM サブスクライバのペア
• Unified CM IM and Presence 5k ユーザ VM 構成のペア

Unified CM IM and Presence 5k ユーザ VM 構成ペアは 5,000 ユーザをサポートし、Unified CM 大規模 VM 構成ペアは 10,000 デバイスをサポートします。

モビリティ

ユニファイド コミュニケーションのモビリティは多面的です。モバイル通信のさまざまな側面がそれぞれ Unified CM リソースを消費し、個別的にもシステム全体の一部としても考慮する必要があります。次のサイジングの考慮事項は、モビリティに適用されますが、Unified CM に影響を与えないモビリティの側面はここでは説明していないことに注意してください。

Cisco Unified Mobility

シングル ナンバー リーチとエンタープライズの 2 ステージ ダイヤリング機能（Mobile Voice Access および Enterprise Feature Access）をサポートするための Unified CM のキャパシティにとって重要な、2 種類のパラメータがあります。これらの機能が適切に動作するには、モビリティを有効にし、シェアド ラインを使用したリモート接続先がユーザ用に定義されている必要があります。 表 1-5 に、各クラスの Unified CM VM 構成で構成されるクラスタ内のユーザ、リモート接続先、モビリティ ID の各制限を示します。

（注） モビリティ対応ユーザは、リモート接続先プロファイルを持ち、1 つ以上のリモート接続先またはデュアルモード デバイスおよびモビリティ ID が設定されているユーザとして定義されます。

システムに定義されているそれぞれのリモート接続先およびモビリティ ID は、いくつかの方法で Unified CM に影響します。

• リモート接続先またはモビリティ ID はデータベースのスタティック メモリおよび設定領域を占有します。
• 各オカレンスでは、ユーザのプライマリ デバイスとのシェアド ラインを使用し、そのためその回線へのコールはより多くの CPU リソースを使用します。
• リモート接続先またはモビリティ ID が外線番号（ユーザの携帯電話またはホームなど）の場合、コールを拡張するために、ゲートウェイのリソースが使用されます。

コール トラフィック

コール トラフィックの量と質は、Unified CM のサイジングにおいて非常に重要な要素です。

ハーフコール モデルでは、コールの発信と終端は異なるイベントと見なされるため、コールの種類を区別することが重要です。同じサブスクライバ ノードに登録されているエンドポイントの場合、これらのエンドポイント間のコールについてはその両半分をそのサブスクライバが処理します。同じクラスタ内の 2 つのサブスクライバ ノード間で発信されたコールについては、参加している各サブスクライバは、コールの発信または終端のいずれかを処理します。異なるクラスタに登録されているエンドポイント間で発信されたコールについては、各クラスタは各コールの片半分のみを処理します。クラスタに登録されているエンドポイントと PSTN 間で発信されたコールについては、PSTN ゲートウェイはコールの片半分を処理し、これらのコール タイプに基づいてゲートウェイをサイジングします。

コール トラフィックの正確なサイジングについては、次の要素を考慮する必要があります。

• ユーザあたりの総最繁時呼数（BHCA）
• コールあたりの平均コール保留時間（ACHT）
• MGCP、H.323、および SIP プロトコルを使用した PSTN との間の BHCA
• H.323 クラスタ間トランクまたは SIP プロトコルを使用した他のクラスタとの間の BHCA
• クラスタ内の BHCA

コールのタイプごとに、呼設定にかかる CPU リソースの量は異なります。最繁時呼数により、CPU 使用率が決まります。CPU 要件は、コール発信レートによって直接影響を受けます。ACHT によって、コールを持続時間保持するためのダイナミック メモリ要件が決まります。ACHT が長くなるほど、割り当てたままにする必要があるダイナミック メモリが多くなるため、メモリ要件が大きくなります。

コール トラフィックは、他のソースで発生する可能性もあります。コールが転送でリダイレクトされるか、ボイスメールにリダイレクトされるたびに、CPU による処理が必要になります。1 つの電話番号が複数の電話機に設定されている場合は、その番号への着信コールをそれらすべての電話機に表示する必要があるため、コール セットアップ時に CPU 使用率が高くなります。高度な機能を使用する場合は、このテクノロジーを使用して発信されたコール、およびこれらのコールのうち、コール品質のために PSTN にリダイレクトする必要があるコールの割合も考慮する必要があります。

ダイヤルプラン

Unified CM のダイヤルプランは、コール ルーティングおよび関連付けられるポリシーを決定する静的設定要素で構成されます。一般に、ダイヤルプラン要素は、Unified CM のスタティック メモリ領域を占有します。次のダイヤルプラン要素が、必要なメモリ量に影響を与えます。

• ボイス メールのディレクトリ番号（DN）
• 共有電話番号、および同じ DN を共有するエンドポイントの平均数
• パーティション、コーリング サーチ スペース、トランスレーション、およびトランスフォーメーション パターン
• ルート パターン、ルート リスト、およびルート グループ
• グローバル ダイヤルプラン レプリケーション（GDPR）
• ハント パイロットおよびハント リスト
• 循環、シーケンシャル、およびブロードキャスト回線グループとそのメンバーシップ

（注） 電話番号（DN）は、Unified CMインメモリデータベースの一部です。

Unified CM によってダイヤルプラン要素に適用される絶対的な制限はありませんが、使用可能な共有システム メモリの量が固定されています。

ほとんどのダイヤルプラン要素は、CPU 使用率に直接影響を与えません。共有回線、ハントリスト、および回線グループは例外です。特定の電話番号を共有するすべてのエンドポイントにコール試行（着信コール）を表示する必要があるため、シェアド ラインごとにコール セットアップの CPU コストが増えます。

アプリケーションと CTI

Unified CM のコンテキストでは、アプリケーションは、Unified CM によって提供される単純な呼処理を超える「追加」機能です。一般に、これらのアプリケーションでは、Computer Telephone Integration（CTI）が利用され、ユーザはコールの発信、終端、再ルーティング、モニタ、および処理を行うことができます。Cisco Unified CM Assistant、アテンダントコンソール、コンタクトセンターなどの機能は、CTI を利用して動作します。

大規模な Unified CM VM 構成では、登録されているすべてのデバイスのCTIをサポートできますが、小規模な VM 構成ではそのように拡張できません。 表 1-6 に、各 Unified CM VM 構成でサポートされる CTI リソースの最大数を示します。これらの最大値は、次のタイプの CTI リソースに適用されます。

• CTI で制御またはモニタされ、Unified CM サブスクライバ ノードに登録できるエンドポイントの最大数。
• CTI Manager サービスを実行している Unified CM サブスクライバ ノードでモニタまたは制御できるエンドポイントの最大数。
• CTI Manager サービスを実行している Unified CM サブスクライバ ノードに接続できる TAPI/JTAPI アプリケーション インスタンスの最大数。CTI Manager サービスを実行している Unified CM サブスクライバ ノードに接続できる TAPI/JTAPI アプリケーション インスタンスは、CTI 接続と呼ばれることもあります。

VM 構成の CTI リソースの最大数は、その VM 構成のエンドポイント キャパシティに対応することに注意してください。

Unified CM によって提供されるネイティブ アプリケーション以外に、Unified CM CTI リソースを使用するサード パーティ アプリケーションも配置できます。CTI ポートとルート ポイントを数える場合は、サードパーティ アプリケーションも考慮してください。

接続とデバイスの最大数以外に、CTI 制限は次の影響も受けます。

• 各制御対象デバイスの回線数（制御対象デバイスあたり最大 5 回線）
• CTI によって制御される回線の共有接続数（回線あたり最大 5）
• アクティブな CTI アプリケーションの数（デバイスあたり最大 5）
• 制御対象デバイスあたり最大 6 BHCA

Unified CM で利用できる CTI リソースは、これらのいずれかの値を超えた場合に減少します。

Unified CM クラスタに必要な CTI リソースの決定

次の手順に従って、Unified CM クラスタに必要な CTI リソースの数を決定します。

ステップ 1 総 CTI デバイス数を調べます。

クラスタ上で使用される予定の CTI デバイスの数を数えます。

ステップ 2 CTI 回線係数を調べます。

表 1-7 に従って、クラスタ内のすべてのデバイスの CTI 回線係数を決定してください。

コメント クラスタ内のデバイスの回線係数がばらついている場合は、システム内のすべての CTI デバイスでの平均回線係数を求めます。

ステップ 3 アプリケーション係数を調べます。

表 1-8 に従って、クラスタ内のすべてのデバイスのアプリケーション係数を決定してください。

ステップ 4 次の公式に従って、CTI リソースの必要な数を計算します。

CTI リソースの必要な数 =（CTI デバイスの合計数）∗（CTI 回線係数または CTI アプリケーション係数の大きい方）

次の例は、このプロセスを示しています。

例 1： デバイスごとの平均回線数が 9、平均アプリケーション数が 4 で、500 台の CTI デバイスが配置されています。 表 1-7 と 表 1-8 にリストされている係数に従うと、デバイスごとの回線数 9 の場合の回線係数は 1.8、デバイスごとのアプリケーション数が 4 の場合のアプリケーション係数は 1.0 になります。これらの値をステップ 4 の式に代入すると、次の値が得られます。

（500 CTI デバイス）∗（{回線係数 1.8 またはアプリケーション係数 1.0} の大きい方）

（500 CTI デバイス）∗（回線係数 1.8）= 900 の総 CTI リソースが必要

例 2： デバイスごとの平均回線数が 5、平均アプリケーション数が 9 で、2,000 台の CTI デバイスが配置されています。 表 1-7 と 表 1-8 にリストされている係数に従うと、デバイスごとの回線数 5 の場合の回線係数は 1.0、デバイスごとのアプリケーション数が 9 の場合のアプリケーション係数は 1.8 になります。これらの値をステップ 4 の式に代入すると、次の値が得られます。

（2000 CTI デバイス）∗（{回線係数 1.0 またはアプリケーション係数 1.8} の大きい方）

（2000 CTI デバイス）∗（アプリケーション係数 1.8）= 3,600 の総 CTI リソースが必要

例 3： デバイスごとの平均回線数が 2、平均アプリケーション数が 3 で、5,000 台の CTI デバイスが配置されています。 表 1-7 と 表 1-8 にリストされている係数に従うと、デバイスごとの回線数 2 の場合の回線係数は 1、デバイスごとのアプリケーション数が 3 の場合のアプリケーション係数は 1 になります。これらの値をステップ 4 の式に代入すると、次の値が得られます。

（5,000 CTI デバイス）∗（{回線係数 1 またはアプリケーション係数 1} の大きい方）

（5,000 CTI デバイス）∗（回線係数またはアプリケーション係数 1）= 5,000 の総 CTI リソースが必要

[IP Phone サービス（ IP Phone Services）]

Cisco Unified IP Phone Service は、Web クライアントやサーバ、および Cisco Unified IP Phone の XML 機能を利用するアプリケーションです。Cisco Unified IP Phone のファームウェアには、限定的な Web ブラウジング機能を可能にするマイクロブラウザが含まれています。これらの電話サービス アプリケーションを、ユーザのデスクトップ電話機上で直接実行することで、付加価値サービスが提供され、生産性も向上する可能性があります。

Cisco Unified IP Phone サービスの大部分は、HTTP クライアントとして機能します。ほとんどの場合、加入サービスのロケーションへの転送サーバとしてだけ Unified CM が使用されます。Unified CM はリダイレクト サーバとしてのみ機能するため、多数の要求（1 分あたり数百以上の要求）がない限り、Unified CM へ与えるパフォーマンスの影響は通常最小限になります。

統合 Extension Mobility および Unified CM Assistant アプリケーションの IP Phone サービスを除き、IP Phone サービスは独立した Web サーバに存在する必要があります。Unified CM ノードで、エクステンション モビリティおよび Unified CM Assistant 以外の電話サービスを実行することはサポートされていません。

Cisco エクステンション モビリティおよびクラスタ間のエクステンション モビリティ

エクステンション モビリティ（EM）は、次のようにシステム パフォーマンスに影響します。

• EM プロファイルを作成するには、ディスク データベース領域とスタティック メモリの両方が必要になります。
• ユーザが EM アカウントにログインする頻度は、CPU 使用率とメモリ使用率の両方に影響します。Unified CM ノードがサポートできる 1 分あたりの最大ログイン数には制限があります。
• クラスタ間のエクステンション モビリティ（EMCC）の方がリソースに大きな影響を及ぼします。Unified CM ノードがサポートできる EMCC ユーザの数には制限があります。サポートされる最大 EMCC ログイン レートは、EM に対してサポートされるレートよりも低くなります。さらに、EM と EMCC のログイン レートにトレードオフがあります。両方が同時に発生した場合、それぞれの最大キャパシティが減ります。
• クラスタあたりの EM と EMCC のログイン レートは、共有データベース内のプロファイルにアクセスする必要があるため、各ノードのログイン レートとクラスタ内のノード数を単純に掛け合わせたものではありません。複数の呼処理サブスクライバで構成されるクラスタ内の最大ログイン レートは、単一サーバ ノードの 1.5 倍に制限する必要があります。

表 1-9 に、VM 構成タイプごとの 1 分あたりの EM と EMCC 最大ログイン数を示します。

Cisco エクステンション モビリティ ログインおよびログアウト機能は、ログイン/ログアウトのクラスタ キャパシティを増加するためにサブスクライバ ノードのペアに分散できます。たとえば、中規模または大規模な VM 構成の 2 つの仮想マシン間で EM の負荷が均等に分散されている場合、クラスタ全体の最大キャパシティは 1 分あたり 750 回の連続ログインまたはログアウトです。

（注） Cisco エクステンション モビリティ サービスは、冗長性を目的として 3 つ以上のノードでアクティブにできますが、最大 2 つのサブスクライバ ノードによるログイン/ログアウトのアクティブな処理を常にサポートしています。

（注） EM セキュリティの有効化はパフォーマンスを低下しません。

Cisco Unified CM Assistant

Cisco Unified CM Assistant アプリケーションは、回線モニタリングおよび電話制御のために Unified CM で CTI リソースを使用します。Unified CM Assistant 用のまたはマネージャ電話用の各回線（インターコム回線を含む）が CTIManager 経由で CTI 制御されている必要があります。加えて、CTIManager 経由で CTI 制御された Unified CM Assistant ルート ポイントも必要になります。Unified CM Assistant を設定する場合、必要な CTI 回線または CTI 接続の数について、クラスタ全体での CTI 回線または CTI 接続に対する制限も合わせて考慮する必要があります。

Unified CM Assistant には、次の制限が適用されます。

• マネージャあたり最大 10 人のアシスタントを設定できる。
• 1 人のアシスタントに対して最大 33 人のマネージャを設定できる（マネージャ毎に 1 つの Unified CM Assistant 制御回線がある場合）。
• クラスタあたり最大 3500 人のアシスタントと 3500 人のマネージャを、7,500 人のユーザまたは 10,000 人のユーザ用の仮想マシンを使用して設定できる（合計 7000 人）。
• Enable Multiple Active Mode サービスパラメータが True に設定され、Unified CM Assistant サーバの 2 番めおよび 3 番めのプールが設定されている場合、プライマリおよびバックアップ Unified CM Assistant ノードのペアをクラスタあたり最大 3 組配置できます。

Unified CM Assistant 最大でアシスタント 3,500 人とマネージャ 3,500 人（合計 7,000 人）のキャパシティを実現するには、複数の Unified CM Assistant サーバ プールを定義する必要があります。

Cisco WebDialer

Cisco WebDialer を使用すると、ユーザは簡単にコールを開始できます。追加リソースが必要になるのはコールの開始時のみで、コール中は不要であるため、Unified CM に対する Cisco WebDialer の影響はかなり限定されます。コールが確立されると、Unified CM に対する影響は他のコールと同様になります。

WebDialer および Redirector サービスは Unified CM クラスタ内で複数のサブスクライバ ノードを実行でき、次のキャパシティがサポートされています。

• 各 WebDialer サービスは、ノードごとに 1 秒あたり最大 4 コール要求まで処理できます。
• 各 Redirector サービスは、1 秒あたり最大 8 コール要求まで処理できます。

次の一般式が WebDialer の 1 秒あたりのコール数の決定に使用できます。

（WebDialer のユーザ数）Ξ（（平均 BHCA）/（3600 秒/時間））

この計算を行う場合、特に WebDialer サービスを使用した発信の、ユーザあたりの BHCA を適切に推定することが重要です。以下の例で、サンプルの組織に対して WebDialer デザイン計算式をどのように使用するかを示します。

例：1 秒あたりの WebDialer コール数の計算

会社 XYZ は、WebDialer サービスを使用してクリックコール アプリケーションを稼働させることを考えています。その事前のトラフィック分析結果は次の資料の通りです。

• 10,000 人をクリックコール機能で有効にする。
• 各ユーザの平均 6 BHCA
• すべてのコールの 50% が発信で、50% が着信
• 計画では、すべての発信のうち、WebDialer サーバを使用して開始する発信を 30% と見積もる。

コメント これらの値は、WebDialer 配置のサイジングの演習を示すために使用した例です。ユーザのダイヤル特性は、組織によって大きく異なります。

10,000 ユーザーで各 6 BHCA ならば、合計 60,000 BHCA です。ただし、WebDialer 配置のサイジングの計算は、発信コールのみ考慮します。このサイジングの例で最初の情報では、合計 BHCA の 50% が発信です。これは、WebDialer を用いたクリックコールが利用可能なすべてのユーザで、合計 30,000 発信 BHCA という結果になります。

この発信数のうち、WebDialer サービスを使用して発信される割合は、組織によって変化します。この例の組織では、ユーザはいくつかのクリックコール アプリケーションを利用可能で、発信の 30% が WebDialer を使用すると見積もられています。

(30,000 発信 BHCA) ∗ 0.30 = 9,000 発信 BHCA が WebDialer を使用

9,000 BHCA の負荷をサポートするのに必要な WebDialer サーバ ノードの数を判別するには、この値を最繁時に維持する必要のある 1 秒あたりの Busy Hour Call Attempt（BHCA）に変換します。

（9,000 call attempts/時間）∗（時間/3,600 秒）= 2.5 cps

各 WebDialer サービスは最大で 4 cps をサポートできます。したがって、この例では、WebDialer サービスを実行するため 1 つのノードを設定できます。これは、将来の WebDialer 拡張使用に利用できます。サーバ ノードの障害発生時に WebDialer キャパシティを維持するには、冗長性を提供する追加のバックアップ WebDialer サーバ ノードを配置する必要があります。

アテンダントコンソール

Attendant Console を使用した Cisco Unified CM の統合は CTI リソースを利用します。サーバ ベースのアテンダントコンソールはアテンダントがコールを送信した最後の 2,000 人のユーザをモニタするため、CTI リソースの使用率が増加します。さらに、各コールでは、グリーティングやキューイングなどに多数の CTI ルート ポイントとポートが使用されます。

メディア リソース

Unified CM は、Cisco IP Voice Media Streaming Application（IPVMS）を提供します。これは、ソフトウェアだけで実行可能で、ハードウェア リソースを必要としない特定のメディア機能を提供します。Unified CM は、メディア ターミネーション ポイント（MTP）、会議ブリッジ、アナンシエータ（アナウンスの再生用）、または保留音ストリームのソースとして動作できます。Unified CM の機能は、Cisco Integrated Service Router（ISR）によって提供される同様の機能と比べて限定されますが、一般的には保留音ストリーム（ユニキャストとマルチキャストの両方）の主要なソースです。

Cisco IP Voice Media Streaming Application は、次の 2 つの方法のいずれかで配置できます。

• 共存配置

共存配置では、Streaming Application は Unified CM ソフトウェアも実行している、クラスタ内の任意のサーバ ノード（パブリッシャまたはサブスクライバ）で実行されます。

コメント 「共存」という用語は、同じサーバ ノードまたは仮想マシンで複数のサービスまたはアプリケーションが実行されている状態を指します。

• スタンドアロン配置

スタンドアロン配置では、Streaming Application は Unified CM クラスタ内の専用サーバ ノードで実行されます。Cisco IP Voice Media Streaming Application サービスは、サーバ ノードで使用できる唯一のサービスであり、サーバ ノードには、ネットワーク内のデバイスにメディア リソースを提供する機能だけがあります。

Cisco IP Voice Media Streaming Application は MTP、アナンシエータ、および会議機能を提供しますが、これらの機能を Cisco Integrated Service Router（ISR）に配置した方が拡張性が向上します。ただし、このアプリケーションの保留音機能は、簡単には外部ソースに配置できません。 表 1-10 に、これらの各サービスに設定できる最大値を示します。

ここでは、 表 1-10 について説明します。

• すべての値は、メディア デバイスごとにサポートされる発信者の数を表します。たとえば、48 のソフトウェア会議ブリッジが 16 の三者会議をサポートできます。
• これらのデバイスは、デフォルト設定を使用する場合、またはデフォルト設定に近い場合、呼処理ノードと共存できます。
• キャパシティを最大値まで増やす場合は、メディア デバイスをスタンドアロン ノード（呼処理ではない）に配置することを推奨します。
• 最初の（グリーティング）アナウンスメントで MoH オーディオ ソースを使用する場合は、最初のアナウンスを 15 秒未満に抑えることを推奨します。そうしない場合、余分なファイル I/O により、MoH サーバ ノードあたりの MoH ストリームの最大数を 500 〜 700 に減らす必要があります。
• 各メディア デバイスは、IPVMS サービスパラメータ（MoH は MoH デバイス設定ページにありますを使用して無効または有効にできます）。MoH 専用の Unified CM ノードなどを設定できます。

（注） 個別の ISR でサポートされている DSP の各メディア機能のキャパシティを計算するには、Cisco ISR の製品データシートを参照してください。

保留音（Music On Hold）

表 1-11 は、VM 構成と、その設定でサポートできる各ノードの最大同時保留音（MoH）ストリーム数をリストしています。MoH の最大ストリーム キャパシティがこの最大同時セッション数を超えてから、さらに負荷が増えると、MoH 品質の低下、不規則な MoH 動作、または MoH 機能の喪失までも発生するおそれがあるので、実際の使用率が最大同時セッション数を超えないようにしてください。追加の MoH ノード（共存または専用）を追加して、Unified CM クラスタの MoH ストリーム容量を増やします。

表 1-12 のように、Unified CM クラスタでは、保留音のオーディオ固有ソースを最大 500 個定義できます。 表 1-12 に示す最大オーディオ ソース容量は、クラスタで使用される VM 構成のサイズと MoH サーバ タイプ（共存またはスタンドアロン）に基づくクラスタごとの容量です。Unified CM クラスタに MoH ノードを追加しても、MoH ストリーム キャパシティは増加しますが、オーディオ ソース キャパシティは増加しません。音源容量を増やすには、共存 MoH ノードからスタンドアロン MoH ノードに移動するか、クラスタ全体のノード VM 構成のサイズを増やすか、または Unified CM クラスタを追加します。

表 1-11 および 表 1-12 に示されている制限は、ユニキャスト、マルチキャスト、またはユニキャストとマルチキャストの同時ストリームに適用されます。

パフォーマンス上の考慮事項

MoH オーディオ ソースとストリームの数を最大にするには、ソフトウェア MTP やソフトウェア会議ブリッジを無効にするなど、他のメディアデバイスの数を減らす必要があります。Cisco IP Voice Media Streaming Application サービスは、すべてのメディア デバイスの最大設定を同時にサポートしていません。システム リソース（CPU 使用率やディスク I/O など）をメディア デバイスでオーバー サブスクライブすると、システム全体のパフォーマンスに影響します。メディア デバイスがプロビジョニングされた容量を満たせない場合、IPVMS アラームが発行されます。

ローエンド設定（小規模 VM 構成）および MoH 共存と中程度のコール処理の場合、MoH は最大 500 ストリーム、100 MoH オーディオ ソース、および MTP で 48 〜 64 アナンシエータ ストリームに制限され、会議ブリッジがデフォルト値に設定されたるか無効になります。

250 の MoH オーディオ ソースと 250 のアナンシエータ ストリームで 750 の MoH ストリームをサポートするには、専用の小規模 VM 構成の MoH ノードが必要です。

最大 1,000 の MoH ストリーム、500 の MoH オーディオ ソース、および 750 のアナンシエータをサポートするための最小要件は、中規模 OVA 専用スタンドアロン MoH サーバです。

MoH またはアナンシエータに sRTP を使用すると、MoH 発信者の最大数が 25% 削減されます。この場合は、MoH およびアナンシエータ専用の IPVMS サーバを使用することを強く推奨します。

Unified CM MoH サーバは、G.711 ulaw、G.711 mulaw、G729a、および広帯域オーディオの 4 つのコーデックをサポートします。ユニキャスト MoH では、コール セットアップ中にコーデックがネゴシエートされるため、MoH ストリームの数は、有効な MoH コーデックの数ではなく、ユニキャスト MoH で保留中のエンドポイントの数に依存します。マルチキャスト MoH の場合、各マルチキャスト対応オーディオ ソースは、有効な MoH コーデックごとに MoH ストリームを 1 つ生成します。たとえば、2 つのコーデックが有効で、500 のすべての MoH 送信元がマルチキャストに対応している場合、エンドポイントが保留されていなくても、1,000 のマルチキャスト MoH ストリームがアクティブになります。このシナリオでは、いずれかのエンドポイントがユニキャスト MoH に配置されている場合、追加の MoH ストリーム キャパシティが必要になります。

Unified CM に対する影響

共存モードまたはスタンドアロン モードのどちらに配置しても、Cisco IP Voice Media Streaming Application は CPU およびメモリ リソースを消費します。Unified CM の全体のサイジングでは、この影響を考慮する必要があります。

一般に、メディア リソースの使用率は、Unified CM で処理する必要がある BHCA に加算されると見なされます。

コール キューイング（ハント パイロットのキューイング）

コール キューイングに送信できるメディア ストリームの最大数は、保留音ストリームと同じです。詳細については、保留音（Music On Hold）を参照してください。

有効なコール キューイングのハント パイロットの最大数は、Unified CM サブスクライバ ノードごとに 100 です。各ハント パイロットのキューの同時発信者の最大数は 100 です。すべてのハント リストに含まれるメンバの最大数は、コール キューイングがイネーブルのときには変更されません。

LDAP ディレクトリ統合

Unified CM データベース同期機能には、LDAP ストアから Unified CM パブリッシャ データベースへユーザ設定データ（属性）のサブセットをインポートするメカニズムがあります。ユーザ アカウントの同期が発生すると、各ユーザの LDAP アカウント情報が、そのユーザの特定の Unified Communications 機能を有効にするために必要な追加データと関連付けられることがあります。認証も有効な場合、パスワード確認のための LDAP ストアへのバインドに、ユーザのクレデンシャルを使用します。同期や認証が有効な場合に、エンド ユーザのパスワードは Unified CM データベースには格納されません。

ユーザ アカウント情報はクラスタ固有です。各 Unified CM パブリッシャ ノードは、このクラスタから Unified Communications サービスを受けているユーザの一意のリストを保持しています。同期アグリーメントはクラスタ固有で、各パブリッシャにはユーザ アカウント情報の独自コピーがあります。

Unified CM クラスタの最大ユーザ数は、クラスタのメンバー間で複製される内部コンフィギュレーション データベースの最大サイズによって制限されます。現在、設定または同期可能なユーザの最大数は 160,000 です。ディレクトリ同期のパフォーマンスを最適化するには、次の点を考慮してください。

• 電話機や Web ページからのディレクトリ ルックアップには、Unified CM データベースまたは IP Phone Service SDK を使用できる。ディレクトリ ルックアップ機能に Unified CM データベースを使用する場合、LDAP ストアから設定された、または同期されたユーザだけがディレクトリに表示されます。ユーザのサブセットを同期すると、ユーザのそのサブセットだけがディレクトリ ルックアップに表示されます。
• ディレクトリ ルックアップに IP Phone Services SDK を使用する場合に、LDAP に対する Unified CM ユーザの認証が不要であれば、Unified CM クラスタにログインするユーザのサブセットだけに同期を制限できます。
• クラスタが 1 つしか存在せず、LDAP ストア内のユーザ数が Unified CM クラスタでサポートされている最大ユーザ数よりも少なく、ディレクトリ ルックアップが Unified CM データベースに実装されている場合、LDAP ディレクトリ全体をインポートできます。
• 複数のクラスタが存在し、LDAP 内のユーザ数が Unified CM クラスタでサポートされている最大ユーザ数よりも少ない場合、すべてのユーザを各クラスタにインポートし、ディレクトリ ルックアップにすべてのエントリを確実に含めることができます。
• LDAP のユーザアカウントの数が Unified CM クラスタでサポートされている最大ユーザ数を超え、ユーザ セット全体をすべてのユーザに表示する必要がある場合は、Unified IP Phone Services SDK を使用して Unified CM からディレクトリ ルックアップをオフロードする必要があります。
• 同期と認証の両方を有効にすると、Unified CM データベースに設定または同期されたユーザ アカウントはそのクラスタにログインできるようになる。同期するユーザの決定は、ディレクトリ ルックアップ サポートの決定に影響します。

（注） シスコは、上記で説明している制限までユーザ アカウントの同期をサポートしていますが、この制限を強制しているわけではありません。多くのユーザ アカウントを同期化すると、ディスク容量のスターベーション、データベース パフォーマンスの低速化、およびアップグレードの長時間化を招くことがあります。

Cisco Unified CM メガクラスタ配置

呼処理サブスクライバの数が通常クラスタの最大値 4 ペアを超える場合、Unified CM クラスタはメガクラスタと見なされます。メガクラスタには、最大 8 ペアの呼処理サブスクライバと合計 21 未満のサーバ ノードおよび単一の目がクラスタを含めることができます。

たとえば、パブリッシャ、TFTP、TFTP バックアップ、MoH、MoH バックアップ、8 台のプライマリ サーバ、および 8 台のバックアップ サーバを 21 サーバの制限に含めることができます。

（注） IM and Presence は、メガクラスタ配置での 21 サーバの制限にはカウントされません。

Cisco IM and Presence では、25,000 ユーザの VM 構成を使用して、メガクラスタ導入に合わせて VM 構成テンプレートを導入しています。

Unified Communications の配置は、Unified CM メガクラスタで簡素化できる場合があります。このような配置では、次の上限が拡大されます。

• サポートされるエンドポイントの最大数は、通常のクラスタ（8 つの呼処理サブスクライバ ペア）の数の 2 倍です。
• CTI デバイスと接続の最大数も 2 倍になります。

ただし、クラスタ全体の定数は増えません。これらの中で重要なものは次のとおりです。

• コンフィギュレーション データベースのサイズ
• ロケーションとリージョンの数
• LDAP 同期またはプロビジョニングされたエンドユーザの最大数（クラスタあたり 160,000 ユーザ）

（注） メガクラスタ配置に関しては複雑な考慮事項が多数あるので、このような配置の実現を望むお客様は、シスコのアカウント チーム、シスコ アドバンスドサービス、または認定された Cisco Unified Communications パートナーに関与してもらう必要があります。

Cisco IM and Presence

他のすべてのアプリケーションと同様、Cisco IM and Presence のサイジングは、次の方法で実行されます。

• システムを最も基本的なサービスに分解する。
• これらの各サービスのユニット コストを求める。
• 特定のシステム記述を識別されたサービスの集約として分析し、正味システム コストを求める。
• システム コストと配置オプションに基づいて必要なサーバの数を決定する。

IM and Presence については、分析対象システムの次のシステム変数が関連し、正確なサイジングのために考慮する必要があります。

• ユーザの数とタイプ

–ユーザがプレゼンス サービスを取得するために使用するクライアント

–ユーザの動作モード（インスタント メッセージ専用、または完全な Unified Communications ファシリティ）

–ユーザあたりの平均デバイス数

• 標準ユーザが実行するプレゼンス関連のアクティビティ

–カレンダーを含む手動およびコール関連のプレゼンスの変更。プレゼンスの変更の影響は、ウォッチャリストの平均サイズ（連絡先リストのサイズに相当）と構成（クラスタ内、クラスタ間、およびフェデレーテッド）に直接比例します。デフォルトでは、連絡先リストの最大サイズは 200 です。一部のユーザの連絡先が 200 を超える場合、この最大連絡先リストのサイズは、IM and Presence クラスタのプレゼンス設定を変えることで変更できます。

–最繁時におけるユーザごとのインスタント メッセージ（2 人のユーザ間で直接やり取り）の数

–チャット ルームの数、各チャット ルームのユーザ数、および各チャット ルームのユーザあたりのインスタント メッセージ数によるチャット サポート

–各ユーザの状態変更（コール関連とユーザ開始の両方）

• 導入モデル

–クラスタ間プレゼンスがサポートされるかどうか

–フェデレーションがサポートされるかどうか

–ハイ アベイラビリティが必要かどうか

• サーバ設定

–必要な VM 構成のサイズ

• システム オプション

–コンプライアンス レコーディングが必要かどうか

システム要件を定量化したら、 表 1-13 のデータから必要な仮想マシンの数を特定できます。

場合によっては、IM and Presence ノードが追加のリソースを必要とするため、より大きな OVA テンプレートが効果的に動作します。IM and Presence 機能は、IM and Presence に割り当てられたユーザ数およびユーザあたりのデバイス数を超えて、システム パフォーマンスに大きな影響を与えます。

（注） OVA サイズはデバイスの合計数を指し、上記の機能が IM and Presence に与える影響は反映されません。

次の IM and Presence の展開タイプと機能には、15,000 ユーザ OVA 以上の OVA テンプレートが必要です。

• 集中型 IM and Presence 展開（25,000 ユーザ OVA 推奨）：1 つ（または複数）の IM and Presence クラスタと複数の展開
• Unified CM クラスタ
• マルチクラスタ IM and Presence の展開：それぞれが IM and Presence サブクラスタを備えた 2 つ（またはそれ以上）の Unified CM クラスタ、または 2 つ（またはそれ以上）の IM and Presence クラスタを備えた展開。
• 常設チャット
• メッセージ アーカイブ
• サードパーティ コンプライアンス
• Multiple device messaging（MDM）
• マネージド ファイル転送（MFT）
• Outlook 統合（Jabber クライアント）

上記の IM and Presence 導入タイプおよび機能に大きな OVA テンプレートを使用して追加のリソースを提供しない場合、システム CPU、IM and Presence サービスのコアダンプ、常設チャット、およびその他のパフォーマンス関連の問題が発生します。

Cisco IM and Presence の詳細については、次の場所にある『 Cisco Unified Communications Manager and IM and Presence Service 互換性マトリクス 』の最新版を参照してください。

https://www.cisco.com/c/ja_jp/support/unified-communications/unified-communications-manager-callmanager/products-device-support-tables-list.html

Cisco IM and Presence の VM 構成の正式な定義については、次の URL を参照してください。

https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-ucm-im-presence.html

Unified CM に対する影響

Cisco IM and Presence サービスは、Unified CM のパフォーマンスに次のように影響します。

• AXL/SOAP インターフェイスを介したユーザ同期
• SIP トランクを介したプレゼンス情報
• 電話制御を有効にする CTI トラフィック

一般に、ユーザ同期（ワンタイム ヒットを除く）の影響および SIP トランクを介したプレゼンス情報の影響はごくわずかです。ただし、電話機の CTI 制御の影響は、CTI の制限で考慮する必要があります。

IM and Presence VM 構成は、Unified CM VM 構成とは異なります。IM and Presence テンプレートはユーザ ベースですが、Unified CM テンプレートはデバイス ベースです。たとえば、5,000 ユーザの IM and Presence VM 構成を Unified CM の大規模 VM 構成で使用すると、それぞれ 2 つのデバイスを持つ 5,000 人のユーザがサポートされます。同じクラスタ内のすべての IM and Presence ノードでは、同じタイプの VM 構成を使用する必要があります。

一元化された IM and Presence

Cisco IM and Presence は、集中型展開オプションをサポートしています。集中型 IM and Presence クラスタは、複数のリモート Unified CM クラスタのユーザにプレゼンス サービスを提供できます。ただし、各ユーザが単一のクライアントを持つ場合、すべてのリモート Unified CM クラスタのユーザの合計数は 75,000 を超えてはなりません。ユーザごとに複数のクライアントを使用すると、この制限が緩和されます。

（注） 集中型 IM and Presence クラスタには、クラスタ内の合計 7 台のサーバ（3 つの IM and Presence サブクラスタペア（6 台のサーバ）+ Unified CM パブリッシャ ノード）用の Unified CM パブリッシャ ノードが必要です。

集中型 IM and Presence クラスタを展開する場合は、クラスタ内のすべての IM and Presence ノードに 25,000 ユーザの IM and Presence VM テンプレートを使用し、その集中型クラスタの Unified CM パブリッシャ ノードに大規模な Unified CM VM テンプレートを使用することを推奨します。

集中型 IM and Presence の展開は、次の制限に従って WAN 経由でクラスタ化できます。

• すべてのリモート Unified CM クラスタは、集中型 IM and Presence クラスタの 80 ms ラウンドトリップ時間（RTT）以内である必要があります。
• 集中型 IM and Presence クラスタは、最大遅延 300 ミリ秒 RTT のクラスタ間トランクを使用して、別の集中型 IM and Presence クラスタに接続できます。

緊急サービス

Cisco Emergency Responder は、電話機のロケーションと電話機の接続先のアクセス スイッチ ポートを追跡します。電話機は、自動的に検出するか、手動で Emergency Responder に入力できます。 表 1-14 に、Emergency Responder をサポートする VM 構成およびその最大キャパシティを示します。

（注） これらの制限は、スタンドアロン型 Emergency Responder 展開に適用され、ネイティブ緊急サービスが使用されていないことを前提としています。

Cisco Emergency Responder およびその他の Unified Communications 製品用に正式に定義された VM 構成は、次の Web サイトから入手できます。

https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-emergency-responder.html

Unified CM クラスタごとにアクティブにできる Emergency Responder は 1 つのみです。したがって、クラスタ内のすべての電話機で緊急対応できる十分なリソースがある VM 構成を選択してください。

Emergency Responder のネットワークのハードウェアおよびソフトウェア要件の詳細については、次の Web サイトで入手可能な『 Cisco Emergency Responder アドミニストレーション ガイド 』を参照してください。

https://www.cisco.com/en/US/products/sw/voicesw/ps842/prod_maintenance_guides_list.html

Cisco Expressway

Cisco Expressway の導入では、リモート エンドポイントの登録を含む呼制御のコンポーネントとしてCisco Unified CM を使用します。このようなシステムのサイジングでは、実行する機能と Unified CM への影響を考慮に入れます。

Cisco Expressway のサイジングでは、通常、次のパラメータを考慮して、Cisco Expressway-C と Expressway-E のノード ペアの必要数を決定する必要があります。

• ピーク使用時間中の Expressway-C および Expressway-E ノードの各ペアを介したエンドポイント登録の数
• Expressway-C および Expressway-E ノードの各ペアを通過する音声のみの同時コールとビデオ コールの予想数

Expressway-C および Expressway-E クラスタは、最大 6 ノードをサポートします。

モバイルおよびリモートアクセス（MRA）にはライセンスは特に必要ありませんが、Business-to-Business（B2B）コミュニケーションにはリッチメディアのライセンスが必要です。リッチ メディア セッション形式のライセンスは、Expressway クラスタ全体で共有されます。クラスタ内の各 Expressway ノードに割り当てられたリッチメディア セッションは、クラスタ内のすべてのノードで共有されるクラスタ データベースに供与されます。このモデルでは、いずれか 1 つの Expressway ノードが物理的な容量よりも多くのライセンスを保持できます。

Cisco Expressway キャパシティ プランニング

表 1-15 に、Cisco Expressway-C および Expressway-E サーバ ノード ペアとクラスタの Cisco Expressway プロキシ登録とコール キャパシティを示します。

（注） 表 1-15 の容量数は、Expressway-E で MRA の高速パス登録が有効になっていることを前提としています。

（注） 大規模 OVA テンプレートは、限られたハードウェアでのみサポートされます。詳細については、https://www.cisco.com/go/virtualized-collaboration のドキュメントを参照してください。

Cisco Expressway をクラスタ化する場合は、次のガイドラインが適用されます。

• Expressway クラスタは最大 6 ノードをサポートします（クラスタ容量はノード容量の最大 4 倍）。
• Expressway-E クラスタと Expressway-C クラスタの各ペア間およびペア内のすべてのノードの容量は、同じである必要があります。たとえば、Expressway-E クラスタ内または対応する Expressway-C クラスタ内のノードが中規模 VM 構成を使用している場合は、大規模 VM 構成を使用する Expressway-E ノードを展開してはいけません。
• Expressway のピアは、Expressway-E クラスタと Expressway-C クラスタで同じ数だけ展開する必要があります。たとえば、3 ノードの Expressway-E クラスタは、3 ノードの Expressway-C クラスタとともに展開する必要があります。
• Expressway-E クラスタと Expressway-C クラスタのペアは、ノード容量がすべてのノードで同じであるかぎり、アプライアンスで実行されるノードまたは仮想マシンとして実行されるノードを組み合わせて構成できます。
• Expressway ノードの VM 構成または Expressway アプライアンスは、Expressway シリーズ クラスタ ペア間で一致する必要があります。
• 複数の Expressway シリーズ クラスタのペアを展開して、容量を増やすことができます。

（注） Cisco Expressway クラスタと Cisco Unified CM クラスタの間には依存関係があります。Expressway のキャパシティプランニングでは、関連付けられたまたは依存する Unified CM クラスタのキャパシティも考慮する必要があります。

サイジングの制限、キャパシティプランニング、および導入に関する考慮事項など、Cisco Expressway キャパシティプランニングの考慮事項の詳細については、次の Web サイトで入手可能な Cisco Expressway 製品マニュアルを参照してください。

https://www.cisco.com/c/en/us/support/unified-communications/expressway-series/tsd-products-support-series-home.html

ゲートウェイ

PSTN ゲートウェイは、Unified Communications システムと PSTN 間のトラフィックを処理します。トラフィック量は、リソース使用率（CPU とメモリ）およびゲートウェイに必要な PSTN DS0 回線を決定します。

PSTN トラフィックは Unified CM に登録されているエンドポイントによって生成されますが、音声自動応答装置（IVR）アプリケーションやコンタクトセンター配置の一部などの他のソースがある場合もあります。

ゲートウェイは、リソース（CPU、メモリ、DSP など）を必要とする他の機能も実行できます。これらの機能には、メディア ターミネーション ポイント（MTP）、トランスコーディング、会議ブリッジ、RSVP Agent などのメディア処理が含まれます。

特に Cisco Integrated Service Router（ISR）に基づくゲートウェイは、VXML 処理エンジンとしての動作、境界要素としての機能、Cisco Unified Communications Manager Express または Survivable Remote Site Telephony（SRST）としての役割、または WAN エッジ機能の実行などのその他の機能を提供できます。ゲートウェイの負荷を計算するときは、これらのすべてのアクティビティを考慮する必要があります。

ゲートウェイ グループ

ゲートウェイの数を考慮するときは、物理ゲートウェイ サーバの地理的な配置も考慮する必要があります。PSTN アクセスが分散される配置モデルでは、ゲートウェイをグループとしてサイジングし、適切な負荷を各グループに割り当てる必要があります。

共通の特性を持つゲートウェイ群の、特定のゲートウェイを特定の機能専用にする場合にも、グループ化が適切なことがあります。

したがって、必要なゲートウェイの数を正確に見積もるには、次の情報が必要です。

• 共通のグループ プロファイルを共有するゲートウェイのグループ。共通のプロファイルは、配置の複雑さに依存します。
• 各グループのプロファイルを構成するトラフィック パターン、プラットフォーム、ブロック確率など。
• グループを構成する個々のゲートウェイ プラットフォーム。特定のゲートウェイ モデルを決定するときは、期待される機能とキャパシティをそのモデルでサポートできることを確認します。パフォーマンス要件を満たすために選択したプラットフォームの機能に応じて、ゲートウェイ グループに複数のゲートウェイが必要になることがあります。

ボイス メッセージング

ボイス メッセージングは、単独でサイジングするだけでなく、他の Unified Communications コンポーネント（主に Unified CM）に対する影響も考慮してサイジングする必要があるアプリケーションです。

合計ユーザ数は、ボイス メッセージング システムをサイジングする主な要因です。ボイス メッセージングのサイジングに影響を与えるその他の要因は次のとおりです。

• アプリケーションで処理する必要がある最繁時のコール数
• サーバに残されるメッセージの平均的な長さ
• 最繁時にメッセージを確認するユーザの数
• ユーザ セッションの平均的な長さ
• 音声認識や音声合成セッションなどの高度な操作
• メディア トランスコーディング
• ボイス メッセージング システム上のポートは、ゲートウェイ上の DS0 に似ており、最適化する必要がある共有リソースです。確率的着呼に関する同じ考慮事項とブロックの必要性が両方のリソース タイプに適用されます。

表 1-16 に、各種ボイス メッセージング ソリューションが配置の拡張性要件に適合可能かどうかを示します。

表 1-17 に、Cisco Unity Connection を実行している各種 VM 構成のさまざまな機能の上限を示します。

Cisco Unity Connection の VM 構成に関する正式な定義については、次の URL を参照してください。

https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-unity-connection.html

Unified CM に対する影響

Unified CM に対するボイス メッセージング システムの影響は、Unified CM で実行する必要がある追加処理を考慮して測定できます。これらの追加コール フローにより、Unified CM のサイジング負荷が大きくなります。これらのコールは次のとおりです。

• ユーザがいないとき、あるいはユーザが Do Not Disturb（DND）または他の機能を使用してコールを故意に転送するときに、ボイス メッセージング システムに転送する必要があるコール。
• ボイス メッセージングのパイロット番号をダイヤルしてボイス メッセージにアクセスするユーザからのコール。これらのコールは、Unified CM を通過し、コールの数と期間など、Unified CM が処理するコールに追加する必要があります。

コラボレーティブ会議

コラボレーティブ会議システムは、クラウド ベース、オンプレミス ベース、またはハイブリッドです。オンプレミス ベースまたはハイブリッド システムの場合、会議サーバ（VM）に加えて Cisco Unified CM サーバ（VM）が必要です。

会議サーバのサイジングを行う場合、サーバ/ノードのタイプと数を決定するために、次のパラメータを考慮する必要があります。

• 登録済み会議システムの数
• ピーク使用間隔中に予想される会議参加者数（音声、ビデオ、および Web）
• すべての参加者がピーク時の使用間隔（通常は最も混雑する時間帯）の異なる会議に参加するために必要なダイヤルイン時間
• ビデオと音声の品質（解像度、コーデック タイプ）

会議のサイジングに関する一般的なガイドライン

会議リソースの要件を計算する方法はいくつかあります。

• 平均月間使用時間に基づく計算

平均会議使用状況の統計情報（会議コールに費やされた月あたりの分数）が使用可能な場合は、 表 1-18 を使用して、必要なポート数に関する会議キャパシティ要件を概算できます。

• 会議システムのユーザ数に基づく計算

会議システムの使用量が少ない場合、20 〜 50 ごとに 1 つのポートを用意する必要があります。これは、ピーク使用間隔中に電話会議のユーザの 2 〜 5% を想定しています。平均的な会議の使用状況を想定すると、ピーク時の内部通話中のユーザの 5 〜 10% が想定されます。つまり、10 〜 20 人のユーザごとに 1 つのポートです。頻繁に使用される会議では、必要な 5 〜 10 人のユーザごとに 1 つのポートを想定できます。これは、ピーク時の電話会議のユーザの 10 〜 20% です。たとえば、6,000 人のユーザがいるシステムでは、システムの使用状況に応じて 120 〜 1,200 個のポートをプロビジョニングする必要があります。

• ピーク時の間隔の使用時間に基づく計算

ピーク時の実際の会議の使用状況は、通常、既存の会議システムログまたはサービス プロバイダーの請求書から取得できます。会議の統計情報には、通常、会議の数と会議ごとの平均参加者数が示されます。これら 2 つの数値の積は、アクティブな会議参加者の平均数、つまり必要なポート数を定義します。必要なポートの実際の数は、展開の規模によっては実際よりも多くなる可能性があります。小規模な展開の場合は、最大と平均の比率を大きくする必要があります。

音声、ビデオ、Web 会議のサイジングのガイドライン

最新のコラボレーション会議システムのサイジングを行う場合、製品キャパシティ データシートには、さまざまな使用条件（音声/ビデオ、録画、ストリーミング、コンテンツ共有）でサポートされる制限が記載されています。

適切なサイジングの重要な要素（必要なサーバ/システムの数の決定）は、ユーザがビジー間隔の開始時に会議に参加する間隔の期間とともに、コラボレーション会議で同時にユーザを正確に見積もることです。

注：音声と音声/ビデオの容量は同じであるため、ビデオ コールと音声通話の割合は重要な要素ではありません。高品質のビデオが必要な場合、ビデオ品質が要因となり、キャパシティの減少につながる可能性があります。

表 1-19 に、音声、ビデオ、および Web 会議システムのキャパシティ プランニングに関するサイジングの重要な考慮事項を示します。会議展開のサイズを正確に決定するには、同時ユーザの最大数、同時会議の最大数、システムでサポートされる単一の会議の最大参加者数などを定量化して理解することが重要です。

（注） 音声/ビデオ容量は同じになる傾向があるため、ビデオと音声通話の割合は通常、会議システムのサイジングにとって重要な要素ではありません。ただし、高品質のビデオはシステム全体の会議キャパシティを低下させるため、ビデオ品質は考慮すべき重要な要素です。

Unified CM での会議の影響

コール量が増えると、Unified CM のキャパシティ/リソース要件が増加します。コール処理リソースは、ビジー会議期間の最初と最後の数分間影響を受けます。コラボレーションコールで最も混雑する時間帯のユーザの 10% を想定すると、サポートされるコール/秒レートは、コラボレーション コールのユーザなしおよびユーザあたり 4 BHCA と比較して、少なくとも 40% 高くする必要があります。

メモリの要件も高くなります。また、会議コールのユーザの 10% により、同時コールの数が少なくとも 40% 増加します。

Cisco Prime Collaboration 管理ツール

Cisco Prime Collaboration は、Cisco Unified Communication と TelePresence システムを試験、展開、およびモニタリングする統合ツール セットを提供します。Cisco Prime Collaboration には、Prime Collaboration Provisioning、Prime Collaboration Assurance、Prime Collaboration Analytics が含まれます。

これらのアプリケーションは仮想マシン上で実行されます。Cisco Prime Collaboration Provisioning は独自の仮想マシン上で実行され、Cisco Prime Collaboration Assurance と Cisco Prime Analytics は同じ仮想マシン上で実行されます。これらのアプリケーションの仮想マシン サイジングは比較的単純で、管理するエンドポイントまたはネットワークデバイスの数に直接依存します。

Cisco Prime Collaboration Provisioning

Cisco Prime Collaboration Provisioning は、最大 150,000 のエンドポイントをサポートできます。

さまざまなレベルのパフォーマンスに必要な仮想マシンのリソースについては、次の Web サイトから入手可能な『Cisco Prime Collaboration インストールおよびアップグレード ガイド』の最新バージョンを参照してください。

https://www.cisco.com/c/en/us/support/cloud-systems-management/prime-collaboration/products-installation-guides-list.html

Cisco Prime Collaboration Assurance

Cisco Prime Collaboration Assurance は、ルータやスイッチなどの電話やその他のネットワークデバイスを管理できます。これは単一マシン構成で動作し、最大 150,000 台の電話機をサポートします。

さまざまなレベルのパフォーマンスに必要な仮想マシンのリソースについては、次の Web サイトから入手可能な『 Cisco Prime Collaboration Quick Start Guide 』の最新バージョンを参照してください。

https://www.cisco.com/c/en/us/support/cloud-systems-management/prime-collaboration/products-installation-guides-list.html

Cisco Prime Collaboration Analytics

Cisco Prime Collaboration Analytics は、Cisco Prime Collaboration Assurance と同じ仮想マシン上で実行して、音声品質を測定するために Cisco Network Analysis Module（NAM）と連携して動作します。

さまざまなレベルのパフォーマンスに必要なハードウェア リソースについては、次の Web サイトから入手可能な『 Cisco Prime Collaboration Data Sheet 』の最新バージョンを参照してください。

https://www.cisco.com/c/ja_jp/products/cloud-systems-management/prime-collaboration/datasheet-listing.html

Cisco Unified Communications Manager Express

Cisco Unified Communications Manager Express（Unified CME）は、Cisco IOS サービス統合型ルータ（ISR）プラットフォーム（ローエンドの Cisco 881 ISR からハイエンドの Cisco 3945E ISR 2 まで）のいずれかで実行されます。これらの各ルータでは、サポートできる電話機の数に上限があります。これらのプラットフォームが呼処理を実行するための実際のキャパシティは、IP ルーティング、ドメイン ネーム システム（DNS）、Dynamic Host Control Protocol（DHCP）などのほかに他に実行する機能によって制限されることがあります。

Unified CME は、単一の Cisco IOS プラットフォーム上で最大 450 エンドポイントをサポートできます。ただし、各ルータ プラットフォームのエンドポイントのキャパシティは、システムのサイズによって異なります。Unified CME は Cisco Collaboration Sizing Tool ではサポートされないため、次の Web サイトで入手可能な Unified CME の製品データシートに記載されているキャパシティ情報に従う必要があります。

https://www.cisco.com/c/ja_jp/products/unified-communications/unified-communications-manager-express/datasheet-listing.html

Cisco Business Edition

Cisco Business Edition は、高品質な音声、ビデオ、モビリティ、メッセージング、会議、インスタントメッセージとプレゼンス、コンタクトセンターなどのアプリケーションがプリロードされたコラボレーション ソリューション パッケージです。

Cisco Business Edition 6000 および 7000には、選択可能なプラットフォーム モデル オプションがあります。

Cisco Business Edition 6000 には、次の2 つ のハードウェア プラットフォーム オプションがあります。

• BE6000H：最大容量 1,000 ユーザ。 2,500 台のデバイス 100 のコンタクトセンター エージェント。通常、単一の仮想サーバプラットフォームで 9 つのコラボレーション アプリケーション オプションをサポートします。最大 5,000 BHCA
• BE6000M：最大容量 1,000 ユーザ。 1,200 台のデバイス 100 のコンタクトセンター エージェント。通常、単一の仮想サーバプラットフォームで 5 つのコラボレーション アプリケーション オプションをサポートします。最大 5,000 BHCA

Cisco Business Edition 6000 ソリューションの詳細については、 https://www.cisco.com/go/be6000 を参照してください。

Cisco Business Edition 7000 には、次の 2 つのハードウェア プラットフォーム オプションがあります。

• BE7000H：この高密度モデルは、ユーザ数 1000 ～ 5000 人、デバイス数 3000 ～ 15,000 台の複数サイト環境に導入した場合、通常 5 ～ 10 のコラボレーション アプリケーションを使用できます。
• BE7000M：この中密度モデルは、ユーザ数 1000 ～ 5000 人、デバイス数 3000 ～ 15,000 台の複数サイト環境に導入した場合、通常 4 ～ 6 のコラボレーション アプリケーションを使用できます。

Cisco Business Edition 7000 ソリューションの詳細については、 https://www.cisco.com/go/be7000 を参照してください。

Cisco Business Edition の最繁時呼数（BHCA）

このセクションでは、Cisco Business Edition 6000H を使用してキャパシティを計算しますが、このセクションの情報は BE6000M および 750 BHCA キャパシティの小さい BE6000S にも適用されます。

前述のとおり、Business Edition 6000H は、最大 5,000 BHCA をサポートします。システム使用の計算では、Cisco Business Edition 6000 のオーバーサブスクリプションを回避するために、 BHCA 最大数を超えないようにします。任意の電話機の BHCA が 4 BHCA を超えたときに、BHCA に対する配慮が必要になります。真の BHCA 値は、最繁時における電話機の使用状況の基準測定を実施することによってのみ、決定されます。この使用状況を基準なしで見積もった場合は特に注意が必要です。

Cisco Business Edition 6000H のデバイスの見積もり

デバイスは、この計算の目的の主な 2 つのカテゴリである電話デバイスとトランク デバイスに分けることができます。

電話デバイスは、単一のコール可能なエンドポイントです。これには、Cisco Unified IP Phone 8800 シリーズやその他のコラボレーション音声およびビデオ エンドポイントなどの単体のクライアントデバイス、Cisco Jabber などのソフトウェア クライアント、アナログ電話機ポートや H.323 クライアントなどが含まれます。Cisco Business Edition 6000 は中密度のサーバでは最大 1,200 のエンドポイント、高密度サーバでは最大 2,500 のエンドポイントをサポートしますが、上記で説明するように、実際のエンドポイント キャパシティはシステムの合計 BHCA によって異なります。

トランク デバイスは、複数のコールを複数のエンドポイントまで伝送します。これには、SIP トランクまたはゲートキーパー制御 H.323 トランクなどのトランクまたはゲートウェイ デバイスを使用できます。Business Edition 6000 は、H.323 トランク、SIP トランク、および MGCP トランクやゲートウェイならびにアナログ ゲートウェイのようなクラスタ間トランキングをサポートします。他のプロトコルではなく SIP トランクを使用することを推奨します。

BHCA を見積もる方法は、両方のタイプのデバイスでほとんど同じですが、一般に、トランク デバイスは、外部のユーザ グループ（PSTN または他の PBX 内線）にアクセスするためにより大きなエンドポイントのグループで使用されるため、BHCA が高くなります。

BHCA に基づく使用状況の特性を参照してデバイス グループ（電話デバイスまたはトランク デバイス）を定義してから、各デバイス グループの BHCA を加算して、システムの総 BHCA を求めることができます。これによって、サポートされている 5,000 BHCA を超えないことが保証されます。

たとえば、4 BHCA の 100 台の電話機と 12 BHCA の 80 台の電話機の総 BHCA は、次のように計算できます。

4 BHCA の 100 台の電話機：100∗4 = 400

12 BHCA の 80 台の電話機：80∗12 = 960

すべての電話機の総 BHCA = (100∗4) + (80∗12) = 1,360 BHCA

トランク デバイスの場合は、デバイスで処理されるコールのうち PSTN との間で発着信する割合がわかっていれば、BHCA を計算できます。この例では、すべてのデバイス コールの半分が PSTN との間で発着信している場合、デバイス BHCA （この場合は 1360）のゲートウェイに対する実効値は、1360 の半分、つまり、680 BHCA になります。したがって、この例での電話デバイスとトランク デバイスに関する総システム BHCA は次のようになります。

総システム BHCA = 1,360 + 680 = 2,040 BHCA

複数の電話機でシェアド ラインにしている場合は、シェアド ラインを設定している電話機ごとに 1 つずつのコール レッグ（コールごとに 2 コール レッグ）を BHCA に含める必要があります。複数のデバイス グループにまたがるシェアド ラインは、そのグループの BHCA に影響します。つまり、シェアド ラインに対する 1 つのコールが、回線インスタンスあたり 1 つのコール レッグ、つまり、1 コールの半分として計算されます。BHCA が異なる複数の電話機グループがある場合は、次の方法で BHCA 値を計算します。

シェアド ライン BHCA = 0.5 ∗ （シェアド ライン数） ∗ （1 回線あたりの BHCA）

たとえば、次の特徴を持つ 2 つのユーザ クラスがあるとします。

8 BHCA の 100 台の電話機 = 800 BHCA

4 BHCA の 150 台の電話機 = 600 BHCA

また、1 グループあたり 10 本のシェアド ラインがあるとして、次の BHCA 値に加算します。

8 BHCA のグループ内の 10 本のシェアド ライン = 0.5∗10∗8 = 40 BHCA

4 BHCA のグループ内の 10 本のシェアド ライン = 0.5∗10∗4 = 20 BHCA

この場合のすべての電話デバイスに関する総 BHCA は、シェアド ラインの BHCA の合計に加算された電話機グループごとの BHCA の合計になります。

800 + 600 + 40 + 20 = 1,460 総 BHCA

上記の各例の総 BHCA は、システムの最大数である 5,000 BHCA を下回っているため、許容範囲に含まれることに注意してください。

Business Edition 6000 でシングル ナンバー リーチ（SNR）用に Cisco Unified Mobility を使用している場合、リモート接続先およびモビリティ ID に転送されたコールまたはオフシステム電話番号が BHCA に影響することに留意してください。アプライアンスがオーバーサブスクライブするのを防ぐには、この SNR リモート接続先またはオフシステム電話の BHCA を考慮する必要があります。

（注） Secure RTP（SRTP）を使用したメディア認証と暗号化は、システム リソースとシステム性能に影響を与えます。メディア認証または暗号化の使用を検討している場合は、この事実に留意して適切な調整を行ってください。通常、セキュリティに対応していない 100 台の IP Phone は、セキュリティに対応した 90 台の IP Phone と同じ影響をシステム リソースに与えます（10 対 9 の割合）。

Cisco Business Edition 6000 について考慮するキャパシティ プランニングのもう 1 つの側面は、コール カバレッジです。特殊なデバイス グループを作成し、特定のサービスの着信コールを複数のルール（トップダウン、循環ハント、最長アイドル時間、またはブロードキャスト）に従って処理できます。これは、Cisco Business Edition 6000 のハント グループまたは回線グループの設定で実現されます。回線グループの分配アルゴリズムにブロードキャスト（全メンバーを呼び出す）を用いる場合には、この要素によっても BHCA が影響を受けます。Cisco Business Edition 6000 でブロードキャスト分配アルゴリズムが必要な場合は、1 つのハント グループまたは回線グループのメンバー数を 3 以下にすることを推奨します。システムの負荷によっては、この実施によってシステムの BHCA が大きく影響され、プラットフォームのリソースがオーバーサブスクライブする可能性があります。ブロードキャストの分配アルゴリズムを使用するハント グループまたは回線グループの数も 3 以下に制限する必要があります。これらはシステム BHCA のオーバーサブスクリプションを回避するために開発されたベストプラクティスの推奨事項です。システム全体の BHCA キャパシティを超えない限り、配置内でのこれらの推奨事項の超過はサポートされます。

Unified CM クラスタ内で異なるタイプのハードウェア プラットフォームを混在させることもできます。ただし、すべての VM構成がすべてのサーバプラットフォームでサポートされるわけではないため、VM 構成を混在させるとクラスタ全体のキャパシティに影響します。

Cisco Business Edition 6000 向け Cisco Unified Mobility

Cisco Business Edition 6000 システムでの Cisco Unified Mobility ユーザの容量は、サーバのハードウェアではなく、ユーザあたりのリモート接続先数および Unified Monbility を有効にしているユーザの BHCA にのみ依存します。したがって、Cisco Business Edition 6000 でサポートされるリモート接続先数は、これらのユーザの BHCA に直接依存します。

設定された各リモート接続先またはモビリティ ID は、BHCA に影響を与える可能性があります。ユーザに設定されているリモート接続先またはモビリティ ID ごとに、追加のコール レッグが 1 つずつ使用されます。各コールは 2 つのコール レッグで構成されているため、1 つのリモート接続先の呼び出しが 1 つのコールの半分に相当します。そのため、リモート接続先の合計 BHCA は次の式で計算できます。

次に例を示します。

5 BHCA ごとに 300 人のユーザがいて、それぞれのユーザに 1 つずつのリモート接続先またはモビリティ ID（全部で 300 のリモート接続先およびモビリティ ID）が割り当てられたシステムがあるとすると、リモート接続先およびモビリティ ID の合計 BHCA の計算は次のようになります。

リモート接続先およびモビリティ ID の合計 BHCA =
0.5 ∗（300 ユーザ）∗（ユーザあたり 1 リモート接続先またはモビリティ ID）∗（ユーザあたり 5 BHCA）= 750 BHCA

この例でユーザの合計 BHCA は（300 ユーザ） ∗ （ユーザあたり 5 BHCA）、つまり 1,500 です。この値にリモート接続先の合計 BHCA である 750 を加算すると、システムの合計 BHCA 2,250（ユーザの合計 BHCA 1,500 + リモート接続先およびモビリティ ID BHCA の合計 750）が得られます。

上記の例のシステムで他のアプリケーションや追加の BHCA 変数が使用されている場合は、容量はさらに制限される可能性があります（詳細については、前項を参照してください）。

Cisco Business Edition 6000 キャパシティ プランニングの詳細については、他の製品情報と同様、Cisco Business Edition 6000 向けの次の製品マニュアルを参照してください。

• https://www.cisco.com/jp/go/be6000
• https://www.cisco.com/c/ja_jp/support/unified-communications/business-edition-6000/tsd-products-support-series-home.html

全般的な前提事項

表 1-21 以下に、（すべてのサイズの）簡易サイジングの例に適用される設計と展開の前提条件の基本セットを示します。

仮想マシンの配置

簡易サイジング例の仮想マシン（VM）の配置例は、必要な VM をレイアウトする方法の 1 つですが、BE7000 プラットフォーム全体に VM を分散する方法は多数あります。単一の BE7000 の障害が展開内の必要なアプリケーションのすべてのインスタンスを完全に排除しないように、各アプリケーションの冗長 VM ノードを異なる BE7000 に分離することが重要です。

これらの例では、より多くのアプリケーション VM を必要とする導入の拡大に対応するために各 BE7000 に予備容量がありますが、この予備容量には、ソフトウェアやハードウェアのメンテナンス操作のために 1 台のサーバを解放するために、BE7000 サーバ間でアプリケーション VM を一時的に移動するほどの余裕があります。追加の BE7000 VM ホスト サーバは、追加のコラボレーション アプリケーション VM（たとえば、Cisco Emergency Responder）、および既存のアプリケーションと進行中の VM およびサーバ メンテナンスの将来の拡張に対応するために展開できます。

（注） Cisco Meeting Server（CMS）と CUBE は、それぞれ CMS 1000 または CMS 2000 と CUBE IOS / IOS-XE ルータ プラットフォームに展開されているため、仮想マシンの配置レイアウトの図には示されていません。

小規模

小規模で簡素化されたサイジングの例は、最大 1,000の ユーザまたはデバイスの導入であり、コール、IM and Presence、ボイスメッセージング、エッジサービス、および会議ワークロードが含まれます。すべてのサイジングは、コラボレーション アプリケーション仮想マシンが Business Edition 7000M（BE7000M）プラットフォームでホストされていることを前提としています。

このサイジングの例は、次のワークロード固有の前提に基づいています。

• 通話

–展開は、「1:1 冗長性」で展開された Unified CM Small OVA ノードに基づいています。

–最大 1,000 のロケーション、リージョン、およびデバイスプール。

–DN の合計数 2,000、最大 3 つの追加エンドポイントで共有される最大 100 の DN。

–ハント パイロットが最大 25 個、ハント リストが最大 15 個、サーキュラーおよびシーケンシャル回線グループが最大 15 個（回線グループあたりのメンバー数は平均 5）、ブロードキャスト回線グループが最大 15 個（回線グループあたりのメンバー数は平均 10）です。

–最大 100 個の CTI ポートおよび最大 25 個の CTI ルートポイント。

–1 分あたり最大 125 回の EM ログイン/ログアウトがサポートされています。

• IM & Presence

–Unified CM IM&P ノードは、1,000 ユーザの OVA/VM に展開されます。

コメント この例では、高度な IM&P 機能（永続的なチャットとマネージド ファイル転送（MFT）を含む）は有効になりません。これらの機能を有効にするには、少なくとも 5,000 のユーザ OVA/VM を使用する必要があります。

• ボイス メッセージング

–Unity Connection ノードは、1,000 ユーザ の OVA/VM に導入されます。

• エッジ

–Expressway-C および Expressway-E ノードは、小規模 OVAテンプレートに展開されます。

• ミーティング

–Cisco Meeting Server（CMS）は、CMS 1000 プラットフォームに展開されます。

–Cisco Meeting Management（CMM）ノードは、小規模 OVA/VM に展開されます。

–TelePresence Management Suite（TMS）ノードは、通常の OVA に展開されます。

図 1-3 この小規模な導入例に必要なコラボレーション アプリケーション仮想マシンのレイアウト例を示します。

図 1-3 小規模な簡易サイジングのための仮想マシンの配置例

中規模

中規模サイジングの例は、最大 10,000 のユーザまたはデバイスを導入するためのもので、コール、IM and Presence、ボイスメッセージング、エッジサービス、会議のワークロードが含まれます。すべてのサイジングは、コラボレーション アプリケーション仮想マシンが Business Edition 7000M（BE7000M）プラットフォームでホストされていることを前提としています。

（注） 図 1-4 の中規模 #1 の例のVMレイアウトと図 1-5 のメディア #2 の例の VM レイアウトの主な違いは、メディア #2 の例では 2 番目の Unified CM サブスクライバ ペア（CM SUB3 と CM SUB4）が追加されることです。および別の Expressway-C や Expressway-E のペア（Expwy-C3 および Expwy-E3）は、増加したユーザやデバイスの負荷を処理します。さらに、中規模 #2 の例では、より大きな Unity Connection OVA（UCXN1 および UCXN2）と追加のより大きな TMS OVA（TMS1、TMS2、TMS-SQL1、TMS-SQL2、TMSXE1、および TMSEXE2）が必要です。

中規模 #1

最初の中規模のサイジングの例は、最大 5,000 人のユーザを展開する場合です。この例は、次のワークロード固有の前提に基づいています。

• 通話

–展開は、「1:1 冗長性」で展開された Unified CM 中規模 OVA ノードに基づきます。

–最大 2,000 のロケーション、リージョン、およびデバイスプール。

–平均で 3 つの追加エンドポイント間で共有される最大 500 の DN を持つ 10,000 の DN の総数

–ハント パイロットが最大 100 個、ハント リストが最大 100 個、サーキュラーおよびシーケンシャル回線グループが最大 50 個（回線グループあたりのメンバー数は平均 5）、ブロードキャスト回線グループが最大 50 個（回線グループあたりのメンバー数は平均 10）。

–最大 500 個の CTI ポートおよび最大 100 個の CTI ルートポイント。

–1 分あたり最大 500 回の EM ログイン/ログアウトがサポートされています。

• IM & Presence

–Unified CM IM&P ノードは、15,000 ユーザの OVA/VM に導入されます。

–マネージド ファイル転送（MFT）と常設チャットは両方とも、すべての IM＆P ユーザに対して有効です。

• ボイス メッセージング

–Unity Connection ノードは、5,000 人のユーザ OVA/VM に展開されます。

• エッジ

–Expressway-C および Expressway-E ノードは、中規模 OVA テンプレートに展開されます。

• ミーティング

–Cisco Meeting Server（CMS）は、CMS 1000 プラットフォームに展開されます。

–Cisco Meeting Management（CMM）ノードは、小規模 OVA/VM に展開されます。

–TelePresence Management Suite（TMS）ノードは、通常の OVA に展開されます。

（注） 表 1-20 に含まれる一般的な前提条件、上記のメディア #1 の前提条件例、および 図 1-4 に示す VM レイアウトの例は、https://www.cisco.com/go/pa から入手できる 『Enterprise On-Premises PA for CSR 14 Cisco Validated Design（CVD）』ガイドの「サイジング」の章に含まれる簡易サイジングの例と一致しています。

図 1-4 中規模 #1 の導入例に必要なコラボレーションアプリケーション仮想マシンのレイアウト例を示します。

図 1-4 中規模 #1 のサイジングの仮想マシン配置の例

中規模 #2

2 番目の中規模のサイジングの例は、最大 10,000 のユーザまたはデバイスの導入です。このサイジングの例は、次のワークロード固有の前提に基づいています。

• 通話

–展開は、「1:1 冗長性」で展開された Unified CM 中規模 OVA ノードに基づきます。

–最大 2,000 のロケーション、リージョン、およびデバイスプール。

–平均で 3 つの追加エンドポイント間で共有される最大 1,000 の DN を持つ 20,000 の DN の総数。

–ハント パイロットが最大 200 個、ハント リストが最大 200 個、サーキュラーおよびシーケンシャル回線グループが最大 100 個（回線グループあたりのメンバー数は平均 5）、ブロードキャスト回線グループが最大 100 個（回線グループあたりのメンバー数は平均 10）。

–最大 1,000 個の CTI ポートおよび 200 個の CTI ルートポイント。

–1 分あたり最大 750 回の EM ログイン/ログアウトがサポートされています。

–最大 150 の Unified CM Manager をサポートする最大 150 の Unified CM Assistant。

–最大 2 台のアテンダントコンソール サーバと最大 1,000 人の DN を監視する最大 5 人のアテンダント。

• IM & Presence

–Unified CM IM&P ノードは、15,000 ユーザの OVA/VM に展開されます。

–マネージド ファイル転送（MFT）と常設チャットは両方とも、すべての IM&P ユーザに対して有効です。

• ボイス メッセージング

–Unity Connection ノードは、10,000 ユーザの OVA/VM に展開されます。

• エッジ

–Expressway-C および Expressway-E ノードは、中規模 OVA テンプレートに展開されます。

• ミーティング

–Cisco Meeting Server（CMS）は、CMS 1000 プラットフォームに展開されます。

–Cisco Meeting Management（CMM）ノードは、小規模 OVA/VM に展開されます。

–TelePresence Management Suite（TMS）ノードは、大規模 OVA/VM に展開されます。

図 1-5 では、中規模 #2 の導入例に必要なコラボレーションアプリケーション仮想マシンのレイアウト例を示します。

図 1-5 中規模 #2 の簡易サイジングに関する仮想マシンの配置例

大規模

大規模で簡易サイジングの例は、最大 20,000 のユーザまたはデバイスの導入であり、コール、IM and Presence、ボイス メッセージング、エッジ サービス、および会議ワークロードが含まれます。すべてのサイジングは、コラボレーション アプリケーション仮想マシンが Business Edition 7000H（BE7000H）プラットフォームでホストされていることを前提としています。

このサイジングの例は、次のワークロード固有の前提に基づいています。

• 通話

–展開は、「1:1 冗長性」で展開された Unified CM 大規模 OVA ノードに基づきます。

–最大 2,000 のロケーション、リージョン、およびデバイスプール。

–DN の合計数 40,000、最大 3 つの追加エンドポイントで共有される最大 2,000 の DN。

–ハント パイロットが最大 500 個、ハント リストが最大 500 個、サーキュラーおよびシーケンシャル回線グループが最大 250 個（回線グループあたりのメンバー数は平均 5）、ブロードキャスト回線グループが最大 200 個（回線グループあたりのメンバー数は平均 10）。

–最大 2,000 個の CTI ポートおよび最大 500 個の CTI ルートポイント。

–1 分あたり最大 750 回の EM ログイン/ログアウトがサポートされています。

–最大 300 の Unified CM Manager をサポートする最大 300 の Unified CM Assistant。

–最大 4 台のアテンダントコンソール サーバ、最大 10 人のアテンダントが最大 2,000 の DN をモニタ。

• IM & Presence

–Unified CM IM&P ノードは、25,000 ユーザの OVA/VM に展開されます。

–マネージド ファイル転送（MFT）と常設チャットは両方とも、すべての IM&P ユーザに対して有効です。

• ボイス メッセージング

–Unity Connection ノードは、20,000 ユーザの OVA/VM に展開されます。

• エッジ

–Expressway-C および Expressway-E ノードは、中規模 OVA テンプレートに展開されます。

• ミーティング

–Cisco Meeting Server（CMS）は、CMS 2000 プラットフォームに展開されます。

–Cisco Meeting Management（CMM）ノードは、大規模 OVA/VM に展開されます。

–TelePresence Management Suite（TMS）ノードは、大規模 OVA/VM に展開されます。

図 1-6 および 図 1-7 に、大規模な導入例に必要なコラボレーションアプリケーション仮想マシンのレイアウト例を示します。

図 1-6 大規模で簡易サイジングのための仮想マシンの配置例（1/2）

図 1-7 大規模な簡易サイジングのための仮想マシンの配置例（1/2）