Cisco Unified Communications システム リリース 9.x SRND
Unified Communications の設計および配置サイジングに関する考慮事項
Unified Communications の設計および配置サイジングに関する考慮事項
発行日;2013/04/24 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 38MB) | フィードバック

目次

Unified Communications の設計および配置サイジングに関する考慮事項

この章の新規情報

サイジングに影響する要素

Cisco Unified Communications Sizing Tool

Unified Communications のサイジングと PBX のサイジングの比較

用語の定義

パフォーマンスのための設計

パフォーマンスの定量分析

コンピュータ システムのパフォーマンス モデル

メモリ使用量の分析

CPU 使用率の分析

音声トラフィック エンジニアリングの基礎

製品別サイジング

Cisco Unified Communications Manager Express

Cisco Business Edition

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

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

Business Edition5000 と Cisco Unified Contact Center

Cisco Business Edition の Cisco Unified Mobility

Cisco Unified Communications Manager

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

展開オプション

エンドポイント

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

コール トラフィック

ダイヤル プラン

アプリケーションと CTI

メディア リソース

LDAP ディレクトリ統合

Cisco UnifiedCM メガクラスタ配置

Cisco Unified CM Session Management Edition

Cisco Intercompany Media Engine

緊急サービス

ゲートウェイ

ゲートウェイ グループ

PSTN トラフィック

一般業務のトラフィック プロファイル

コンタクト センターのトラフィック プロファイル

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

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

コーデック

パフォーマンスの過負荷

パフォーマンスの調整

その他の情報

ボイス メッセージング

コラボレーティブ会議

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

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

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

UnifiedCM に対する影響

特定の会議システムのサイジングのガイドライン

Cisco IM and Presence

Cisco Unified Communications Management Suite

Cisco Prime Unified Provisioning Manager

Cisco Prime Unified Operations Manager

Cisco Prime Unified Service Monitor

Cisco Unified Service Statistics Manager

まとめ

Unified Communications の設計および配置サイジングに関する考慮事項

Unified Communications 製品を正しく配置するには、ハードウェア プラットフォームのタイプと数量を正確に見積もることが前提条件となります。期待するサービス目標を達成するために、適切なコンピューティング リソースとネットワーク リソースを用意する必要があります。

各 Unified Communications 製品は、それが実行される各ハードウェア サーバ プラットフォームにおけるキャパシティ制限を公開しています。これらの公開されている制限は、ハードウェア リソースの必要な量を決定するうえで重要な要素です。ただし、個々の製品は、最良のパフォーマンス数値のみを公開している場合と、一般的な配置の数値を公開している場合があります。これらの数値は両方とも非常に役立ちますが、実際のサイジングには不十分です。たとえば、Cisco Unified Communications Manager(Unified CM)は、Cisco MCS-7845-I3 サーバで構成されるクラスタがサポートできるエンドポイントの最大数を公開しています。この数値は、平均コール レートで、クラスタに他の主要なアクティビティがないことを想定している可能性があります。実際の使用シナリオでは、コール レートは想定よりも高いか、他のサービスをサポートするための要件が存在する可能性があり、電話機の公称の数を超えていない場合でも、1 つのクラスタでは不十分な場合があります。

各製品は単独で使用されることがほとんどないため、他にも複雑なことが生じます。ほとんどの製品は、他の Unified Communications 製品を含むより大きな配置の一部として使用されます。たとえば、Cisco Unity Connection は、Unified CM およびゲートウェイと併用されることがよくあります。より大規模で複雑な配置は、Cisco Contact Center ポートフォリオの製品など(Cisco Unified Contact Center Enterprise、Unified Customer Voice Portal、Unified Intelligence Center など)の複数の Unified Communications 製品で構成されることがあります。これらの製品は、Unified CM、ゲートウェイ、Cisco Unified MeetingPlace、Cisco Unity Connection ボイス メッセージング、およびネットワーク管理アプリケーションと連動する必要があります。これらのコンポーネント間の相互作用を考慮する必要があります。たとえば、Unified CM は、通常の電話機だけでなく、コール量が増加する可能性があるエージェントに割り当てられた電話機も管理することが必要になる場合があります。また、ゲートウェイは、通常のボイス コール以外に、VXML コールの処理も必要になることがあります。サイジングを正確に見積もるには、このような相互作用を考慮する必要があります。

この章では、個々の Unified Communications コンポーネントおよび相互通信する複数のコンポーネントで構成されたシステムのサイジングについて説明します。各種 Unified Communications 製品がサポートするさまざまな機能によるパフォーマンスへの影響、および「データシートによる設計」が複雑な Unified Communications ネットワークを配置するのに適した方法でない理由についても説明します。さらに、利用できるさまざまなサイジング ツール、特に Cisco Unified Communications Sizing Tool の使用方法について詳しく説明します。


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


この章の新規情報

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

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

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

コラボレーティブ会議

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

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 日

サイジングに影響する要素

Unified Communications 製品は、拡張性を備えた設計になっています。特定のサービスのキャパシティは、通常、高キャパシティ サーバへのステップアップまたはサーバ数の追加によって増やすことができます。各製品には、サポートするサーバとその拡張性モデルの一覧があります。サポートするサーバにおけるテスト済みの制限事項の一覧もあります。理論上は、これらの制限事項とモデルに従うだけで、特定の配置に必要なサーバの数がわかります。

ただし、実際には、サイジングはそう単純ではありません。まず、任意の配置に適用される制限事項が複数あります。たとえば、ある Unified CM サーバは、ユーザの登録は 2,500 人、リージョンの定義は最大 500 という制限があります。このようなサーバで構成された Unified CM クラスタは、これらの制限のいずれかを超えた場合、他の値がまだ制限内であっても、サーバの追加が必要になります。さらに、これらの制限の一部は絶対的なものではなく、システムで設定されている他の要素に基づいて動的に変化します。

サイジングにおける他の主な課題は、コンポーネント間の相互作用です。Unified CM は、ほとんどすべての Unified Communications 配置において中心的な役割を果たしており、お客様がどのように他のシステムを選択するかによって影響を受けます。たとえば、会議を可能にするために Cisco Unified MeetingPlace を追加すると、多くのコール セットアップが短期間(会議セッションの最初)に集中する傾向があるため、Unified CM の負荷がその短期間に大きくなります。Unified CM のサイジングではこの点を考慮する必要があります。

サーバのバリエーションも考慮する必要があります。たとえば、Cisco MCS-7815 または MCS-7816 サーバで実行されている Unified CM は、単なるスタンドアロン エンティティであり、クラスタ化することはできません。同様に、Cisco Integrated Service Router(ISR)の各種モデルでは、ホストできるネットワーク モジュールまたは Services Ready Engine(SRE)モジュールの数とタイプに制限があります。

お客様の観点から、サイジングでは、提案された配置で期待されるすべての機能を列挙します。これらのパフォーマンス要素の一部は明確ですが、その他は明確ではありません。たとえば、システムで処理すると予測される最繁時呼数(BHCA)が、期待されるパフォーマンスの重要な要素であることは正しく推測できます。ただし、BHCA にも、コールのタイプなど、考慮しなければならない事項があります。各コール タイプ(同じサーバ内の電話機間のコール、同じクラスタ内の 2 つのサーバ間のコール、2 つのクラスタ間のコール、および PSTN に出入りするコール)によって消費されるリソースには違いがあります。異なるタイプの電話機やゲートウェイからのコールも、プロトコルやビデオなどのサービスによって異なります。サイジングに影響する別の明確な要素の例として、電話機とユーザの期待数があります。この場合も、電話機のタイプ、電話機に設定されている回線の数、電話機がセキュア モードであるかどうかなどが Unified CM のサイジングに影響します。

これらの要素および考えられるバリエーションがあるため、適切なサイジングは複雑で、特に大規模な配置ではよく理解する必要があります。この章では、完全で正確なサイジングのために、厳密に見積もる必要があるリソースを消費する重要な要素およびシステムに対する影響について説明します。

Cisco Unified Communications Sizing Tool

この章を読み終えても、複雑なシステムのサイジングを実行できるようになるとは限りません。むしろ、サイジングの要素のすべてを手作業で計算するのは現実的ではありません。ただし、この章を読むと、システム全体のパフォーマンスに重大な影響を及ぼす要素と、サイジングで考慮する必要がある要素について把握できます。

サイジングを正確に行えるように、シスコは、これらの重大なパフォーマンス要素に基づいて計算を実行するいくつかのツールを提供しています。これらのツールでは、テストに基づくデータ、個々のサーバ パフォーマンス、製品リリースにおける拡張機能と新規機能、この SRND の設計上の推奨事項、およびその他の要素が考慮されています。ツールを使用して具体的な配置情報を入力すると、入力したデータにサイジング アルゴリズムが適用され、一連のハードウェア リソースの推奨事項が提示されます。目標とする配置に対してこの推奨事項が適切かどうかは、入力データの正確さに左右されます。ツールのユーザ ガイドには、入力に関する説明、および最適な入力内容を既存のシステムから収集したり、まだ設計段階のシステムに対して見積もる方法が記載されています。

