Cisco Collaboration 9.xソリューション リファレンス ネットワーク デザイン(SRND)
コラボレーション ソリューションの設計および配置サイジングに関する考慮事項
コラボレーション ソリューションの設計および配置サイジングに関する考慮事項
発行日;2013/10/03 | 英語版ドキュメント(2013/09/09 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 30MB) | フィードバック

目次

コラボレーション ソリューションの設計および配置サイジングに関する考慮事項

この章の新規情報

システム サイジングに関する方法論

パフォーマンス テスト

システム モデリング

メモリ使用量の分析

CPU 使用率の分析

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

定義

音声トラフィック

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

ビデオ トラフィック

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

システム サイジングの考慮事項

ネットワーク設計の要因

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

サイジング ツールの概要

SME サイジング ツールの使用

VXI サイジング ツールの使用

Cisco Unified Communications Sizing Tool の使用

Cisco Unified Communications Manager

サーバとクラスタの最大数

展開オプション

エンドポイント

Cisco Collaboration クライアントおよびアプリケーション

コール トラフィック

ダイヤル プラン

アプリケーションと CTI

メディア リソース

LDAP ディレクトリ統合

Cisco UnifiedCM メガクラスタ配置

Cisco Intercompany Media Engine

緊急サービス

ゲートウェイ

ゲートウェイ グループ

PSTN トラフィック

コンタクト センター トラフィックに対するゲートウェイのサイジング

音声アクティビティ検出(VAD)

コーデック

パフォーマンスの過負荷

パフォーマンスの調整

その他の情報

ボイス メッセージング

コラボレーティブ会議

音声会議のサイジングに関するガイドライン

システム サイジングに影響する要素

ビデオ会議のサイジングに関するガイドライン

UnifiedCM に対する影響

Cisco WebEx Meetings Server

MeetingPlace とのコラボレーティブ会議

Cisco IM and Presence

Cisco Unified Communications Management ツール

Cisco Prime Unified Provisioning Manager

Cisco Prime Unified Operations Manager

Cisco Prime Unified Service Monitor

Cisco Unified Service Statistics Manager

スタンドアロン製品のサイジング

Cisco Unified Communications Manager Express

Cisco Business Edition

Cisco Business Edition の最繁時呼数(BHCA)

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

Cisco Business Edition の Cisco Unified Mobility

コラボレーション ソリューションの設計および配置サイジングに関する考慮事項

この章では、Cisco Collaboration 製品およびシステムのシステム サイジングについて説明します。サイジングは、システムが提供するユーザの数、トラフィックの構成、および機能に基づいてシステムに必要なハードウェア プラットフォームを正確に見積もります。

正確なサイジングは、展開されたシステムがコール量とスループットに関して予期されたサービス品質を満たすために重要です。スタンドアロン製品の場合、システム サイズの手動計算が実行できる場合があります(「スタンドアロン製品のサイジング」の項で詳しく説明)。ただし、複雑なシステム配置では、多くのサイジングの考慮事項があります。たとえば、複数の製品がさまざまな場所に分散しており、ビデオ エンドポイント、コール センター、および音声/ビデオ会議が含まれている場合があります。シスコは、その複雑さを扱うための一連のサイジング ツールを提供します。

この章では、システム サイジングの方法およびサイジングに影響を与える要因に関する概要、およびサイジング ツールの使用方法について説明します。


) この章は、このマニュアルの他の章で説明する製品の説明、および設計と配置についての考慮事項とあわせて読む必要があります。配置を成功させるには、これら両面をよく理解する必要があります。


この章の主な内容は、次のとおりです。

「この章の新規情報」

「システム サイジングに関する方法論」

「システム サイジングの考慮事項」

「サイジング ツールの概要」

「SME サイジング ツールの使用」

「VXI サイジング ツールの使用」

「Cisco Unified Communications Sizing Tool の使用」

「スタンドアロン製品のサイジング」

この章の新規情報

表 27-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。

表 27-1 新規情報、またはこのマニュアルの以前のリリースからの変更情報

新規トピックまたは改訂されたトピック
説明箇所
改訂日

Cisco Jabber クライアント

「Cisco Collaboration クライアントおよびアプリケーション」

2013 年 5 月 24 日

Cisco UC Integration TM for IBM Sametime

「Cisco UC IntegrationTM for IBM Sametime」

2013 年 5 月 24 日

Cisco Unified IP Phone サービス

「IP Phone サービス」

2013 年 5 月 24 日

WebEx Meetings Server

「Cisco WebEx Meetings Server」

2013 年 4 月 2 日

章の全般的な再編成およびその他の更新や修正

この章のすべての項

2013 年 4 月 2 日

コラボレーティブ会議

「コラボレーティブ会議」

2012 年 10 月 31 日

CTI リソース

「アプリケーションと CTI」

2012 年 8 月 31 日

Cisco Unified Mobility のサイジング情報

「Cisco Business Edition の Cisco Unified Mobility」

2012 年 6 月 28 日

Cisco Collaboration クライアントおよびアプリケーションを使用する Unified CM のサイジング情報

「Cisco Collaboration クライアントおよびアプリケーション」

2012 年 6 月 28 日

LDAP ディレクトリ統合についてのサイジング情報

「LDAP ディレクトリ統合」

2012 年 6 月 28 日

Cisco Unified Communications システム Release 9.0 向けの、その他のマイナー アップデート

この章の各項で説明

2012 年 6 月 28 日

システム サイジングに関する方法論

正確なシステム サイジングを実行するため、シスコは、システムが処理する必要がある予期された最大トラフィックを見積もるために、実際のパフォーマンス テストの結果によって提供され、業界標準トラフィック エンジニアリング モデルが組み込まれている方法論に従います。

次の各項では、サイジングの方法論について説明します。

「パフォーマンス テスト」

「システム モデリング」

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

パフォーマンス テスト

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

ほとんどのシステムは、特定の範囲内で線形性を示し、その範囲を超えるとシステムのパフォーマンスが予測不能になります。シスコは、各機能のリソース使用率の線形範囲を識別するため、各パフォーマンス テストに使用レベルを設定します。各テストの結果は、グラフ化できます。必要に応じて、シスコは、グラフの線形セクションを確認するための追加のテスト(中間の負荷レベルで)を実行します。

グラフの線形セクションは、追加された処理の各増分に対するリソースの使用率をモデル化する式で表現できます。R 2 値は、式と測定されたデータ間の寄与率です。R 2 値が 1 に近い場合、式はデータとほぼ一致しています。

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

この特定の試験では、R 2 値はきわめて 1 に近くなっています。式から、電話機がない場合に消費されるメモリは 462,000 KB(Y 切片)で、システムに追加設定される 1 回線の電話機ごとに 8.91 KB 消費されることがわかります。

図 27-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 秒間の平均コール数を定義するために使用できます(この数は 60 で割ることによって求められる毎時コール数に相当します)。

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

最繁時

24 時間の中でトラフィックが最大となる 1 時間。この時間は、組織とトラフィックのタイプによって異なります。ビジネス音声トラフィックの場合、多くの最繁時は朝(たとえば、午前 10 時~午前 11 時)になります。

最繁時呼数(BHCA)

ユーザ BHCA は、ユーザが最繁時にコールを開始または受信する平均数を表します。通常、BHCA は、1 年間の最も忙しい 30 日からの最繁時コール数の平均で計算されます。システム BHCA は、ユーザ BHCA にユーザ数を掛け合わせたものです。

ブロック係数

リソース不足によって最繁時にコールがブロックされる確率で表されるサービス グレードを示します。たとえば、1% のブロック係数は、処理に必要なリソースの不足が原因で 100 コールごとに 1 コールがブロックされる可能性があることを示しています。

平均コール保留時間

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

アーラン

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

リソース(トランク グループなど)によって処理されるアーランの数は、同時コール数と等しくなります。アーラン値は通常、1 時間の期間で平均化されます。

アーラン B モデル

アーラン B モデルにより、指定されたブロック係数でトラフィック ロード(アーラン単位)を処理するために必要なトランク数を判断できます。拡張アーラン B モデルには、再試行(ブロックされたコールのため)のモデルが含まれます。再試行の割合は、拡張アーラン B モデルへの追加入力です。

アーラン C モデル

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

バースト トラフィック

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

音声トラフィック

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

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

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

 

表 27-2 アーラン B トラフィック テーブル(必要な回線の数)

アーラン数
ブロック確率
0.05%
1%
2%
3%
4%
5%

10

19

18

17

16

15

15

20

32

30

28

27

26

26

30

44

42

39

38

37

36

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

アーラン要件が 20 でブロック係数が 1% の場合、システムには 30 回線が必要です。

より大きいブロック係数(5% など)を提供するのではなく、より小さいブロック係数(1% など)を提供する必要がある場合は、回線を追加します。

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

