この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、シスコ コラボレーション製品およびシステムのシステム サイジングについて説明します。サイジングは、システムが提供するユーザの数、トラフィックの構成、トラフィックの負荷、および機能に基づいてシステムに必要なハードウェア プラットフォームを正確に見積もります。
正確なサイジングは、導入されたシステムがコール量とスループットに関して予期されたサービス品質を満たすために重要です。スタンドアロン製品の場合、システム サイズの手動計算が実行できる場合があります(スタンドアロン製品のサイジングの項で詳しく説明)。ただし、複雑なシステム導入では、多くのサイジングの考慮事項があります。たとえば、複数の製品がさまざまな場所に分散しており、ビデオ エンドポイント、コール センター、および音声/ビデオ会議が含まれている場合があります。シスコは、その複雑さを扱うための一連のサイジング ルールを提供します。
この章では、システム サイジングの方法およびサイジングに影響を与える要因に関する概要、およびサイジング ツールの使用方法について説明します。
(注) この章は、このマニュアルの他の章で説明する製品の説明、および設計と導入についての考慮事項とあわせて読む必要があります。導入を成功させるには、これら両面をよく理解する必要があります。
(注) コラボレーション サイジング ツールを使用しない簡単なサイジングのガイダンスについては、https://www.cisco.com/go/pa で入手可能な『Cisco Preferred Architecture for Enterprise Collaboration CVD』の最新版を参照してください。
表 25-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。
|
|
|
---|---|---|
正確なシステム サイジングを実行するため、シスコは、通常の動作条件でシステムが処理する必要がある予想される最大のトラフィックを見積もるため、実際のパフォーマンス テストの結果によってサポートされ、業界標準のトラフィック エンジニアリング モデルが組み込まれている方法論に従います。
それぞれの製品は一連の機能を実行し、それぞれの機能はさまざまなリソース(CPU やメモリなど)を利用します。シスコは、さまざまな使用レベルで各機能に対するリソースの使用率を正確に測定できるパフォーマンス テストを定義および実行します。
ほとんどのシステムは、特定の範囲内で線形性を示し、その範囲を超えるとシステムのパフォーマンスが予測不能になります。シスコは、各機能のリソース使用率の線形範囲を識別し、確定するため、各パフォーマンス テストに使用レベルを設定します。各テストの結果は、最小限のデータ ポイントを使用してグラフ化できます。必要に応じて、追加のデータ ポイント(中間負荷レベルで)実際のシステム動作を定義するために取得されます。
グラフの線形セクションの傾斜は、追加作業の各差分のリソース使用状況やコストを定義します。R 2 値を使用して、一致精度を予測します。R 2 値が 1 に近い場合、式はデータとほぼ一致しています。
たとえば、図 25-1 に、単一回線の IP Phone を設定するために必要なメモリを判断するために実行されたテストの結果を示します。Unified CM で 1,500 台、4,500 台、および 7,500 台の単一回線の IP Phone を設定することで消費されるメモリを示しています。グラフは、傾向線の式が線形であり、制御変数(電話機の数)に基づく従属変数(この場合はメモリ)の予測に使用できることを示しています。
この特定の試験では、R 2 値はきわめて 1 に近くなっています。式から、7,500 台の単一回線電話の設定で使用されるメモリは約 519,000 キロバイトであり、システム内のエンドポイント用に設定された追加の回線それぞれがさらに 8.91 キロバイトを使用すると計算できます。
シスコは、パフォーマンス テストの結果を使用してシステム モデルを作成します。システム モデルは、指定された機能、エンドポイント、およびモデルへの入力として提供されるトラフィックの構成のセットに対する最大リソース使用率を計算する数学的モデルです。
特定の製品に対するシステム モデルを作成するには、次の手順を実行します。
1. 製品が実行するすべての機能を列挙します。テストする必要がある機能の種類を識別します。たとえば、各コール タイプが使用する測定されたリソースの量は異なります。
2. 対象のリソースを決定します。通常、メモリおよび CPU が含まれます。特定の製品には、システム サイジングに影響を与える追加のリソースが含まれている可能性があります。
3. パフォーマンス テスト(前述の項で説明)を実行し、各機能のリソース使用率を判別します。
4. 機能ごとに、線形範囲を使用してリソース使用率を定義します。
他の要因(ソフトウェア リリース、コールの構成、エンドポイントのタイプなど)がリソース使用率に影響を与える可能性があるため、これらの手順を何度も実行する必要があります。
製品のシステム モデルは、製品によってサポートされている各機能に関する式の集約で構成されます。一部の製品のモデルはかなりシンプルですが、複数の機能、複数のエンドポイント タイプ、および複数のコール タイプをサポートする製品のモデルは非常に複雑になることがあります。
システム モデルは、異なる使用特性を持つスタティック メモリとダイナミック メモリを区別します。また、オペレーティング システムとその他のプロセス用に予約されているシステム メモリもあります。これらの 3 つのメモリ タイプについては、次の項で説明します。
スタティック メモリはシステムにトラフィックがない場合でも消費されます。スタティック メモリ使用率には、システム設定のデータおよび登録済みエンドポイントのデータが含まれます。スタティック メモリには、ダイヤル プラン(パーティション、トランスレーション パターン、ルート リスト、およびグループなどの項目を含む)の設定も含まれます。また、スタティック メモリには CTI および他のアプリケーションに割り当てられたメモリも含まれます。大規模なシステムでは、スタティック メモリは、主に設定済みエンドポイント数およびダイヤル プランのサイズの関数です。
消費されるメモリの量は、エンドポイントのタイプごとに異なることに注意してください。メモリ使用率は、デバイス プロトコル(SIP または SCCP)、ライン アピアランスの数、セキュリティ機能、およびその他の要因によって異なる場合もあります。これらの要因をそれぞれ測定し、モデルに組み込む必要があります。
ダイナミック メモリは、各アクティブ コールのコンテキストの保存などの一時的なアクティビティに使用されます。大規模なシステムでは、ダイナミック メモリは、主に同時発生コール数の関数です。
同時発生コール数は、平均コール保留時間(ACHT)によって決定されます。ACHT が長くなると同時発生アクティブ コール数が大きくなるため、より多くのダイナミック メモリが使用されます。
システム メモリは、オペレーティング システム(OS)およびその他のプロセスとサービスによって必要とされます。また、一部のメモリは、一時的な使用率の急激な増加のために予約されている場合があります。システム メモリにより、プラットフォームで動作するアプリケーションで使用可能なメモリ量が減少します。
非アクティブなシステムで多少の CPU アクティビティが表示されますが、ほとんどの CPU の使用は、コールのセットアップまたは終了時に発生します。したがって、CPU 使用率の主な決定要因の 1 つは提供されるコール レートです。
CPU 使用率は、コールのタイプによって大きく異なる場合があります。コールは同じサーバ内で発信または終端するか、2 つの異なるサーバまたはクラスタ間で発信または終端できます。また、Unified CM クラスタから発信され、PSTN ゲートウェイまたはトランクで終端することもできます。
CPU 使用率の分析は、Unified CM でのコールの発信と終了のコストの違い、使用中のプロトコル、およびセキュリティ機能が有効かどうかを考慮する必要があります。CPU 使用率は、コンフィギュレーション データベースの複雑さ、および CDR または CMR のどちらが生成されているかなどの要因によっても異なります。
CPU 使用率は、実際のハードウェア プラットフォームによって大幅に異なります。したがって、同じパフォーマンス テストを各製品がサポートされているすべてのサーバに対して繰り返す必要があります。
また、CPU 使用率は、コール転送、会議、およびメディア リソース機能(MTP や保留音)など、CPU 消費が激しいコール操作の影響も受けます。シェアド ラインは、シェアド ラインへの各コールが回線を共有するすべての電話機に提供されるため、追加の CPU リソースを消費します。
シスコは、業界標準のトラフィック エンジニアリング モデルを使用してシステムの動的な負荷を見積もります。
トラフィック エンジニアリングは、一連のユーザに対して予測される最大トラフィック レベルを計算する数学的モデルを提供します。特定のトラフィック負荷をサポートするのに必要な共有リソース(PSTN トランクなど)の量がモデルによって決まります。
システムで一度に処理可能な、同時アクティブ コールの最大数。
1 秒間にシステムに着信した新しいコールの試行数および同じ 1 秒間に切断した既存のコール数。この単位は、システムが最繁時に受信することが予測される 1 秒間の平均コール数を定義するために使用できます(この数は 60 で割ることによって求められる最繁時のコール数に相当します)。
また、システムが処理する必要があるトラフィックの最大バーストを定義するためにも使用できます。
24 時間の中でトラフィックが最大となる 1 時間。この時間は、組織とトラフィックのタイプによって異なります。ビジネス音声トラフィックの場合、従来、最繁時は午前中(たとえば、午前 10 時~午前 11)と見なされています。
ユーザ BHCA は、ユーザが最繁時にコールを開始または受信する平均数を表します。通常、BHCA は、1 年間の最も通話の多い 30 日間の最繁時呼数の平均で計算されます。システム BHCA は、ユーザ BHCA にユーザ数を掛け合わせたものです。
リソース不足によって最繁時にコールがブロックされる確率で表されるサービス グレードを示します。たとえば、1 % のブロック係数は、処理に必要なリソースの不足が原因で 100 コールごとに 1 コールがブロックされる可能性があることを示しています。
リソースがビジーである平均期間です。たとえば、音声コールの場合、ACHT は、2 者間に開いている通話路がある場合のコール設定とコール終了間の期間です。音声システムのトラフィック エンジニアリングで使用する保留時間の業界平均値は 3 分(180 秒)です。
アーランはシステムのトラフィック負荷の測定単位です。アーランを計算するには、1 時間あたりのコール数に平均保留時間(1 時間単位)を掛け合わせます。リソース要件は、適切なアーラン モデルを使用してアーランから取得できます。
リソース(トランク グループなど)によって処理されるアーランの数は、同時コール数と等しくなります。アーラン値は通常、1 時間の期間で平均化されます。
アーラン B モデルにより、指定されたブロック係数でトラフィック負荷(アーラン単位)を処理するために必要なトランク数を判断できます。拡張アーラン B モデルには、再試行(ブロックされたコールのため)のモデルが含まれます。再試行の割合は、拡張アーラン B モデルへの追加入力です。
アーラン C モデルは着信コールのキューイングを備えているため、コール センター トラフィックをモデル化するのに非常に役立ちます。
トラフィック モデルは、コール試行の着呼率がかなり安定していることを前提としています。これは、独立して動作する多数のサブスクライバに対して有効な前提です。ただし、実際のシステムでは、多数のコールが非常に短時間に到着する可能性があります。このようなトラフィック バーストはシステム リソースを急速に消費し、多数のコールがブロックされることがあります。製品によっては、処理できるトラフィック バーストのサイズと期間が指定されている可能性があります。
標準音声トラフィックは、最繁時呼数(BHCA)および平均コール保留時間(ACHT)の指定によって特徴付けられます。たとえば、システム BHCA が 200 で平均コール期間が 3 分の場合、システムは合計 600 分間(10 アーラン)使用されます。
共有リソース(PSTN トランク グループなど)の使用率を計算するには、ブロック係数も指定する必要があります。たとえば、アーラン値とブロック係数が指定されている場合、アーラン カルキュレータまたはルックアップ テーブルを使用して PSTN ゲートウェイで必要な音声回線を計算できます。
表 25-2 に、トランクの数、ブロック確率、およびトラフィックのアーランの関係を示します。
|
|
|||||
---|---|---|---|---|---|---|
|
|
|
|
|
|
|
表 25-2 より、次の情報を確認できます。
コンタクト センターでは、通常これらのシステムが少数のエージェントまたは自動音声応答(IVR)システムによって処理される大量のコールを処理するため、独特のトラフィック パターンが見られます。コンタクト センターは、高いリソース使用率を実現するように設計されているため、エージェント、トランク、および IVR システムは業務時間中(通常は 1 日 24 時間)ずっと稼働した状態が続きます。コール キューイングの使用が一般的で(着信コール トラフィックがオペレータの処理能力を超えると、次のオペレータが空くまでコールはキュー内で待機します)、オペレータは通常、自分の勤務時間の間、コンタクト センターに寄せられた電話の応対に専念します。
コンタクト センターでのコールの平均保留時間は、多くの場合、通常のビジネス コールよりも短くなります。IVR システムの段階で用件が済み、オペレータと通話しない場合が多くなります。これらのコールは、セルフサービス コールと呼ばれます。エージェントの平均保留時間は 3 分(一般業務トラフィックと同じ)であるのに対して、セルフサービス コールの平均保留時間は約 30 秒であることから、コンタクト センター全体での平均保留時間は一般業務トラフィックよりも短くなります。
コンタクト センター管理の目標は、リソース(IVR ポート、PSTN トランク、オペレータなど)の使用を最適化するためです。そのため、リソース使用率が高くなります。
コンタクト センターでは通常、一般的な業務環境よりも着呼率が高くなります。これらの着呼率は、一般業務トラフィックとは異なる時間帯(通常の最繁時ではない時間帯)に異なる理由で最大になります。たとえば、特別な休日パックのテレビ CM を流して申し込み用のフリー ダイヤルを知らせた場合、システムの着呼率は、CM 放送後の約 15 分間にトラフィックのピークを迎えます。この着呼率は、コンタクト センターの平均着呼率を 1 桁上回ることもあります。
前述したように、コンタクト センターのサイジングは、アーラン C モデルを使用してキューで待機中のコールを考慮します。コンタクト センターには、自動音声応答(IVR)ポートなどの追加のリソースが必要です。PSTN ゲートウェイをサイジングする場合は、キューでコールが待機する時間を考慮する必要があります(コンタクト センター トラフィックに対するゲートウェイのサイジングを参照)。
(注) シスコ ユニファイド コンタクト センターの導入に関する追加情報については、次の場所にある『Solution Design Guide for Cisco Unified Contact Center Enterprise』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-implementation-design-guides-list.html。
ポイントツーポイント ビデオ トラフィックは、着呼率、ピーク時の使用時間、および通話時間が同等の音声トラフィックと類似した特徴を示します。また、コール セットアップおよび終了のシグナリングは、音声コールに類似しています。
ビデオ パケットのペイロードは音声パケットよりもはるかに大きいため、ビデオ トラフィックには、音声をはるかに上回るネットワーク帯域幅が必要です。また、ビデオ トラフィックは、音声よりもバーストが大きくなります。音声パケット サイズは、通常はほぼ一定(使用中のエンコーディング アルゴリズムによって固有)ですが、ビデオ フレームのサイズは、以前のフレームからどれほどの変更があったかに応じて大幅に異なります。その結果、RTP パケット ストリームはトラフィックのバーストを示すことがあります。
会議トラフィックには、ポイントツーポイントの音声/ビデオ コールとは大きく異なる特性があります。会議トラフィックのトラフィック モデルでは、次の違いを考慮する必要があります。
従来のトラフィック モデルは、最繁時の着信が最繁時全体に渡ってポアソン分布することを前提としています。ただし、ほとんどの参加者は、開始時間の 5 ~ 10 分以内に会議コールに参加し、ほとんどの会議コールは正時に開始されるようにスケジューリングされています。したがって、着呼率は、時間全体でのポアソン分布ではなく、開始後 0 分の単一のバーストで表されます。
ビジネス音声トラフィックには通常、午前中(10:00 ~ 11:00 AM)と午後(1:00 ~ 2:00 PM)の個別のピークがあります。ただし、会議機能は通常は限られたリソースであるため、会議は、営業日全体により均等に配布され、ピーク時にピークが緩和されます。
平均ビジネス音声コール期間は 3 分です。平均会議コール時間はほぼ 50 分です(30 分、60 分、さらに長い会議の組み合わせによって異なります)。
ビデオ ストリームの切り替えまたは組み合わせを提供するには、専用装置が必要です。そのため、ビデオ エンドポイントの予期される使用率は、モデルにおける重要な要素です。
会議用の導入のサイジングでは、主に必要な同時接続数を特定します。たとえば、TelePresence Server のサイジングでは次の事項を考慮する必要があります。
地域ネットワークの会議メディアをできるだけ多く維持するため、会議リソースは一般に 1 つの地域でのみ使用されます。したがって、サイジングは地域単位で検討することができます。
大規模で複雑な導入の場合、システム設計者は、システム サイジングに影響する多くの設計と導入の要因を考慮する必要があります。次の項では、これらの要因について説明します。
ソリューション サイジングは、次のネットワーク設計の要素の影響を受けます。
主要な設計上の決定項目として、大規模な集中型の Cisco Unified CM クラスタを作成するか、それぞれの主要な場所でクラスタを作成するかどうかがあります。中央クラスタの使用率は高くなる可能性がありますが、クラスタの制限を超えた場合は、2 つめのクラスタを使用せざるを得なくなる可能性があります。
一部のシステムの制限は絶対ではなく、システムで設定された他のサービスのサイズに基づいて動的に変更できます。
Unified CM は、ほとんどの Cisco Collaboration 配置において中心的な役割を果たしており、システムの他のコンポーネントによって影響を受けます。たとえば、Cisco WebEx Meetings Server の追加は、短時間(会議セッションの開始時)に多数のコール セットアップを集中させる傾向があります。Unified CM によって網羅された他の機能に応じて、追加の Unified CM サーバ ノードが必要になる場合があります。
それぞれのタイプのサーバまたはルータは、異なる機能をサポートします。たとえば、より強力なサーバには Cisco Business Edition 6000 プラットフォームまたは Cisco Integrated Services Router(ISR)よりも多くのネットワーク ポートがある場合があります。
別の例として、Cisco Integrated Service Router(ISR)の各種モデルでは、ホストできるネットワーク モジュールまたは Cisco Unified Computing System(UCS)E シリーズ ブレード サーバのモジュールの数とタイプに制限があります。
システム サイジングは、コール詳細レコード(CDR)またはコール管理レコード(CMR)の生成などのオプションを有効にしている場合に影響を受ける可能性があります。
各コール タイプ(同じサブスクライバ ノード内の電話機間のコール、同じクラスタ内の 2 つのサブスクライバ ノード間のコール、2 つのクラスタ間のコール、および PSTN に出入りするコール)によって消費されるリソースには違いがあります。異なるタイプの電話機やゲートウェイからのコールも、プロトコルやビデオなどのサービスによって異なります。
サイジングに影響する別の明確な要因の例として、期待される電話機とユーザの数があります。この場合も、電話機のタイプ、電話機に設定されている回線の数、電話機がセキュア モードであるかどうかなどがシステム サイジングに影響します。
システム リソースの使用率は、システム リリースに応じて異なることがあります。場合によっては、リリースの新機能によってリソース使用率が増加する原因となる可能性があります。また、ソフトウェアの向上によってリソース使用率が低下する可能性があります。
外部アプリケーションは、CTI などのインターフェイスを使用してコール処理エージェントと通信できます。システム サイジングでは、この負荷の影響を考慮する必要があります。
システム使用率が来年または再来年に増加することが予測されている場合は、近い将来に破壊的とも言える可能性のあるアップグレードに直面する代わりに、その成長を元のシステムに組み込むことを推奨します。
システム サイジングが、現実的なピーク時使用率の観点に基づいていることを確認します。ピークが過小評価されていると、実際にピーク トラフィックに遭遇した場合に、システムでサービスの低下または機器の障害が発生する可能性があります。
すべての要因およびその変動の可能性により、大規模システム配置の正確なサイジングは複雑な作業です。このため、シスコは次の項で説明するシステム サイジング ツールを使用することを強く推奨します。
シスコでは、正確なソリューション サイジングを支援する複数のサイジング ツールを提供しています。サイジング ツールは、次のサイトで入手できます(シスコの従業員および認定パートナーだけがこのサイトにアクセスできます)。
https://cucst.cloudapps.cisco.com/landing
シスコは、サイジング ツールを使用してシステム サイジングを実行することを推奨します。これらのツールでは、パフォーマンス テストに基づくデータ、個々の製品制限とパフォーマンス レーティング、製品リリースにおける拡張機能と新規機能、この SRND の設計上の推奨事項、およびその他の要因が考慮されています。システム設計者によって提供される入力に基づいて、ツールは、サイジング アルゴリズムを提供されたデータに適用して、一連のハードウェア リソースを推奨します。
サイジング ツールにアクセスできない場合は、シスコ アカウント担当者またはシスコ パートナー インテグレータに問い合わせて、システムのサイジング情報を取得してください。
次のツール固有の項には、ツールに必要な入力に関する説明、および最適な入力内容を既存のシステムから収集する方法、また設計段階のシステムに対して見積もる方法が記載されています。言うまでもなく、ツールによって生成されるサイジングの推奨内容は、ユーザが提供する入力データの正確性と同程度の正確性しかありません。
このツールは、システムの導入全体を通してユーザをガイドします。このツールは、次の製品およびコンポーネントに対応しています。
– Cisco Unified Communications Manager(Unified CM)
– Cisco Unified Communications Management Suite
– Cisco Unified Contact Center コンポーネント
これは、Unified CM Session Management Edition の導入の特定の機能に重点を置いた専用ツールです。
これは、Cisco Virtual Experience Infrastructure(VXI)のサイジング専用ツールです。
これらのツールおよびアクセス権限の詳細については、次の場所にある『 Collaboration Sizing Tool Frequently Asked Questions 』を参照してください。
https://cucst.cloudapps.cisco.com/help/UC_Sizing_Tools_FAQ.pdf
これらのサイジング ツールに加えて、有効なログイン アカウントを持つシスコのパートナーとお客様は Virtual Machine Placement Tool を Virtual Machine Placement Tool 利用できます。Virtual Machine Placement Tool は、Tested Reference Configurations(TRC)または仕様ベースのハードウェアを選択し、これらのサーバ上のさまざまな Cisco Collaboration アプリケーションの仮想マシンをドラッグ アンド ドロップするグラフィカル ツールです。サードパーティ製アプリケーションの仮想マシンを表すプレースホルダは、Cisco Collaboration アプリケーションをサードパーティ製アプリケーションと共存させて配置する際にも使用できます。サイジング ツールは、必要なサーバの規模と仮想マシンの台数を決定します。さまざまな仮想マシンの配置方法や配置する必要のあるサーバ数を決定するために、この情報を Virtual Machine Placement Tool に入力できます。共存ルールの一部はツールに実装されていますが、次の Web サイトで入手可能なガイドラインを確認することを推奨します。
https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/collaboration-virtualization-sizing.html
Virtual Machine Placement Tool は次の Web サイトから入手可能です(正しいログイン認証がある場合)。
Session Management Edition(SME)は、特定の導入モードで動作する Unified CM です。純粋な SME の導入では、コール トラフィックがトランク インターフェイスでのみ動作し、SME はライン インターフェイスをホストしません。
SME クラスタは、通常の Unified CM クラスタと同じトポロジに従います。パブリッシャ ノードにマスター設定リポジトリが用意されています。クラスタ内の電話機や MGCP ゲートウェイの数が比較的少ない場合、TFTP サービスをパブリッシャ ノードで実行できます。呼処理サブスクライバについては、冗長性の比率を 1:1 にすることを推奨します。
SME クラスタをサイジングするには、期待される機能を考慮する必要があります。基本構成では、SME は、多くのリーフ クラスタのルーティング集約ポイントとして機能します。接続されているすべてのリーフ クラスタに集中型 PSTN アクセスを提供します。高度な構成では、SME は集中型ボイス メッセージング、モビリティ、および会議サービスもホストできます。SME のパフォーマンスは、リーフ クラスタが SME への接続に使用するトランク プロトコルのタイプおよびこれらのトランクの BHCA の影響を受けます。
SME のサイジング ツールには、次の入力パラメータが必要です。
SME がサービス集約ポイントとして機能する場合は、次の追加のサイジング パラメータを考慮する必要があります。
SME のパフォーマンスは、プロトコルの各ペアの 1 秒あたりのコール数で測定されます。ハードウェア プラットフォームやソフトウェア バージョン間で違いがあります。
Cisco Virtualization Experience Infrastructure(VXI)はシステム アプローチの 1 つであり、仮想デスクトップ、音声、およびビデオを統合することで、優れた仮想ワークスペース エクスペリエンスを提供します。Cisco VXI Sizing Tool は、Virtualization Experience Infrastructure ソリューションのサイジング コンポーネントのタスクを支援します。
Cisco Collaboration Sizing Tool は、さまざまな製品やコンポーネントのサイジングに対応しています。ツールによってサポートされているコンポーネントとバージョンの完全なリストについては、サイジング ツールのインストール パッケージに含まれているリリース ノートを参照してください。
次の項では、各製品のサイジングに影響する重要な要因、およびこれらの各製品がシステム導入内の他の製品のサイジングに関する考慮事項に及ぼす影響について説明します。
Cisco Unified Communications Manager(Unified CM)は、Unified Communications 導入のハブです。これは、エンドポイントの制御、コールのルーティング、ポリシーの施行、およびアプリケーションのホストなどの主要な機能を実行します。Unified CM は、PSTN ゲートウェイ、Cisco Unity Connection、Cisco Unified MeetingPlace、Cisco Unified Communications Manager IM and Presence Service、および Cisco Unified Contact Center などの他の Unified Communications 製品に対する連携を提供します。連携機能は、Unified CM のパフォーマンスに影響を与えるため、Unified CM サイジングで考慮する必要があります。
多くの要因が Unified CM のパフォーマンスに影響するため、Unified CM 導入のサイジングで考慮する必要があります。次の項では、これらの要因について説明します。
サイジング ツールには、次のサーバ ノードとクラスタの最大数が適用されます。これらの値は、Unified CM ソフトウェアのバージョンに応じて異なることがあります。
次の導入オプションは、システム内のすべての動作に影響する全体的な設定であり、登録されているエンドポイントの数や進行中のコールの数とは無関係です。
Unified CM のコンフィギュレーション データベースが複雑であると見なされる場合、CPU 使用率はかなり高くなります。データベースが単純か複雑かを判断するメトリックはありません。一般に、数千を超えるエンドポイントと数百を超えるダイヤル プラン要素(トランスレーションおよびルート パターン、ハント パイロット、シェアド ラインなど)がある場合、データベースは複雑になります。
Unified CM クラスタ内のリージョンとロケーションの設定には、データベースとスタティック メモリの両方が必要です。クラスタに定義できるゲートウェイの数は、定義できるロケーションの数にも関係します。 表 25-3 に、一部の Unified CM の VM 設定におけるこれらの制限を示します。
|
|
|
|
---|---|---|---|
クラスタに最大数のロケーションとリージョンを実際に定義できるかどうかは、コーデック マトリクスがどの程度「疎」であるかによって異なります。リージョン間コーデック設定にデフォルト以外の値が多すぎる場合は、リージョンまたはロケーションのためにシステムをフル キャパシティに拡張できません。一般に、デフォルトからの変更は最大数の 10% を超えないようにします。
コール詳細レコード(CDR)とコール管理レコード(CMR)の生成により、CPU に大きな負荷がかかります。
指定した導入に必要なノードの最小数を特定した後、冗長性を提供するために目的の数の追加のサブスクライバ ノードを追加します。冗長性オプションについては、呼処理の章を参照してください。
通常のクラスタに最大 4 つのサブスクライバ ペアを設定できます。分散型トポロジでは、クラスタが最大数に達していない場合でも複数のクラスタがある場合があります。
集中型トポロジの場合、キャパシティの制限に到達しない限りは通常は 1 つのクラスタがあります。他のシステム制限によって、ノードごとの使用率が制限に達していない場合でも、新しいクラスタを使用せざるを得ない可能性があることに注意してください。
シスコはハイパーバイザにロードできる Open Virtualization Archive(OVA)の VM 設定を提供します。指定する機能はテンプレートごとに異なります。たとえば、10,000 人のユーザ用テンプレートでは、10,000 個のエンドポイントの最大キャパシティを持つ仮想マシンを定義します。また、最大 1,000、2,500、および 7,500 個のエンドポイントをサポートするように定義されたテンプレートもあります。
Unified CM およびその他の Unified Communications 製品用に正式に定義された VM 設定は、次の Web サイトから入手できます。
https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/collaboration-virtualization-sizing.html
Unified CM の特定の情報については、次の Web サイトから入手できます。
https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-unified-communications-manager.html
Unified CM では、VM 設定の一部はローエンド ハードウェア プラットフォームではサポートされていません。どの VM 設定がハードウェア プラットフォームでサポートされているかを確認するには、次の Web サイトで入手可能なマニュアルを参照してください。
http://www.cisco.com/go/virtualized-collaboration
次の要件は、すべてのアプリケーションに共通です。追加の要件および制限事項については、各アプリケーションの製品マニュアルを参照してください。
https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/collaboration-virtualization-hardware.html
https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-software-requirements.html
(注) Unified CM およびその他の Unified Communications 製品を実行する仮想マシンの配置の選択は、パフォーマンスと可用性に影響することがあります。これらの詳細および UCS の導入における Unified Communications のその他の考慮事項については、次の Web サイトのマニュアルを参照してください。
http://www.cisco.com/go/virtualized-collaboration 。
エンドポイントの数は、システムでサポートする必要がある全体の負荷の重要な部分です。さまざまなタイプのエンドポイントがあり、タイプごとに Unified CM にかかる負荷は異なります。エンドポイントは次の要素で区別できます。
システムで設定されている各エンドポイントは、定義され登録されているだけのシステム リソース(スタティック メモリなど)を使用します。エンドポイントは、コール レートに基づいて CPU とダイナミック メモリを消費します。
エンドポイントは、Unified CM 内で実行されるサービスと対話するアプリケーション(CTI など)を実行することによって、Unified CM にさらに負荷をかけます。
表 25-4 に、異なるタイプの VM 設定でサポートされているエンドポイントの最大数を示します。これらはガイドラインとしての値であることに注意してください。導入に他のアプリケーションが含まれているために、システムによってはこれらの最大容量をサポートしない場合があります。
|
|
---|---|
1.これらの制限は、データベースで設定され、仮想サブスクライバ ノードごとに登録可能なエンドポイントの最大数を表します。メディア ターミネーション ポイント(ソフトウェアのハードウェア)または SIP トランクなどの他のすべての登録済みデバイスは、これらの制限に対してカウントされません。 |
Cisco Collaboration System Release(CSR)12. x では、次の VM 設定テンプレートの場合、Unified CM を導入するのに、すべての仮想ノードで vRAM のメモリを 2 GB 増やす必要があります。
Cisco Collaboration クライアントには、ユーザのデスクトップや他のアクセス デバイスで実行される、次のソフトウェア アプリケーションが含まれます。
Cisco Jabber は、Windows 用と Mac 用の Cisco Jabber クライアントおよび Microsoft Lync 用の Cisco UC Integration TM を含めて、これらのクライアントの基本となるサービス レイヤを提供します。
Jabber デスクトップ クライアントは、Unified CM でそれぞれが異なるリソースを使用する 2 つのオペレーション モードを提供します。Jabber クライアントは、ソフトフォン モードで動作する場合、SIP 登録されたエンドポイントとして機能し、システム内のエンドポイントの総数としてカウントされます。Jabber クライアントは、デスクフォン モードで動作する場合、CTI エージェントとして機能するため、Unified CM で CTI リソースを使用します。
ユーザは、いずれかのモードで動作するように Jabber ベースのクライアントを切り替えることができます。したがって、予想される使用方法に必要なシステム リソースを正しく把握する必要があります。
Jabber デスクトップ クライアントの導入では、さらに次の項目についても考慮する必要があります。
ソフトフォン モードで設定した場合は、Unified CM 呼制御の設定情報のために、Jabber デスクトップ クライアントのコンフィギュレーション ファイルが TFTP または HTTP 経由でクライアントにダウンロードされます。さらに、アプリケーション ダイヤル規則やディレクトリ ルックアップ規則があれば、それらも TFTP または HTTP を介して Jabber デスクトップ クライアントのデバイスにダウンロードされます。
Jabber デスクトップ クライアントは Cisco Unified CM Cisco IP Phone(CCMCIP)または UDS サービスを使用してユーザに関連付けられたデバイスについての情報を集め、この情報を使用してデスクフォン制御モードにあるクライアントが制御可能な IP Phone のリストを提供します。ソフトフォン モードの Jabber デスクトップ クライアントは、Unified CM への登録のデバイス名を検出するために CCMCIP または UDS サービスを使用します。
デスクフォン モードで設定した場合は、IP Phone の制御を可能にするために、ログインと登録の際に Jabber デスクトップ クライアントが Unified CM への CTI 接続を確立します。Unified CM は、最大 40,000 個の CTI 接続をサポートします。デスク フォン モードで動作する多数のクライアントがある場合は、CTI 接続を CTIManager サービスを実行中の Unified CM サブスクライバ全体に均等に分散させるようにします。このことは、それぞれ異なる CTIManager アドレスのペアを持つ複数の CTI ゲートウェイ プロファイルを作成し、CTI ゲートウェイ プロファイルの割り当てをデスクフォン モードを使用するすべてのクライアントに配分することで実現できます。
ボイスメール用に設定されている場合、Jabber デスクトップ クライアントは、メールストアとの IMAP または REST 接続を通じてボイスメールを更新および取得します。
クライアントのログインと認証、コンタクト プロファイル情報、および着信したコールの発信者 ID のすべてが、ローカル Jabber デスクトップ クライアント キャッシュに保存されていない限り、LDAP ディレクトリへの照会を通じて処理されます。
Jabber デスクトップ クライアントで使用できる複数のコンタクト ソースがあります。たとえば、UDS サービスは、クライアントが Unified CM ユーザ データベース内のコンタクトを検索するために使用できます。また、LDAP 統合を使用できます。要求されたコンタクトがローカル Jabber デスクトップ クライアント キャッシュで見つからない場合は、UDS または LDAP のコンタクト検索が実行されます。
Cisco Jabber クライアントのためのソリューションの設計とサイジングを検討する際は、すべてのコンポーネントについて、スケーラビリティに関する次のインパクトを考慮する必要があります。
Cisco IM and Presence サービス VM 設定テンプレートによって、クラスタでサポートできるユーザの数が決定されます。Cisco Jabber クライアントの導入は、クラスタ内の全ノードで、全ユーザに均等にする必要があります。これは、User Assignment Mode Sync Agent サービス パラメータを [balanced] に設定すれば、自動的に処理されます。
IMAP または IMAP-Idle の接続数は、メッセージング統合プラットフォームが決定します。
クライアントは、ネットワークで提供される会議サービスにアクセスできます。これらのサービスの同時参加者の数をサイジングする場合、これらのユーザを考慮する必要があります。詳細については、Cisco Rich Media Conferencingの章を参照してください。
Cisco Jabber クライアントは、iPhone、iPad、Android ではモバイル クライアントとして、Windows と Mac ではデスクトップ クライアントとしてサポートされます。Jabber クライアントを使用した導入のサイジングでは、ユーザがデスクトップ クライアントとモバイル クライアントの任意の組み合わせを使用している可能性があることに注意してください。ユーザに対してマルチ デバイス メッセージング(MDM)機能が有効になっている場合は、ユーザに関連付けられた各クライアントがデバイスと見なされるため、Unified CM テンプレートと IM and Presence VM テンプレートの両方で、サポートされるユーザの総数にカウントされます。
(注) ユーザがデスクトップ制御モードで 1 つの Jabber デスクトップ クライアントだけを使用している場合は、単一のデバイスと見なされます。これは、デスク フォン制御が CTI リソースと回線を利用するという事実によります。
Cisco Jabber クライアントは、Unified CM と連携します。そのため、Cisco Jabber クライアントの音声またはビデオ コールを開始した場合、Unified CM の現在の機能に関する次のガイドラインが適用されます。
デスクフォン モードでは、Cisco Jabber クライアントからのコールは Unified CM の CTI インターフェイスを使用します。したがって、呼処理の章に明記された CTI の制限を遵守してください。Unified CM クラスタのサイジングを行う際は、これらの CTI デバイスを含める必要があります。
Cisco Jabber クライアントは、Unified CM ロケーションまたは RSVP 経由で、音声またはビデオ コールに対してコール アドミッション制御を適用します。
Cisco Jabber クライアントの音声およびビデオ コールは、Unified CM リージョン設定によるコーデックの選択を利用します。
このマニュアルのシスコのボイス メッセージングの章の帯域幅の管理の項を参照してください。
Jabber クライアントを使用した導入のサイジングでは、ユーザがデスクトップ クライアントとモバイル クライアントを使用している場合や複数のモバイル クライアントまたはデスクトップ クライアントを使用している場合があることに注意してください。マルチ デバイス メッセージング(MDM)のユーザの方がこの機能を要求する可能性が高くなります。有効になっている場合は、ユーザに関連付けられた各クライアントがデバイスと見なされるため、Unified CM テンプレートと IM and Presence VM テンプレートの両方で、サポートされるユーザの総数にカウントされます。ユーザがデスクトップ制御モードで 1 つの Jabber デスクトップ クライアントだけを使用している場合は、単一のデバイスと見なされます。これは、デスク フォン制御が CTI リソースを利用するという事実によります。
Cisco WebEx Meetings Server は、仮想化環境内の音声、ビデオ、コラボレーションのセッションで WebEx 会議サービスを提供します。Cisco WebEx Meetings Server の詳細については、次の Web サイトで入手可能な『 Cisco WebEx Meetings Server Planning Guide and System Requirements 』を参照してください。
https://www.cisco.com/c/en/us/support/conferencing/webex-meetings-server/products-installation-and-configuration-guides-list.html
UDS は、Unified CM によって提供される包括的なサービス API です。UDS は、Jabber over Cisco Edge シリーズのデバイスが連絡先ソースの検索に使用できる連絡先ソース API を提供します。UDS の連絡先ソースを連絡先の解決に使用すると、システムにさらに負荷がかかります。
Cisco Unified CM 10. x は、Security Assertion Markup Language シングル サインオン(SAML SSO)機能を提供します。この機能を使用すると、ユーザが 1 度のログインで Cisco Collaboration ソリューション内のすべてのアプリケーションにアクセスできるため、エンド ユーザのエクスペリエンスが向上します。
SAML SSO はエンド ユーザのクレデンシャルや関連情報を使用して複数の Unified Communications のアプリケーション(Unified CM、Cisco Unity Connection、IM and Presence など)に利用するセキュアなメカニズムを提供します。SAML シングル サインオン機能が予想どおりに機能するように、ネットワーク アーキテクチャは各クラスタのユーザ数をサポートするように拡張する必要があります。
複数のアプリケーション(Unified CM、Cisco Unity Connection、IM and Presence など)への Unified Communications の導入の場合、すべての SAML 要求は ID プロバイダー(IdP)で認証して Cisco Jabber クライアントが正常にログインするようにする必要があります。
(注) SSO は SAML を使用して Unified Communications サービスでサポートされます。
普段の日の同じ時刻にシステムにログインするユーザの数がユーザがログインするための所要時間に影響する可能性があるため、システム サイジングでは SAML SSO ログインによる Cisco Jabber も考慮する必要があります。システムが 1 回につき処理できる要求の数の制限要因により、これが予期されます。Jabber ユーザの現在の最大ログイン レートは 1 秒あたり 2.7 ログイン(1 分あたり約 166 ログイン)または 1 時間内で 10,000 ログインです。これは、すべてのユーザとデバイスがすべてのノードに均一に分散されており、Cosco Jabber がソフトフォン モードにあることを想定しています。
Unified CM クラスタの安定性に影響する可能性がある相互依存変数(リージョン、ロケーション、ゲートウェイ、メディア リソースなど)が多数存在しています。したがって、必要な負荷の処理にリソースを使用できるように効果的に導入するには、ユーザの数、エンドポイント、1 時間あたりの 1 ユーザごとのコール数を特定することが重要です。
たとえば、5,000 人のユーザをサポートする冗長サブスクライバ ペアで、それぞれが 2 つのデバイス(デスク フォンとソフトフォン)に関連付けられている導入を検討します。この導入では、次の数の仮想マシンと VM 設定が必要です(高可用性と冗長性を想定)。
IM and Presence の 5k の VM 設定ペアは 5,000 人のユーザをサポートし、Unified CM の 10k の VM 設定のペアは 10,000 個のデバイスをサポートします。
エンド ユーザが Cisco WebEx Messenger サービスにログインして、プレゼンス、インスタント メッセージング、および Voice over IP(VoIP)コーリングなどの基本機能を利用するために必要なものは、56 kbps ダイヤルアップ インターネット接続だけです。ただし、小規模のオフィスやブランチ オフィスでファイル転送やスクリーン キャプチャなどの高度な機能を利用するには、512 kbps 以上のブロードバンド接続が必要です。
ネットワークとデスクトップの要件の詳細については、次の場所にある『 Cisco WebEx Messenger Administration Guide 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/webex-messenger/products-installation-guides-list.html
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 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 エンドポイント デバイスを含める必要があります。
サードパーティ製の Extensible Messaging and Presence Protocol(XMPP)クライアントは、WebEx Messenger サービスのプラットフォームと Cisco IM and Presence サービスの両方で使用される場合があります。これらのクライアントでは、音声、ビデオ、およびその他のコラボレーション機能は(インスタント メッセージングおよびチャットを除く)これらのクライアントでは、通常サポートされません。機能によっては、これらのクライアントが前述のサーバ上でサポートされるデバイス容量にカウントされる場合があります。
ユニファイド コミュニケーションのモビリティは多面的です。モバイル通信のさまざまな側面がそれぞれ Unified CM リソースを消費し、個別的にもシステム全体の一部としても考慮する必要があります。次のサイジングの考慮事項は、モビリティに適用されますが、Unified CM に影響を与えないモビリティの側面はここでは説明していないことに注意してください。
シングル ナンバー リーチ(以前の Mobile Connect)とエンタープライズの 2 ステージ ダイヤリング機能(Mobile Voice Access および Enterprise Feature Access)をサポートするための Unified CM のキャパシティにとって重要な、2 種類のパラメータがあります。これらの機能が適切に動作するには、モビリティを有効にし、シェアド ラインを使用したリモート接続先がユーザ用に定義されている必要があります。 表 25-5 に、各クラスの Unified CM のMV 設定で構成されるクラスタ内のユーザ、リモート接続先、モビリティ ID の各制限を示します。
|
|
|
---|---|---|
(注) モビリティ対応ユーザは、リモート接続先プロファイルを持ち、1 つ以上のリモート接続先またはデュアルモード デバイスおよびモビリティ ID が設定されているユーザとして定義されます。
システムに定義されているそれぞれのリモート接続先およびモビリティ ID は、いくつかの方法で Unified CM に影響します。
コール トラフィックの量と質は、Unified CM のサイジングにおいて非常に重要な要素です。
ハーフコール モデルでは、コールの発信と終端は異なるイベントと見なされるため、コールの種類を区別することが重要です。同じサブスクライバ ノードに登録されているエンドポイントの場合、これらのエンドポイント間のコールについてはその両半分をそのサブスクライバが処理します。同じクラスタ内の 2 つのサブスクライバ ノード間で発信されたコールについては、参加している各サブスクライバは、コールの発信または終端のいずれかを処理します。異なるクラスタに登録されているエンドポイント間で発信されたコールについては、各クラスタは各コールの片半分のみを処理します。クラスタに登録されているエンドポイントと PSTN 間で発信されたコールについては、PSTN ゲートウェイはコールの片半分を処理し、これらのコール タイプに基づいてゲートウェイをサイジングします。
コール トラフィックの正確なサイジングについては、次の要素を考慮する必要があります。
コールのタイプごとに、呼設定にかかる CPU リソースの量は異なります。最繁時呼数により、CPU 使用率が決まります。CPU 要件は、コール発信レートによって直接影響を受けます。ACHT によって、コールを持続時間中保持するためのダイナミック メモリ要件が決まります。ACHT が長くなるほど、割り当てたままにする必要があるダイナミック メモリが多くなるため、メモリ要件が大きくなります。
コール トラフィックは、他のソースで発生する可能性もあります。コールが転送でリダイレクトされるか、ボイスメールにリダイレクトされるたびに、CPU による処理が必要になります。1 つの電話番号が複数の電話機に設定されている場合は、その番号への着信コールをそれらすべての電話機に表示する必要があるため、コール セットアップ時に CPU 使用率が高くなります。高度な機能を使用する場合は、このテクノロジーを使用して発信されたコール数と、これらのコールのうちでコール品質のために PSTN にリダイレクトする必要があるコールの割合も考慮する必要があります。
Unified CM のダイヤル プランは、コール ルーティングおよび関連付けられるポリシーを決定する設定要素で構成されます。一般に、ダイヤル プラン要素は、Unified CM のスタティック メモリ領域を占有します。次のダイヤル プラン要素が、必要なメモリ量に影響を与えます。
Unified CM によってダイヤル プラン要素に適用される絶対的な制限はありませんが、使用可能な共有システム メモリの量が固定されています。
ほとんどのダイヤル プラン要素は、CPU 使用率に直接影響を与えません。ハント リストや回線グループなどのシェアド ラインは例外です。特定の電話番号を共有するすべてのエンドポイントにコールを表示する必要があるため、シェアド ラインごとにコール セットアップの CPU コストが増えます。
Unified CM のコンテキストでは、アプリケーションは、Unified CM によって提供される単純な呼処理を超える「追加」機能です。一般に、これらのアプリケーションでは、Computer Telephone Integration(CTI)が利用され、ユーザはコールの発信、終端、再ルーティング、モニタ、および処理を行うことができます。Cisco Unified CM Assistant、アテンダント コンソール、コンタクト センターなどの機能は、CTI を利用して動作します。
大規模な Unified CM の VM 設定は登録されているすべてのデバイスに対する CTI をサポートできますが、より小規模な VM 設定ではそこまで大きく拡張しません。 表 25-6 に、各 Unified CM の VM 設定でサポートされる CTI リソースの最大数を示します。これらの最大値は、次のタイプの CTI リソースに適用されます。
VM 設定用の CTI リソースの最大数がその VM 設定のエンドポイント キャパシティに対応することに注意してください。
Unified CM によって提供されるネイティブ アプリケーション以外に、Unified CM CTI リソースを使用するサード パーティ製アプリケーションも導入できます。CTI ポートとルート ポイントを数える場合は、サードパーティ アプリケーションも考慮してください。
|
|
---|---|
5,000 または 7,5002 |
|
2.Unified CM 10.5 以降のリリースでサポートされる CTI リソースは 7,500 個で、リリース 10.5 より前の Unified CM でサポートされる CTI リソースは 5,000 個です。 |
次の手順に従って、Unified CM クラスタに必要な CTI リソースの数を決定します。
クラスタ上で使用される予定の CTI デバイスの数を数えます。
表 25-7 に従って、クラスタ内のすべてのデバイスの CTI 回線係数を決定してください。
|
|
---|---|
(注) クラスタ内のデバイスの回線係数がばらついている場合は、システム内のすべての CTI デバイスでの平均回線係数を求めます。
表 25-8 に従って、クラスタ内のすべてのデバイスのアプリケーション係数を決定してください。
|
|
---|---|
手順 4 次の公式に従って、CTI リソースの必要な数を計算します。
CTI リソースの必要な数 =(CTI デバイスの合計数) ∗ (CTI 回線係数または CTI アプリケーション係数の大きい方)
例 1: デバイスごとの平均回線数が 9、平均アプリケーション数が 4 で、500 台の CTI デバイスが配置されています。 表 25-7 と 表 25-8 にリストされている係数に従うと、デバイスごとの回線数が 9 の場合の回線係数は 1.8、デバイスごとのアプリケーション数が 4 の場合のアプリケーション係数は 1.0 になります。これらの値を手順 4 の式に代入すると、次の値が得られます。
(500 CTI デバイス)∗({回線係数 1.8 またはアプリケーション係数 1.0} の大きい方)
(500 CTI デバイス)∗(回線係数 1.8)= 900 の総 CTI リソースが必要
例 2: デバイスごとの平均回線数が 5、平均アプリケーション数が 9 で、2,000 台の CTI デバイスが配置されています。 表 25-7 と 表 25-8 にリストされている係数に従うと、デバイスごとの回線数が 5 の場合の回線係数は 1.0、デバイスごとのアプリケーション数が 9 の場合のアプリケーション係数は 1.8 になります。これらの値を手順 4 の式に代入すると、次の値が得られます。
(2000 CTI デバイス)∗({回線係数 1.0 またはアプリケーション係数 1.8} の大きい方)
(2000 CTI デバイス)∗(アプリケーション係数 1.8)= 3,600 の総 CTI リソースが必要
例 3: デバイスごとの平均回線数が 2、平均アプリケーション数が 3 で、5,000 台の CTI デバイスが配置されています。 表 25-7 と 表 25-8 にリストされている係数に従うと、デバイスごとの回線数が 2 の場合の回線係数は 1、デバイスごとのアプリケーション数が 3 の場合のアプリケーション係数は 1 になります。これらの値を手順 4 の式に代入すると、次の値が得られます。
(5,000 CTI デバイス)∗({回線係数 1 またはアプリケーション係数 1} の大きい方)
(5,000 CTI デバイス)∗(回線係数またはアプリケーション係数 1)= 5,000 の総 CTI リソースが必要
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 へ与えるパフォーマンスの影響は通常最小限になります。
統合された Extension Mobility と Unified CM Assistant アプリケーションの IP Phone サービスを除き、IP Phone サービスは独立した Web サーバに存在する必要があります。Unified CM ノードで、Extension Mobility および Unified CM Assistant 以外の電話サービスを実行することはサポートされていません。
Extension Mobility(EM)は、次のようにシステム パフォーマンスに影響します。
表 25-9 に、VM 設定のタイプごとの 1 分あたりの EM と EMCC の最大ログイン数を示します。
|
|
|
|
|
|
---|---|---|---|---|---|
Cisco エクステンション モビリティ ログインおよびログアウト機能は、ログイン/ログアウトのクラスタ キャパシティを増加するためにサブスクライバ ノードのペアに分散できます。たとえば、EM 負荷が 7,500 人のユーザの VM 設定を持つ 2 つの仮想マシンの間で均等に分散される場合、1 分あたりのクラスタ全体のキャパシティは最大で 375 回の順次ログインまたはログアウト(あるいはその両方)になります。
(注) Cisco Extension Mobility サービスは、冗長性を目的として 3 つ以上のノードでアクティブにできますが、最大 2 つのサブスクライバー ノードまでが同時にアクティブにログイン/ログアウト処理することをサポートしています。
(注) EM セキュリティの有効化はパフォーマンスを低下しません。
EMCC ログイン/ログアウト処理は、クラスタ内 EM ログイン/ログアウトよりも多くの処理リソースを必要とします。したがって、サポートされるログイン/ログアウトの最大レートは EMCC では低くなります。クラスタ内 EM ログイン/ログアウトがない場合、Unified CM は 7,500 人のユーザまたは 10,000 人のユーザ用の VM 設定を使用して、仮想マシンごとに 1 分あたり 75 回の EMCC ログイン/ログアウトの最大レートをサポートします。ほとんどの導入では、クラスタ内ログイン/ログアウトとクラスタ間ログイン/ログアウトの組み合わせが発生します。より一般的なこのシナリオでは、EMCC ログイン/ログアウトの混合(ホーム クラスタまたは Visiting クラスタのどちらとして機能する場合でも)は、1 分あたり 40 回のモデルにする必要があります。同時にクラスタ内 EM ログインは、シングル EM サーバ ノードを使用する場合、185 回のログイン/ログアウトのモデルにする必要があります。クラスタ内 EM ログイン レートは、デュアル EM ノード構成で 7,500 人のユーザまたは 10,000 人のユーザ用のVM 設定を使用する場合、1 分あたり 280 回のログイン/ログアウトに増やすことができます。( 表 25-9 を参照)。
EMCC ログイン デバイス(Visiting 電話機)は、クラスタ内の他のエンドポイントの 2 倍のリソースを消費します。EMCC ログイン デバイスの最大サポート数はクラスタあたり 2,500 台ですが、これによっても、クラスタあたりの他のデバイスの理論的な最大数は 30,000 から 25,000 に減少します。クラスタ内の他の登録デバイス数を削減しても、EMCC ログイン デバイスの最大サポート数は 2,500 台のままです。
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 には、次の制限が適用されます。
Unified CM Assistant 最大でアシスタント 3,500 人とマネージャ 3,500 人(合計 7,000 人)のキャパシティを実現するには、複数の Unified CM Assistant サーバ プールを定義する必要があります(詳細については、Unified CM Assistantを参照してください)。
Cisco WebDialer を使用すると、ユーザは簡単にコールを開始できます。追加リソースが必要になるのはコールの開始時のみで、コール中は不要であるため、Unified CM に対する Cisco WebDialer の影響はかなり限定されます。コールが確立されると、Unified CM に対する影響は他のコールと同様になります。
WebDialer および Redirector サービスは Unified CM クラスタ内で複数のサブスクライバ ノードを実行でき、次のキャパシティがサポートされています。
次の一般式が WebDialer の 1 秒あたりのコール数の決定に使用できます。
(WebDialer のユーザ数)∗((平均 BHCA)/(3600 秒/時間))
この計算を行う場合、特に WebDialer サービスを使用した発信の、ユーザあたりの BHCA を適切に推定することが重要です。以下の例で、サンプルの組織に対して WebDialer デザイン計算式をどのように使用するかを示します。
会社 XYZ は、WebDialer サービスを使用してクリックコール アプリケーションを稼働させることを考えています。その事前のトラフィック分析結果は次の資料の通りです。
(注) これらの値は、WebDialer 配置のサイジングの演習を示すために使用した例です。ユーザのダイヤル特性は、組織によって大きく異なります。
10,000 ユーザで各 6 BHCA ならば、合計 60,000 BHCA です。ただし、WebDialer 配置のサイジングの計算は、発信コールのみ考慮します。このサイジングの例で最初の情報では、合計 BHCA の 50 % が発信です。これは、WebDialer を用いたクリックツーコールが利用可能なすべてのユーザで、合計 30,000 発信 BHCA という結果になります。
この発信数のうち、WebDialer サービスを使用して発信される割合は、組織によって変化します。この例の組織では、ユーザはいくつかのクリックコール アプリケーションを利用可能で、発信の 30 % が WebDialer を使用すると見積もられています。
(30,000 発信 BHCA)∗ 0.30 = 9,000 発信 BHCA が WebDialer を使用
9,000 BHCA の負荷をサポートするのに必要な WebDialer サーバ ノードの数を判別するには、この値を最繁時に維持する必要のある 1 秒あたりの Busy Hour Call Attempt(BHCA)に変換します。
(9,000 call attempts / 時間)∗(時間/3,600 秒)= 2.5 cps
各 WebDialer サービスは最大で 4 cps をサポートできます。したがって、この例では、WebDialer サービスを実行するため 1 つのノードを設定できます。これは、将来の WebDialer 拡張使用に利用できます。サーバ ノードの障害発生時に WebDialer キャパシティを維持するには、冗長性を提供する追加のバックアップ WebDialer サーバ ノードを配置する必要があります。
Attendant Console を使用した Cisco Unified CM の統合は CTI リソースを利用します。サーバ ベースのアテンダント コンソールはアテンダントがコールを送信した最後の 2,000 人のユーザをモニタするため、CTI リソースの使用率が増加します。さらに、各コールでは、グリーティングやキューイングなどに多数の CTI ルート ポイントとポートが使用されます。
Unified CM は、Cisco IP Voice Media Streaming Application(IPVMS)を提供します。これは、ソフトウェアだけで実行可能で、ハードウェア リソースを必要としない特定のメディア機能を提供します。Unified CM は、メディア ターミネーション ポイント(MTP)、会議ブリッジ、アナンシエータ(アナウンスの再生用)、または保留音ストリームのソースとして動作できます。Unified CM の機能は、Cisco Integrated Service Router(ISR)によって提供される同様の機能と比べて限定されますが、一般的には保留音ストリーム(ユニキャストとマルチキャストの両方)の主要なソースです。
Cisco IP Voice Media Streaming Application は、次の 2 つの方法のいずれかで導入できます。
共存導入では、Streaming Application は Unified CM ソフトウェアも実行している、クラスタ内の任意のサーバ ノード(パブリッシャまたはサブスクライバ)で実行されます。
(注) 「共存」という用語は、同じサーバ ノードまたは仮想マシンで複数のサービスまたはアプリケーションが実行されている状態を指します。
スタンドアロン導入では、Streaming Application は Unified CM クラスタ内の専用サーバ ノードで実行されます。Cisco IP Voice Media Streaming Application サービスは、サーバ ノードで使用できる唯一のサービスであり、サーバ ノードには、ネットワーク内のデバイスにメディア リソースを提供する機能だけがあります。
Cisco IP Voice Media Streaming Application は MTP、アナンシエータ、および会議機能を提供しますが、これらの機能を Cisco Integrated Service Router(ISR)に配置した方が拡張性が向上します。ただし、このアプリケーションの保留音機能は、簡単には外部ソースに配置できません。 表 25-10 に、これらの各サービスに設定できる最大値を示します。
|
|
|
|
---|---|---|---|
ここでは、 表 25-10 について説明します。
(注) 個別の ISR でサポートされている DSP の各メディア機能のキャパシティを計算するには、Cisco ISR の製品データ シートまたはメディア リソースの章を参照してください。
表 25-11 11 に、VM 設定と、各ノードがサポートできる同時保留音(MoH)ストリームの最大数を示します。実際の使用率がこれらの制限値を超えないようにしてください。MoH の最大ストリーム キャパシティに到達してさらに負荷が増えると、MoH の品質低下、MoH 動作の不安定化、または MoH 機能の損失を引き起こす可能性があります。さらに MoH ノード(共存および専用)が増えると、Unified CM のクラスタ MoH ストリームのキャパシティが増大します。
|
|
|
||
---|---|---|---|---|
|
|
|
|
|
|
表 25-12 に示すように、Unified CM 10.5(2) 以降、Unified CM クラスタでの保留音の最大 500 個の一意のオーディオ ソースを定義できるようになりました。 表 25-12 に示す最大オーディオ ソース キャパシティは、クラスタ内で使用される VM 設定のサイズと MoH サーバ タイプに基づいたクラスタ単位のものです。Unified CM クラスタに MoH ノードを追加すると、MoH ストリームのキャパシティのみが増加し、オーディオ ソースのキャパシティは増加しません。オーディオ ソースのキャパシティは、共存 MoH ノードからスタンドアロンの MoH ノードに移動することによってのみ増加させることができ、クラスタ全体のノード VM 設定サイズを大きくしたり、追加 Unified CM クラスタを増やしたりできます。
|
|
|
||
---|---|---|---|---|
|
|
|
|
|
表 25-11 および 表 25-12 に示したキャパシティの制限は、ユニキャスト、マルチキャスト、またはユニキャストとマルチキャストの同時ストリームに適用されます。
MoH オーディオ ソースとストリームの数を最大にするには、ソフトウェア MTP やソフトウェア会議ブリッジを無効にするなど、他の一部のメディア デバイスの数を減らす必要があります。Cisco IP Voice Media Streaming Application サービスは、すべてのメディア デバイスの最大設定を同時にサポートしません。システム リソース(CPU 使用率やディスク I/O など)をメディア デバイスでオーバーサブスクライブすると、システム全体のパフォーマンスに影響を及ぼします。IPVMS アラームは、メディア デバイスがプロビジョニングされたキャパシティを満たすことができない場合に発行されます。
ローエンド設定(1,000 ユーザまたは 2,500 ユーザの VM 設定)と中程度の呼処理と MoH の共存では、MoH は最大 500 のストリーム、100 の MoH オーディオ ソース、MTP での 48 ~ 64 のアナンシエータ ストリーム、デフォルト値に設定されるか無効になっている会議ブリッジに制限されます。
250 のオーディオ ソースの 750 MoH ストリームと 250 のアナンシエータ ストリームをサポートするには、1,000 人のユーザまたは 2,500 人のユーザ用の VM 設定の専用 MoH ノードが必要です。
最大 1,000 の MoH ストリーム、500 の MoH オーディオ ソース、および 750 のアナンシエータをサポートするには、最低でも 7,500 人のユーザ用の OVA 専用スタンドアロン MoH サーバが必要です。
MoH 用またはアナンシエータあるいはその両方の sRTP を使用すると、MoH 発信者の最大数が 25 % 減少します。この場合には、MoH およびアナンシエータ専用の IPVMS を推奨します。
Unified CM MoH サーバは 4 つのコーデック(G.711 ulaw、G.711 mulaw、G729a、および高帯域オーディオ)をサポートします。ユニキャスト MoH を使用すると、コール セットアップ時にコーデックがネゴシエートされるため、MoH ストリームの数は有効になっている MoH コーデックの数ではなく、ユニキャスト MoH で保留になっているエンドポイントの数によって異なります。マルチキャスト MoH の場合、各マルチキャスト対応オーディオ ソースが、有効になっている MoH コーデックごとに 1 つの MoH ストリームを生成します。たとえば、2 つのコーデックが有効になっていて、500 すべての MoH ソースがマルチキャスト対応である場合、エンドポイントが保留になっていなくても、1,000 のマルチキャスト MoH ストリームがアクティブになります。このシナリオでは、エンドポイントがユニキャスト MoH に配置されている場合は、MoH ストリームのキャパシティを増やす必要があります。
共存モードまたはスタンドアロン モードのどちらで導入したかにかかわらず、Cisco IP Voice Media Streaming Application は CPU とメモリ リソースを消費します。Unified CM の全体のサイジングでは、この影響を考慮する必要があります。
一般に、メディア リソースの使用率は、Unified CM で処理する必要がある BHCA に加算されると見なされます。
コール キューイングに送信できるメディア ストリームの最大数は、保留音ストリームと同じです。詳細については、保留音を参照してください。
有効なコール キューイングのハント パイロットの最大数は、Unified CM サブスクライバ ノードごとに 100 です。各ハント パイロットのキューの同時発信者の最大数は 100 です。すべてのハント リストに含まれるメンバの最大数は、コール キューイングがイネーブルのときには変更されません。
Unified CM データベース同期機能には、LDAP ストアから Unified CM パブリッシャ データベースへユーザ設定データ(属性)のサブセットをインポートするメカニズムがあります。ユーザ アカウントの同期が発生すると、各ユーザの LDAP アカウント情報が、そのユーザの特定の Unified Communications 機能を有効にするために必要な追加データと関連付けられることがあります。認証も有効な場合、パスワード確認のための LDAP ストアへのバインドに、ユーザのクレデンシャルを使用します。同期や認証が有効な場合に、エンド ユーザのパスワードは Unified CM データベースには格納されません。
ユーザ アカウント情報はクラスタ固有です。各 Unified CM パブリッシャ ノードは、このクラスタから Unified Communications サービスを受けているユーザの一意のリストを保持しています。同期アグリーメントはクラスタ固有で、各パブリッシャにはユーザ アカウント情報の独自コピーがあります。
Unified CM クラスタの最大ユーザ数は、クラスタのメンバー間で複製される内部コンフィギュレーション データベースの最大サイズによって制限されます。現在、設定または同期可能なユーザの最大数は 160,000 です。ディレクトリ同期のパフォーマンスを最適化するには、次の点を考慮してください。
(注) シスコは、上記で説明している制限までユーザ アカウントの同期をサポートしていますが、この制限を強制しているわけではありません。多くのユーザ アカウントを同期化すると、ディスク容量のスターベーション、データベース パフォーマンスの低速化、およびアップグレードの長時間化を招くことがあります。
呼処理サブスクライバの数が通常クラスタの最大値 4 ペアを超える場合、Unified CM クラスタはメガクラスタと見なされます。メガクラスタには、最大 8 ペアの呼処理サブスクライバと 1 つのメガクラスタに 21 未満のサーバ ノードを含めることができます。
たとえば、サーバの上限値の 21 を考慮して、パブリッシャ、TFTP、TFTP バックアップ、MoH、MoH バックアップ、8 個のプライマリ サーバおよび 8 個の バックアップサーバを含めることができます。
(注) IM and Presence はメガクラスタの導入の場合、サーバ上限値の 21 を考慮しません。
Cisco IM and Presence では VM 設定テンプレートを導入し、25,000 ユーザの VM 設定を使用してメガクラスタの導入と一致するようにしています。
Unified Communications の導入は、Unified CM メガクラスタで簡素化できる場合があります。このような導入では、次の上限が拡大されます。
ただし、クラスタ全体の定数は増えません。これらの中で重要なものは次のとおりです。
(注) メガクラスタの導入に関しては複雑な考慮事項が多数あるので、このような導入の実現を望むお客様は、シスコのアカウント チーム、シスコ アドバンスド サービス、または認定された Cisco Unified Communications パートナーに関与してもらう必要があります。
他のすべてのアプリケーションと同様、Cisco IM and Presence のサイジングは、次の方法で実行されます。
IM and Presence については、分析対象システムの次のシステム変数が関連し、正確なサイジングのために考慮する必要があります。
– ユーザがプレゼンス サービスを取得するために使用するクライアント
– ユーザの動作モード(インスタント メッセージ専用、または完全な Unified Communications ファシリティ)
– 連絡先リストのサイズと構成(クラスタ内、クラスタ間、およびフェデレーション)。Cisco IM and Presence のシステム アーキテクチャは、フル装備のシステムでユーザ 1 人あたり 75 件という連絡先リストの平均サイズに基づいています。システム全体ではユーザごとの連絡先リストのサイズが異なりますが、システムのユーザの多くが 75 件の連絡先という平均リスト サイズを超える場合はシステム パフォーマンスに影響します。デフォルトでは、連絡先リストの最大サイズは 200 です。一部のユーザの連絡先が 200 件を超えている場合は、IM and Presence クラスタの [プレゼンスの設定(Presence Settings)] を修正することで、この最大連絡先リスト サイズを変更できます。
– 最繁時におけるユーザごとのインスタント メッセージ(2 人のユーザ間で直接やり取り)の数
– チャット ルームの数、各チャット ルームのユーザ数、および各チャット ルームのユーザあたりのインスタント メッセージ数によるチャット サポート
システム要件を定量化したら、 表 25-13 のデータから必要な仮想マシンの数を特定できます。
|
|
---|---|
|
ユーザの連絡先とウォッチャの数はシステム パフォーマンスに影響します。重大な影響の可能性があるため、システム管理者は使用率を監視して、ユーザごとのクラスタ平均が 75 件の連絡先またはウォッチャ、あるいはその両方を超えないように確認する必要があります。
デフォルトでは、サービス パラメータは、ユーザごとに最大連絡先数は 200、ウォッチャ数は 200 に設定されます。このデフォルトのパラメータ設定は、多数の連絡先を必要とするユーザにオプションを提供するためのものです。IM and Presence ノードの 15,000 プレゼンスのユーザ全員が 200 件の連絡先とウォッチャをそれぞれに設定できるという意味ではありません。
IM and Presence のすべての導入で、ユーザごとの連絡先かウォッチャまたはその両方のサービス パラメータを 200 に設定している場合でも、そのクラスタ平均 75 を超えないようにすることを推奨します。
たとえば、15,000 のユーザ VM 設定テンプレートが 3 つのサブクラスタと 45,000 人のプレゼンス対応ユーザが含まれているフル装備のクラスタ内にあるとします。クラスタのすべてのユーザの連絡先の平均を 75 件に維持したい場合は、クラスタ全体で許容する連絡先の最大数は次のようになります。
(45,000 人のユーザ)∗(ユーザごとに 75 件の連絡先) = 3,375,000 件の連絡先が IM and Presence で許可
クラスタ内のすべてのユーザの連絡先の総数が 3,375,000 を超えない範囲で、クラスタ内の一部のユーザは最大 200 件の連絡先を設定すると同時に他のユーザの連絡先の件数は少なくなります。
また、5,000 人の IM and Presence ユーザを含む導入で、これらのユーザのうちの 50 人それぞれが 1,000 件の連絡先を必要としているものとします。この導入で許可された連絡先の最大数は次のようになります。
(5,000 人のユーザ)∗(ユーザごとに 75 件の連絡先) = 375,000 件の連絡先が導入全体で許可
50 人のヘビー ユーザには、(50 人のユーザ)∗(ユーザごとに 1,000 件の連絡先) = 50,000 件の連絡先。この場合は、(375,000 - 50,000)= 325,000 件の連絡先が残りの 4,950 人のユーザに使用できます。つまり、
325,000/4,950 = 残りの 4,950 人の各ユーザが使用できるのは平均で約 65 件の連絡先
Cisco IM and Presence の追加情報については、次の場所にある『 Compatibility Matrix for Cisco Unified Communications Manager and the IM and Presence Service 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-device-support-tables-list.html
Cisco IM and Presence 用に正式に定義された VM 設定は、次の Web サイトから入手できます。
https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-ucm-im-presence.html
Cisco IM and Presence サービスは、Unified CM のパフォーマンスに次のように影響します。
一般に、ユーザ同期(ワンタイム ヒットを除く)の影響および SIP トランクを介したプレゼンス情報の影響はごくわずかです。ただし、電話機の CTI 制御の影響は、CTI の制限で考慮する必要があります。
IM and Presence の VM 設定は、Unified CM の VM 設定とは異なります。IM and Presence のテンプレートはユーザ ベースですが、Unified CM のテンプレートはデバイス ベースです。たとえば、Unified CM の 10k ユーザの VM 設定で使用する 5k ユーザの IM and Presence の VM 設定では、5,000 人のユーザとそれぞれ 2 台のデバイスをサポートします。同じクラスタ内の IM and Presence ノードは、同じタイプの VM 設定を使用する必要があります。
(注) IM and Presence リリース 11.5 より前は、同時ユーザ ログイン数が最大で IM and Presence VM テンプレート容量の 80 % に制限されていました。IM and Presence 11.5 以降のリリースでは、プレゼンス ユーザの 100 % が同時に Jabber を介してログインできます。たとえば、45,000 人のプレゼンス対応ユーザの導入では、IM and Presence 11.5 より前のリリースが 36,000(45,000 の 80 %)件の同時ログインしかサポートしないのに対して、IM and Presence 11.5 以降のリリースは 45,000 人すべてのユーザの同時ログインをサポートします(ユーザ ログインあたり 1 つの Jabber クライアントのみとする)。また、この拡張機能は、許容される同時 Jabber ユーザ数を 20 % 増加させます。
Cisco IM and Presence は、集中型導入オプションをサポートしています。集中型 IM and Presence クラスタは、複数のリモート Unified CM クラスタ上でユーザにプレゼンス サービスを提供できます。ただし、すべてのリモート Unified CM クラスタ全体のユーザの総数が 75,000 人を超えないようにする必要があります(各ユーザが 1 つずつのクライアントを使用するものとする)。1 人のユーザが複数のクライアントを使用する場合は、この制限が下がります。
(注) 集中型 IM and Presence クラスタには、クラスタ内の全部で 7 つのサーバ(3 つの IM and Presence サブクラスタ ペア(6 サーバ)+ Unified CM パブリッシャ ノード)用の Unified CM パブリッシャー ノードが必要です。
集中型 IM and Presence クラスタの展開では、クラスタ内のすべての IM and Presence ノードに対して 25k ユーザ IM and Presence VM テンプレートを使用し、その集中型クラスタの Unified CM パブリッシャ ノードに対して 10k ユーザ Unified CM VM テンプレートを使用することをお勧めします。
Cisco Emergency Responder は、電話機のロケーションと電話機の接続先のアクセス スイッチ ポートを追跡します。電話機は、自動的に検出するか、手動で Emergency Responder に入力できます。 表 25-14 に、Emergency Responder をサポートする VM 設定とその最大キャパシティを示します。
(注) これらの制限は、スタンドアロンの Emergency Responder の導入に適用され、また、ネイティブ緊急サービスが使用されていないものと想定しています。
|
|
|
|
|
|
|
---|---|---|---|---|---|---|
Cisco Emergency Responder およびその他の Unified Communication 製品用に正式に定義された VM 設定は、次の Web サイトで入手できます。
https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-emergency-responder.html
Unified CM クラスタごとにアクティブにできる Emergency Responder は 1 つのみです。したがって、クラスタ内のすべての電話機に緊急対応できる十分なリソースがある OVA テンプレートを選択してください。
Emergency Responder のネットワークのハードウェアおよびソフトウェア要件の詳細については、次の Web サイトで入手可能な『 Cisco Emergency Responder Administration Guide 』を参照してください。
https://www.cisco.com/en/US/products/sw/voicesw/ps842/prod_maintenance_guides_list.html
Cisco Expressway の導入は、リモート エンドポイントの登録を含むコール制御のコンポーネントとしての Cisco Unified CM に依存します。このようなシステムのサイジングでは、実行する機能と Unified CM への影響を考慮する必要があります。
Cisco Expressway をサイジングする場合、通常は Cisco Expressway-C と Expressway-E のノードペアの必要数を決定する次のパラメータを検討する必要があります。
Expressway-C クラスタと Expressway-E クラスタは最大 6 つのノードをサポートします。
モバイルおよびリモート アクセスにはライセンスは特に必要ありませんが、Business-to-Business(B2B)コミュニケーションにはリッチ メディアのライセンスが必要です。リッチ メディア セッション形式のライセンスは、Expressway クラスタ全体で共有されます。クラスタ内の各 Expressway ノードに割り当てられたリッチ メディア セッションは、クラスタ内のすべてのノードで共有されるクラスタ データベースに供与されます。このモデルでは、いずれか 1 つの Expressway ノードが物理的なキャパシティよりも多くのライセンスを保持できます。
Cisco Expressway のキャパシティ プランニング
表 25-15 に、Cisco Expressway のプロキシ登録数と Cisco Expressway-C ノードと Expressway-E ノードのペアおよびクラスタのコール キャパシティを示します。
|
|
|
|
---|---|---|---|
クラスタごとに 2,5006 |
クラスタごとに 100 2 |
クラスタごとに 200 2 |
(注) 大規模 OVA テンプレートは、限られたハードウェアでのみサポートされます。詳細については、https://www.cisco.com/go/virtualized-collaboration にあるドキュメントを参照してください。
Cisco Expressway をクラスタ化する場合は、次のガイドラインが適用されます。
(注) Cisco Expressway クラスタと Cisco Unified CM クラスタ間には依存関係があります。また、Expressway のキャパシティ プランニングでも、関連または依存する Unified CM クラスタのキャパシティも考慮する必要があります。
サイジングの制限、キャパシティ プランニング、および導入に関する考慮事項など、Cisco Expressway のキャパシティ プランニングに関する考慮事項の詳細については、次の Web サイトで入手可能な Cisco Expressway の製品マニュアルを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/expressway-series/tsd-products-support-series-home.html
PSTN ゲートウェイは、Unified Communications システムと PSTN 間のトラフィックを処理します。トラフィック量は、リソース使用率(CPU とメモリ)およびゲートウェイに必要な PSTN DS0 回線を決定します。
PSTN トラフィックは Unified CM に登録されているエンドポイントによって生成されますが、音声自動応答装置(IVR)アプリケーションやコンタクト センター配置の一部などの他のソースがある場合もあります。
ゲートウェイは、リソース(CPU、メモリ、DSP など)を必要とする他の機能も実行できます。これらの機能には、メディア ターミネーション ポイント(MTP)、トランスコーディング、会議ブリッジ、RSVP Agent などのメディア処理が含まれます。
特に Cisco Integrated Service Router(ISR)に基づくゲートウェイは、VXML 処理エンジンとしての動作、境界要素としての機能、Cisco Unified Communications Manager Express または Survivable Remote Site Telephony(SRST)としての役割、または WAN エッジ機能の実行などのその他の機能を提供できます。ゲートウェイの負荷を計算するときは、これらのすべてのアクティビティを考慮する必要があります。
ゲートウェイの数を考慮するときは、物理ゲートウェイ サーバの地理的な配置も考慮する必要があります。PSTN アクセスが分散される配置モデルでは、ゲートウェイをグループとしてサイジングし、適切な負荷を各グループに割り当てる必要があります。
PSTN 回線は、システム内のすべてのユーザによって共有され、通常は PSTN 回線よりも多くのユーザが存在します。必要な回線の数は、コール トラフィックの項で説明されているトラフィック管理の原理を使用して予測されます(コール トラフィック)。
必要な PSTN 回線の数は、企業で受信および発信される外部トラフィックの量によって決まります。TDM ベースのシステムから変換する場合、お客様の多くは、IP ベースのコミュニケーション システムにおいても、それまでのシステムで使用していたのと同じ数の回線を使用し続けます。しかし、新たにトラフィック分析を行うことで、現在のトラフィックのレベルに対してシステムのプロビジョニングが過剰である(その結果、不要な回線にコストを費やしている)かどうかを明らかにすることができます。システムのプロビジョニングが不足している場合、許容できない数のコールのブロックや損失が発生します。この場合は回線数を増やすと状況が改善します。
ゲートウェイの DSP 要件は、PSTN 回線の数によって決まります。IP と TDM 音声間の変換を実行するには、DSP リソースが必要です(PSTN 回線は TDM エンコーディングを使用します)。
重要な入力の 1 つにブロック係数があり、ピーク トラフィック レベルで処理できない可能性があるコール試行の比率が決まります。ブロック係数を小さくとると、より多くのコール試行が成功しますが、システムはブロック係数が高い場合よりもより多くの回線を必要とします。
短い通話時間とバースト性のある着呼率は、PSTN ゲートウェイのトラフィック処理能力に影響を与えます。このような状況では、通話時間の長いコールを一定期間にわたって均等に受けるような場合に比べて、すべてのコールをタイムリーに処理するためにゲートウェイでより多くのリソースが必要となります。ゲートウェイにはこのようなトラフィック パターンを処理するさまざまな機能が装備されているため、ゲートウェイを選定する際は使用する環境を考慮して入念に検討する必要があります。ゲートウェイの中には、サポートする T1/E1 ポートの数が多い機種や、同時に着信した複数コールの処理能力が高い機種などがあります。
複数のコールがほぼ同時に着信する(つまり、着呼率が高い、またはバースト性がある)トラフィック パターンでは、適切なコール数/秒(cps)性能を持つゲートウェイが最も適しています。このような状況で、たとえば、Cisco 3945 ntegrated Services Router では 28 cps(一度にアクティブにできるコール数は 420 )を維持できます。
着呼率が安定したトラフィック パターンでは、通常、ゲートウェイが処理可能なアクティブ コールの最大数がより重要になります。このような状況で、たとえば保留時間が 180 秒のコールを使用すると、Cisco 3945 Integrated Services Router では 720 の同時アクティブ コール(着呼率は最大 4 cps)を維持できます。
これらの数値は、次の条件がすべて該当する場合を前提とします。
音声アクティビティ検出(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 IOS ゲートウェイは短時間のコールのバーストであれば処理できるようになっていますが、推奨される着呼率(コール数/秒)が継続的に超過するような状況はサポートされていません。
(注) ゲートウェイに未使用のハードウェア ポートがある場合は、そのポートを他のタスクに割り当てたくなるものです(たとえば、Cisco Communication Media Module(CMM)ゲートウェイで、トラフィック計算によって PSTN トラフィックに一部のポートしか使えないことがわかっている場合など)。しかし、残りのポートは必ず未使用のままにしておく必要があります。そうしないと、CPU がサポートされるレベルを超えて過負荷状態に陥ります。
Cisco IOS 音声ゲートウェイの CPU 使用率は、シャーシで有効にされているすべてのプロセスの影響を受けます。最も低レベルのプロセスの一部(IP ルーティングやメモリのデフラグなど)は、シャーシにライブ トラフィックがないときにも実行されます。
CPU 使用率が下がると、リアルタイムの音声パケットやコール セットアップ命令の処理に十分な CPU リソースを使用できるようになり、Cisco IOS 音声ゲートウェイのパフォーマンスが向上します。CPU 使用率を削減する手法のいくつかを 表 25-16 に示します。
この章では、すべてのゲートウェイ、その機能、および呼処理キャパシティの詳細については説明していません。Cisco 音声ゲートウェイの詳細については、次のマニュアルを参照してください。
https://www.cisco.com/c/en/us/products/unified-communications/communications-gateways/index.html
https://www.cisco.com/c/en/us/products/routers/3900-series-integrated-services-routers-isr/relevant-interfaces-and-modules.html
https://www.cisco.com/c/en/us/products/routers/2900-series-integrated-services-routers-isr/relevant-interfaces-and-modules.html
https://www.cisco.com/c/dam/en/us/products/collateral/routers/2800-series-integrated-services-routers-isr/product_data_sheet0900aecd8057f2e0.pdf
https://www.cisco.com/c/en/us/products/collateral/unified-communications/ios-gateways-session-initiation-protocol-sip/product_data_sheet0900aecd804110a2.html
https://www.cisco.com/c/en/us/products/collateral/unified-communications/vg-series-gateways/product_data_sheet09186a00801d87f6.html
https://www.cisco.com/c/dam/en/us/products/collateral/routers/2800-series-integrated-services-routers-isr/product_data_sheet0900aecd8057f2e0.pdf
ボイス メッセージングは、単独でサイジングするだけでなく、他の Unified Communications コンポーネント(主に Unified CM)に対する影響も考慮してサイジングする必要があるアプリケーションです。
合計ユーザ数は、ボイス メッセージング システムをサイジングする主な要因です。ボイス メッセージングのサイジングに影響を与えるその他の要因は次のとおりです。
表 25-17 に、各種ボイス メッセージング ソリューションが配置の拡張性要件に適合可能かどうかを示します。
表 25-18 に、Cisco Unity Connection を実行している各種 VM 設定のさまざまな機能の上限を示します。
|
|
|
|
|
---|---|---|---|---|
Cisco Unity Connection 用の正式の VM 設定の定義は、次の Web サイトから入手できます。
https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-unity-connection.html
Unified CM に対するボイス メッセージング システムの影響は、Unified CM で実行する必要がある追加処理を考慮して測定できます。これらの追加処理によるコール フローは、Unified CM のサイジング負荷を次のように増やします。
Cisco コラボレーティブ会議システムには、呼制御のためのコンポーネントとして Cisco Unified CM が含まれます。このようなシステムのサイジングでは、実行する機能と Unified CM への影響とを考慮に入れる必要があります。
そのような会議システムをサイジングする場合は、一般に次のパラメータを考慮してノードのタイプと数を決定する必要があります。
音声会議の平均使用時間(1 ヵ月あたりの平均時間(分))がわかっている場合は、 表 25-19 を使用して音声会議容量を計算します。
|
|
|
---|---|---|
平均的使用率の 20 ユーザごとに 1 ポートを割り当てるように検討する必要があります。使用頻度の高い会議ユーザの場合は、15 ユーザごとに 1 ポートを用意します。たとえば、6000 ユーザのシステムでは、300 音声ポートを用意する必要があります。ただし、ユーザの会議使用頻度が高い場合は、400 音声ポートを検討します。
一般的に、音声会議のピーク時の使用時間は、既存の音声会議システムのログまたはサービス プロバイダーの請求書から得られます。余裕をもった会議容量を確保するために、実際のピーク時使用時間よりも 30 % 多い容量を用意することを推奨します。
システム ベースライン ポートの要件について前述した方法による見積もり以外に、次の要素もシステム サイジングに影響します。
(1 日あたりの予想会議数)∗(予想ユーザ数)> ベースラインの 80 %
総ポート数には、上記要素のすべてとベースラインが含まれます。見積もったポート容量の合計がサポートされる最大ポート数の 80 % を超える場合、会議システムの容量拡張を検討してください。
ビデオ会議のキャパシティを計算するために次の 3 つの方法を推奨します。
40 人のナレッジ ワーカごとに 1 つのビデオ ユーザ ライセンスを用意することを推奨します。
既存の音声ユーザ ライセンス数の 17 ~ 25 % の範囲のビデオ会議容量を用意することを推奨します。この割合は、ビデオ会議に関するビジネス要件と会議システムの規模によって異なります。
Unified CM に対する影響は、会議システムによって生成される追加分のコール トラフィックに基づいて分析できます。最大の影響は、会議ユーザが通常 0 分または 30 分にスケジュールされる会議にダイヤルインしたときに発生します。会議の開始後数分以内に大量のコール トラフィックが発生し、その数分間の Unified CM 上の負荷が増大するため、適切に設計する必要があります。さらに、会議ユーザに PSTN または他のクラスタからの発信者が含まれている場合、それらのパラメータも考慮してゲートウェイに対するその影響を測定する必要があります。
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 の詳細については、次の場所にある『 Cisco WebEx Meetings Server Planning Guide and System Requirements 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/conferencing/webex-meetings-server/products-installation-and-configuration-guides-list.html
サイジング ツールは、次の入力を使用してシステム容量を計算します。
ナレッジ ユーザの数は、会議システムにアクセス(会議を開始または会議に参加するため)できる従業員の集合として定義されます。
多くのナレッジ ユーザは、使用可能な会議ポートを共有します。任意の時点で、一部のユーザのみ会議コールでアクティブであることが前提とされています。この割合に基づいて、これらのユーザをサポートするのに必要な会議ポートの数を見積もることができます。
サイジング ツールは、低い使用率(一度に 3.3 % のユーザがアクティブ)、平均的な使用率(5 % がアクティブ)、および高い使用率(10 % がアクティブ)を定義します。そのため、平均的な使用率で動作するシステムは、高い使用率のシステムに比べて 2 倍のユーザをサポートします。
1 ヵ月あたりのユーザ時間(分)は、すべてのポートにおける月のアクティブ会議の合計時間(分)です。この値は、数千分で表されます。この要因は、記録サーバのサイズを計算する際に重要となります。
実際のピーク使用率は、システムの同時ユーザの最大数として定義されます。この数は、必要な会議ポート数を決定する際に重要となります。シスコは、ピーク使用時に十分な会議ポートが使用可能であることを保証するため、実際のピーク使用率よりも 30 % 多くのユーザを処理するのに十分な容量のプロビジョニングを推奨しています。
ビデオおよび高画質ビデオでの会議の割合は、システムによって要求されるネットワーク帯域幅に影響を与えます。最大 50 % のユーザが高画質ビデオを使用できます。
異なるコール タイプには、異なる Unified CM リソースが必要です。Unified CM の影響を正確に評価するため、ツールは次のコール タイプの評価を要求します。
– エンタープライズ IP Phone を介して着信する会議コールの割合。このコール レッグは Unified CM によって処理されるため、Unified CM キャパシティに影響を与えます。
– PSTN ゲートウェイのサイジングに影響を与える外部コール レッグの割合。
外部ユーザがシステムにアクセスする必要がある場合は、追加の仮想マシンを設定してリバース プロキシ機能を提供します。システムが内部ユーザだけを対象としている場合は、これらの追加の仮想マシンは必要ありません。
ディザスタ リカバリでは、セカンダリ データセンターにコールドスタンバイ システムを設定できます。プライマリ システムがハイ アベイラビリティで設定されている場合、ディザスタ リカバリ システムに対してハイ アベイラビリティを設定するように選択することもできます。
システムは、非冗長モードまたはハイ アベイラビリティ(HA)モードで設定できます。HA モードでは、クラスタは 1 つ以上のバックアップ サーバでプロビジョニングされます(システム サイズに応じて特定の設定)。
Cisco WebEx Meetings Server は、 表 25-20 に示すよう、4 つのシステム サイズで提供されます。システム サイズは、システムの同時ユーザの最大数で表されます。最大同時ユーザは、所定の時間に会議コールに参加できるユーザの最大数を定義します。
|
|
|
|
|
---|---|---|---|---|
最大 5 % のポート(または 10 % の会議)を録画できます。録画された会議を保存するには、十分なサイズの NFS 搭載ハード ドライブをプロビジョニングする必要があります。50 ~ 100 MB のサイズのファイルが 1 つの会議で生成されます。
LAN および WAN で必要な帯域幅を見積もるため、サイジング ツールは次の前提を行います。
そのため、LAN の必要な帯域幅(Mbps)は 0.8 * (ポート数)であり、WAN は 0.2 * (ポート数)です。
Cisco Prime Collaboration は、Cisco Unified Communication と TelePresence システムを試験、導入、およびモニタリングする統合ツール セットを提供します。Cisco Prime Collaboration には、Prime Collaboration Provisioning、Prime Collaboration Assurance、Prime Collaboration Analytics が含まれます。
これらのアプリケーションは仮想マシン上で実行されます。Cisco Prime Collaboration Provisioning は独自の仮想マシン上で実行され、Cisco Prime Collaboration Assurance と Cisco Prime Analytics は同じ仮想マシン上で実行されます。これらのアプリケーションの仮想マシン サイジングは比較的単純で、管理するエンドポイントまたはネットワーク デバイスの数に直接依存します。
Cisco Prime Collaboration Provisioning は最大 150,000 のエンドポイントをサポートし、単一のマシン(最大 10,000 のエンドポイントの場合)または 2 台のマシン(10,000 以上エンドポイントの場合)のいずれかに実装されます。
さまざまなレベルのパフォーマンスに必要な仮想マシン リソースについては、次の場所にある『Cisco Prime Collaboration のインストール ガイドとアップグレード ガイド』の最新版に記載されています。
https://www.cisco.com/c/en/us/support/cloud-systems-management/prime-collaboration/products-installation-guides-list.html
Cisco Prime Collaboration Assurance は、ルータやスイッチなどの電話やその他のネットワーク デバイスを管理できます。これは単一マシン構成で動作し、最大 150,000 台の電話機をサポートします。
さまざまなレベルのパフォーマンスに必要な仮想マシンのリソースについては、次の Web サイトから入手可能な『 Cisco Prime Collaboration Quick Start Guide 』の最新バージョンを参照してください。
https://www.cisco.com/c/en/us/support/cloud-systems-management/prime-collaboration/products-installation-guides-list.html
Cisco Prime Collaboration Analytics は、Cisco Prime Collaboration Assurance と同じ仮想マシン上で実行し、音声品質を測定するために Cisco Network Analysis Module(NAM)と連携して動作します。
さまざまなレベルのパフォーマンスに必要なハードウェア リソースについては、次の Web サイトから入手可能な『 Cisco Prime Collaboration Data Sheet 』の最新バージョンを参照してください。
https://www.cisco.com/c/en/us/products/cloud-systems-management/prime-collaboration/datasheet-listing.html
次の製品はサイジング ツールに含まれていませんが、次の項でこれらの製品をサイジングする方法について説明します。
Cisco Unified Communications Manager Express(Unified CME)は、Cisco IOS サービス統合型ルータ(ISR)プラットフォーム(ローエンドの Cisco 881 ISR からハイエンドの Cisco 3945E ISR 2 まで)のいずれかで実行されます。これらの各ルータでは、サポートできる電話機の数に上限があります。これらのプラットフォームが呼処理を実行するための実際のキャパシティは、IP ルーティング、ドメイン ネーム システム(DNS)、Dynamic Host Control Protocol(DHCP)などのほかに他に実行する機能によって制限されることがあります。
Unified CME は、単一の Cisco IOS プラットフォーム上で最大 450 エンドポイントをサポートできます。ただし、各ルータ プラットフォームのエンドポイントのキャパシティは、システムのサイズによって異なります。Unified CME は Cisco Collaboration Sizing Tool ではサポートされないため、次の場所にある Unified CME の製品データ シートに記載されているキャパシティ情報に従う必要があります。
https://www.cisco.com/c/en/us/products/unified-communications/unified-communications-manager-express/datasheet-listing.html
Cisco Business Edition は、音声、ビデオ、モビリティ、メッセージング、会議、インスタント メッセージとプレゼンス、コンタクト センター アプリケーション用のプレミアム サービスがプリロードされ、パッケージ化されたコラボレーション ソリューションです。
Cisco Business Edition 4000(BE4000)は、Business Edition ファミリに新しく加えられたものです。BE4000 は、Cisco Unified Communication Manager Express が組み込まれており、中小の単一サイト導入と、リモート サイトでのローカル呼処理が必要な導入に呼処理サービスを提供します。
BE4000 は、それぞれのデバイスにテレフォニーとボイスメール ポートがライセンスされている最大 200 台の音声テレフォニー デバイスに音声テレフォニーおよびボイスメール サービスを提供する、専用のクラウドマネージ型プラットフォームです。
BE4000 は、次の最大 200 ユーザをサポートします。
Cisco Unified Business Edition 6000 と 7000 の両方に、形式を選択するためのプラットフォーム モデル オプションが備わっています。
Cisco Business Edition 6000 は、次の 3 つのハードウェア プラットフォーム オプションで入手できます。
Cisco Business Edition 6000 ソリューションの詳細については、 https://www.cisco.com/go/be6000 を参照してください。
Cisco Business Edition 7000 は、次の 2 つのハードウェア プラットフォーム オプションで入手できます。
Cisco Business Edition 7000 ソリューションの詳細については、 https://www.cisco.com/go/be7000 を参照してください。
この項では、Cisco Business Edition 6000H を例として使用してキャパシティを計算します。ただし、この項の情報は BE6000M とキャパシティが小さい 750 BHCA の BE6000S にも適用されます。
前述のとおり、Business Edition 6000H は、最大 5,000 BHCA をサポートします。システム使用の計算では、Cisco Business Edition 6000 のオーバーサブスクリプションを避けるため、この BHCA 最大数を超えないようにします。任意の電話機の BHCA が 4 BHCA を超えたときに、BHCA に対する配慮が必要になります。真の BHCA 値は、最繁時における電話機の使用状況の基準測定を実施することによってのみ、決定されます。この使用状況を基準なしで見積もった場合は特に注意が必要です。
デバイスは、この見積もりの目的に沿って 2 つの主なカテゴリーに分けられます。すなわち、電話デバイスとトランク デバイスです。
電話デバイスは、単一のコール可能なエンドポイントです。これには、Cisco Unified IP Phone 8800 シリーズ、またはその他のコラボレーション音声およびビデオ エンドポイントなどの単体のクライアント デバイス、Cisco Jabber などのソフトウェア クライアント、アナログ電話機ポートや H.323 クライアントなどが含まれます。Cisco Business Edition 6000 は BE6000S の最大 300 のエンドポイント、中密度のサーバでは最大 1,200 のエンドポイント、高密度サーバでは最大 2,500 のエンドポイントをサポートしますが、上記で説明するように、実際のエンドポイント キャパシティはシステムの合計 BHCA によって異なります。
トランク デバイスは、複数のコールを複数のエンドポイントまで伝送します。これには、SIP トランクまたはゲートキーパー制御 H.323 トランクなどのトランクまたはゲートウェイ デバイスを使用できます。Business Edition 6000 は、H.323 トランク、SIP トランク、および MGCP トランクやゲートウェイならびにアナログ ゲートウェイのようなクラスタ間トランキングをサポートします。他のプロトコルではなく、SIP トランクの使用を推奨します。
BHCA を見積もる方法は、両方のタイプのデバイスでほとんど同じですが、一般に、トランク デバイスは、外部のユーザ グループ(PSTN または他の PBX 内線)にアクセスするためにより大きなエンドポイントのグループで使用されるため、BHCA が高くなります。
BHCA に基づく使用状況の特性を参照してデバイス グループ(電話デバイスまたはトランク デバイス)を定義してから、各デバイス グループの BHCA を加算して、システムの総 BHCA を求めることができます。これによって、サポートされる最大数の 5,000 BHCA を超えないことを常に確認します。
たとえば、4 BHCA の 100 台の電話機と 12 BHCA の 80 台の電話機の総 BHCA は、次のように計算できます。
4 BHCA の 100 台の電話機:100 ∗ 4 = 400
12 BHCA の 80 台の電話機:80 ∗ 12 = 960
すべての電話機の総 BHCA = (100 ∗ 4) + (80 ∗ 12) = 1,360 BHCA
トランク デバイスの場合は、デバイスで処理されるコールのうち PSTN との間で発着信する割合がわかっていれば、BHCA を計算できます。この例では、すべてのデバイス コールの半分が PSTN との間で発着信している場合、デバイス BHCA(この場合は 1360)のゲートウェイに対する実効値は、1360 の半分、つまり、680 BHCA になります。したがって、この例での電話デバイスとトランク デバイスに関する総システム BHCA は次のようになります。
総システム BHCA = 1,360 + 680 = 2,040 BHCA
複数の電話機でシェアド ラインにしている場合は、シェアド ラインを設定している電話機ごとに 1 つずつのコール レッグ(コールごとに 2 コール レッグ)を BHCA に含める必要があります。複数のデバイス グループにまたがるシェアド ラインは、そのグループの BHCA に影響します。つまり、シェアド ラインに対する 1 つのコールが、回線インスタンスあたり 1 つのコール レッグ、つまり、1 コールの半分として計算されます。BHCA が異なる複数の電話機グループがある場合は、次の方法で BHCA 値を計算します。
シェアド ライン BHCA = 0.5 ∗(シェアド ライン数)∗(1 回線あたりの BHCA)
たとえば、次の特徴を持つ 2 つのユーザ クラスがあるとします。
また、1 グループあたり 10 本のシェアド ラインがあるとして、次の BHCA 値に加算します。
8 BHCA のグループ内の 10 本のシェアド ライン = 0.5 ∗ 10 ∗ 8 = 40 BHCA
4 BHCA のグループ内の 10 本のシェアド ライン = 0.5 ∗ 10 ∗ 4 = 20 BHCA
この場合のすべての電話デバイスに関する総 BHCA は、シェアド ラインの BHCA の合計に加算された電話機グループごとの BHCA の合計になります。
800 + 600 + 40 + 20 = 1,460 総 BHCA
上記の各例の総 BHCA は、システムの最大数である 5,000 BHCA を下回っているため、許容範囲に含まれることに注意してください。
Business Edition 6000 でシングル ナンバー リーチ(SNR)用に Cisco Unified Mobility を使用している場合、リモート接続先およびモビリティ ID に転送されたコールまたはオフシステム電話番号が BHCA に影響することに留意してください。アプライアンスがオーバーサブスクライブするのを防ぐには、この SNR リモート接続先またはオフシステム電話の BHCA を考慮する必要があります。これらの SNR 機能の BHCA を計算するには、Cisco Unified Mobility のキャパシティ プランニングを参照して、その値を総 BHCA 値に加算します。
(注) Secure RTP(SRTP)を使用したメディア認証と暗号化は、システム リソースとシステム性能に影響を与えます。メディア認証または暗号化の使用を検討している場合は、この事実に留意して適切な調整を行ってください。通常、セキュリティに対応していない 100 台の IP Phone は、セキュリティに対応した 90 台の IP Phone と同じ影響をシステム リソースに与えます(10 対 9 の割合)。
Cisco Business Edition 6000 について考慮するキャパシティ プランニングのもう 1 つの側面は、コール カバレッジです。特殊なデバイス グループを作成し、特定のサービスの着信コールを複数のルール(トップダウン、循環ハント、最長アイドル時間、またはブロードキャスト)に従って処理できます。これは、Cisco Business Edition 6000 のハント グループまたは回線グループの設定で実現されます。回線グループの分配アルゴリズムにブロードキャスト(全メンバーを呼び出す)を用いる場合には、この要素によっても BHCA が影響を受けます。Cisco Business Edition 6000 でブロードキャスト分配アルゴリズムが必要な場合は、1 つのハント グループまたは回線グループのメンバー数を 3 以下にすることを推奨します。システムの負荷によっては、この実施によってシステムの BHCA が大きく影響され、プラットフォームのリソースがオーバーサブスクライブする可能性があります。ブロードキャストの分配アルゴリズムを使用するハント グループまたは回線グループの数も 3 以下に制限する必要があります。これらはシステム BHCA のオーバーサブスクリプションを回避するために開発されたベスト プラクティスの推奨事項です。システム全体の BHCA キャパシティを超えない限り、配置内でのこれらの推奨事項の超過はサポートされます。
Unified CM クラスタ内に異なる種類のハードウェア プラットフォームを混在させることも可能です。ただし、すべての VM 設定がすべてのサーバ プラットフォームでサポートされているわけではないため、ハードウェア プラットフォームおよび Business Edition プラットフォームの混在の項で説明するように、VM 設定の混在がクラスタ全体のキャパシティに影響します。
Cisco Business Edition 6000 システムでの Cisco Unified Mobility ユーザの容量は、サーバのハードウェアではなく、ユーザあたりのリモート接続先数および Unified Monbility を有効にしているユーザの BHCA にのみ依存します。したがって、Cisco Business Edition 6000 でサポートされるリモート接続先数は、これらのユーザの BHCA に直接依存します。
設定された各リモート接続先またはモビリティ ID は、BHCA に影響を与える可能性があります。ユーザに設定されているリモート接続先またはモビリティ ID ごとに、追加のコール レッグが 1 つずつ使用されます。各コールは 2 つのコール レッグで構成されているため、1 つのリモート接続先の呼び出しが 1 つのコールの半分に相当します。そのため、リモート接続先の合計 BHCA は次の式で計算できます。
5 BHCA ごとに 300 人のユーザがいて、それぞれのユーザに 1 つずつのリモート接続先またはモビリティ ID(全部で 300 のリモート接続先およびモビリティ ID)が割り当てられたシステムがあるとすると、リモート接続先およびモビリティ ID の合計 BHCA の計算は次のようになります。
リモート接続先およびモビリティ ID の合計 BHCA =
0.5 ∗(300 ユーザ)∗ (ユーザあたり 1 リモート接続先またはモビリティ ID)∗ (ユーザあたり 5 BHCA)=
750 BHCA
この例でユーザの合計 BHCA は(300 ユーザ)∗(ユーザあたり 5 BHCA)、つまり 1,500 です。この値にリモート接続先の合計 BHCA である 750 を加算すると、システムの合計 BHCA 2,250(ユーザの合計 BHCA 1,500 + リモート接続先およびモビリティ ID BHCA の合計 750)が得られます。
上記の例のシステムで他のアプリケーションや追加の BHCA 変数が使用されている場合は、容量はさらに制限される可能性があります(詳細については、前項を参照してください)。
Cisco Business Edition 6000 キャパシティ プランニングの詳細については、他の製品情報と同様に、Cisco Business Edition 6000 に関する次の製品マニュアルを参照してください。