サイジング ツールは、 http://tools.cisco.com/cucst で入手できます。次のツールがあります。

Cisco Unified Communications Sizing Tool:Cisco Unified CM、ボイス メッセージング、会議、ゲートウェイ、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)のサイジング専用ツール。

サイジング ツールにアクセスできるのは、認定された Cisco ログイン アカウントを持つユーザに限定されます。これらのツールおよびアクセス権限の詳細については、次の URL で入手可能な『 Unified Communications Sizing Tool Frequently Asked Questions (FAQ) 』を参照してください。

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


注意 システム設計のいずれかのパラメータが、前述のサイジング ツールが入力を許容する値の範囲を超える場合、作業を進める前に設計について Cisco Certified Systems Engineer(CCSE)に相談する必要があります。

Unified Communications のサイジングと PBX のサイジングの比較

以前の PBX のサイジングは、大部分は PSTN アクセス トランクに関するものでした。そのため、特定のユーザ ベースに必要なトランク回路の数およびサービスの目的のレベルを決定するためのプロセスについては、十分に実証されています。その目的では、アーラン B、拡張アーラン B、アーラン C などのよく知られたモデルが使用されています。ただし、Unified Communications システムのサイジングは、次の理由により本質的に複雑です。

Unified Communications はモノリシック システムではありません。異なる処理を実行し、相互に通信する複数のサーバで構成されています。

Unified CM は、PBX よりも多くの機能を実行し、多くのサービスを提供します。

用語の定義

この章では次の用語を使用します。

同時コール

システム内ですべてが同時にアクティブになるコールの数。

最大同時コール

システムで一度に処理可能な、アクティブ(通話)状態にある同時コールの最大数。

コール数/秒

着呼率。1 秒間に着信したコールの数(つまり、新しいコール セットアップが試行されたコールの数)として定義されます。着呼率は多くの場合 1 時間あたりのコール数で計算されますが、このメトリックでは 1 時間の最後の 5 秒間に 100 件のコールが着信した場合でも平均着呼率は 100 コール/時間となり(これは通信システムとしては非常に低い数値です)、厳密とは言えません。この例を 1 秒間あたりの着呼率に換算すると、20 コール/秒という高い率になります。20 コール/秒の着呼率が 1 時間持続すると、1 時間あたりのコール数は 72,000 件になります。したがって、コール数/時間は、着信バースト トラフィック パターンを処理するシステムの能力を把握するという目的では有効なメトリックではありません。

最繁時

ユーザが電話機を使用する可能性が最も高い、1 日のうちで最も忙しい時間。この時間は、組織や業界によって異なります。ただし、多くの場合、朝(たとえば、午前 9 時~午前 10 時)または午後(たとえば、午後 2 時~午後 3 時)です。

最繁時呼数(BHCA)

1 日の最も忙しい時間(ピーク時間)に試行されたコールの数。これは 1 日の最も忙しい時間のコール数/秒(cps)と同じですが、1 秒間ではなく 1 時間で表します。たとえば、10 cps は 36,000 コール/時間と同じです。最繁時呼完了数(BHCC)というメトリックもありますが、これは一部のコールが成功しなかった場合(ブロック要因が存在する場合など)、BHCA(試行されたコールの数)より低くなる可能性があります。この章では、呼完了率が 100% である(つまり、BHCA = BHCC)と仮定しています。

ブロック係数

最繁時にブロックされる可能性があるコール試行の最大比率または割合。ブロック係数が 0.0 の場合、回線数が発信者数と等しいことを意味しますが、これはほとんどの配置で非現実的です。

平均保留時間

ボイス コールの「通話時間」。つまり、コールのセットアップから終了までの間の、2 者間に通話路が開いている時間を示します。音声システムのトラフィック エンジニアリングで使用する保留時間の業界平均値は 3 分(180 秒)です。平均コールの保留時間が短くなるほど、コールのセットアップと終了に費やされるシステム CPU 時間の割合が、通話路の維持に費やされる CPU 時間に比べて高くなります。

バースト トラフィック

安定した着呼とは、ある期間にわたってコール試行の間隔がほぼ均等であることを意味します。たとえば、着呼率が安定しているときには、60 コール/時間はほぼ 1 分間に 1 回コール試行があることを示します(約 0.02 cps)。着呼が集中すると、ある一定の期間(1 時間など)に到着するコールの間隔が均等でなくなり、短時間にコールが集中して 1 ~数回のスパイクが生じます。最悪のケースでは、着呼率が同じ 60 コール/時間であっても、1 時間のうちの 1 秒間にすべてのコールが集中します。この場合は、その 1 時間中のほぼすべての時間の着呼率は平均 0 cps になり、1 秒間だけが 60 cps と突出します。この種のトラフィックをバースト トラフィックといい、通信システムに非常に大きな負担をかけます。

アーラン

アーランは、通信トラフィックの測定単位です。1 時間の 1 リソースの使用量を表すために使用されます。1 アーランは、1 つのリソースが 1 時間 100% 使用されたことを意味します。これは、1 時間 1 コール、または期間が合計 1 時間になる複数のシーケンシャル コールによるものです。したがって、10 アーラン必要な場合、すべてのトラフィックを処理するには 10 個のリソースが必要です。

パフォーマンスのための設計

機能要件を分析し、Unified Communications システムに適切な製品を特定したら、次の主要な問題は、可用性、信頼性、応答時間、およびサービス品質で測定される、許容可能なパフォーマンスを適切に提供できるようにネットワークを設計する方法です。リアルタイムのパフォーマンス要件への対応、目的のユーザ数のサポート、および予測可能な将来の高まるニーズに対応するための拡張をシステムで行うことは可能でしょうか。

Unified Communications のネットワーク設計者がこのような質問に答えられるように、シスコは各製品のパフォーマンス特性をテストしています。結果は公開され、特定の数のユーザをサポートするために配置する必要があるクラスタ、サーバ、およびその他のコンポーネントのサイズや数について幅広い推奨事項が示されています。多くの場合、これらのテスト結果は、このマニュアル内の設計上の考慮事項と合わせて、ほとんどの Unified Communications 配置に十分な情報を提供します。ただし、その他の場合、システム設計者は、各製品の動作およびユーザによる製品の使用方法をよく把握してから実行可能なハードウェア セットを選択する必要があります。このようなセットは、対処が必要な次の考慮事項により、複雑になることもあります。

システム リリース

設定の複雑さ

トレース圧縮、コール詳細レコード(CDR)、コール管理レコード(CMR)の生成などのオプションの利用

個々の製品間の相互作用

予想される拡張

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

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

パフォーマンスの定量分析

パフォーマンス テストとは、一連の基本機能が設計どおりに動作するかを検証し、それに基づいて製品を分析するものです。たとえば、Unified CM は多くの機能を実行し、各機能には有限の CPU とメモリが必要です。Unified CM では、エンドポイント登録、ユーザが開始したコール、データベース クエリーなどの多くの機能が処理されます。パフォーマンス テストでは、各基本機能を分離してテストし、ボリュームを増加させながら実行した際に使用されたコンピューティング リソースを測定します。

ハードウェア プラットフォームを考慮したソフトウェア システムのパフォーマンス特性を定量分析するために、システム動作の線形範囲を特定することを目的とした一連のテストが行われます。線形範囲では、リソースの使用率と達成されるスループットが相互に正比例して変化します。この範囲はきわめて重要です。なぜならシステムが線形挙動を示さない場合はパフォーマンスが予測不能になるからです。ほとんどのシステムは、特定の範囲内で線形性を示し、その範囲を超えるとシステムのパフォーマンスが予測不能になります。したがって、システムが線形範囲のパラメータ内で動作するように設計する必要があります。

逆に、システムを配置する際には、要件を基本機能のセットに分解し、公開されているテスト結果と比較して、動作の線形範囲でパフォーマンス ニーズを満たすサーバのセットを特定します。

コンピュータ システムのパフォーマンス モデル

コンピュータ システムの能力を判断する最初の手順は、実行のために呼び出されるさまざまなタスクを挙げることです。たとえば、次のタスクをすべて実行するには、Unified CM が必要になる場合があります。

エンドポイント、電話番号、ダイヤル プランなどの設定済みの値の初期化。

エンドポイント登録の実行。これには、初期登録メッセージの処理、データベースからの設定情報の検索、およびダウンロードするエンドポイントのコンフィギュレーション ファイルの作成が必要です。

定期的な登録メッセージの処理によるエンドポイント登録の維持

新しいコール要求の処理。これは、ユーザ権限付与の確認、ダイヤルされた桁の分析、宛先(別の電話機、ゲートウェイ、またはトランク)の特定、データベースに格納されているルールに基づく正しいシグナリングの組み立て、およびコール シグナリング メッセージの送受信で構成され、かなり複雑なプロセスになる可能性があります。

転送や会議などの通話切替機能の提供。