コンタクト センターでは、通常これらのシステムが少数のエージェントまたは自動音声応答(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 SRND』を参照してください。
http://www.cisco.com/en/US/products/sw/custcosw/ps1844/products_implementation_design_guides_list.html


ビデオ トラフィック

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

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

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

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

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

コール到達

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

ピーク

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

通話時間

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

ビデオ会議

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

システム サイジングの考慮事項

大規模で複雑な導入の場合、システム設計者は、システム サイジングに影響する多くの設計と導入の要因を考慮する必要があります。次の項では、これらの要因について説明します。

「ネットワーク設計の要因」

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

ネットワーク設計の要因

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

クラスタ サイズ

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

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

個々の製品間の相互作用

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

サーバ機能

それぞれのタイプのサーバまたはルータは、異なる機能をサポートします。たとえば、一部のサーバ プラットフォームではクラスタリングをサポートしておらず、他のプラットフォームでは必要な冗長性機能をサポートしていない場合があります。

別の例として、Cisco Integrated Service Router(ISR)の各種モデルでは、ホストできるネットワーク モジュールまたは Services Ready Engine(SRE)モジュールの数とタイプに制限があります。

オプションの機能

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

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

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

コール タイプの混合

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

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

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

システム リリース

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

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

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

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

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

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

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

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

サイジング ツールの概要

シスコでは、正確なソリューション サイジングを支援する複数のサイジング ツールを提供しています。サイジング ツールは、次のサイトで入手できます(シスコの従業員および認定パートナーだけがこのサイトにアクセスできます)。

http://tools.cisco.com/cucst

シスコは、サイジング ツールを使用してシステム サイジングを実行することを推奨します。これらのツールでは、パフォーマンス テストに基づくデータ、個々の製品制限とパフォーマンス レーティング、製品リリースにおける拡張機能と新規機能、この SRND の設計上の推奨事項、およびその他の要因が考慮されています。システム設計者によって提供される入力に基づいて、ツールは、サイジング アルゴリズムを提供されたデータに適用して、一連のハードウェア リソースを推奨します。

サイジング ツールにアクセスできない場合は、シスコ アカウント担当者またはシスコ パートナー インテグレータに問い合わせて、システムのサイジング情報を取得してください。

次のツール固有の項には、ツールに必要な入力に関する説明、および最適な入力内容を既存のシステムから収集する方法、また設計段階のシステムに対して見積もる方法が記載されています。言うまでもなく、ツールによって生成されるサイジングの推奨内容は、ユーザが提供する入力データの正確性と同程度の正確性しかありません。

シスコは、次のサイジング ツールを提供しています。

Cisco Unified Communications Sizing Tool

このツールは、システムの導入全体を通してユーザをガイドします。ツールは、次の製品およびコンポーネントに対応しています。

Cisco Unified Communications Manager(Unified CM)

IM and Presence サービス

ボイス メッセージング

会議

ゲートウェイ

Cisco Intercompany Media Engine(IME)

Cisco Unified Communications Management Suite

Cisco Unified Contact Center コンポーネント

Cisco Unified Communications Manager Session Management Edition(SME)Sizing Tool

これは、Unified CM Session Management Edition 配置の特定の機能に重点を置いた専用ツールです。

Cisco VXI Sizing and Configuration Tool

これは、Cisco Virtual Experience Infrastructure(VXI)のサイジング専用ツールです。

これらのツールおよびアクセス権限の詳細については、次の URL で入手可能な『 Unified Communications Sizing Tool Frequently Asked Questions (FAQ) 』を参照してください。

http://tools.cisco.com/cucst/help/ucst_faq.pdf


注意 システム設計のいずれかのパラメータが、前述のサイジング ツールが入力を許容する値の範囲を超える場合、作業を進める前に設計についてシスコのアカウント チームまたはシスコのシステム エンジニア(SE)に相談する必要があります。

SME サイジング ツールの使用

Session Management Edition(SME)は、特定の配置モードで動作する Unified CM です。純粋な SME の配置では、コール トラフィックがトランク インターフェイスでのみ動作し、SME がライン インターフェイスをホストしません。

SME クラスタは、通常の Unified CM クラスタと同じトポロジに従います。パブリッシャ サーバにマスター設定リポジトリが用意されています。クラスタ内の電話機または MGCP ゲートウェイの数が比較的少ない場合、TFTP サーバはパブリッシャ サーバと共存できます。呼処理サブスクライバについては、冗長性の比率を 1:1 にすることを推奨します。

SME クラスタをサイジングするには、期待される機能を考慮する必要があります。基本構成では、SME は、多くのリーフ クラスタのルーティング集約ポイントとして機能します。接続されているすべてのリーフ クラスタに集中型 PSTN アクセスを提供します。高度な構成では、SME は集中型ボイス メッセージング、モビリティ、および会議サービスもホストできます。SME のパフォーマンスは、リーフ クラスタが SME への接続に使用するトランク プロトコルのタイプおよびこれらのトランクの BHCA の影響を受けます。

SME のサイジング ツールには、次の入力パラメータが必要です。

クラスタが処理するトランク インターフェイスの各種タイプ。SME では次のトランク プロトコルがサポートされます。

SIP

H.323

MGCP(Q.931)

SIP(Q.SIG)

H.323 Annex M1

MGCP(Q.SIG)

トランク インターフェイスの各タイプを経由して SME クラスタ サービスにアクセスするユーザの数。

クラスタ間コールのためにリーフ クラスタへの各トランク インターフェイスにアクセスするユーザあたりの BHCA

オフネット(PSTN)コールのためにリーフ クラスタへの各トランク インターフェイスにアクセスするユーザあたりの BHCA

SME クラスタによって PSTN への接続に使用されるトランク インターフェイスのタイプ

コールの平均保留時間

ルートおよびトランスレーション パターンの数

SME がサービス集約ポイントとして機能する場合は、次の追加のサイジング パラメータを考慮する必要があります。

集中型ボイス メッセージングの場合、ボイスメールに送信されるコールの割合

モビリティの場合、ユーザの数およびユーザあたりのリモート接続先の数

会議の場合、会議ダイヤルイン間隔

SME のパフォーマンスは、プロトコルの各ペアの 1 秒あたりのコール数で測定されます。ハードウェア プラットフォームやソフトウェア バージョン間で違いがあります。

VXI サイジング ツールの使用

Cisco Virtualization Experience Infrastructure(VXI)はシステム アプローチの 1 つであり、仮想デスクトップ、音声、およびビデオを統合することで、優れた仮想ワークスペース エクスペリエンスを提供します。Cisco VXI Sizing Tool は、Virtualization Experience Infrastructure ソリューションのサイジング コンポーネントのタスクを支援します。

Cisco Unified Communications Sizing Tool の使用

Cisco Unified Communications Sizing Tool は、多くの製品およびコンポーネントのサイジングに対応しています。ツールによってサポートされているコンポーネントとバージョンの完全なリストについては、サイジング ツールのインストール パッケージに含まれているリリース ノートを参照してください。

次の項では、各製品のサイジングに影響する重要な要因、およびこれらの各製品がシステム配置内の他の製品のサイジングに関する考慮事項に及ぼす影響について説明します。

「Cisco Unified Communications Manager」

「メディア リソース」

「Cisco Unified CM メガクラスタ配置」

「Cisco Intercompany Media Engine」

「緊急サービス」

「ゲートウェイ」

「ボイス メッセージング」

「コラボレーティブ会議」

「Cisco IM and Presence」

「Cisco Unified Communications Management ツール」

Cisco Unified Communications Manager

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

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

「サーバとクラスタの最大数」

「展開オプション」

「エンドポイント」

「Cisco Collaboration クライアントおよびアプリケーション」

「コール トラフィック」

「ダイヤル プラン」

「アプリケーションと CTI」

「メディア リソース」

サーバとクラスタの最大数

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

各クラスタは、最大 40,000 台のセキュアまたは非セキュア SCCP または SIP 電話機の設定および登録をサポートできます。

クラスタ内のエンドポイント数が 1,250 を超えた場合は、専用パブリッシャに加えて 2 つの TFTP サーバが必要です。

CTI 接続のサポートが最新のいくつかのリリースで向上し、各クラスタは最大 40,000 の CTI 接続をサポートできます。

クラスタ内の呼処理サブスクライバの数は、4 つおよびスタンバイ 4 つの合計 8 つの呼処理サーバを超えることはできません。また、パブリッシャ、TFTP、メディア サーバなどのクラスタ内のサーバの合計数が 20 を超えることはできません。

展開オプション

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

データベースの複雑さ

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

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

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

 

表 27-3 リージョン、ロケーション、ゲートウェイ、およびトランクの最大数

サーバ プラットフォーム
リージョンの最大数
ロケーションの最大数
トランクとゲートウェイの最大数

MCS 7816

100

100

110

MCS 7825

1,000

1,000

1,100

MCS 7835 または同等 Open Virtualization Archive(OVA)

1,000

1,000

1,100

MCS 7845 または同等 OVA

2,000

2,000

2,100

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

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

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

ハイ アベイラビリティ

指定した配置に必要なサーバの最小数を特定した後、冗長性を提供するために目的の数の追加のサブスクライバ サーバを追加します。冗長性オプションについては、「コラボレーションの配置モデル」の章を参照してください。一部のサーバ モデルは、他のサーバ モデルに比べて冗長構成に適していることに注意してください。

クラスタあたりのサーバ数

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

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

サーバと UCS プラットフォームの選択

Unified CM は、さまざまな Cisco Media Convergence Server(MCS)および Unified Computing System(UCS)プラットフォームでサポートされています。UCS プラットフォームで Unified CM 仮想マシンを定義するために、ハイパーバイザにロードできる Open Virtualization Archive(OVA)テンプレートが用意されています。指定する機能はテンプレートごとに異なります。たとえば、10000 テンプレートでは、10,000 個のエンドポイントの最大キャパシティを持つ仮想マシンを定義します。また、最大 1,000、2,500、および 7,500 個のエンドポイントをサポートするように定義されたテンプレートもあります。

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

http://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Downloads_(including_OVA/OVF_Templates)


) Unified CM およびその他の Unified Communications 製品を実行する仮想マシンの配置の選択は、パフォーマンスと可用性に影響することがあります。これらの詳細および UCS 配置における Unified Communications のその他の考慮事項については、次の Web サイトのマニュアルを参照してください。
http://www.cisco.com/go/uc-virtualized


エンドポイント

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

デジタル(IP)またはアナログ(アダプタを使用)

ソフトウェアベースまたはハードウェア

サポートされるプロトコル(SIP または SCCP)

エンドポイントでセキュリティが設定されているかどうか

ダイヤル モード(一括またはオーバーラップ)

音声のみ、または音声とビデオ

ゲートウェイなどの他のデバイス(H.323 または MGCP)

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

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

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

 

表 27-4 サーバ プラットフォームまたは OVA テンプレートごとの最大エンドポイント数

サーバ プラットフォームの特性
サーバまたは OVA テンプレートごとの最大エンドポイント数

Cisco MCS 7845-I3 または同等 OVA

10,000

Cisco MCS 7845(その他のサポートされているモデルすべて)または同等 OVA

7,500

Cisco MCS 7835(サポートされているモデルすべて)または同等 OVA

2,500

Cisco MCS 7825(サポートされているモデルすべて)または同等 OVA

1,000

Cisco MCS 7816(すべてのサポート モデル)

500

Cisco Collaboration クライアントおよびアプリケーション

Cisco Collaboration クライアントには、ユーザのデスクトップや他のアクセス デバイスで実行される、次のソフトウェア アプリケーションが含まれます。

「Cisco Jabber クライアント」

「Cisco WebEx Connect」

「Cisco UC IntegrationTM for IBM Sametime」

「Cisco UC IntegrationTM for Microsoft Lync」

「サードパーティ製 XMPP クライアントおよびアプリケーション」

さらに、次のクライアントは仮想デスクトップ アクセスと統合されたテレフォニー クライアントを提供します。

「Cisco Virtualization Experience Client」

Cisco Jabber Desktop Client

Cisco Jabber は、Windows 用と Mac 用の Cisco Jabber クライアントおよび Microsoft Lync 用の Cisco UC Integration TM を含めて、これらのクライアントの基本となるサービス レイヤを提供します。

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

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

Jabber Desktop Client の導入では、さらに次の項目について考慮する必要があります。

デバイス設定

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

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

デスクフォン モード

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

ボイスメール

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

認証

クライアントのログインと認証、コンタクト プロファイル情報、および着信したコールの発信者 ID のすべてが、ローカル Jabber Desktop Client キャッシュに保存されていない限り、LDAP ディレクトリへの照会を通じて処理されます。

連絡先の検索

Jabber Desktop Client で使用できる複数のコンタクト ソースがあります。たとえば、UDS サービスは、クライアントが Unified CM ユーザ データベース内の連絡先を検索するために使用できます。また、LDAP 統合を使用できます。要求された連絡先がローカル Jabber Desktop Client のキャッシュで検出できない場合は、UDS または LDAP 連絡先の検索が実行されます。

Cisco Jabber クライアント

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

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

Cisco IM and Presence サービス ハードウェアの配置が決まれば、クラスタがサポートできるユーザの数が決定されます。Cisco Jabber クライアントの配置は、クラスタ内の全サーバで、全ユーザに均等にする必要があります。これは、User Assignment Mode Sync Agent サービス パラメータを [balanced] に設定すれば、自動的に処理されます。連絡先リストには、連絡先を最大 200 まで設定できます。

IMAP のスケーラビリティ

IMAP または IMAP-Idle の接続数は、メッセージング統合プラットフォームが決定します。特定の設定のサイジングについては、 http://www.cisco.com で入手可能な Cisco Unity Connection の製品マニュアルを参照してください。

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

クライアントは、ネットワークで提供される会議サービスにアクセスできます。これらのサービスの同時参加者の数をサイジングする場合、これらのユーザを考慮する必要があります。詳細については、「Cisco Collaboration サービス」の章を参照してください。

Cisco Jabber Video for TelePresence

このクライアントは、Cisco TelePresence Video Communication Server(Cisco VCS)のサイジングに影響を与えます。Cisco Jabber Video for TelePresence について詳しくは、次の Web サイトで入手可能なマニュアルを参照してください。

http://www.cisco.com/en/US/products/ps11328/tsd_products_support_series_home.html

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

CTI のスケーラビリティ

デスクフォン モードでは、Cisco Jabber クライアントからのコールは Unified CM の CTI インターフェイスを使用します。したがって、「呼処理」の章に明記された CTI の制限を遵守してください。Unified CM クラスタのサイジングを行う際は、これらの CTI デバイスを含める必要があります。

コール アドミッション制御

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

コーデックの選択

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

Cisco Unified MeetingPlace の音声、ビデオ、Web コラボレーション セッション

「Cisco Unified MeetingPlace」を参照してください。

Cisco Unity Connection

このマニュアルの「シスコのボイス メッセージング」の章の「帯域幅の管理」の項を参照してください。

Cisco WebEx Connect

エンド ユーザが Cisco WebEx Messenger サービスにログインして、プレゼンス、インスタント メッセージング、および Voice over IP(VoIP)コーリングなどの基本機能を利用するために必要なものは、56 kbps ダイヤルアップ インターネット接続だけです。ただし、小規模のオフィスやブランチ オフィスでファイル転送やスクリーン キャプチャなどの高度な機能を利用するには、512 kbps 以上のブロードバンド接続が必要です。

ネットワークおよびデスクトップの要件の詳細については、次の URL で入手可能な『Cisco WebEx Administrator's Guide』を参照してください。

http://www.webex.com/webexconnect/orgadmin/help/index.htm

Cisco Unified Communications 統合は、クリックツーコール アプリケーションおよび Cisco Unified Client Services Framework でのデスクフォン制御モードに Unified CM CTI Manager を使用します。したがって、「アプリケーションと CTI」の項に明記された CTI の制限を遵守してください。Cisco UC Integration TM for Connect がソフトフォン(コンピュータ上の音声)モードで動作している場合、Cisco Jabber Desktop Client は Cisco Unified CM に SIP 登録されたエンドポイントです。Cisco Unified Communications を含むソリューションのサイジングを行う際には、Unified CM クラスタ上のリソースを使用する CTI デバイスと SIP エンドポイント デバイスを含める必要があります。

ネットワーク要件

Cisco WebEx Messenger サービスの配置でのネットワーク要件については、次の URL で入手可能です。

http://www.webex.com/webexconnect/orgadmin/help/17161.htm

Cisco UC Integration TM for IBM Sametime

Cisco UC Integration TM for IBM Sametime では、Cisco Unified Communications サービスではなく、IBM のインスタント メッセージングおよびプレゼンス サービスが提供されます。

Cisco UC Integration TM for IBM は、その基盤となる Cisco Unified Communications サービスでのクリックツーダイヤル アプリケーションとデスクフォン制御モードに Unified CM CTI Manager を使用します。したがって、「呼処理」の章に明記された CTI の制限を遵守してください。Cisco UC Integration TM for IBM がソフトフォン(コンピュータ上の音声/ビデオ)モードで動作している場合、クライアントは Cisco Unified CM に SIP 登録されたエンドポイントです。Cisco Unified Communications を含むソリューションのサイジングを行う際には、Unified CM クラスタ上のリソースを使用する CTI デバイスと SIP エンドポイント デバイスを含める必要があります。

Cisco UC Integration TM for Microsoft Lync

Cisco UC Integration TM for Microsoft Lync は、クリックツーダイヤル アプリケーションとデスクフォン制御モードに Unified CM CTI Manager を使用します。したがって、「呼処理」の章に明記された CTI の制限を遵守してください。Cisco UC Integration TM for Microsoft Lync がソフトフォン(コンピュータ上の音声)モードで動作している場合、クライアントは Cisco Unified CM に SIP 登録されたエンドポイントです。Cisco Unified Communications を含むソリューションのサイジングを行う際には、Unified CM クラスタ上のリソースを使用する CTI デバイスと SIP エンドポイント デバイスを含める必要があります。

サードパーティ製 XMPP クライアントおよびアプリケーション

サードパーティ製の Extensible Messaging and Presence Protocol(XMPP)クライアントは、WebEx Messenger サービスのプラットフォームと Cisco IM and Presence サービスの両方で使用される場合があります。これらのクライアントでは、音声、ビデオ、およびその他のコラボレーション機能は(インスタント メッセージングおよびチャットを除く)これらのクライアントでは、通常サポートされません。機能によっては、これらのクライアントが前述のサーバ上でサポートされるデバイス容量にカウントされる場合があります。

Cisco Virtualization Experience Client

すべての Cisco Virtualization Experience Client は、Virtual Desktop Infrastructure(VDI)コンポーネントとともに配置され、一部の配置には Unified Communications コンポーネントも含まれている場合があります。Cisco Virtualization Experience Client を使用する場合の VDI のキャパシティ プランニングとデータセンター リソース使用率は、Virtualization Experience Infrastructure(VXI)のサイジングの一部として説明されます。詳細については、次の URL で入手可能な VXI のマニュアルを参照してください。

http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns1100/landing_vxi.html

Unified Communications コンポーネントのキャパシティ プランニングは、配置されている Virtualization Experience Client によって異なります。

Cisco VXC 2111 および 2112 の統合フォーム ファクタ ゼロ クライアントは、Cisco Unified IP Phone 8961、9951、または 9971 とペアになっています。ユーザの仮想デスクトップで実行される Cisco クライアントは、Cisco Unified IP Phone のデスクフォン制御モードを使用するため、配置されるクライアントごとにコンピュータ テレフォニー インテグレーション(CTI)プランニング ガイドラインに従う必要があります。

Cisco VXC 2211 および 2212 スタンドアロン フォーム ファクタ ゼロ クライアントは、VDI だけとして配置するか、または複数の各種 Cisco Unified IP Phone と完全に統合された音声、ビデオ、および仮想デスクトップとして配置できます。Unified Communications 環境で配置した場合、ユーザの仮想デスクトップで実行される Cisco クライアントは Cisco Unified IP Phone のデスクフォン制御モードを使用するため、配置されるクライアントごとに CTI プランニング ガイドラインに従う必要があります。

Cisco VXC 4000 ソフトウェア アプライアンスは、ソフトウェアだけの VXC 配置オプションです。ユーザの仮想デスクトップで実行される Cisco クライアントは、VXC 4000 のデスクフォン制御モードを使用するため、配置される VXC 4000 ごとに CTI プランニング ガイドラインに従う必要があります。

VDI だけのモードで実行される Cisco VXC 6215 シン クライアントは、VDI キャパシティ プランニングに従いますが、VXC 6215 が完全に統合された音声、ビデオ、および仮想デスクトップとして配置されている場合は、追加の Unified Communications キャパシティを考慮する必要があります。ユーザの仮想デスクトップで実行される Cisco クライアントは、Linux シン クライアント上でローカルに実行される Virtualization Experience Media Engine(VXME)のデスクフォン制御モードを使用するため、配置されるクライアントごとに CTI プランニング ガイドラインに従う必要があります。

VXME は、Cisco Unified CM 上の SIP 回線側登録済みデバイスであるため、完全に統合された音声、ビデオ、および仮想デスクトップとして実行される各 VXC 6215 シン クライアントの場合、SIP 回線デバイスおよび CTI 接続が使用されます。

モバイル ユニファイド コミュニケーション

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

Cisco Unified Mobility

モバイル アクセスとエンタープライズ機能アクセスをサポートするための Unified CM の機能にとって重要な、2 種類のパラメータがあります。これらの機能が適切に動作するには、モビリティを有効にし、シェアド ラインを使用したリモート接続先がユーザ用に定義されている必要があります。 表 27-5 に、各クラスの Unified CM サーバで構成されるクラスタ内のユーザとリモート接続先の制限を示します。

 

表 27-5 クラスタごとのモビリティ ユーザとリモート接続先の最大数

クラスタ サーバ
クラスタごとのモビリティ対応ユーザの最大数
クラスタごとのリモート接続先の最大数

MCS 7845 または同等 OVA

15,000

15,000(またはサーバあたり 3,750)

MCS 7835 または同等 OVA

10,000

10,000(またはサーバあたり 2,500)

MCS 7825 または同等 OVA

4,000

4,000(またはサーバあたり 1,000)


) モビリティ対応ユーザは、リモート接続先プロファイルを持ち、1 つ以上のリモート接続先またはモビリティ ID が設定されているユーザとして定義されます。


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

リモート接続先は、スタティックメモリおよびデータベースのコンフィギュレーション領域を占有します。

各オカレンスでは、ユーザのプライマリ デバイスとのシェアド ラインを使用し、そのためその回線へのコールはより多くの CPU リソースを使用します。

リモート接続先が外線番号(ユーザの携帯電話またはホームなど)である場合、コール拡張にゲートウェイ リソースが使用されます。

コール トラフィック

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

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

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

ユーザあたりの総最繁時呼数(BHCA)

コールあたりの平均コール保留時間(ACHT)

MGCP、H.323、および SIP プロトコルを使用した PSTN との間の BHCA

H.323 クラスタ間トランクまたは SIP プロトコルを使用した他のクラスタとの間の BHCA

Cisco Intercompany Media Engine(IME)を使用した他の企業との間の BHCA

クラスタ内の BHCA

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

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

ダイヤル プラン

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

電話番号

共有電話番号、および同じ DN を共有するエンドポイントの平均数

パーティション、コーリング サーチ スペース、トランスレーション、およびトランスフォーメーション パターン

ルート パターン、ルート リスト、およびルート グループ

アドバタイズされ、学習された DN パターン

ハント パイロットおよびハント リスト

循環、シーケンシャル、およびブロードキャスト回線グループとそのメンバーシップ

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

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

大規模なダイヤル プランのもう 1 つの要素は、ダイヤル プランの要素を Informix データベース システムに格納するために必要な領域です。Unified CM の設定全体を保持するのに利用できるディスク領域の量は固定されているため、特に大規模なダイヤル プランは、その量を超える可能性があります。この場合、ダイヤル プランを分割し、複数のクラスタに格納する必要がある場合があります。

アプリケーションと CTI

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

ハイエンドのサーバ プラットフォームでは登録されているすべてのデバイスで CTI がサポートされていますが、ローエンドのプラットフォームはそれほど拡張性が高くありません。 表 27-6 に、サーバ プラットフォームの各タイプでサポートされている CTI リソースの最大数を示します。これらの最大値は、次のタイプの CTI リソースに適用されます。

CTI で制御またはモニタされ、Unified CM サブスクライバ ノードに登録できるエンドポイントの最大数。

CTI Manager サービスを実行している Unified CM サブスクライバ ノードでモニタまたは制御できるエンドポイントの最大数。

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