ユーザの管理および割り込み不可やコール転送などの機能に対する要求。

各機能がコンピューターシステムで実行される際には、CPU、メモリ、およびディスク I/O からなるリソースの何らかが消費されます。

テスト対象のシステムの線形動作範囲は、システムを一連のテストの対象とすることによって決まります。この項では、この範囲を探すための一部のテストについて説明します。このような動作の線形範囲から、動作の増分単位ごとに CPU、メモリ、およびディスク I/O で発生するコストを判断できます。

たとえば、特定タイプの各追加エンドポイントのメモリ使用量は、さまざまなエンドポイントに使用されるメモリの量を示す線の傾斜で判断できます。同様に、エンドポイントの登録ごと、および追加コールごとのメモリ使用量は、同じ手法を使用して定量化できます。

メモリ使用量の分析

システムでは、2 つのタイプ(スタティックおよびダイナミック)のメモリ使用量が識別されます。スタティック メモリは、コール トラフィックがない場合でも使用中のメモリの量と定義されます。このメモリ使用量は、設定データ、エンドポイントの登録、およびその他の要因で発生します。ダイナミック メモリ使用量は、コール アクティビティの結果発生します。各アクティブ コールごとに、コンテキストを保存する必要があり、その結果、アクティブ コール時間分、特定の量のメモリが使用されます。したがって、スタティック メモリはエンドポイントの数に依存しますが、ダイナミック メモリは同時発生コールの数に依存し、それ自体はコール レート(秒あたりのコール数)とコールあたりの平均保留時間(AHT)に依存します。

実際は、オペレーティング システム(OS)と他のプロセスでシステム メモリも必要になるため、動作に利用できる正味メモリ(スタティック メモリとダイナミック メモリ)は、プラットフォームで利用できる合計メモリよりも若干少なくなります。さらに、システムで実行されている他のプロセスやサービスおよび予期しない使用率のスパイクにメモリが必要になります。

図 29-1 に、1 回線の電話機を設定するために必要なメモリを判断するために実行されたテストの結果を示します。Unified CM で単純に 1500、4500、および 7500 IP Phone を設定することで消費されるメモリを示しています。データ ポイントを通る傾向線を引くために、線形回帰法が使用されています。相関係数 R 2 と同様に、この傾向線の公式が決まります。相関係数が 1 または 1 にきわめて近い場合(0.99 以上)、傾向は線形であり、傾向線の公式が有効で制御変数(電話機の数)に基づく従属変数(この場合はメモリ)の予測に使用できます。

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

 

この特定の試験では、R 2 値はきわめて 1 に近く(測定における小さなエラーは考慮されません)、傾向線の公式が有効です。公式から、電話機がない場合に消費されるメモリは 452,394 KB(Y 切片)で、システムに追加設定される 1 回線の電話機ごとに 8.91 KB 消費されることがわかります。

図 29-2 に、6 回線の電話機を設定するために必要なメモリを示します。この図では、R 2 は実際に 1 に等しく、傾向線が有効なモデルであることを示しています。公式から、6 回線の IP Phone を設定するごとに、約 33 KB のメモリが消費されることがわかります。

図 29-2 6 回線の電話機を設定するために必要なメモリ

 

スタティック メモリ(電話機の登録に必要なメモリ)を構成する他のコンポーネントも同じように見積もることができます。図 29-3 に、それぞれ 6 回線を持つ 1500、4500、および 7500 電話機を設定および登録するために必要なメモリをテスト、測定、およびプロットしたグラフを示します。R 2 は 1 に十分近いため、傾向線は有効なモデルです。公式から、6 回線の IP Phone を登録するごとに、約 128 KB のメモリが消費されることがわかります。

図 29-3 6 回線の電話機の設定および登録用のメモリ

 

スタティック メモリには、パーティション、トランスレーション パターン、ルート リスト、グループなどの他の設定項目および CTI や他のアプリケーションに使用されるメモリも含まれます。

ダイナミック メモリと呼ばれるもう 1 つのメモリ タイプは、アクティブ コールに使用されるメモリと定義されています。常に割り当てられたままの状態のスタティック メモリとは異なり、ダイナミック メモリはコール試行のたびに割り当てられ、その割り当てが継続するのはコールが終了するまでのみです。図 29-4 に、Unified CM クラスタの 1 つのサブスクライバ ノードで 180、540、および 900 のアクティブ コールにどのようにメモリが利用されるかを示します。グラフは、傾向線が適切で、アクティブ コールごとに約 294 KB が使用されることを示しています。

図 29-4 アクティブ コールごとのメモリ消費

 

これまでのグラフと分析は、システムにおけるメモリの測定方法を示しています。これらの一連の観察により、データはシステムで行われるさまざまなアクティビティのメモリ モデルの構築を開始できるように補間されている可能性があります。たとえば、次の数値を見積もることができます。

追加回線の設定ごとに必要な増分メモリ

メモリを使い果たしてページングを開始するまでにシステムに存在できるコールの最大数

ダイナミック メモリの使用率の主要な決定要素は、各コールの平均持続期間である平均保留時間(ACHT)です。ACHT が長いほど、常に多数のアクティブ コールが存在することになるため、システムで使用されるメモリは多くなります。

この項では、説明を簡略化しています。Unified CM では、プロトコル、機能、セキュリティ ステータス、およびその他の変数が異なるさまざまな電話機を設定できるため、さらに複雑になります。これらのバリエーションはそれぞれテストおよび分析されています。さらに、これらのバリエーションは、改良や新機能が追加される可能性があるソフトウェア リリースに依存しています。アクティブ コールの測定では、異なる宛先間(2 台の SCCP 電話機間、SIP 電話機と MGCP ゲートウェイ間など)で発信できるさまざまなタイプのコールも考慮されています。

CPU 使用率の分析

CPU 使用率の分析は、メモリの分析に使用される方法に従います。コールが発信または終端されていない場合でも、多少の CPU アクティビティが存在しますが、ほとんどの CPU 利用は、コールのセットアップまたは終了時に発生します。したがって、CPU 使用率の主な決定要因の 1 つはコール レートです。

発信されるコールのタイプには、大きな違いがあります。コールは同じサーバ内で発信または終端するか、2 つのサーバ間で発信されます。また、Unified CM クラスタから発信され、ゲートウェイまたはトランクを通過することもあります。これらの異なるコール アクティビティ タイプはすべて CPU に及ぼす影響が異なるため、慎重に考慮することが重要です。

図 29-5 に、1、3、および 5 コール/秒で測定された CPU 使用率を示します。傾向線は線形であるため、1 秒間に 1 つの着信コールを処理するのに必要な CPU 処理コストは約 1% であると言えます。

図 29-5 コール セットアップあたりの CPU 消費

 

メモリ分析と同様に、CPU 使用率は、考慮する必要がある多くの複雑さを伴っています。たとえば、CPU 使用率の分析では、コールの発信と終端のさまざまなコスト、さまざまなプロトコル、コールをセキュリティで保護するかどうかなどを考慮する必要があります。CPU 使用率は、コンフィギュレーション データベースが複雑であるか比較的単純であるか、CDR や CMR が生成されているかなどにも依存します。

メモリ使用量の増分は実際のサーバ プラットフォームに依存しませんが、CPU 使用率は、テスト対象の実際のハードウェアによって大幅に異なります。したがって、同じテストをサポートされているすべてのサーバに対して繰り返す必要があります。

コール転送、会議、メディア リソース機能(MTP や保留音)などの他の CPU 消費が激しいコール操作も、CPU リソースのサイジング時に考慮する必要があります。

シェアド ラインも CPU リソースを消費します。シェアド ラインは DN を共有する電話機で追加の回線と見なされるだけでなく、シェアド ライン電話機からの各コールまたはこの電話機への各コールは、他のすべての電話機にも反映されます。

音声トラフィック エンジニアリングの基礎

トラフィック エンジニアリングは、主要な使用状況データを考慮してリソースの最適な数を決定する手段です。テレフォニーでは、このユーザ データに最繁時呼数(BHCA)と平均保留時間(AHT)が含まれます。BHCA は、平均的なユーザが 1 日の最も忙しい時間に開始または受信するすべてのコール数です。AHT は、ユーザが開始または受信した各コールについて電話機で費やした時間です。個々の BHCA にユーザ数を乗算すると、システムが処理する必要があるコールのボリュームがわかります。BHCA の合計と AHT がわかったら、システムで処理する必要があるアーラン値を計算できます。1 アーランは、1 時間の通話に相当します。たとえば、システム BHCA が 10 でコールがそれぞれ 3 分間続く場合、システムは合計 30 分間使用されるため、対応するアーラン値は 0.5 です。


) このマニュアルでは、トラフィックがランダム着信パターンの拡張アーラン B モデルに従い、ブロックされた発信者がコールを完了するために複数回試行することを前提としています。業界で使用されている各種アーラン モデルの詳細については、http://www.erlang.com/calculator/ の情報を参照してください。