ハイエンドの各サーバ クラスの数は、クラスがサポートできるデバイスの数に等しくなります。

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

 

表 27-6 Unified CM における CTI リソースの制限

サーバ プラットフォーム
サーバあたりの最大 CTI リソース

MCS 7815

150

MCS 7816-I2/I3/I4

400

MCS 7816-I5

500

MCS 7825-I1/I2

800

MCS 7825-I3/I4

900

MCS 7825-I5 および同等 OVA

1,000

MCS 7835-I1/I2

2,000

MCS 7835-I3 および同等 OVA

2,500

MCS 7845-I1

2,500

MCS 7845-I2 および同等 OVA

5,000

MCS 7845-I3 および同等 OVA

10,000

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

各制御対象デバイスの回線数(制御対象デバイスあたり最大 5 回線)

CTI によって制御される回線の共有接続数(回線あたり最大 5)

アクティブな CTI アプリケーションの数(デバイスあたり最大 5)

制御対象デバイスあたり最大 6 BHCA

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

表 27-7 に、Cisco Business Edition でサポートされる CTI デバイスの数を示します。

 

表 27-7 Cisco Business Edition におけるユーザおよび CTI デバイス

モデル
最大ユーザ数
最大 CTI デバイス

Business Edition 3000

300

400

Business Edition 6000

1,000

1,200

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

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


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

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

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

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

 

表 27-8 CTI 回線係数

CTI デバイスごとの回線数
CTI 回線係数

1 ~ 5 回線

1.0

6 回線

1.2

7 回線

1.4

8 回線

1.6

9 回線

1.8

10 回線

2.0


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


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

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

 

表 27-9 CTI アプリケーション係数

CTI デバイスごとのアプリケーション数
CTI アプリケーション係数

1 ~ 5 個のアプリケーション

1.0

6 個のアプリケーション

1.2

7 個のアプリケーション

1.4

8 個のアプリケーション

1.6

9 個のアプリケーション

1.8

10 個のアプリケーション

2.0

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

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


 

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

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

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

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

IP Phone サービス

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

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

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

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

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

EM プロファイルを作成するには、ディスク データベース領域とスタティック メモリの両方が必要になります。

ユーザが EM アカウントにログインする頻度は、CPU 使用率とメモリ使用率の両方に影響します。サーバがサポートできる 1 分あたりの最大ログイン数には制限があります。

クラスタ間のエクステンション モビリティ(EMCC)の方がリソースに大きな影響を及ぼします。サーバがサポートできる EMCC ユーザの数には制限があります。サポートされる最大 EMCC ログイン レートは、EM に対してサポートされるレートよりも低くなります。さらに、EM と EMCC のログイン レートにトレードオフがあります。両方が同時に発生した場合、それぞれの最大キャパシティが減ります。

クラスタあたりの EM と EMCC のログイン レートは、共有データベース内のプロファイルにアクセスする必要があるため、各サーバのログイン レートとクラスタ内のサーバ数を単純に掛け合わせたものではありません。複数の呼処理サブスクライバで構成されるクラスタ内の最大ログイン レートは、単一サーバの 1.5 倍に制限する必要があります。

表 27-10 に、サーバ タイプごとの 1 分あたりの EM と EMCC の最大ログイン数を示します。

 

表 27-10 サーバ タイプごとの EM および EMCC レート

サーバ タイプ
最大 EM ログイン レート(サーバあたり)
最大 EM ログイン レート(デュアル サーバ)
最大 EMCC ログイン レート(サーバあたり)
最大 EMCC ログイン レート(デュアル サーバ)
最大同時 EMCC デバイス

MCS 7815、MCS 7816

15

22

5

7

100(MCS 7815)または 167(MCS 7816)

MCS 7825 および同等 OVA

200

300

60

70

333

MCS 7835(I2/H2、I3/H3)および同等 OVA

235

352

71

80

833

MCS 7845 および同等 OVA

250

375

75

90

2,500

Cisco エクステンション モビリティ ログインおよびログアウト機能は、ログイン/ログアウトのクラスタ キャパシティを増加するためにサブスクライバ ノードのペアに分散できます。たとえば、EM 負荷が 2 つの MCS 7845-H2/I2 サーバの間で均等に分散される場合、1 分あたりのクラスタ全体のキャパシティは最大で 375 回の順次ログインまたはログアウト(あるいはその両方)になります。


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



) EM セキュリティの有効化によってパフォーマンスは低下しません。


EMCC ログイン/ログアウト処理は、クラスタ内 EM ログイン/ログアウトよりも多くの処理リソースを必要とします。したがって、サポートされるログイン/ログアウトの最大レートは EMCC では低くなります。クラスタ内 EM ログイン/ログアウトがない場合、Unified CM は、Cisco MCS 7845-H2/I2 および MCS 7845-I3 サーバで 1 分あたり 75 回の EMCC ログイン/ログアウトという最大レートをサポートします。ほとんどの配置では、クラスタ内ログイン/ログアウトとクラスタ間ログイン/ログアウトの組み合わせが発生します。より一般的なこのシナリオでは、EMCC ログイン/ログアウトの混合(ホーム クラスタまたは Visiting クラスタのどちらとして機能する場合でも)は、1 分あたり 40 回のモデルにする必要があります。同時にクラスタ内 EM ログインは、シングル EM ログイン サーバを使用する場合、185 回のログイン/ログアウトのモデルにする必要があります。クラスタ内 EM ログイン レートは、デュアル EM サーバ設定で MCS 7845-H2/I2 または MCS 7845-I3 サーバを使用する場合、1 分あたり 280 回のログイン/ログアウトまで増大できます。( 表 27-10 を参照)。

EMCC ログイン デバイス(Visiting 電話機)は、クラスタ内の他のエンドポイントの 2 倍のリソースを消費します。EMCC ログイン デバイスの最大サポート数はクラスタあたり 2,500 台ですが、これによっても、クラスタあたりの他のデバイスの理論的な最大数は 30,000 から 25,000 に減少します。クラスタ内の他の登録デバイス数を削減しても、EMCC ログイン デバイスの最大サポート数は 2,500 台のままです。

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 制御回線がある場合)。

クラスタあたり最大 3,500 人のアシスタントと 3,500 人のマネージャを、Cisco MCS 7845 サーバを使用して設定できる(合計 7,000 人)。

プライマリおよびバックアップ Unified CM Assistant サーバのペアをクラスタあたり最大 3 組配置できる。ただし、[Enable Multiple Active Mode] アドバンスト サービス パラメータが [True] に設定され、Unified CM Assistant サーバの 2 番めおよび 3 番めのプールが設定されている場合。

Unified CM Assistant 最大でアシスタント 3,500 人とマネージャ 3,500 人(合計 7,000 人)のキャパシティを実現するには、複数の Unified CM Assistant サーバ プールを定義する必要があります。(詳細については、「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 サーバの数を判別するには、この値を最繁時に維持する必要のある平均の Busy Hour Call Attempt(BHCA)1 秒あたりに変換します。

(9,000 call attempts/時間)∗(時間/3,600 秒)= 2.5 cps

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

Attendant Console

Cisco Unified CM と Cisco Unified Department、Unified Business、および Unified Enterprise Attendant Consoles の統合では CTI リソースの使用量が重要になります。これらのアプリケーションは、アテンダントがコールを送信した最後の 2,000 ユーザをモニタするため、CTI リソースの使用率が増えます。さらに、各コールでは、グリーティングやキューイングなどに多数の CTI ルート ポイントとポートが使用されます。

メディア リソース

Unified CM サーバは、Cisco IP Voice Media Streaming Application を提供します。これは、ソフトウェアだけで実行可能で、ハードウェア リソースを必要としない特定のメディア機能を提供します。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)に配置した方が拡張性が向上します。ただし、このアプリケーションの保留音機能は、簡単には外部ソースに配置できません。 表 27-11 に、これらの各サービスに設定できる最大値を示します。

 

表 27-11 Cisco IP Voice Media Streaming Application のキャパシティ制限

サービス
ストリームの最大数

アナンシエータ

400

会議ブリッジ

256

メディア ターミネーション ポイント

512


) 個別の ISR でサポートされている DSP の各メディア機能のキャパシティを計算するには、Cisco ISR の製品データ シートまたは「メディア リソース」の章を参照してください。


保留音(Music on Hold)

表 27-12 は、サーバ プラットフォームと、そのプラットフォームがサポートできる最大同時保留音(MoH)セッション数をリストしています。MoH セッションがこの最大同時セッション数を超えてから、さらに負荷が増えると、MoH 品質の低下、不規則な MoH 動作、または MoH 機能の喪失までも発生するおそれがあるので、実際の使用率が最大同時セッション数を超えないようにしてください。

表 27-12 保留音のキャパシティ制限

サーバ プラットフォーム
サポートされるコーデック
MoH セッションの最大数

MCS 7816
MCS 7825
MCS 7878
および同等 OVA

G.711(A-law および mu-law)
G.729a
ワイドバンド オーディオ

共存サーバまたはスタンドアロンサーバ:

500 MoH セッション

MCS 7835
MCS 7845
および同等 OVA

G.711(A-law および mu-law)
G.729a
ワイドバンド オーディオ

共存サーバまたはスタンドアロンサーバ:

1,000 MoH セッション

Unified CM クラスタでは、保留音の固有ソースを最大 51 個定義できます。各 MoH ソースを最大 4 つのエンコーディングでストリーミングできることを考えると、クラスタ内に最大 204 個のマルチキャスト ストリームを定義できることになります。 表 27-12 に示されている制限は、ユニキャスト、マルチキャスト、またはユニキャストとマルチキャストの同時セッションに適用されます。

Unified CM に対する影響

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

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

LDAP ディレクトリ統合

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

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

Unified CM クラスタの最大ユーザ数は、クラスタのメンバー間で複製される内部コンフィギュレーション データベースの最大サイズによって制限されます。現在、設定または同期可能なユーザの最大数は 80,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 未満のサーバを含めることができます。

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

サポートされるエンドポイントの最大数が通常のクラスタの 2 倍になります(MCS 7845-I3 または同等 OVA を使用する場合、最大 80,000)。

CTI デバイスと接続の最大数も 2 倍になります。

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

コンフィギュレーション データベースのサイズ

ロケーションとリージョンの数


) メガクラスタ配置の周りに存在する多数の潜在的な複雑さが原因で、このような配置の実現を望むお客様は、シスコのアカウント チームまたは認定された Cisco Unified Communications パートナーに関与してもらうことが必要になります。


Cisco Intercompany Media Engine

Cisco Intercompany Media Engine(IME)の実行に使用されるサーバのサイジングは、IME サービスに登録されている電話番号の数にのみ依存します。 表 27-13 に、サポートされている各サーバのキャパシティを示します。

 

表 27-13 IME サーバでサポートしているキャパシティ

サーバ プラットフォーム
登録 DID の最大数

MCS 7825-I2/H2 と 7825-I4/H4

20,000

MCS 7845-I2/H2 と 7845-I3

40,000

すべての IME コール メディア(オーディオおよびビデオ)が IME 対応の Cisco Adaptive Security Appliance(ASA)を経由するため、キャパシティは ASA を経由するコールのタイプおよび数によって異なります。IME 対応の ASA は、音声品質確保のためインターネットから着信したオーディオ ストリームだけをモニタします。ビデオ メディアは音声品質確保の目的でモニタされることはありませんが、RTP と SRTP 間の変換のため IME 対応の ASA を経由します。そのため、ビデオの帯域幅は各 ASA で処理できるセッションの数に直接影響を与えます。 表 27-14 に、ASA-5550 および ASA-5580 のキャパシティ制限を示します。その他の ASA モジュールのパフォーマンス制限は、まだ検証されていません。

 

表 27-14 コール タイプおよび ASA モデルごとの IME コールの最大数

ASA モデル
Voice G.711
Video 300 kbps
Video 800 kbps
Video 1 Mbps

ASA-5500 4 GB

480 コール

240 コール

120 コール

80 コール

ASA-5580-20 4 GB

900 コール

600 コール

300 コール

200 コール

Unified CM に対する IME の影響

Unified CM では、処理できる IME コールの数に制限はありませんが、クラスタが提供するコール キャパシティに対する IME コールの影響を考慮する必要があります。さらに、IME 経由の一部のコールは、コール品質が許容範囲と見なされない場合にゲートウェイを介して通話中に再ルーティングする必要があります。このようにして再ルーティングするコールの予定数は、Unified CM 処理とゲートウェイ経由のコール数の両方について考慮する必要があります。

緊急サービス

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

 

表 27-15 Cisco Emergency Responder のサーバ プラットフォームとキャパシティ

サーバ プラットフォーム
自動的に追跡される電話機の最大数
手動で設定される電話機の最大数
ローミング電話機の最大数
スイッチの最大数
スイッチ ポートの最大数
緊急応答ロケーションの最大数

MCS 7816

6,000

1,000

600

200

12,000

1,000

MCS 7825 および同等 OVA

12,000

2,500

1,200

500

30,000

3,000

MCS 7835 および同等 OVA

20,000

5,000

2,000

1,000

60,000

7,500

MCS 7845 および同等 OVA

30,000

10,000

3,000

2,000

120,000

10,000

Cisco Emergency Responder およびその他の Unified Communication 製品用に正式に定義された OVA テンプレートは、次の Web サイトで入手できます。

http://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Downloads_(including_OVA/OVF_Templates)

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

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

http://www.cisco.com/en/US/products/sw/voicesw/ps842/prod_maintenance_guides_list.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 アクセスが分散される配置モデルでは、ゲートウェイをグループとしてサイジングし、適切な負荷を各グループに割り当てる必要があります。

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

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

共通のグループ プロファイルを共有するゲートウェイのグループ。共通のプロファイルは、配置の複雑さに依存します。

各グループのプロファイルを構成するトラフィック パターン、プラットフォーム、ブロック確率など。

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

PSTN トラフィック

PSTN 回線は、システム内のすべてのユーザによって共有され、通常は PSTN 回線よりも多くのユーザが存在します。必要な回線の数は、コール トラフィックの項で説明されているトラフィック管理の原理を使用して予測されます(「コール トラフィック」)。

必要な PSTN 回線の数は、企業で受信および発信される外部トラフィックの量によって決まります。TDM ベースのシステムから変換する場合、お客様の多くは、IP ベースのコミュニケーション システムにおいても、それまでのシステムで使用していたのと同じ数の回線を使用し続けます。しかし、新たにトラフィック分析を行うことで、現在のトラフィックのレベルに対してシステムのプロビジョニングが過剰である(その結果、不要な回線にコストを費やしている)かどうかを明らかにすることができます。システムのプロビジョニングが不足している場合、許容できない数のコールのブロックや損失が発生します。この場合は回線数を増やすと状況が改善します。

ゲートウェイの DSP 要件は、PSTN 回線の数によって決まります。IP と TDM 音声間の変換を実行するには、DSP リソースが必要です(PSTN 回線は TDM エンコーディングを使用します)。

重要な入力の 1 つにブロック係数があり、ピーク トラフィック レベルで処理できない可能性があるコール試行の比率が決まります。ブロック係数を小さくとると、より多くのコール試行が成功しますが、システムはブロック係数が高い場合よりもより多くの回線を必要とします。

コンタクト センター トラフィックに対するゲートウェイのサイジング

短い通話時間とバースト性のある着呼率は、PSTN ゲートウェイのトラフィック処理能力に影響を与えます。このような状況では、通話時間の長いコールを一定期間にわたって均等に受けるような場合に比べて、すべてのコールをタイムリーに処理するためにゲートウェイでより多くのリソースが必要となります。ゲートウェイにはこのようなトラフィック パターンを処理するさまざまな機能が装備されているため、ゲートウェイを選定する際は使用する環境を考慮して入念に検討する必要があります。ゲートウェイの中には、サポートする T1/E1 ポートの数が多い機種や、同時に着信した複数コールの処理能力が高い機種などがあります。

複数のコールがほぼ同時に着信する(つまり、着呼率が高い、またはバースト性がある)トラフィック パターンでは、適切なコール数/秒(cps)性能を持つゲートウェイが最も適しています。このような状況で、コールの保留時間を 15 秒と仮定した場合、Cisco AS5400XM ユニバーサル ゲートウェイでは 16 cps(一度にアクティブにできるコール数は 250)、Cisco 3845 サービス統合型ルータでは 13 cps(一度にアクティブにできるコール数は 200)、Cisco 3945 サービス統合型ルータでは 28 cps(一度にアクティブにできるコール数は 420)を維持できます。Cisco AS5350XM ユニバーサル ゲートウェイのパフォーマンスは、コール数/秒の観点では AS5400XM と同等です。

着呼率が安定したトラフィック パターンでは、通常、ゲートウェイが処理可能なアクティブ コールの最大数がより重要になります。このような状況で、コールの保留時間を 180 秒と仮定した場合、Cisco AS5400XM ユニバーサル ゲートウェイでは 600 の同時アクティブ コール(着呼率は最大 3.3 cps)、Cisco 3845 サービス統合型ルータでは 450 の同時アクティブ コール(着呼率は最大 2.5 cps)、Cisco 3945 サービス統合型ルータでは 720 の同時アクティブ コール(着呼率は最大 4 cps)を維持できます。

これらの数値は、次の条件がすべて該当する場合を前提とします。

CPU 使用率が 75% を超えない。

PSTN ゲートウェイ コールは、ISDN PRI トランクで H.323 を使用して行われる。

Real Time Control Protocol(RTCP)タイマーがデフォルト値の 5 秒に設定されている。

音声アクティビティ検出(VAD)がオフになっている。

G.711 のパケット化の周期は 20 ms である。

Cisco IOS Release 15.0.1M が使用されている。

専用の音声ゲートウェイ設定を使用し、イーサネット(またはギガビット イーサネット)出力を有効に、QoS 機能を無効にしている。(QoS 対応の出力インターフェイスまたはイーサネット以外の出力インターフェイス、あるいはその両方を使用すると、CPU リソースの消費量が増えます)。

付加コール機能や付加サービス、たとえばセキュリティ全般(アクセス コントロール リストやファイアウォールなど)、音声固有のセキュリティ(TLS、IPSec、SRTP)、AAA ルックアップ、ゲートキーパーを介したコール セットアップ、VoiceXML または TCL によるコール フロー、コール アドミッション制御(RSVP)、SNMP ポーリング/ロギングなどを有効にしていない。このような追加のコール機能を有効にすると、CPU リソースの消費量が増えます。

音声アクティビティ検出(VAD)

音声アクティビティ検出(VAD)は、コールの特定の方向の通話路が無音と認識されている間、IP パケットがほとんど生成されないようにするデジタル信号処理機能です。通常は、ある時点で発話しているのは一方の通話者だけなので、パケットは一方向だけに流れればよく、逆方向(無音方向)では不定期のキープアライブを除き、パケットを送信する必要はありません。そのため、VAD を使用すると、VoIP コールで送信される IP パケットの数が大幅に減少し、それに伴ってゲートウェイ プラットフォームの CPU サイクルも大幅に低下します。VAD によってパケットが実際にどの程度減少するかは、コール フロー、アプリケーション、および会話の状況によって異なりますが、VAD 設定を無効にした場合と比べて、パケットが 10 ~ 30% 少なくなる傾向があります。

VAD は、エンドポイントや Unified CM ネットワークに配置された音声ゲートウェイではほとんどの場合無効にされており、その他の種類のネットワークに配置された音声ゲートウェイでは、ほとんどの場合、有効にされています。

コーデック

G.711 と G.729A のサンプリング時間はどちらもデフォルトで 20 ms に設定されているため、VoIP コールの一方向のパケット レートは 50 パケット/秒(pps)になります。G.711 の IP パケット(200 バイト)は G.729A のパケット(60 バイト)よりも大きいですが、この差が音声ゲートウェイの CPU パフォーマンスに大きな影響を与えるとは実証されていません。G.711 と G.729 のパケットはどちらもルータには「小さい」IP パケットと見なされます。そのため、パケット レートが CPU パフォーマンスに影響を与える重要なコーデック パラメータです。

パフォーマンスの過負荷

Cisco IOS は、割り込みレベルのイベントを処理するために、ピーク処理中にも CPU の使用率が 100% にならないように設計されています。この項に示すパフォーマンスの数値は、約 75% の平均的な負荷を実行しているプロセッサで測定されたものです。特定の Cisco IOS ゲートウェイの負荷がこのしきい値を継続的に超えると、次のようになります。

Cisco Technical Assistance Center(TAC)でその配置がサポートされなくなります。

Cisco IOS ゲートウェイで、Q.921 タイムアウト、ダイヤル後遅延の増大、インターフェイス フラップなどの異常な動作が起こります。

Cisco IOS ゲートウェイは短時間のコールのバーストであれば処理できるようになっていますが、推奨される着呼率(コール数/秒)が継続的に超過するような状況はサポートされていません。


) ゲートウェイに未使用のハードウェア ポートがある場合は、そのポートを他のタスクに割り当てたくなるものです(たとえば、Cisco Communication Media Module(CMM)ゲートウェイで、トラフィック計算によって PSTN トラフィックに一部のポートしか使えないことがわかっている場合など)。しかし、残りのポートは必ず未使用のままにしておく必要があります。そうしないと、CPU がサポートされるレベルを超えて過負荷状態に陥ります。


パフォーマンスの調整

Cisco IOS 音声ゲートウェイの CPU 使用率は、シャーシで有効にされているすべてのプロセスの影響を受けます。最も低レベルのプロセスの一部(IP ルーティングやメモリのデフラグなど)は、シャーシにライブ トラフィックがないときにも実行されます。

CPU 使用率が下がると、リアルタイムの音声パケットやコール セットアップ命令の処理に十分な CPU リソースを使用できるようになり、Cisco IOS 音声ゲートウェイのパフォーマンスが向上します。CPU 使用率を削減する手法のいくつかを 表 27-16 に示します。

 

表 27-16 ゲートウェイの CPU 使用率を削減する手法

手法
CPU 使用率の削減量
説明

Enable Voice Activity Detection (VAD)

最大 20%

VAD を有効にすると、標準的な会話において音声パケットの量が最大 45% 減少します。問題は、音声認識を使用している場合や遅延が長い場合に音声品質が低下する可能性があることです。音声は発話の開始時に突然生じ、終了時に唐突に消失するように感じられます。