この分析からは、システムが所定の AHT で処理する必要がある合計 BHCA がわかりますが、分析に必要なもう 1 つの主要情報は、ブロック係数です。すべてのユーザが常に電話に出ることができる十分なキャパシティを持つテレフォニー システムを配置するには、特に大規模なシステムでは非常にコストがかかります。したがって、同時にシステムにアクセスしようとする発信者の数が特定の数を超えると、必要に応じて一部の発信者がブロックされます。システム配置における重要な決定事項は、制限を超えた発信者をコールのピーク時間に何名ブロックするかということです。ブロックの確率を低くする(約 0.01、つまり 1%)ために必要なリソースの量は、ブロック係数を 0.1(つまり 10%)にするために必要な量よりも多くなります。

アーラン値とブロック係数は、システムでプロビジョニングする必要がある共有リソースの量を計算するのに役立ちます。たとえば、これらの情報を使用して、必要なブロック係数と所定のアーラン数の通過トラフィックを持つシステムのゲートウェイで必要な DS0 の数がわかります。これは、通常はアーラン カルキュレータまたはルックアップ テーブルを使用して実行します。必要な DS0 の数は、アーラン数とともに増加し、ブロック確率の増加とともに減少します。

表 29-2 に、回線の数、ブロック確率、および最繁時トラフィックの関係を示します。

 

表 29-2 アーラン C のトラフィックの表(最大提供負荷)

回線数
ブロック確率
0.01%
0.05%
0.1%
0.5%
1.0%
2.0%
5.0%
10.0%

1

0.0001

0.0005

0.0010

0.0050

0.0100

0.0200

0.0500

0.1000

2

0.0142

0.0319

0.0452

0.1025

0.1465

0.2103

0.3422

0.5000

3

0.0860

0.1490

0.1894

0.3339

0.4291

0.5545

0.7876

1.0400

4

0.2310

0.3533

0.4257

0.6641

0.8100

0.9939

1.3190

1.6530

5

0.4428

0.6289

0.7342

1.0650

1.2590

1.4970

1.9050

2.3130

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

システムが処理できるアーラン数は、回線の数およびブロック係数とともに増加します。最初の関係は明確ですが、2 つめは、より多くのコールがブロックされることに気付くと理解できます。

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

5 回線でブロック係数が 1% とすると、1.259 アーランを利用できます。したがって、10 ユーザいる場合、各ユーザは最繁時に (1.259∗3600/10) = 453.24 秒間通話できます。


) 特に Cisco Unified Contact Center 配置では、同じ原理に従ってサイジングする必要がある他のリソースが存在する場合があります。たとえば、音声自動応答装置(IVR)のポートとエージェントの数の要件は、同様の定量分析を使用してモデル化されています。ここで平均保留時間と BHCA 以外に考慮する必要があるのは、キューでの待機時間およびその他の係数です。つまり、必要な DS0 回線の数が多くなります。詳細については、次の URL で入手可能な『Cisco Unified Contact Center Enterprise SRND』を参照してください。
http://www.cisco.com/en/US/products/sw/custcosw/ps1844/products_implementation_design_guides_list.html


製品別サイジング

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

「Cisco Unified Communications Manager Express」

「Cisco Business Edition」

「Cisco Unified Communications Manager」

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

「Cisco Unified CM Session Management Edition」

「Cisco Intercompany Media Engine」

「緊急サービス」

「メディア リソース」

「ゲートウェイ」

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

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

「Cisco IM and Presence」

「Cisco Unified Communications Management Suite」

Cisco Unified Communications Manager Express

Cisco Unified Communications Manager Express(Unified CME)は、Cisco IOS サービス統合型ルータ(ISR)プラットフォーム(ローエンドの Cisco 1861 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、5000、および 6000 は、ユーザ数、エンドポイント数、および最大コール量で測定される、異なるキャパシティを提供します。 表 29-3 に、3 つのモデルの関連するパフォーマンス特性を示します。

 

表 29-3 Cisco Business Edition モデルのキャパシティ

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

Business Edition 3000(MCS 7816)

300

400

2,200

Business Edition 5000(MCS 7828)

500

575

3,600

Business Edition 6000(UCS C200)

1,000

1,200

5,000

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

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

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

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

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

電話デバイスは、単一のコール可能なエンドポイントです。これには、Cisco Unified IP Phone 7900 シリーズなどの単体のクライアント デバイス、Cisco IP Communicator などのソフトウェア クライアント、アナログ電話機ポートや H.323 クライアントなどが含まれます。Cisco Business Edition は、 表 29-3 に示すエンドポイントの最大数をサポートしますが、実際のエンドポイント キャパシティは総システム 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 5000 および 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 Analog Voice Gateway もサポートしています。

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

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

Business Edition 5000 または 6000 上で、モバイル コネクト(シングル ナンバー リーチまたは SNR とも呼ばれる)用に Cisco Unified Mobility を使用している場合、あるいは、リーチ ミー エニウェア機能(SNR とも呼ばれる)を使用している場合、リモート接続先に転送されたコールまたはオフシステム電話番号が 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 以下に制限する必要があります。

Business Edition 5000 と Cisco Unified Contact Center

この例では、Cisco Unified Contact Center Express(Unified CCX)が Business Edition 5000 と統合され、次のようなシステム特性があるものとします。

必要な仕様は、最繁時に 1 時間あたり最大 30 コールの 15 人のコンタクト センター エージェントに関するものです。

4 BHCA の平均使用非エージェント ユーザが 96 人いて、各ユーザは Cisco Unified Mobility を使用してシングル ナンバー リーチ用の 1 つのリモート接続先を設定できます。

また、10 BHCA の大量使用非エージェント ユーザが 36 人いて、各ユーザはシングル ナンバー リーチ用の 1 つのリモート接続先を設定できます。

20 本のスタンバイ シェアド ラインがあり、そのうちの 10 本は平均使用プールの 10 ユーザで共有され、残りの 10 本は大量使用プールの 10 ユーザで共有されます。

全トランクの合計が 1200 BHCA の 7 個の T1 トランク(最大 161 の同時コールが可能)があります。


) Cisco Business Edition 5000 は、Cisco Unified Contact Center Enterprise ではサポートされていません。



) この例では、すべてのゲートウェイ トランクに関する BHCA を 1 つの総トランク BHCA 値にまとめます。この方法は主として、単一サイト配置に適しています。ただし、マルチサイト配置では、さまざまなサイトのトランクによってさまざまな BHCA 要件が設定されるため、複数の BHCA グループ分けが必要になります。


このシステムの BHCA 計算は次のようになります。

30 BHCA の 15 人のコンタクト センター エージェント = 450 BHCA

4 BHCA の 96 人の平均使用ユーザ = 384 BHCA

10 BHCA の 36 人の大量使用ユーザ = 360 BHCA

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

10 BHCA グループ内の 10 本のシェアド ライン = 50 BHCA

すべての T1 トランクの総 BHCA = 1,200 BHCA

4 BHCA の 96 人の平均使用ユーザごとの、シングル ナンバー リーチ用の 1 つのリモート接続先 = 192 BHCA (この計算の詳細については、「Cisco Business Edition の Cisco Unified Mobility」を参照してください)。

10 BHCA の 36 人の大量使用ユーザごとの、シングル ナンバー リーチ用の 1 つのリモート接続先 = 180 BHCA (この計算の詳細については、「Cisco Business Edition の Cisco Unified Mobility」を参照してください)。

この場合のすべてのエンドポイント デバイスの総 BHCA は次のとおりです。

(450 + 384 + 360 + 20 + 50 + 192 + 180 + 1200) = 2,836 BHCA

このレベルの使用状況は、システム上限の 3,600 BHCA を下回っているため、許容範囲であり、約 800 BHCA の余裕があります。

このサイジングの例は、Business Edition 5000 だけに適用されます。Business Edition 3000 では、Unified Contact Center 配置へのトランキングはできません。Business Edition 6000 は Unified Contact Center Express 共存で動作します。サイジングに関する考慮事項は同様ですが、この例は特に Business Edition 5000 に関連しています。

Cisco Business Edition の Cisco Unified Mobility

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

ユーザあたり 5 台以上のリモート接続先を設定することはできません。Cisco Business Edition システムあたり最大 500 人のユーザがいる場合、リモート接続先の論理的限界は 2,000 台です。ただし、Cisco Business Edition あたりの最大 BHCA が 3,600 である場合は、システムで 2,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 5000

http://www.cisco.com/en/US/products/ps7273/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

Cisco Unified Communications Manager

Cisco Unified Communications Manager(Unified CM)は、Unified Communications 配置のハブです。最も基本的な機能を実行し、エンドポイントの制御、コールのルーティング、ポリシーの適用、およびアプリケーションのホストを行います。また、一般に、ゲートウェイ、Cisco Unity Connection、Cisco Unified MeetingPlace、Cisco Unified Contact Center 製品スイートなどの他の Unified Communications 製品をアンカーします。これらのアプリケーションは、Unified CM に依存して機能し、Unified CM のパフォーマンスに影響するため、Unified CM のサイジングで考慮する必要があります。