RTCP を無効にする

最大 5%

RTCP を無効にすると、発信側と着信側のゲートウェイ間で送信されるアウトオブバンド情報が減少します。その結果、相手側のゲートウェイに表示される統計情報の品質が低下します。また、コールがすでにアクティブでないかどうかを判断するために RTCP パケットが使用されている場合は、着信側ゲートウェイでコールの「未完結状態」が長くなる可能性があります。

その他の重要でない機能(認証、許可、アカウンティング(AAA)、簡易ネットワーク管理プロトコル(SNMP)、ロギングなど)を無効にする

最大 2%

これらのプロセスは、必要でない場合は無効にできます。これらのプロセスを無効にすると、CPU がその分解放されて CPU 使用率が低下し、リアルタイム トラフィックの処理が高速になります。

コール パターンを変更してコールの長さを長くする(これにより、1 秒あたりのコール数を削減する)

可変

これはさまざまな手法で実現できます。たとえば、コールの最初に長い導入プロンプトを再生する(または既存の導入プロンプトを長くする)、コール スクリプトをコール センターで調整する、といった手法があります。

その他の情報

この章では、すべてのゲートウェイ、その機能、および呼処理キャパシティの詳細については説明していません。Cisco 音声ゲートウェイの詳細については、次のマニュアルを参照してください。

Cisco 音声ゲートウェイソリューション:

http://www.cisco.com/en/US/products/sw/voicesw/index.html#~all-prod

Cisco Unified Communications Manager(Unified CM)でサポートされるゲートウェイ プロトコル:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_0_1/ccmsys/a08gw.html

次の Cisco 音声ゲートウェイでサポートされるインターフェイスおよびシグナリング タイプ:

Cisco 3900 シリーズ サービス統合型ルータ

http://www.cisco.com/en/US/products/ps10536/products_relevant_interfaces_and_modules.html

Cisco 2900 シリーズ サービス統合型ルータ

http://www.cisco.com/en/US/products/ps10537/products_relevant_interfaces_and_modules.html

Cisco 3800 シリーズ サービス統合型ルータ

http://www.cisco.com/en/US/products/ps5855/products_relevant_interfaces_and_modules.html

Cisco 2800 シリーズ サービス統合型ルータ

http://www.cisco.com/en/US/products/ps5854/products_relevant_interfaces_and_modules.html

MGCP、SIP、および H.323 でサポートされるゲートウェイ機能:

http://www.cisco.com/en/US/prod/collateral/routers/ps259/product_data_sheet0900aecd8057f2e0.pdf

SIP ゲートウェイ RFC 準拠:

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps6831/product_data_sheet0900aecd804110a2.html

FXS ゲートウェイでサポートされる Skinny Client Control Protocol(SCCP)機能:

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps2250/ps5516/product_data_sheet09186a00801d87f6.html

ゲートウェイの容量、および会議、トランスコーディング、メディア ターミネーション ポイント(MTP)、MGCP、SIP、H.323 ゲートウェイ機能に必要な Cisco IOS および Unified CM の最小リリース:

http://www.cisco.com/en/US/prod/collateral/routers/ps259/product_data_sheet0900aecd8057f2e0.pdf

音声トラフィックに関する計算手法(アーラン計算など):

http://www.erlang.com/calculator/

ボイス メッセージング

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

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

アプリケーションで処理する必要がある最繁時のコール数

サーバに残されるメッセージの平均的な長さ

最繁時にメッセージを確認するユーザの数

ユーザ セッションの平均的な長さ

音声認識や音声合成セッションなどの高度な操作

メディア トランスコーディング

ボイス メッセージング システム上のポートは、ゲートウェイ上の DS0 に似ており、最適化する必要がある共有リソースです。確率的着呼に関する同じ考慮事項とブロックの必要性が両方のリソース タイプに適用されます。

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

 

表 27-17 ボイス メッセージング ソリューションの拡張

ソリューション
単一サーバでサポートされる最大ユーザ数
(フェールオーバー配置またはクラスタ配置)
デジタル ネットワーキング ソリューションの最大ユーザ数
500
15,000
20,000
100,000
250,000

Cisco Unity Express

Y

N

N

Y

Y

Cisco Business Edition

Y

N

N

N

N

Cisco Unity Connection(ユニファイド/統合メッセージング)

Y

Y

Y

Y

N

表 27-18 に、Cisco Unity Connection を実行している各種サーバのさまざまな機能の上限を示します。

 

表 27-18 サーバおよび Cisco Unity Connection のキャパシティ

サーバ プラットフォーム
ポートの最大数
最大音声認識セッション
最大音声合成セッション
ボイスメール ユーザの最大数

MCS 7825

48

48

48

2,000

MCS 7835

150

150

150

4,000

MCS 7845

250

250

250

20,000

5,000 ユーザの OVA テンプレート

100

100

100

5,000

10,000 ユーザの OVA テンプレート

150

150

150

10,000

20,000 ユーザの OVA テンプレート

250

250

250

20,000

Cisco Unity Connection およびその他の Unified Communication 製品用に正式に定義された OVA テンプレートは、次の Web サイトで入手できます。

http://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Downloads_(including_OVA/OVF_Templates)

Unified CM に対する影響

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

ユーザがいないとき、あるいはユーザが Do Not Disturb(DND)または他の機能を使用してコールを故意に転送するときに、ボイス メッセージング システムに転送する必要があるコール。

ボイス メッセージングのパイロット番号をダイヤルしてボイス メッセージにアクセスするユーザからのコール。これらのコールは、Unified CM を通過し、コールの数と期間など、Unified CM が処理するコールに追加する必要があります。

コラボレーティブ会議

Cisco コラボレーティブ会議システムには、呼制御のためのコンポーネントとして Cisco Unified CM が含まれます。このようなシステムのサイジングでは、実行する機能と Unified CM への影響とを考慮に入れる必要があります。

そのような会議システムをサイジングする場合は、一般に次のパラメータを考慮してアプリケーション サーバのタイプと数を決定する必要があります。

システムを一度に使用できるユーザの数

ピーク使用時におけるシステム上の音声、ビデオ、および Web ユーザの数

必要なダイヤルイン期間

ビデオ解像度とオーディオ コーデックの要件

音声会議のサイジングに関するガイドライン

音声会議容量を計算するために次の方法を推奨します。

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

音声会議の平均使用時間(1 ヵ月あたりの平均時間(分))がわかっている場合は、 表 27-19 を使用して音声会議容量を計算します。

 

表 27-19 平均月間使用時間に基づく音声会議容量

平均月間使用時間(分)
ベースライン使用時間(1 ヵ月間のポートあたりの分数)
予想ポート数

20,000 ~ 50,000

1,500

15 ~ 35

50,000 ~ 500,000

2,000

25 ~ 250

500,000 ~ 1,000,000

3,000

165 ~ 335

1,000,000 ~ 2,000,000

3,500

285 ~ 570

2,000,000 ~ 8,000,000

4,000

500 ~ 2,000

ユーザ数に基づく計算

平均的使用率の 20 ユーザごとに 1 ポートを割り当てるように検討する必要があります。会議の頻度が高いユーザの場合は、15 ユーザごとに 1 ポートを用意します。たとえば、6000 ユーザのシステムでは、300 音声ポートを用意する必要があります。ただし、ユーザの会議使用頻度が高い場合は、400 音声ポートを検討します。

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

一般的に、音声会議のピーク時の使用時間は、既存の音声会議システムのログまたはサービス プロバイダーの請求書から得られます。余裕をもった会議容量を確保するために、実際のピーク時使用時間よりも 30% 多い容量を用意することを推奨します。

システム サイジングに影響する要素

システム ベースライン ポートの要件について前述した方法による見積もり以外に、次の要素もシステム サイジングに影響します。

「オペレータ スケジュール」モデルからユーザ スケジュール モデルに移行する場合は、ベースラインに 20 % 上積みしなければならない可能性があります。

デフォルトの平均会議サイズは、会議あたり 4.5 発信者です。デフォルトと異なる場合は、自分のケースに応じた値を使用してください。

次の条件が当てはまる場合は、それに応じてベースライン見積もりを増やします。

(1 日あたりの予想会議数)∗(予想ユーザ数)> ベースラインの 80%

最大規模の会議が予想容量の 20% を超えている場合は、それに応じて見積もりを増やします。

専用ポートを使用して会議を連続して行う場合は、追加のポート((会議数)∗(専任発信者数))をベースラインに加算する必要があります。

総ポート数には、上記要素のすべてとベースラインが含まれます。見積もったポート容量の合計がサポートされる最大ポート数の 80 % を超える場合、会議システムの容量拡張を検討してください。

ビデオ会議のサイジングに関するガイドライン

ビデオ会議容量を計算するために次の 3 つの方法を推奨します。

ナレッジ ワーカの数に基づく計算

40 人のナレッジ ワーカごとに 1 つのビデオ ユーザ ライセンスを用意することを推奨します。

音声会議ユーザ ライセンス数に基づく計算

既存の音声ユーザ ライセンス数の 17 ~ 25% の範囲のビデオ会議容量を用意することを推奨します。この割合は、ビデオ会議に関するビジネス要件と会議システムの規模によって異なります。

既存のビデオ マルチポイント コントロール ユニット(MCU)に基づく計算

既存のビデオ会議システムをそのまま置き換えることを推奨します。

Unified CM に対する影響

Unified CM に対する影響は、会議システムによって生成される追加分のコール トラフィックに基づいて分析できます。最大の影響は、会議ユーザが通常 0 分または 30 分にスケジュールされる会議にダイヤルインしたときに発生します。会議の開始後数分以内に大量のコール トラフィックが発生し、その数分間の Unified CM 上の負荷が増大するため、適切に設計する必要があります。さらに、会議ユーザに PSTN または他のクラスタからの発信者が含まれている場合、それらのパラメータも考慮してゲートウェイに対するその影響を測定する必要があります。

Cisco WebEx Meetings Server

Cisco WebEx Meetings Server は、企業によって提供されたサーバ(企業データセンター内の Cisco UCS サーバ クラスタ)を使用して WebEx 会議サービスを提供します。

Cisco WebEx Meetings Server は、異なる構成で提供されます。この場合、サイジング ツールで、主に会議サービスにアクセスできるナレッジ ワーカーの数に基づいて選択されます。

各構成について、シスコは、ハードウェアと VMware 製品の特定の構成がある標準 Cisco UCS サーバ タイプを推奨しています。ただし、Cisco WebEx Meetings Server は、これらの仕様を満たしているか、またはそれらを上回る、同等またはより優れた Cisco UCS Server で機能するように設計されています。

この製品は、DVD 上のソフトウェア パッケージの集まりではなく、VMware vSphere 対応の OVA 仮想アプライアンスとしてパッケージ化されています。そのため、Cisco WebEx Meeting Server は、OVA を導入し Cisco WebEx Meeting Server 製品をインストールするのに vCenter 製品を必要とします。

現在、Cisco WebEx Meetings Server は、Cisco UCS サーバの共存モードでは動作しません。Cisco WebEx Meetings Server には、専用 UCS サーバが必要です。

Cisco WebEx Meetings Server に関する詳細については、次の Web サイトで入手可能な『 Cisco WebEx Meetings Server System Requirements 』を参照してください。

http://www.cisco.com/en/US/products/ps12732/products_installation_and_configuration_guides_list.html

サイジングの要因

サイジング ツールは、次の入力を使用してシステム容量を計算します。

ナレッジ ユーザの数

ナレッジ ユーザの数は、会議システムにアクセス(会議を開始または会議に参加するため)できる従業員の集合として定義されます。

多くのナレッジ ユーザは、使用可能な会議ポートを共有します。任意の時点で、一部のユーザのみ会議コールでアクティブであることが前提とされています。この割合に基づいて、これらのユーザをサポートするのに必要な会議ポートの数を見積もることができます。

サイジング ツールは、低い使用率(一度に 3.3% のユーザがアクティブ)、平均的な使用率(5% がアクティブ)、および高い使用率(10% がアクティブ)を定義します。そのため、平均的な使用率で動作するシステムは、高い使用率のシステムに比べて 2 倍のユーザをサポートします。

1 ヵ月あたりのユーザ時間(分)

1 ヵ月あたりのユーザ時間(分)は、すべてのポートにおける月のアクティブ会議の合計時間(分)です。この値は、数千分で表されます。この要因は、記録サーバのサイズを計算する際に重要となります。

実際のピーク使用率

実際のピーク使用率は、システムの同時ユーザの最大数として定義されます。この数は、必要な会議ポート数を決定する際に重要となります。シスコは、ピーク使用時に十分な会議ポートが使用可能であることを保証するため、実際のピーク使用率よりも 30% 多くのユーザを処理するのに十分な容量をプロビジョニングすることを推奨しています。

ビデオ

ビデオおよび高画質ビデオでの会議の割合は、システムによって要求されるネットワーク帯域幅に影響を与えます。最大 50% のユーザが高画質ビデオを使用できます。

トラフィックの構成

異なるコール タイプには、異なる Unified CM リソースが必要です。Unified CM の影響を正確に評価するため、ツールは次のコール タイプの評価を要求します。

エンタープライズ IP Phone を介して着信する会議コールの割合。このコール レッグは Unified CM によって処理されるため、Unified CM キャパシティに影響を与えます。

PSTN ゲートウェイのサイジングに影響を与える外部コール レッグの割合。

外部ユーザによるアクセス

外部ユーザがシステムにアクセスする必要がある場合は、追加の仮想マシンを設定してリバース プロキシ機能を提供します。システムが内部ユーザだけを対象としている場合は、これらの追加の仮想マシンは必要ありません。

ディザスタ リカバリ

ディザスタ リカバリでは、セカンダリ データセンターにコールドスタンバイ システムを設定できます。プライマリ システムがハイ アベイラビリティで設定されている場合、ディザスタ リカバリ システムに対してハイ アベイラビリティを設定するように選択することもできます。

ハイ アベイラビリティ

システムは、非冗長モードまたはハイ アベイラビリティ(HA)モードで設定できます。HA モードでは、クラスタは 1 つ以上のバックアップ サーバでプロビジョニングされます(システム サイズに応じて特定の設定)。

システム容量

Cisco WebEx Meetings Server は、 表 27-20 に示すよう、4 つのシステム サイズで提供されます。システム サイズは、システムの同時ユーザの最大数で表されます。最大同時ユーザは、所定の時間に会議コールに参加できるユーザの最大数を定義します。

 

表 27-20 Cisco WebEx Meeting Server のサーバと容量

最大
50 人の同時ユーザ
250 人の同時ユーザ
800 人の同時ユーザ
2,000 人の同時ユーザ

音声と Web ユーザ(組み合わせ)

50

250

800

2,000

高画質ビデオおよびビデオ共有(組み合わせ)

25

125

400

1,000

1 つの会議の参加者

50

100

100

100

終了した会議の記録の再生

13

63

200

500

進行中の会議の記録

5

25

80

200

会議数(会議あたり平均 2 人の参加者)

25

125

400

1,000

コール数/秒

1

3

8

20

次のオプションの機能がシステム容量に影響を与えることなく使用できることに注意してください。

暗号化された音声(sRTP)

セキュアな Web 会議センター(SSL)

異なる音声コーデック

低解像度のビデオ

録音

最大 5% のポート(または 10% の会議)を録音できます。録音された会議を保存するには、十分なサイズの NFS 搭載ハード ドライブをプロビジョニングする必要があります。50 ~ 100 MB のサイズのファイルが 1 つの会議で生成されます。

ネットワーク帯域幅

LAN および WAN で必要な帯域幅を見積もるため、サイジング ツールは次の前提を行います。

各ポートは、1 Mbps のネットワーク帯域幅を使用する。

ユーザの混合は、80% が企業内部であり、20% が外部である。

そのため、LAN の必要な帯域幅(Mbps)は 0.8 * (ポート数)であり、WAN は 0.2 * (ポート数)です。

MeetingPlace とのコラボレーティブ会議

特定の Cisco Unified MeetingPlace ソリューションのキャパシティは、Unified MeetingPlace Meeting Director と Express Media Server(EMS)を使用するアプリケーション サーバがインストールされているプラットフォームによって異なります。たとえば、Cisco MCS 7845-I3(または同等)サーバにインストールされた Unified MeetingPlace アプリケーション サーバでは、音声会議は単一のシステムまたは会議ノードで 1,200 ポート(G.711)になります。ただし、Cisco MCS 7835-I3 にインストールされた Unified MeetingPlace アプリケーション サーバでは、音声会議は同じ設定を持つ 400 ポート(G.711)のみになります。

帯域幅や解像度などのビデオ使用特性は、Express Media Server のサイジングに重要です。

システム サイジングに影響する他の要素

Cisco Unified MeetingPlace の最大キャパシティを維持するには、次の推奨事項を考慮してください。

G.711 以外の音声コーデックが必要な場合、最大容量を達成するには、Cisco Integrated Services Router(ISR)ベースのトランスコーダを使用する。

Unified MeetingPlace のビルトイン Line Echo Cancellation(LEC)ではなく、ISR などの外部デバイスによって提供される LEC を使用する。

Express Media Server

Unified MeetingPlace アプリケーション サーバと共存インストールされるため、Cisco Unified MeetingPlace Express Media Server(EMS)のキャパシティはコーデックとビデオ帯域幅に直接関係します。Unified MeetingPlace アプリケーション サーバが Cisco MCS 7835-H2/I2 サーバ上にインストールされる場合、全体的なシステム キャパシティは EMS 展開と HMS 展開の両方で減少します。標準ベースのビデオと G.729 および G.722 音声コーデックはすべて、EMS システムのキャパシティに影響します。キャパシティの詳細な数字については、次の Web サイトで入手可能な『 Planning Guide for Cisco Unified MeetingPlace 』の最新バージョンを参照してください。

http://www.cisco.com/en/US/products/sw/ps5664/ps5669/products_implementation_design_guides_list.html

EMS では、システム リソース ユニット(SRU)という概念が導入されます。この概念では、システム キャパシティ(つまり、合計 SRU 値)は、Unified MeetingPlace アプリケーション サーバが存在するハードウェア プラットフォームのタイプと、そのシステムのプロセッサの速度および数に基づきます。システムは、通常の動作でこれらの SRU の一部を合計から直接消費し、残りのリソースを SRU プールに置いて、拡張音声/ビデオ機能で使用できるようにします。 表 27-21 に、拡張音声およびビデオで使用できる合計 SRU 数を、サポートされるプラットフォームごとに示します。

 

表 27-21 サポートされる各 EMS プラットフォームの合計システム リソース ユニット

サーバ プラットフォーム
拡張音声およびビデオで使用できる合計システム リソース ユニット(SRU)

MCS 7835-I3

400

MCS 7845-I2/H2

500

MCS 7845-I3

1,200

UCS B200 または C210 シリーズ

1,200(Meeting Director が共存する場合またはしない場合)

UCS C200 シリーズ

500(冗長性のある 2 ノード)

 

表 27-22 さまざまな音声コーデックおよびビデオ帯域幅で消費されるシステム リソース ユニットの数

セッション タイプ
使用される SRU 数

G.711 音声ポート 1 個

1

G.729 または G.722 音声ポート 1 個

6

ビデオ ポート 1 個(320 kbps)1

1

ビデオ ポート 1 個(384 kbps)

1

ビデオ ポート 1 個(768 kbps)

2

ビデオ ポート 1 個(2,000 kbps)

6

1.ビデオ ライセンスに対して保証される最低レートは 320 kbps です。

表 27-21 および 表 27-22 のデータで示したように、G.711 音声コールだけを処理する MCS 7845-I3 サーバでは、EMS は 1,200 音声セッションをサポートします。または、最大 384 kbps で 600 ビデオ セッションを G.711 音声とともにサポートします(ビデオ セッションは音声セッション用にも SRU を消費します)。

Unified CM では、Unified MeetingPlace へのコール送信に使用される SIP トランクのリージョン設定を、EMS に送信されるコールの音声コーデックおよびビデオ帯域幅を制御するために設定できます。Unified MeetingPlace にダイヤルインするエンドポイントの性質と機能を理解することが、正しい設計のために重要です。EMS キャパシティ プランニングの詳細については、次の Web サイトで入手可能な『 Planning Guide for Cisco Unified MeetingPlace 』の最新バージョンを参照してください。

http://www.cisco.com/en/US/products/sw/ps5664/ps5669/products_implementation_design_guides_list.html

Unified MeetingPlace Web サーバ

Unified MeetingPlace Web サーバが必要なるのは、Web ユーザ インターフェイスから会議をスケジュールしたり会議に参加するための Unified MeetingPlace Scheduling の配置、Lotus Notes の統合、または録音ストレージへのアクセスのみです。これらのサーバにキャパシティ プランニングに関する考慮事項はありません。大規模な Unified MeetingPlace 展開にも Cisco MCS 7835 サーバで十分ですが、MCS 7845 サーバを使用することもできます。

Cisco IM and Presence

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

システムを最も基本的なサービスに分解する。

これらの各サービスのユニット コストを求める。

特定のシステム記述を識別されたサービスの集約として分析し、正味システム コストを求める。

システム コストと配置オプションに基づいて必要なサーバの数を決定する。

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

ユーザの数とタイプ

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

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

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

連絡先リストのサイズと構成(クラスタ内、クラスタ間、およびフェデレーション)

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

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

各ユーザの状態変更(コール関連とユーザ開始の両方)

配置モデル

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

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

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

サーバ設定

目的のサーバまたはボイス メッセージング プラットフォームのクラス

システム オプション

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

システム要件を定量化したら、 表 27-23 のデータから必要なサーバの数を特定できます。

 

表 27-23 IM and Presence クラスタごとにサポートされる最大ユーザ数

サーバ プラットフォーム
完全な Unified Communications モードでサポートされる最大ユーザ数
インスタント メッセージ専用モードでサポートされる最大ユーザ数

MCS 7816

3,000

7,500

MCS 7825 および同等 OVA

6,000

6,000

MCS 7835 および同等 OVA

15,000

37,500

MCS 7845 および同等 OVA

45,000

75,000

追加情報については、次の Web サイトで入手可能な、『 Hardware and Software Compatibility Information for IM and Presence Service on Cisco Unified Communications Manager 』の最新版を参照してください。

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