次の要素が Unified CM のパフォーマンスに影響するため、Unified CM の配置をサイジングするときに考慮する必要があります。

サーバとクラスタの最大キャパシティ

データベースの複雑さ、トレース レベルなどのシステムレベルの設定

Unified CM に登録されているエンドポイントの数とタイプ

ユーザ数

トラフィックの構成

ダイヤル プラン

Unified CM 内のアプリケーション(Extension Mobility、WebDialer、およびその他の CTI 対応のアプリケーション)

Cisco IP Voice Media Streaming Application を使用してサブスクライバがホストするメディア リソース

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

特定のサイジング計算に必要な Unified CM サーバの数を正確に判断するために、必要な詳細を常にリストするのは現実的ではありませんが、観察する必要がある特定のサーバとクラスタの最大数があり、これらの値の一部は Unified CM のソフトウェア バージョンによって変わります。

各クラスタは、最大 40,000 台のセキュアまたは非セキュア SCCP または SIP 電話機(Unified CM 8.6(1) 以降のリリースを使用)の設定および登録をサポートできます。

各クラスタは、最大 30,000 台のセキュアまたは非セキュア SCCP または SIP 電話機(Unified CM 8.5 以前のリリースを使用)の設定および登録をサポートできます。

クラスタ内のエンドポイントの数が 1,250 を超える場合は、2 つの TFTP サーバが必要です。

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

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

次の項では、Unified CM のこれらの各コンポーネントがサイジングにどのように影響するかについて説明し、そのためコンポーネントを特定のシステム記述の分析で考慮する必要があることを示します。

展開オプション

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

トレース レベル

2 つのトレース レベル(デフォルトと詳細)がサポートされています。Unified CM 9.0 以降のリリースでは、詳細なトレースがデフォルトでイネーブルになっていますが、CPU リソースへの実質的な影響はありません。以前のリリースの詳細なトレースは、デフォルトのトレース オプションに比べ、約 20 % 多くの CPU リソースを必要としていました。

データベースの複雑さ

実際には、Unified CM の設定情報のデータベースを単純と見なすか、複雑と見なすかを決定する基準はありません。一般に、数千を超えるエンドポイントと数百を超えるダイヤル プラン要素(トランスレーションおよびルート パターン、ハント パイロット、シェアド ラインなど)がある場合、生成されるデータベースは複雑と見なす必要があります。基本となるデータベースが複雑な場合、CPU 使用率はかなり高くなります。

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

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

トレース圧縮

Cisco Unified CM 8.0 以降、トレースは常に圧縮され、圧縮をオンまたはオフにできなくなりました。それよりも前のリリースでは、圧縮をオンにすると、ディスク領域を節約できますが、CPU 使用率が高くなります。

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

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

 

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

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

MCS-7815 および 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% を超えないようにします。

ハイ アベイラビリティ

冗長サーバを配置すると、ソリューションで必要になるサーバの合計数が増えます。指定した配置に必要なサーバの最小数がわかったら、目的の数のサブスクライバ サーバを追加します。冗長性オプションについては、「Unified Communications の配置モデル」の章を参照してください。一部のサーバは冗長性にあまり役立ちません。

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

クラスタは、1 ~ 4 つのサブスクライバ ペアで構成されるように設定できます。クラスタあたりのサブスクライバ ペアの数を減らすと、クラスタの数が増える可能性があるため、特定のサイジング分析に必要なサーバの合計数も増えます。配置が地理的に均等に分散された大規模なロケーションで構成される場合、または、なんらかのクラスタ全体の制限によって、サーバあたりの使用率が低い場合であっても、クラスタ数を増やすことが望ましいことがあります。

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

Unified CM は、さまざまな Cisco Media Convergence Server(MCS)および Unified Computing System(UCS)プラットフォームでサポートされています。UCS プラットフォームで Unified CM 仮想マシンを定義するために、ハイパーバイザにロードできる Open Virtualization Archive(OVA)テンプレートが用意されています。指定する機能はテンプレートごとに異なります。たとえば、10000 テンプレートでは、4 つの仮想 CPU、6 GB の RAM、および 160 GB のハード ディスク領域を搭載し、10,000 個のエンドポイントまで対応できる最大キャパシティを持つ仮想マシンを定義します。1000、2500、および 7500 個のエンドポイント用に定義された同様のテンプレートもあります。

Unified CM およびその他の Unified Communication 製品用に正式に定義された 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 の内部で実行されるサービスと対話するアプリケーションを実行することによって、Unified CM に負荷をかけます。

表 29-5 に示すように、エンドポイントの最大サポート数がサーバ機種ごとに定義されています。これらの値は単なるガイドラインであり、他のアプリケーションが配置で実行されている場合は、これらの最大数がサポートされないことがあります。

 

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

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

Cisco MCS 7845-I3 または同等 OVA

10,000

Yes

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

7,500

Yes

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

2,500

Yes

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

1,000

No

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

500

No

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

300

No

表 29-5 のハイ アベイラビリティの欄は、そのサーバで構成されたクラスタ内でハイ アベイラビリティのためにサーバがペアになっているかどうかを示します。

一部のエンドポイントは、2 つのモードのいずれかで動作できます。Cisco Unified Personal Communicator などのエンドポイントおよび Cisco WebEx Connect、Cisco UC Integration TM for Microsoft Lync などの Common Services Framework(CSF)をベースにしたエンドポイントは、Unified CM に電話機として直接登録されているソフトフォンとして動作するか、またはデスクフォンを制御するために CTI を使用して Unified CM と通信するアプリケーションとして機能するデスクフォン制御モードで動作します。いずれの場合も、エンドポイントは Unified CM リソース(エンドポイントまたは CTI アプリケーション)を使用しますが、動作上の制限に対して異なる影響を与えます。

エンドポイントともに、最繁時のユーザ数も考慮する必要があります。ユーザ数とエンドポイントの総合的な使用状況によって、システムにかかる呼処理の負荷が決まります。

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

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

「Cisco Unified Personal Communicator」

「Cisco WebEx Connect」

「Cisco UC IntegrationTM for Microsoft Lync」

「Cisco Unified Mobile Communicator」

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

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

「Cisco Virtualization Experience Client」

Cisco Unified Client Services Framework

Cisco Unified Client Services Framework は、Cisco Unified Personal Communicator、Cisco WebEx Connect、および Cisco UC Integration for Microsoft Lync を含め、これらのクライアントの基本となるサービス レイヤを提供します。フレームワークは 1 つまたは 2 つのモードで動作し、それぞれ Unified CM で異なるリソースを使用します。Client Services Framework は、ソフト フォンとして動作するよう設定される場合があります。このモードでは、SIP 登録されたエンドポイントとして機能し、システム内のエンドポイントの総数としてカウントされます。Client Services Framework は、ユーザのデスクトップフォンの制御用に設定することもでき、この場合は CTI リソースを使用します。また、ユーザはどちらかのモードで動作するようこれらのフレームワーク ベースのクライアントを切り替える場合もあります。したがって、予想される使用方法に必要なシステム リソースを正しく把握する必要があります。

Client Services Framework の配置では、さらに次の項目について考慮する必要があります。

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

CTI:デスクフォン(音声にデスクフォンを使用)で設定した場合は、IP 電話の制御を可能にするために、ログインと登録の際に Client Services Framework が Unified CM への CTI 接続を確立します。

CCMCIP:Client Services Framework は、制御に使用できる IP 電話をリストするために、Unified CM IP Phone サービスを使用して、ユーザに関連付けられているデバイスに関する情報を収集します。

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

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

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

Cisco Unified Personal Communicator

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

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

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

IMAP のスケーラビリティ

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

Web 会議

Cisco Unified MeetingPlace Web ライセンシングは、同時に可能な Web 会議参加者の数を決定します。特定の設定のサイジングについては、 http://www.cisco.com で入手可能な Cisco Unified MeetingPlace の製品マニュアルを参照してください。

ビデオのサイジングとキャパシティ

ビデオ会議とスイッチングは、Cisco Unified Videoconferencing MCU のサイジングと設定、Cisco MeetingPlace Hardware Media Server(HMS)のサイジングと設定、または Cisco Unified MeetingPlace Express VT によって同時音声、ビデオ、および Web 参加者のために決定されます。特定の設定のサイジングについては、 http://www.cisco.com で入手可能な Cisco Unified MeetingPlace Express VT の製品マニュアルを参照してください。

Cisco Unified Personal Communicator は Unified CM と相互接続します。そのため、Cisco Unified Personal Communicator 音声またはビデオ コールを開始した場合、Unified CM の現在の機能に関する次のガイドラインが適用されます。

CTI のスケーラビリティ

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

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

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

コーデックの選択

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

Cisco Unified Personal Communicator のすべての設定と連絡先は、Cisco IM and Presence データベースに保存されます。これらには、大量のデータが含まれる可能性があります。現在の会話履歴リストは、各タブ([Chats]、[Voice Messages]、[Calls])で 50 エントリに制限されており、連絡先リストのサイズは 200 個の連絡先に制限されています。したがって、プレゼンス データの交換と、会議、ビデオ、およびメッセージングのトラフィックに対して帯域幅の使用率を考慮する必要があります。

Cisco Unified Personal Communicator には、帯域幅に関する次の考慮事項も適用されます。

プレゼンス ユーザ プロファイル(PUP)は、ログイン、プレゼンス ステータスの変更、および参加者の変更の数を考慮してユーザ配置トラフィック パターンを調べます。ログイン数が 1 時間あたり 0.5、プレゼンス ステータスの変更数が 1 時間あたり 0.5、参加者の変更数が 1 時間あたり 0.25 の一般的な PUP では、Cisco Unified Personal Communicator と Cisco IM and Presence 間の帯域幅使用率(1 秒あたりのキロビット数)を計算する場合の一般的なガイドラインとして次の式を使用できます(例については、 表 29-6 を参照)。

USERS ∗ [30 + ROSTER∗7 + IM∗3 + CALLS ∗ (33 + 3∗ROSTER)] / 1000

引数の説明

USERS = Unified Personal Communicator を使用しているユーザ数。

ROSTER = Unified Personal Communicator ユーザの平均参加者サイズ。

IM = Unified Personal Communicator ユーザの 1 時間あたりのインスタント メッセージ数。

CALLS = 1 時間あたりのソフトフォン コール数。

 

表 29-6 Unified Personal Communicator の帯域幅要件の例

企業
ユーザ数
参加者サイズ
IM 数
1 時間あたりのコール数
帯域幅使用率

1,000

100

25

4

2,100 kbps(2.1 Mbps)

5,000

200

25

4

20,185 kbps(20.2 Mbps)

Cisco Unified MeetingPlace の音声、ビデオ、Web コラボレーション セッションについては、「Cisco Unified MeetingPlace」を参照してください。

ビデオ コールについては、「IP ビデオ テレフォニー」の章を参照してください。

Cisco Unity または Unity Connection については、「シスコのボイス メッセージング」の章の「帯域幅の管理」の項を参照してください。

Cisco WebEx Connect

エンド ユーザが Cisco WebEx Messenger サービス(以前の WebEx Connect サービス)にログインして、プレゼンス、インスタント メッセージング、および Voice over IP(VoIP)コーリングなどの基本機能を利用するために必要なものは、56 kbps ダイヤルアップ インターネット接続だけです。ただし、小規模のオフィスや拠点オフィスでファイル転送、スクリーン キャプチャ、PC 間のビデオ コール、チーム スペースなどの高度な機能を使用するには、512 kbps 以上のブロードバンド接続が必要です。高品位 720p などの高い品質のビデオの場合、推奨される最小の帯域幅接続は 2 Mbps です。

ネットワークおよびデスクトップの要件の詳細については、次の 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 Unified Client Services Framework は 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 Microsoft Lync

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

Cisco Unified Mobile Communicator

Cisco Unified Mobility Advantage サーバでは、次のユーザの容量をサポートしています。

Cisco MCS 7845-H2/I2 では、最大 1,000 台の Unified Mobile Communicator クライアントをサポートする。

Cisco MCS 7825-H4/I4 では、最大 500 台の Unified Mobile Communicator クライアントをサポートする。

Cisco MCS 7825-H2/I2 または 7825-H3/I3 では、最大 250 台の Unified Mobile Communicator クライアントをサポートする。

1 箇所で 1,000 人を超える Unified Mobile Communicator ユーザをサポートするには、追加の Unified Mobility Advantage サーバをインストールする必要があります。ただし、1 台の Cisco Unified Mobility Advantage サーバに関連付けるように設定された Unified Mobile Communicator クライアントは、別のサーバ上のクライアントにテキスト メッセージを送信できません。

エンタープライズ コール ログ統合のために Unified Mobile Communicator と Cisco Unified CM を統合した場合は、Unified Mobility Advantage サーバと Unified CM CTIManager が連携してデスクトップフォンの回線をモニタします。コール ログ統合が有効にされた Unified Mobile Communicator ごとに、Cisco Unified Mobility Advantage サーバが CTIManager への CTI 接続を確立します。そのため、すべてのユーザに対してコール ログ統合が有効にされた MCS 7845 を実行しているフル実装の Unified Mobility Advantage サーバと一緒に Unified Mobile Communicator を配置した場合は、1,000 個の CTI 接続が消費されます。このため、コールログ統合を使用する Unified Mobile Communicator を配置する場合、「アプリケーションと CTI」 で説明されている必要な CTI 接続の数について考慮する必要があります。

他のアプリケーション用の CTI 接続が必要な場合は、コール ログ統合を有効にする Unified Mobile Communicator ユーザの容量を制限できます。

Dial-via-office と Unified Mobility 機能のための Unified Mobile Communicator と Unified CM の統合では、各 Unified Mobile Communicator を Unified CM デバイスとして設定し、携帯の番号をモビリティ ID として設定する必要があります。したがって、これらの統合を実施する場合は、Unified CM 電話機とモビリティ対応ユーザの機能全体を検証する必要もあります。

サードパーティ製 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 シン クライアント上でローカルに実行される VXC ソフトウェア アプライアンスのデスクフォン制御モードを使用するため、配置されるクライアントごとに CTI プランニング ガイドラインに従う必要があります。VXC ソフトウェア アプライアンスは、Cisco Unified CM 上の SIP 回線側登録済みデバイスであるため、完全に統合された音声、ビデオ、および仮想デスクトップとして実行される各 VXC 6215 シン クライアントの場合、SIP 回線デバイスおよび CTI 接続が使用されます。

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

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

Cisco Unified Mobility

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

 

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

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

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 番めに大きな要件を課します。ハーフコール モデルでは、コールの発信と終端は異なるイベントと見なされるため、コールの種類を区別することが重要です。同じサーバに登録されている 2 つのエンドポイント間で発信されたコールは、コールの両ハーフともそのサーバで処理する必要があります。同じクラスタ内の 2 つのサーバ間で発信されたコールについては、参加している各サーバはコールの片ハーフのみを処理する必要があります。異なるクラスタに登録されているエンドポイント間で発信されたコールについては、サーバとクラスタ全体で各コールの片ハーフのみを処理する必要があります。クラスタに登録されているエンドポイントと PSTN 間で発信されたコールについては、PSTN ゲートウェイでコールの片ハーフを処理する必要があり、これらのコールに基づいてゲートウェイをサイジングします。

コール トラフィックを考慮するときは、コールを転送する場合、および会議を開始する場合に異なるプロトコルで動作するエンドポイント間(たとえば、SIP ベースの電話機と SCCP ベースの電話機の間)のコールにより、他にも複雑なことが生じます。

一般に、次の要素を考慮する必要があります。

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

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

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

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

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

クラスタ内の BHCA

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

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

ダイヤル プラン

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

電話番号

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

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

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

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

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

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

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

上記のダイヤル プラン要素の中で特に注目する必要があるのは、複数のエンドポイントで共有される回線の数です。特定の電話番号を共有するすべてのエンドポイントにコールを表示する必要があるため、シェアド ラインごとに呼設定の CPU コストが増えます。

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

アプリケーションと CTI

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

従来より、CTI のやり取りは、Unified CM では比較的コストのかかる動作でシステムの拡張性を厳しく制限していましたが、最近は最適化により、拡張性への影響が低減されました。Unified CM 9. x では、ハイエンドのサーバ プラットフォームによって、登録されているすべてのデバイスで CTI がサポートされていますが、ローエンドのプラットフォームはそれほど拡張性は高くありません。 表 29-8 に、サーバ プラットフォームの各タイプでサポートされている 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 ポートとルート ポイントを数える場合は、サードパーティ アプリケーションも考慮してください。

 

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

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

MCS 7815

150

MCS 7816-I2/I3/I4

400

MCS 7816-I5

Unified CM 8.6 以降のリリースでは 500、その他のリリースでは 400

MCS 7825-I1/I2

800

MCS 7825-I3/I4

900

MCS 7825-I5 および同等 OVA

Unified CM 8.6 以降のリリースでは 1,000、その他のリリースでは 900

MCS 7835-I1/I2

2,000

MCS 7835-I3 および同等 OVA

Unified CM 8.6 以降のリリースでは 2,500、その他のリリースでは 2,000

MCS 7845-I1

2,500

MCS 7845-I2 および同等 OVA

5,000

MCS 7845-I3 および同等 OVA

Unified CM 8.6 以降のリリースでは 10,000、その他のリリースでは 5,000

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

各制御対象デバイスの回線数(Unified CM 8.6 以降のリリースでは制御対象デバイスあたり最大 5 回線、その他のリリースでは制御対象デバイスあたり最大 2 回線)

CTI によって制御される回線の共有接続数(Unified CM 8.6 以降のリリースでは回線あたり最大 5、その他のリリースでは回線あたり最大 2)