Cisco IM and Presence およびその他の Unified Communication 製品用に正式に定義された OVA テンプレートは、次の Web サイトで入手できます

http://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Downloads_(including_OVA/OVF_Templates)

Unified CM に対する影響

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

AXL/SOAP インターフェイスを介したユーザ同期

SIP トランクを介したプレゼンス情報

電話制御を有効にする CTI トラフィック

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

Cisco Unified Communications Management ツール

Cisco Prime Collaboration は、Cisco Unified Communications と TelePresence システムを試験、展開、およびモニタリングする統合ツール セットを提供します。Cisco Prime Collaboration には、次の製品が含まれます。Cisco Prime Provisioning Manager、Cisco Prime Operations Manager、および Cisco Prime Service Monitor。追加の管理製品である Cisco Unified Service Statistics Manager は、高度な統計分析およびレポート機能を提供します。

これらのアプリケーションのサイジングは比較的単純で、管理するエンドポイントまたはネットワーク デバイスの数に直接依存します。これらのアプリケーションは、個別のハードウェア サーバにホストされたスタンドアロン モード、または単一サーバの共存環境で動作できます。

管理アプリケーションをホストするためのサーバ特性は、一般にハードウェアの仕様に着目して説明されます。つまり、CPU 特性(プロセッサ速度とコアの数)、メモリ、目的のキャパシティ レベルごとのディスク領域などです。

たとえば、共存サーバは、管理アプリケーションの 1 つから 4 つまですべてをホストでき、2 つのコンフィギュレーションのいずれかを使用できます。最大 2,000 エンドポイントを管理するコンフィギュレーションと、最大 10,000 エンドポイントを管理するより大規模なコンフィギュレーションです。このような共存サーバの仕様は次のとおりです。

大規模な共存コンフィギュレーション:

プロセッサ:3 GHz、8 コア

メモリ:16 GB

ディスク領域:320 GB

小規模な共存コンフィギュレーション:

プロセッサ:3 GHz、4 コア

メモリ:8 GB

ディスク領域:100 GB

これらのハードウェア特性は、同等の Cisco MCS または UCS サーバにマッピングできます。

Cisco Prime Unified Provisioning Manager

Cisco Prime Unified Provisioning Manager(Unified PM)は、最大 60,000 台の電話機をサポートでき、単一マシンまたは 2 台のマシンに実装できます。電話機の台数が 30,000 を超える場合は、2 台のマシンに配置することを推奨します。

パフォーマンスの各種レベルで必要なハードウェア リソースについては、次の Web サイトで入手可能な『 Cisco Unified Provisioning Manager Data Sheet 』を参照してください。

http://www.cisco.com/en/US/products/ps7125/products_data_sheets_list.html

Cisco Prime Unified Operations Manager

Cisco Prime Unified Operations Manager(Unified OM)は、電話機およびルータやスイッチなどのネットワーク デバイスを管理できます。Unified Operations Manager は、単一マシン構成で動作します。Unified OM では、最大 45,000 台の電話機と 2,000 台のその他の IP デバイスがサポートされます。

パフォーマンスの各種レベルで必要なハードウェア リソースについては、次の Web サイトで入手可能な『 Cisco Unified Operations Manager Data Sheet 』を参照してください。

http://www.cisco.com/en/US/products/ps6535/products_data_sheets_list.html

Cisco Prime Unified Service Monitor

Cisco Prime Unified Service Monitor(Unified SM)は、Unified SM ソフトウェアを実行するサーバだけでなく、音声品質を測定するための Cisco 1040 Sensor および Network Analysis Module(NAM)でも構成されています。 表 27-24 に、1040 Sensor とさまざまな NAM でサポートされる同時 RTP ストリームの最大数を示します。

表 27-24 1040 Sensor とさまざまな NAM タイプのパフォーマンス

シスコ ネットワーク分析モジュール タイプ
1040 Sensor
NME-NAM
NAM-2
NAM 2204 アプライアンス
NAM 2220 アプライアンス

サポートされる同時 RTP ストリームの最大数

100

100

400

1,500

4,000

パフォーマンスの各種レベルで必要なハードウェア リソースについては、次の Web サイトで入手可能な『 Cisco Unified Service Monitor Data Sheet 』を参照してください。

http://www.cisco.com/en/US/products/ps6536/products_data_sheets_list.html

Unified SM でサポートされている音声品質モニタリング キャパシティは、次のとおりです。

最大 50 台の Cisco 1040 Sensor

最大 45,000 台の IP Phone

1 分あたり最大 5,000 本のセンサーベースの RTP ストリーム(Cisco 1040 Sensor または NAM を使用)

1 分あたり最大 1,600 本の Cisco Voice Transmission Quality(CVTQ)コール

1 分あたり最大 1,500 本の RTP ストリームと 666 本の CVTQ コール

Cisco Unified Service Statistics Manager

Cisco Unified Service Statistics Manager(Unified SSM)は、単一サーバ モードで動作し、最大 45,000 台の電話機を管理するように拡張できます。

パフォーマンスの各種レベルで必要なハードウェア リソースについては、次の Web サイトで入手可能な『 Cisco Unified Service Statistics Manager Data Sheet 』を参照してください。

http://www.cisco.com/en/US/products/ps7285/products_data_sheets_list.html

スタンドアロン製品のサイジング

次の製品はサイジング ツールに含まれていませんが、次の項でこれらの製品をサイジングする方法について説明します。

「Cisco Unified Communications Manager Express」

「Cisco Business Edition」

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 Unified Communications Sizing Tool ではサポートされないため、次の Web サイトで入手可能な Unified CME の製品データ シートに記載されているキャパシティ情報に従う必要があります。

http://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_data_sheets_list.html

Cisco Business Edition

Cisco Business Edition の 3 つのモデル、Business Edition 3000 および 6000 は、ユーザ数、エンドポイント数、および最大コール量で測定される、異なるキャパシティを提供します。 表 27-25 に、モデルの関連するパフォーマンス特性を示します。

 

表 27-25 Cisco Business Edition モデルのキャパシティ

モデル
最大ユーザ数
最大エンドポイント数
最大 BHCA

Business Edition 3000(MCS 7890-C1)

300

400

2,200

Business Edition 6000(UCS C200)

1,000

1,200

5,000

Cisco Business Edition の最繁時呼数(BHCA)

表 27-25 に示すように、Business Edition 3000 では最大 2,200 BHCA、Business Edition 6000 では最大 5,000 BHCA がサポートされます。システム使用の計算では、Cisco Business Edition のオーバーサブスクリプションを回避するために、 表 27-25 に示す BHCA 最大数を超えないようにします。

任意の電話機の BHCA が 4 BHCA を超えたときに、BHCA に対する配慮が必要になります。真の BHCA 値は、最繁時における電話機の使用状況の基準測定を実施することによってのみ、決定されます。この使用状況を基準なしで見積もった場合は特に注意が必要です。

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

デバイスは、この見積もりの目的に沿って 2 つの主なカテゴリーに分けられます。すなわち、電話デバイスとトランク デバイスです。

電話デバイスは、発着信可能な単一のエンドポイントです。これには、Cisco Unified IP Phone 7900 シリーズなどの単体のクライアント デバイス、Cisco IP Communicator などのソフトウェア クライアント、アナログ電話機ポートや H.323 クライアントなどが含まれます。Cisco Business Edition は、 表 27-25 に示すエンドポイントの最大数をサポートしますが、実際のエンドポイント キャパシティは総システム BHCA によって異なります。


) Business Edition 3000 がサポートするエンドポイントのセットには、制限があります。サポートされているエンドポイントのリストについては、次の Web サイトから入手可能な『Administration Guide for Cisco Business Edition 3000』を参照してください。
http://www.cisco.com/en/US/products/ps11370/prod_maintenance_guides_list.html


トランク デバイスは、複数のコールを複数のエンドポイントまで伝送します。これには、SIP トランク、ゲートキーパー制御の H.323 トランク、または Business Edition 3000 の場合は MGCP バックホール PRI トランクなどのトランク デバイスやゲートウェイ デバイスが含まれます。

Business Edition 6000 は、H.323 トランク、SIP トランク、および MGCP トランクやゲートウェイならびにアナログ ゲートウェイのようなクラスタ間トランキングをサポートします。ただし、Business Edition 3000 は、クラスタ間トランキングをサポートしていません。Business Edition 3000 のトランクおよびゲートウェイ サポートは、最大 2 つの E1/T1 PRI による MGCP PSTN 接続用の Cisco 2901 サービス統合型ルータ(ISR)に制限されます。Business Edition 3000 は、アナログ電話機用の Cisco VG224 アナログ音声ゲートウェイもサポートしています。

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

BHCA に基づく使用状況の特性を参照してデバイス グループ(電話デバイスまたはトランク デバイス)を定義してから、各デバイス グループの BHCA を加算して、システムの総 BHCA を求めることができます。これによって、 表 27-25 に示すサポートされる 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 は、 表 27-25 に示すシステムの最大 BHCA を下回っているため、許容範囲に含まれることに注意してください。

Business Edition 6000 でモバイル コネクト(シングル ナンバー リーチ(SNR)とも呼ばれる)用に Cisco Unified Mobility を使用している場合、リモート接続先に転送されたコールまたはオフシステム電話番号が BHCA に影響することに留意してください。アプライアンスがオーバーサブスクライブするのを防ぐには、この SNR リモート接続先またはオフシステム電話の BHCA を考慮する必要があります。これらの SNR 機能の BHCA を計算するには、「Cisco Unified Mobility のキャパシティ プランニング」を参照して、その値を総 BHCA 値に加算します。


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



) Cisco Business Edition 3000 は、メディア認証または暗号化をサポートしていません。


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

Cisco Business Edition の Cisco Unified Mobility

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

ユーザあたり 5 台以上のリモート接続先を設定することはできません。Cisco Business Edition システムあたり最大 1,000 人のユーザがいる場合、リモート接続先の論理的限界は 4,000 台です。ただし、Cisco Business Edition あたりの最大 BHCA が 5,000 であることから、システムで 4,000 台のリモート接続先をサポートできない可能性があります。代わりに BHCA 計算を使用して、システムによって処理可能なリモート接続先数を適切にサイジングする必要があります。

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

リモート接続先の合計 BHCA =

0.5 ∗(ユーザ数)∗(ユーザごとのリモート接続先数)∗(ユーザ BHCA)

次に、例を示します。

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

リモート接続先の合計 BHCA = 0.5 ∗(300 ユーザ)∗(ユーザあたり 1 つのリモート接続先)∗(ユーザあたり 5 BHCA)= 750 BHCA

この例でユーザの合計 BHCA は(300 ユーザ) ∗ (ユーザあたり 5 BHCA)、つまり 1,500 です。この値にリモート接続先の合計 BHCA である 750 を加算すると、システムの合計 BHCA 2,250(ユーザの合計 BHCA 1,500 + リモート接続先の合計 BHCA 750)が求まります。

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

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

Cisco Business Edition 3000

http://www.cisco.com/en/US/products/ps11370/tsd_products_support_series_home.html

Cisco Business Edition 6000

http://docwiki.cisco.com/wiki/Cisco_Unified_Communications_Manager_Business_Edition_6000

http://www.cisco.com/en/US/products/ps11369/tsd_products_support_series_home.html