アクティブな CTI アプリケーションの数(Unified CM 8.6 以降のリリースではデバイスあたり最大 5、その他のリリースではデバイスあたり最大 2)

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

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

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

 

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

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

Business Edition 3000

300

400

Business Edition 5000

500

575

Business Edition 6000

1,000

1,200

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


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

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

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

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

 

表 29-10 CTI 回線係数

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

1 ~ 5 回線

1.0

6 回線

1.2

7 回線

1.4

8 回線

1.6

9 回線

1.8

10 回線

2.0


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


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

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

 

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

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

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

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

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

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

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

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

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

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

 

表 29-12 サーバ タイプごとの 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 8. x は、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 回のログイン/ログアウトまで増大できます。( 表 29-12 を参照)。

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 秒あたり最大 2 コール要求(1 時間あたり 7,200 コール)まで処理できます。

各 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 サービスは最大で 2 cps をサポートできます。したがって、この例では、WebDialer サービスを実行するため 2 つのノードを設定する必要があります。これは、将来の 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)に配置した方が拡張性が向上する場合があります。ただし、このアプリケーションの保留音機能は、簡単には外部ソースに配置できません。 表 29-13 に、これらの各サービスに設定できる最大値を示します。

 

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

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

アナンシエータ

400

会議ブリッジ

256

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

512


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


保留音(Music on Hold)

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

表 29-14 保留音のキャパシティ制限

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

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

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

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

250 MoH セッション

MCS 7835
MCS 7845
および同等 OVA

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

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

500 MoH セッション

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

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 クラスタが処理できる最大ユーザ数は、クラスタのメンバー間で複製される内部コンフィギュレーション データベースの最大サイズによって制限されます。Unified CM リリース 8.6(1) 以降では、設定および同期可能な最大ユーザ数が、60,000 から 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 CM Session Management Edition

Session Management Edition(SME)は、特定の配置モードの Unified CM です。したがって、Unified CM のサイジングに関するすべての説明は SME にも当てはまります。大きな違いは、純粋な SME の配置におけるコール トラフィックが回線インターフェイスではなくトランク インターフェイスのみを通過する点です。したがって、SME クラスタのサイジングは、一般に Unified CM のサイジングよりも全体的に簡単です。

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 秒あたりのコール数で測定されます。ハードウェア プラットフォームやソフトウェア バージョン間で違いがあります。

SME サイジングの計算では、 http://tools.cisco.com/cucst で入手できる Cisco Unified CM SME Sizing Tool を使用します。

Cisco Intercompany Media Engine

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

 

表 29-15 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 で処理できるセッションの数に直接影響を与えます。 表 29-16 に、ASA-5550 および ASA-5580 のキャパシティ制限を示します。その他の ASA モジュールのパフォーマンス制限は、まだ検証されていません。

 

表 29-16 コール タイプおよび 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 に入力できます。 表 29-17 に、Emergency Responder をサポートするサーバ プラットフォームおよびその最大キャパシティを示します。

 

表 29-17 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)

Emergency Responder のキャパシティも 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

ゲートウェイ

ゲートウェイの予想入出力トラフィックは、必要な DS0 の数を計算するうえで重要です。このトラフィックを計算するには、トラフィックを発信および終端できるソースを考慮します。Unified CM に登録されているエンドポイントが主なトラフィック消費者ですが、音声自動応答装置(IVR)アプリケーションやコンタクト センター配置の一部などもあります。

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

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

ゲートウェイ グループ

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

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

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

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

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

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

PSTN トラフィック

この章で前述した音声トラフィック分析に関する説明(「コール トラフィック」)は、時分割多重(TDM)音声インターフェイスに必要な PSTN 回線の DS0 の数を決定するときに、特にゲートウェイと関連します。システム ユーザの数よりも PSTN 回線の数の方が少ない可能性があるため、ゲートウェイの PSTN 回線の最適な数、したがって DSP 要件を判断する必要があります。ブロック係数によって、ピーク トラフィック レベルで処理できない可能性があるコールの比率が決まります。ブロック係数が小さいほど、必要な回線の数が多くなります。

トラフィックはアーランで測られ、1 アーランは「1 つのコールが 1 時間持続すること」と定義されています。この項では、アーランについては詳しく説明しません。単に、特定のトラフィック量に対して必要な回線の数を算出する際にアーラン B とアーラン C という数表を使用する、と述べるにとどめます。

必要な外線のサイズは、企業で受信および発信されるトラフィックの量によって決まります。ただし、お客様の多くは一般に、IP ベースのコミュニケーション システムにおいても、それまで TDM ベースのシステムで使用していたのと同じ数の回線を使用し続けます。このサイジング方法は特に問題が発生しなければ有効ですが、その一方で継続的なシステム トラフィック分析プロセスを日常的なメンテナンス業務に組み込むことも重要です。トラフィック分析を行うと、現在のトラフィック レベルに対してシステムのプロビジョニングが過剰である(その結果、不要な回線にコストを費やしている)ことが判明したり、あるいは逆にプロビジョニングが不足していてコールのブロックや損失が起こる可能性のあることが指摘されたりします(この場合は回線数を増やすと状況が改善されます)。

一般業務のトラフィック プロファイル

ほとんどのお客様のトラフィック プロファイルは一般業務パターンです。これは、最繁時が通常 1 日 2 時間(午前 10:00 ~ 11:00 と午後 2:00 ~ 3:00)あることを意味します。これらの最繁時パターンは、多くの場合、1 日の業務の始まりや昼休み明けなどの要因に起因します。コールは保留時間が長くなる傾向があり、安定的に着信、終了する傾向も見られます。トラフィック計算に使用する保留時間の一般的な業界平均値は、3 分です。

最繁時のトラフィックを考慮して通信システムを設計していれば、通常は問題は起こりません。それより低いレベルでシステムを設計していると、コールのブロックや損失が発生し、業務に悪影響をもたらすおそれがあります。

コンタクト センターのトラフィック プロファイル

コンタクト センターでは、通常ある一定数のオペレータまたは自動音声応答(IVR)システムを利用して大量のコールを処理するという点で、少し異なるトラフィック パターンが見られます。コンタクト センターではリソースを最大限に活用する必要があるため、オペレータ、トランク、および IVR システムは業務時間中(通常は 1 日 24 時間)ずっと稼働した状態が続きます。コール キューイングの使用が一般的で(着信コール トラフィックがオペレータの処理能力を超えると、次のオペレータが空くまでコールはキュー内で待機します)、オペレータは通常、自分の勤務時間の間、コンタクト センターに寄せられた電話の応対に専念します。

コンタクト センターでのコールの平均保留時間は、多くの場合、一般業務の電話よりも短くなります。コールの平均保留時間が短くなる理由は、IVR システムの段階で用件が済み、オペレータと通話しない場合が多いことによります(これを「セルフサービス コール」と呼ぶことがあります)。オペレータと通話した場合の平均保留時間は 3 分(一般業務トラフィックと同じ)であるのに対して、セルフサービス コールの典型的な保留時間は約 30 秒であることから、コンタクト センター全体での平均保留時間は一般業務トラフィックよりも短くなります。

リソース(IVR ポート、PSTN トランク、オペレータなど)の使用を最適化するというコンタクト センターの目標と、コンタクト センターが電話応対専門の組織であることを考え合わせると、コンタクト センターのシステムでは通常の業務環境よりも着呼率は高くなります。これらの着呼率は、一般業務トラフィックとは異なる時間帯(通常の最繁時ではない時間帯)に異なる理由で最大になります。たとえば、特別な休日パックのテレビ CM を流して申し込み用のフリー ダイヤルを知らせた場合、その電話を受け付けるシステムの着呼率は、CM 放送後の約 15 分間にトラフィックのピークを迎えます。この着呼率は、コンタクト センターの平均着呼率を 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 使用率を削減する手法のいくつかを 表 29-18 に示します。

 

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

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

Enable Voice Activity Detection (VAD)

最大 20%

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

RTCP を無効にする

最大 5%

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

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

最大 2%

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

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

可変

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

その他の情報

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

Cisco Voice Gateway ソリューション:

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 Voice Gateway でサポートされるインターフェイスおよびシグナリング タイプ:

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)に対する影響も考慮してサイジングする必要があるアプリケーションです。

ボイス メッセージング システムのハードウェア(Cisco Unity または Cisco Unity Connection)をサイジングする場合は、システム内のユーザの合計数を考慮する必要があります。メッセージング ハードウェアに影響するその他の項目は、次のとおりです。

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

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

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

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

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

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

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

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

 

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

ソリューション
単一サーバでサポートされる最大ユーザ数
(フェールオーバー配置またはクラスタ配置)
デジタル ネットワーキング ソリューションの最大ユーザ数
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

Cisco Unity(ユニファイド メッセージングおよびボイス メッセージング)

Y

Y

N

Y

Y

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

 

表 29-20 サーバおよび 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 ヵ月あたりの平均時間(分))がわかっている場合は、 表 29-21 を使用して音声会議容量を計算します。

 

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

平均月間使用時間(分)
ベースライン使用時間(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 コラボレーティブ会議システム固有のサイジング情報についてさらに説明します。

Cisco WebEx Meetings Server

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

Cisco Unified MeetingPlace

Cisco Unified MeetingPlace では、Hardware Media Server(HMS)と Express Media Server(EMS)の 2 種類のメディア サーバ オプションが利用できます。どのオプションが十分であるかを判断するには、次のパラメータを使用します。

iLBC またはその他の高複雑度コーデックの使用。これらのコーデックを使用するには、HMS が必要です。

ビデオの分割表示やエコー キャンセレーションなどのメディア オプション。これらのオプションは両方とも HMS を必要とします。

帯域幅や解像度などのビデオ使用特性は、両方のメディア サーバ(HMS と EMS)のサイジングに重要です。

特定の Cisco Unified MeetingPlace ソリューションのキャパシティは、Unified MeetingPlace Meeting Director、EMS か HMS を使用するアプリケーション サーバ、または MCS か ASR サーバ向け WebEx ノードがインストールされるプラットフォーム、および配置される Unified MeetingPlace メディア サーバのキャパシティによって異なります。たとえば、Cisco MCS 7845-I3(または同等)サーバにインストールされた Unified MeetingPlace アプリケーション サーバでは、音声会議は単一のシステムまたは会議ノードで EMS の場合 1,200 ポート(G.711)、HMS の場合 2,000 ポート(G.711)になります。

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

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 プールに置いて、拡張音声/ビデオ機能で使用できるようにします。 表 29-22 に、拡張音声およびビデオで使用できる合計 SRU 数を、サポートされるプラットフォームごとに示します。

 

表 29-22 サポートされる各 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 ノード)

 

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

セッション タイプ
使用される 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 です。

表 29-22 および 表 29-23 のデータで示したように、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

Hardware Media Server

Cisco Unified MeetingPlace Hardware Media Server(HMS)では、EMS とは少し異なる設定が使用されます。Unified MeetingPlace Application Administration のグローバル音声モード設定が、Unified MeetingPlace HMS 音声ブレードの音声容量に直接影響します。グローバル音声モードは次のいずれかの方法で設定できます。

回線エコー キャンセレーション(LEC)のない G.711 および G.729

この設定では、HMS 内の 1 つの音声ブレードで最大 250 個の音声ポートがサポートされます。サポートされるシステムの最大限度である 2,000 の同時音声セッションに達するには、8 つの音声ブレードが必要となります。

回線エコー キャンセレーション(LEC)のある G.711、G.722、iLBC、または G.729

この設定では、1 つの音声ブレードで最大 166 個の音声ポートがサポートされます。8 つの音声ブレードの場合、これらの追加コーデックを使用してサポートされる同時音声セッションの最大数は 1,328 です。

Unified MeetingPlace Application Administration のグローバル ビデオ モード設定は、Unified MeetingPlace HMS ビデオ ブレードのビデオ容量を決定します。グローバル ビデオ モードは次のいずれかの方法で設定できます。

標準レート(最大 384 kbps のビデオ コール スピード)

このモードでは、HMS 内のビデオ ブレードは最大 40 個のビデオ ポートをサポートできます。

高レート(最大 2,048 kbps のビデオ コール スピード)

このモードでは、ビデオ ブレードは最大 20 個のビデオ ポートをサポートできます。

Unified MeetingPlace でサポートされるビデオ形式の全リストについては、次の Web サイトで入手可能な『 Compatibility Matrix for Cisco Unified MeetingPlace 』の最新バージョンを参照してください。

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

Unified MeetingPlace Hardware Media Server は、Cisco Unified MeetingPlace 3515 または Cisco Unified MeetingPlace 3545 シャーシを選べます。Unified MeetingPlace 3515 は、1 つの音声ブレードと 1 つのビデオ ブレードがインストールされた固定プラットフォームです。Unified MeetingPlace 3545 は、4 つの音声ブレードまたはビデオ ブレードのさまざまな組み合わせをサポートするシャーシで構成されたモジュラ プラットフォームです。

音声ブレードとビデオ ブレードのカスケーディング

Unified MeetingPlace 3545 に複数の音声ブレードとビデオ ブレードがインストールされている場合は、メディア サーバで仮想カスケーディングを使用して、ある音声ブレードまたはビデオ ブレードから別の音声ブレードまたはビデオ ブレードへ、オーディオ ストリームとビデオ ストリームがオーバーフローされます。音声ブレードには、音声セッション容量を減少させないカスケーディング ポートが組み込まれています。単一のビデオ ブレードを Unified MeetingPlace システムに展開することによって、すべてのビデオ ポートがビデオ会議に使用できます。複数のビデオ ブレードを展開した場合は、メディア サーバによって自動的にカスケーディング用のビデオ ポートが予約されます。標準レート ビデオの場合は、カスケーディング用に 8 個のビデオ ポートが予約され、40 個のビデオ ポートが他の目的に使用できます。高レート ビデオの場合は、カスケーディング用に 4 個のビデオ ポートが予約され、20 個のビデオ ポートが他の目的に使用できます。

例 29-1 Cisco Unified MeetingPlace 音声会議

Cisco Unified MeetingPlace 3545 メディア サーバが、2 つの音声ブレードおよび 2 つのビデオ ブレードと一緒に配置されます。会議は 350 個の音声ポートを使用してスケジュールされ、グローバル音声モードが LEC を使用する G.711 に設定されます。この場合、次のように計算します。

メディア サーバで、最初の音声ブレードから 251 個のポートが割り当てられます。そのうちの 250 個のポートが音声参加者用に使用され、1 個のポートがビデオ カスケーディングまたは 2 番めの音声ブレードとの接続に使用されます。

メディア サーバで、2 番めの音声ブレードから 101 個のポートが割り当てられます。そのうちの 100 個のポートが音声参加者用に使用され、1 個のポートがビデオ カスケーディングに使用されます。

例 29-2 Cisco Unified MeetingPlace ビデオ会議

Cisco Unified MeetingPlace 3545 メディア サーバが、2 つの音声ブレードおよび 2 つのビデオ ブレードと一緒に配置されます。この例では、会議が 65 個のビデオ ポートでスケジュールされ、グローバル ビデオ モードが標準レート ビデオ用に設定されます。この場合、次のように計算します。

メディア サーバで、最初のビデオ ブレードから 41 個のポートが割り当てられます。そのうちの 40 個のポートがビデオ参加者用に使用され、1 個のポートがビデオ カスケーディングまたは 2 番めのビデオ ブレードとの接続に使用されます。

メディア サーバで、2 番めのビデオ ブレードから 26 個のポートが割り当てられます。そのうちの 25 個のポートがビデオ参加者用に使用され、1 個のポートがビデオ カスケーディングに使用されます。

Unified MeetingPlace Web サーバ

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

WebEx ノード、MCS 向け

MCS 向け Cisco WebEx ノードをオプションで使用する Web 会議は、MCS 向け WebEx ノードが存在するハードウェアのタイプに応じて、最大 500 の Web セッションに対応できます。ソリューションごとに最大 4 つの MCS 向け WebEx ノードを展開でき、ASR 向け WebEx ノードを使用する場合は展開できるノード数が無制限になるので、冗長性を備えたオンプレミスでの最大 2,000 の Web セッションのスケーラビリティが可能です。WebEx ノードはお客様のネットワーク内の任意の場所に分散できますが、大きい Web ユーザ グループの近くに展開することを推奨します。MCS または ASR 向け WebEx ノードとの Web セッションを使用できるのは内部ユーザだけです。外部ユーザは常にクラウドに接続します。MCS または ASR 向け Cisco WebEx ノードの詳細なキャパシティについては、次の Web サイトで入手可能な『 Planning Guide for Cisco Unified MeetingPlace 』の最新バージョンを参照してください。

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

Cisco IM and Presence

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

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

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

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

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

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

ユーザの数とタイプ

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

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

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

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

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

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

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

配置モデル

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

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

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

サーバ設定

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

システム オプション

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

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

 

表 29-24 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 Suite

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

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

たとえば、共存サーバは、Unified Communications Management Suite アプリケーションの 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 およびネットワーク分析モジュール(NAM)でも構成されています。

表 29-25 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

まとめ

要約すると、連携する多くの個別アプリケーションで構成された大規模な Unified Communications システムのハードウェア構成を決定するのは容易でない場合があります。ただし、ソフトウェアの機能要件、およびソフトウェアの実行が認定されているハードウェア プラットフォームのパフォーマンス特性を理解すると、必要なサーバを正確に見積もるのに非常に役立ちます。この章で前述したように、この目的のためにシスコが開発したツールを使用できます。詳細については、シスコ パートナーまたはシスコのシステム エンジニアにお問い合わせください。担当者が Cisco Unified Communications Sizing Tool( http://tools.cisco.com/cucst )を使用して、すべての設計を検証できます。