Cisco Collaboration 9.xソリューション リファレンス ネットワーク デザイン(SRND)
コラボレーションの配置モデル
コラボレーションの配置モデル
発行日;2013/10/03 | 英語版ドキュメント(2013/09/09 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 30MB) | フィードバック

目次

コラボレーションの配置モデル

この章の新規情報

Unified Communications および Collaboration の配置

配置モデル アーキテクチャ

Unified Communications 配置モデルの概要

配置モデルのハイ アベイラビリティ

配置モデルのキャパシティ プランニング

共通の設計基準

サイトベースの設計ガイドライン

サービスの集中化

サービスの分散化

サービスのインターネットワーク化

Unified Communications サービスの地理的多様性

キャンパス

キャンパス モデルのベスト プラクティス

集中型呼処理を使用するマルチサイト

集中型呼処理モデルのベスト プラクティス

リモート サイトのサバイバビリティ(呼処理の継続)

SRST モードの UnifiedCME

SRST モードの UnifiedCME のベスト プラクティス

SRST ルータのベスト プラクティス

Cisco Unified Survivable Remote Site Telephony Manager

集中型呼処理のバリエーションとしての Voice Over the PSTN

分散型呼処理を使用するマルチサイト

分散型呼処理モデルのベスト プラクティス

分散型呼処理配置のダイヤル プラン集約プラットフォーム

分散型呼処理モデルのリーフ ユニファイド コミュニケーション システム

UnifiedCM Session Management Edition

UnifiedCM Session Management Edition を配置する状況

UnifiedCM Session Management Edition と標準の UnifiedCM クラスタの相違

デュアル呼制御配置の設計上の考慮事項

デュアル呼制御配置のコール アドミッション制御に関する考慮事項

分散サードパーティ呼制御によるマルチ サイト集中型 Unified CM 配置

集中型サードパーティ呼制御によるマルチ サイト集中型 Unified CM 配置

デュアル呼制御配置におけるダイヤル プランに関する考慮事項

IP WAN を介したクラスタリング

WAN の考慮事項

クラスタ内通信

UnifiedCM パブリッシャ

コール詳細レコード(CDR)およびコール管理レコード(CMR)

遅延のテスト

エラー率

トラブルシューティング

ローカル フェールオーバー配置モデル

ローカル フェールオーバーに対する UnifiedCM のプロビジョニング

ローカル フェールオーバー用のゲートウェイ

ローカル フェールオーバー用のボイスメール

ローカル フェールオーバーに対する保留音とメディア リソース

リモート フェールオーバー配置モデル

Cisco Business Edition 6000 の WAN を介したクラスタリング

仮想サーバでの Unified Communications の配置

Cisco Unified Computing System

Cisco UCS B シリーズ ブレード サーバ

Cisco UCS 5100 シリーズ ブレード サーバ シャーシ

CiscoUCS 2100 および 2200 シリーズ ファブリック エクステンダ

CiscoUCS 6100 および 6200 シリーズ ファブリック インターコネクト スイッチ

CiscoUCS Manager

ハイパーバイザ

ストレージ エリア ネットワーキング

B シリーズ ブレード サーバ上で仮想 Unified Communications アプリケーションを実行する場合の設計上の考慮事項

ブレード サーバ

ハイパーバイザ

SAN およびストレージ アレイ

CiscoUCS C シリーズ ラックマウント サーバ

C シリーズ ラックマウント サーバ上で仮想 Unified Communications アプリケーションを実行する場合の設計上の考慮事項

仮想サーバが配置モデルに及ぼす影響

Service Advertisement Framework の呼制御ディスカバリ(CCD)を使用したコール ルーティングおよびダイヤル プラン配信(SAF)

SAF でアドバタイズできるサービス

SAF CCD 配置の考慮事項

Cisco Intercompany Media Engine

コラボレーションの配置モデル

この章では、Cisco Unified Communications システムの配置モデルについて説明します。

この章の旧版では、Cisco Unified Communications Manager(Unified CM)向けの呼処理配置モデルのみに基づいて、配置モデルを説明しました。この章の最新版では、単なる呼処理サービスではなく多くの機能を備えた Cisco Unified Communications および Collaboration System 全体の設計ガイドラインを提供します。

以前のリリースの Cisco Unified Communications での設計ガイドラインについては、次の Web サイトで入手可能な Cisco Unified Communications ソリューション リファレンス ネットワーク デザイン(SRND)のマニュアルを参照してください。

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

この章の新規情報

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

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

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

Unified CM クラスタ間で許可される最大遅延の変更

「WAN の考慮事項」

2013 年 5 月 24 日

Cisco IOS 拡張 ping の例の小規模な変更

「遅延のテスト」

2013 年 5 月 24 日

サービスとしてのクラウド ベースの Unified Communications

「Unified Communications および Collaboration の配置」

2013 年 4 月 2 日

Cisco TelePresence Video Communication Server(VCS)および VCS Expressway

この章の各項で説明

2013 年 4 月 2 日

次のトピックに関する詳細の削除:

Cisco Unified Computing System(UCS)

Service Advertisement Framework(SAF)Call Control Discovery(CCD)

Cisco Intercompany Media Engine(IME)

これらのトピックの詳細情報については、次の URL にある『 Cisco Unified Communications System 9.0 SRND 』の「 Unified Communications Deployment Models 」の章を参照してください。

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/models.html

2013 年 4 月 2 日

Cisco Unified Survivable Remote Site Telephony(SRST)Manager

「Cisco Unified Survivable Remote Site Telephony Manager」

2012 年 8 月 31 日

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

この章の各項で説明

2012 年 6 月 28 日

Unified Communications および Collaboration の配置

今から 10 年から 15 年前、初めて Voice over IP(VoIP)と IP テレフォニーが公開されてから、現在の Unified Communications および Collaboration に至るまで、ユーザは多様な機能を備えたさまざまなデバイスを駆使して、いろいろな方法でコミュニケーションを図ることができるようになりました。現在、Unified Communications および Collaboration システムは、IM and Presence 向け Jabber クライアントのみの導入から開始し、必要に応じて段階的に音声、ビデオ、Web 会議、モバイル ボイス アプリケーション、ソーシャル メディア、ビデオ会議とテレプレゼンスを追加できます。Unified Communications ユーザ単位で使用可能なデバイスの数と、コミュニケーションの形態が増加するにつれ、Unified Communications アーキテクチャを緊密に統合する必要が生じました。ユーザは通信の形式に関係なく、単一のユーザ名で識別したいと考えるため、急速に変わり、拡大を続け、より URI 中心となる、Unified Communications 環境の要件に対応するため、シスコの Unified Communications および Collaboration アーキテクチャは柔軟性とスケーラビリティを備えています。

サービスとしてのコラボレーション

Unified Communications がより一般的になるにつれて、「サービスとしてのコラボレーション」と、従来型のオンプレミスの Unified Communications および Collaboration の配置に対する要求に対処するため、Cisco Unified Communications および Collaboration の配置オプションが増加しました。この章の主な焦点は、オンプレミスの Unified Communications および Collaboration の配置の設計ガイドラインを読者に提供することですが、マネージド クラウド ベースの Unified Communications および Collaboration サービスとして配置できる Cisco Hosted Collaboration Solution(HCS)や Cisco WebEx などのシステムについても説明します。オンプレミス、クラウド ベース、ハイブリッドのいずれのソリューションを使用するかは、多くの要因により判断されます。たとえば、クラウド ベースのソリューションには、現場の専門知識はそれほど必要ありませんが、多くの企業が必要とする配置の柔軟性が欠如している場合があります。ハイブリッド デザインは、呼制御などの一部の Unified Communications 機能がオンプレミスで提供され、他の機能はクラウド ベースのサービスとして提供される場所に配置できます。

シスコは、オンプレミスの Unified Communications 配置で提供される機能の拡張または置換に使用できる次の「サービスとしてのコラボレーション」製品を提供します。

次のクラウド ベースのサービスを提供する Cisco WebEx

Cisco WebEx 会議

Cisco WebEx Social

Cisco WebEx Telepresence

インスタント メッセージング(IM)を提供する Cisco WebEx Connect

WebEx 会議と WebEx Social は固有のクラウド ベースのサービスですが、WebEx Telepresence とインスタント メッセージングは、Cisco Unified CM、Cisco Video Communication Server(VCS)、Cisco IM and Presence を使用して、WebEx クラウド サービスまたはオンプレミス サービスとして配置できます。

Cisco WebEx の詳細については、次の Web サイトにあるマニュアルを参照してください。

http://www.cisco.com/en/US/products/ps10352/index.html

Cisco Hosted Collaboration Solution は、次のさまざまなアプリケーションとサービスを提供します。

Cisco Unified Communications Manager(Unified CM)

Cisco Unified Attendant Consoles

Cisco Unity Connection

Cisco IM and Presence

Cisco WebEx

Cisco Hosted Collaboration Solution の詳細については、次の Web サイトで入手可能なマニュアルを参照してください。

http://www.cisco.com/en/US/products/ps11363/index.html

配置モデル アーキテクチャ

一般に、配置モデル アーキテクチャは、サービスを提供する企業のアーキテクチャに従います。配置モデルは、企業の代表的なトポロジにおける Unified Communications ニーズを満たす参照アーキテクチャを記述します。たとえば、集中型呼処理配置モデルは、1 箇所または数箇所の中央集中型の本社に接続された多数のサイトで業務の大部分が行われる企業に向いたモデルです。

場合によっては、技術的制約のために技術の配置モデルが企業の配置モデルから逸脱することがあります。たとえば、企業に 1 つあるキャンパスのスケールが 1 つのサービス インスタンス(Cisco Unified Communications Manager が提供する呼処理サービスなど)のスケールを超えている場合、1 つのキャンパスに複数の呼処理クラスタ インスタンスまたは複数のメッセージング製品が必要になることがあります。

標準クラスタのサイジング制限を超えるお客様は、別の選択肢として、拡張性を向上できるメガクラスタの配置を検討できます。メガクラスタの詳細については、「メガクラスタ」を参照してください。


) 特に明記されていない限り、この SRND 内に含まれる呼処理配置に関連するすべての情報(キャパシティ、ハイ アベイラビリティ、一般的な設計上の考慮事項など)は、最大 8 個の呼処理サブスクライバ ノードを持つ標準クラスタにのみ適用されます。


Unified Communications 配置モデルの概要

この章では、Unified Communications およびコラボレーションの 3 種類の基本的なオンプレミスの配置モデルについて説明します。

キャンパス配置モデル

Unified Communications および Collaboration サービス、これらに関連するエンドポイント、ゲートウェイ、ボーダー コントローラ、メディア リソース、その他のコンポーネントがすべて 1 つの高速 LAN または MAN 上に位置しています。

集中型配置モデル

Unified Communications および Collaboration サービスは中央キャンパス サイトまたはデータセンターに位置しますが、エンドポイント、ゲートウェイ、メディア リソース、その他のコンポーネントは、QoS 対応の WAN によって相互接続される複数のリモート サイトに分散されます。

分散型配置モデル

複数のキャンパスおよび集中型配置、またはこの一方が QoS 対応 WAN 経由で相互接続されます。

集中型または分散型 PSTN アクセスやサービスの配置など、この 3 種類の基本的な配置モデルに無制限のバリエーションがありますが、この章で説明する基本的な設計のガイドラインが、対象の大部分に引き続き適用されます。

配置モデルのハイ アベイラビリティ

Unified Communications サービスは、ハイ アベイラビリティを実現するための機能を数多く備えています。その実装には、次のようにさまざまな方法があります。

フェールオーバー冗長性

不可欠なサービスの場合、設計に単一障害点が存在しないように冗長な要素を配置します。2 つ(またはそれ以上)の要素間の冗長性が自動的に確保されます。たとえば、Cisco Unified Communications Manager(Unified CM)に使用されているクラスタリング技術では、最大 3 台のサーバがお互いをバックアップできます。このタイプの冗長性は、技術的境界を越えて実現される場合があります。たとえば、1 台の電話機に対して、優先順位 3 番めまでの呼制御エージェントとして、同じ呼処理クラスタに属する 3 台の独立した Unified CM サーバを設定できます。そして 4 番めの選択肢として、Cisco IOS ルータを利用して呼処理サービスを提供するように電話機を設定することもできます。

リンクの冗長性

1 つの WAN リンクでの障害に対処するために、IP WAN リンクなどの冗長な IP リンクを配置すると有益な場合があります。

地理的多様性

一部の製品は、冗長なサービス ノードを WAN リンク越しに分散させて、(あらかじめ設定しておいた UPS および発電バックアップ システムの機能を超えて長時間停電が発生するなど)サイト全体がオフラインになっても、別の場所にある別のサイトで事業を継続できるようにしています。

配置モデルのキャパシティ プランニング

さまざまな配置モデルのキャパシティは、一般にその基となる製品のキャパシティと切り離すことができません。この章では、適宜キャパシティについて説明します。サービスをサポートしている製品をこのドキュメントの他の項で詳しく取り上げている場合、その項でその製品のキャパシティについて説明します。

共通の設計基準

Cisco Unified Communications システムを構成するどの技術でも、設計時に検討する基準として次のものがあります。

サイズ

このコンテキストでのサイズとは一般にユーザ数を指し、これが IP フォン、ボイスメールボックス、プレゼンス ウォッチャなどの数量に読み換えられます。また、データセンターなど、ユーザがほとんど(あるいはまったく)存在しないサイトでは、処理キャパシティの点からサイズを考えることもできます。

ネットワーク接続

サイトをシステムの他の部分への接続を設計する際に考慮が必要な主な要素が 3 つあります。

Quality of Service(QoS)を確保できる帯域幅

遅延

信頼性

多くの場合、ローカル エリア ネットワーク(LAN)ではこれらの要素は十分達成されています。すべての LAN 機器で QoS が達成されており、帯域幅は一般にギガビット範囲、遅延は最小限(数ミリ秒程度)で、優れた信頼性が標準で確保されています。

メトロポリタン エリア ネットワーク(MAN)では、3 つの要素とも LAN に近いものとなっています。帯域幅は一般にまだ数メガビット範囲、遅延は一般に数十ミリ秒で、優れた信頼性が確保されています。一般にパケット処理ポリシーが MAN プロバイダーから提供されるため、エンドツーエンドの QoS を実現できます。

ワイド エリア ネットワーク(WAN)では、これらの要素に特に注意する必要があります。帯域幅はコストが何よりも重視され、遅延は実効的な送出速度だけでなく物理的な距離にかかわる実際の伝搬遅延にも左右されることがあり、信頼性はさまざまな要因の影響を受けます。また、QoS 実現のために、余分な運用コストと設定作業が必要になることもあります。

帯域幅は、サイトで利用できる Unified Communications サービスのタイプおよびサービスの提供方法に大きな影響を与えます。たとえば、20 人のユーザにサービスを提供するサイトがシステムの他の部分に 1.5 Mbps の帯域幅で接続している場合、サイトの音声、プレゼンス、インスタント メッセージング、電子メール、およびビデオ サービスをリモートのデータセンター サイトに問題なくホストできます。その同じサイトが 1000 人のユーザをホストしている場合、比較的限られた帯域幅がシグナリングおよびメディア フローで飽和状態になるのを避けるために、サービスの一部をローカルにホストするのが最善です。これ以外にもう 1 つ、リモートのデータセンター サイトから WAN 全体にサービスを配信できるよう帯域幅を拡大する方法もあります。

遅延が設計に与える影響は、リモートに配置する Unified Communications サービスのタイプに応じて異なります。たとえば、片方向の遅延が 200 ms である WAN 全体に音声サービスを提供する場合、ダイヤルトーン遅延やメディア カットスルー遅延増大などの問題が発生することがあります。プレゼンスなど他のサービスでは、200 ms の遅延があっても問題が発生しない可能性があります。

サイトからネットワークの他の部分への接続の信頼性は、技術に適した配置モデルを決定する際の基本的な考慮事項です。信頼性が高い場合は、ほとんどの Unified Communications コンポーネントではリモート サイトからホストされるサービスを配置できます。信頼性が安定しない場合、一部の Unified Communications コンポーネントはリモートからホストされる際に正しく実行されないことがあります。信頼性が低いと、サイトに Unified Communications サービスのコロケーションが必要になることがあります。

ハイ アベイラビリティ要件

サービスのハイ アベイラビリティは常に設計の目標となるものです。信頼性の必要性とその実現に伴うコストとのバランスを保つには、実際的な設計の判断が必要です。次のいずれの要素も、設計がハイ アベイラビリティを実現できるかどうかに影響を与えます。

帯域幅の信頼性。Unified Communications サービスの配置モデルに直接影響を与えます。

電源の可用性

停電は、どんなシステムでもきわめて破壊的な事象です。停電中はサービスが利用できなくなるだけでなく、電力復旧によってリプル効果がもたらされるためです。電力の可用性が高いサイト(たとえば、無停電電源(UPS)および発電装置によるバックアップを備えて、電力グリッド接続が安定しているサイト)は、一般に Unified Communications サービスのホストに選択できます。サイトの電力可用性に一貫性がない場合、そのサイトをホスト用のサイトとして使用するのは賢明な判断ではありません。

熱、湿度、振動などの環境要因

一部の Unified Communications サービスは、サーバなど定期的な保守を必要とする機器を使用して配信されます。Unified Communications コール エージェント サーバのホストなど、一部の Unified Communications 機能は、能力ある人材が配属されているサイトに配置するのが最善です。

サイトベースの設計ガイドライン

このドキュメント全体を通して、さまざまな Unified Communications サービスおよび技術の系列に沿って設計ガイドラインを編成しています。たとえば、呼処理の章では、呼処理サービスを実際に説明するだけでなく、サイトのサイズ、ネットワーク接続、およびハイ アベイラビリティの要件に基づいて IP Phone および Cisco Unified Communications サーバを配置するための設計ガイドラインも示します。同様に、コール アドミッション制御の章では、技術自体の説明に焦点を当てるだけでなく、サイトベースの設計考慮事項も示します。

一般に、特定の Unified Communications サービスまたは技術のほとんどの側面が、サイトのサイズまたはネットワーク接続とは関係なく、すべての配置に関係しています。必要に応じて、サイトベースの設計考慮事項について説明します。サービスは集中化、分散化、インターネットワーク化、および地理的多様化が可能です。

サービスの集中化

企業の支社サイトが地理的に分散し、ワイド エリア ネットワークで相互接続されている用途では、Cisco Unified Communications サービスを中央に配置しつつ、WAN 接続でエンドポイントにサービスを提供できます。たとえば、呼処理サービスを集中的に配置できます。テレフォニー サービスの配信に必要なのは、リモート サイトとの IP 接続だけです。同様に、Cisco Unity Connection プラットフォームから提供されるようなボイス メッセージ サービスも中央にプロビジョニングして、IP WAN で接続されたリモートからサービスをエンドポイントに配信できます。

中央にプロビジョニングした Unified Communications サービスは、WAN 接続中断の影響を受けます。そのため、サービスごとに、ローカル サバイバビリティ オプションを計画すべきです。たとえば、Cisco Unified CM から提供されるような呼処理サービスには、Survivable Remote Site Telephony(SRST)や Cisco Unified Communications Manager Express(Unified CME)などのローカル サバイバビリティ機能を設定できます。同様に、Unity Connection Survivable Remote Site Voicemail(SRSV)を使用してローカル ボイス メール サービスにアクセスするには、SRST 下でリモート サイトの操作を許可するように、Cisco Unity Connection のような集中型ボイス メッセージ サービスをプロビジョニングできます。

すべての Unified Communications サービスでサービスの集中化を統一する必要はありません。たとえば、複数のサイトが 1 つの集中型呼処理サービスを利用する場所にシステムを配置し、一方で Cisco Unity Express などの非集中型(分散型)ボイス メッセージ サービスでそのシステムをプロビジョニングすることもできます。同様に、Cisco Unity Connection などの集中型ボイス メッセージ サービスとともに、Cisco Unified Communications Manager Express を使用して呼処理が各サイトでローカルにプロビジョニングされる形態で Unified Communications システムを配置することもできます。

多くの場合、各サービスの設計時に考慮すべき主要な基準は、サイト間の IP ネットワークの可用性と品質です。サイト間の IP 接続が次の特性を備えている場合、Unified Communications サービスの集中化は、機器のホストと運用に伴う資本費用と運用費用のどちらの面でもスケールメリットが得られます。

予想されるトラフィック負荷に十分対応できる帯域幅。ボイスメールへのアクセス、集中型の PSTN 接続へのアクセス、音声やビデオを含むサイト間オンネット通信などによって発生する、ピーク時のアクセス負荷も含めます。

ハイ アベイラビリティ。WAN サービス プロバイダーがサービス レベル契約に従って接続を迅速に保守および復旧することによりもたらされます。

低遅延。主要な中央サイトへのラウンドトリップ時間のためにシステムの応答時間に遅延が発生しても、リモート サイトのローカルなイベントは損害を受けません。

また、特定のサービスを中央に配置して複数のサイトのエンドポイントにサービスを提供した場合、複数のサイトでユーザに同じ処理リソースを使用することから、機能の透過性という利点が得られます。たとえば、2 つのサイトに同じ集中型 Cisco Unified Communications Manager クラスタからサービスを提供する場合、ユーザは 2 つのサイト間でライン アピアランスを共有できます。各サイトに異なる(分散した)呼処理システムからサービスを提供する場合には、この利点は得られません。

機能の透過性およびスケール メリットという利点は、Unified Communications トラフィックの需要に応えるために WAN ネットワークを構築および運用する際の相対的コストに照らして評価する必要があります。

サービスの分散化

Unified Communications サービスは、複数のサイトに分散させて個別に配置することもできます。たとえば、2 つ(またはそれ以上の)のサイトを独立した呼処理 Cisco Unified CME ノードでプロビジョニングできます。同じ場所にあるエンドポイントに対するサービスの可用性を確保するために WAN を利用する必要はありません。同様に、サイトを Cisco Unity Express などの独立したボイス メッセージング システムでプロビジョニングできます。

Unified Communications サービスを分散させた場合の主な利点は、配置方法が WAN 接続の相対的な可用性およびコストに依存しないことです。たとえば、WAN 接続が使用できないか、きわめて費用がかかるか、または信頼性が高くないリモートの場所でサイトを運用している場合、そのリモート サイト内で Cisco Unified Communications Manager Express などの独立した呼処理ノードをプロビジョニングすると、WAN がダウンしても呼処理の中断が回避されます。

サービスのインターネットワーク化

2 つのサイトを独立したサービスでプロビジョニングした場合でも、両サイトを相互接続してサイト間で機能の透過性をある程度実現できます。たとえば、Cisco Unified Communications Manager Express でプロビジョニングした分散型呼処理サービスを H.323 トランクまたは SIP トランクでインターネットワーク化して、サイト間で IP コールを許可できます。同様に、Cisco Unity Connection または Cisco Unity Express の独立したインスタンスを同じメッセージング ネットワークに参加させることによって、ユニファイド メッセージ ネットワーク内でメッセージをルーティングしたり、サブスクライバ情報およびディレクトリ情報を交換したりできます。

Unified Communications サービスの地理的多様性

一部のサービスを IP WAN 越しで複数の冗長なノードにプロビジョニングすると、停電やネットワーク障害でサイトが中断したり、火事や地震などの重大な災害でサイトの物理的な整合性が損なわれたりしても、サービスを継続できます。

このような地理的多様性を実現するには、個々のサービスが冗長なノードをサポートするだけでなく、IP WAN の遅延と帯域幅の制約を越えてこれらのノードを配置できる必要があります。たとえば、ノード間のエンドツーエンドの合計ラウンドトリップ時間が 80 ms を超えず、適度な容量の QoS 対応帯域幅をプロビジョニングしている限り、Unified CM の呼処理サービスは単一クラスタの呼処理ノードを IP WAN 越しに配置できます。これに対して、Unified CME は冗長性を備えていないため、地理的に多様な構成に配置できません。

表 10-2 に、各 Cisco Unified Communications サービスを上記の方法で配置できるかどうかをまとめます。

 

表 10-2 Cisco Unified Communications サービスに使用可能な配置オプション

サービス
集中型
分散型
インターネットワーク化
地理的多様性

Cisco Unified CM

Yes

Yes

Yes

Yes

Cisco Unified CME

No

Yes

Yes

No

Cisco Business Edition 6000

Yes

Yes

Yes

Yes

Cisco Business Edition 3000

Yes

No

No

No

Cisco Unity Express

No

Yes

Yes(Cisco Unified Messaging Gateway を使用)

No

Cisco Unity Connection

Yes

Yes(サイトごとに 1 つの Cisco Unity Connection)

Yes(Cisco Unified Messaging Gateway を使用)

Yes

Cisco Emergency Responder

Yes

Yes(サイトごとに 1 つの Emergency Responder グループ)

Yes(Emergency Responder クラスタリングを使用)

Yes

Cisco IM and Presence

Yes

Yes(サイトごとに 1 つの Cisco IM and Presence サービス)

Yes(ドメイン間フェデレーションを使用)

Yes

Cisco Unified Mobility

Yes

Yes(Unified CM シングル ナンバー リーチとして)

No

Yes

Cisco VCS

Yes

Yes

Yes

Yes

Cisco VCS Expressway

Yes

Yes

Yes

Yes

呼処理は基本的なサービスであるため、この章では基本呼処理配置モデルについて説明します。Cisco Unified Communications Manager 呼処理の技術的詳細については、「呼処理」の章を参照してください。

キャンパス

この呼処理配置モデルでは、Unified Communications サービスとエンドポイントはキャンパスの同じ場所にあります。サービス ノード、エンドポイント、およびアプリケーション間の QoS 対応ネットワークは高い可用性を実現しており、帯域幅は事実上無制限で、エンドツーエンドの遅延は 15 ミリ秒未満です。同様に、電源の品質および可用性はきわめて高く、サービスは適切なデータセンター環境にホストされます。エンドポイント間の通信は、LAN または MAN を通過し、企業外部の通信は PSTN などの外部ネットワークを経由します。企業は、一般に LAN または MAN で接続された 1 つまたは複数のまとまったビルにキャンパス モデルを配置します。

図 10-1 キャンパス配置の例

 

キャンパス モデルの設計上の特長は、次のとおりです。

単一の Cisco Unified CM クラスタ。一部のキャンパス呼処理配置では、複数の Unified CM クラスタが必要になる場合があります。たとえば、コールの対象となるエンドポイントの数が多すぎて単一のクラスタでは対応できない場合や、クラスタをコール センターなどの用途に限る必要がある場合などです。

一方、小規模な配置では、Cisco Business Edition 3000、5000、または 6000 をキャンパスに配置できます。

1 つの Unified CM クラスタあたり最大 40,000 の設定済みおよび登録済み Skinny Client Control Protocol(SCCP)または Session Initiation Protocol(SIP)IP Phone、ビデオ エンドポイント、モバイル クライアントおよび Cisco Virtualization Experience Client(VXC)。

Unified CM クラスタごとに最大 2,100 のゲートウェイおよびトランク(つまり、H.323 ゲートウェイ、H.323 トランク、デジタル MGCP デバイス、および SIP トランクの合計数)。

キャンパスの外部にある宛先へ向かうすべてのコール用のトランクやゲートウェイ(IP または PSTN)。

会議、トランスコーディング、およびメディア ターミネーション ポイント(MTP)に対応する、同じ場所のデジタル シグナル プロセッサ(DSP)リソース。

メッセージング(ボイスメール)、プレゼンス、モビリティなどその他の Unified Communications サービスも一般に同じ場所に設置されます。

PBX やボイスメール システムなどレガシー音声サービスへのインターフェイスがキャンパス内に接続されるため、帯域幅または接続に運用コストがかかりません。

SIP ベースのビデオ ISDN ゲートウェイは、公衆 ISDN 網上のビデオ会議デバイスと通信するために必要です。

Cisco TelePresence Video Communication Server(VCS)は、他社のサードパーティ製を含む SIP、H323 通信で行われるルームタイプの Telepresence 会議などに使用されます。

Cisco TelePresence Video Communication Server Expressway(VCS Expressway)は、インターネット上での安全な企業間のテレプレゼンスおよびビデオ通信を提供します。

広帯域オーディオ(たとえば、G.711 または G.722)はサイト内のデバイス間で使用できます。

広帯域ビデオ(たとえば、384 kbps ~ 1.5 Mbps)はサイト内のデバイス間で使用できます。

キャンパス モデルのベスト プラクティス

単一サイト モデルを実装する場合は、次のガイドラインに従い、ベスト プラクティスを参考にしてください。

インフラストラクチャがハイ アベイラビリティで、QoS に対応し、復元性、高速コンバージェンス、およびインライン パワーを備えていることを確認します。

自社内のコール パターンを知っておく必要があります。キャンパス モデルは、大部分のコールが社内の同一サイトから発信されている場合、または社外の PSTN ユーザ宛てに発信されている場合に適用します。

すべてのエンドポイントに G.711 コーデックを使用します。この方式を実施すると、トランスコーディングに対してデジタル シグナル プロセッサ(DSP)リソースを消費する必要がなくなり、その分のリソースは、会議やメディア ターミネーション ポイント(MTP)などの他の機能に割り当てることができます。

ハイ アベイラビリティ、電話機用の接続オプション(インライン パワー)、Quality of Service(QoS)メカニズム、およびセキュリティ用の推奨ネットワーク インフラストラクチャを実装しています (「ネットワーク インフラストラクチャ」を参照)。

「呼処理」の章にリストされているプロビジョニングの推奨事項を実行します。

集中型呼処理を使用するマルチサイト

この呼処理配置モデルでは、エンドポイントは QoS 対応のワイド エリア ネットワークを越えて呼処理サービスとは離れた場所に置かれます。WAN 全体で利用できる帯域幅の容量が限られているため、特定の WAN リンクで認められるコールの数を管理して、負荷を使用可能な帯域幅の制限内に収めるには、コール アドミッション制御メカニズムが必要です。エンドポイント間のオンネット通信は、LAN/MAN(エンドポイントが同じサイトにある場合)または WAN(エンドポイントが異なるサイトにある場合)のいずれかを通過します。企業外部の通信は、エンドポイントと同じ場所または異なる場所に配置できるゲートウェイまたは Cisco Unified Border Element(CUBE)セッション ボーダー コントローラ(SBC)を介して PSTN などの外部ネットワークを経由します(たとえば、メイン サイトで集中型ゲートウェイを使用する場合、またはエンタープライズ ネットワーク全体でテールエンド ホップオフ(TEHO)を行う場合)。

IP WAN は、中央サイトとリモート サイト間の呼制御シグナリングも伝送します。図 10-2 は、一般的な集中型呼処理配置を示しています。この配置では、中央サイトの呼処理エージェントとして Unified CM クラスタを使用し、すべてのサイトを接続するために、QoS 対応の IP WAN を使用します。この配置モデルでは、管理と保守全体のコストを削減するために、ボイス メッセージ、プレゼンス、モビリティなど他の Unified Communications サービスも中央サイトにホストすることがよくあります。WAN の信用性が低い場合や、WAN 帯域幅のコストが高い場合には、サービスの可用性が WAN の障害の影響を受けないように、ボイス メッセージング(ボイスメール)など一部の Unified Communications サービスを分散させることができます。


) このマニュアルで説明する集中型呼処理モデル用のソリューションでは、さまざまなサイトが QoS に対応した IP WAN に接続されます。


図 10-2 集中型呼処理を使用するマルチサイト配置

 

集中型呼処理を使用するマルチサイト モデルの設計上の特長は、次のとおりです。

単一の Unified CM クラスタ。一部の集中型呼処理配置では、複数の Unified CM クラスタが必要になる場合があります。たとえば、コールの対象となるエンドポイントの数が多すぎて単一のクラスタでは対応できない場合や、クラスタをコール センターなどの用途に限る必要がある場合などです。

小規模な配置では、Cisco Business Edition 3000 を最大 9 つのリモート サイトに対応する集中型呼処理構成で配置できます。

Cisco Business Edition 6000 は、最大 49 のリモート サイトに対応する集中型呼処理構成で配置できます。

1 つの Unified CM クラスタあたり最大 40,000 の設定済みおよび登録済み Skinny Client Control Protocol(SCCP)または Session Initiation Protocol(SIP)IP Phone、ビデオ エンドポイント、モバイル クライアントおよび Cisco Virtualization Experience Client(VXC)。

Unified CM クラスタあたり最大 2,000 のロケーションまたは支社サイト。

Unified CM クラスタごとに最大 2,100 のゲートウェイおよびトランク(つまり、H.323 ゲートウェイ、H.323 トランク、デジタル MGCP デバイス、および SIP トランクの合計数)。

すべてのオフネット コールのための PSTN 接続。

会議、トランスコーディング、およびメディア ターミネーション ポイント(MTP)用のデジタル シグナル プロセッサ(DSP)リソースを各サイトにローカルに分散させて、DSP を必要とするコールが消費する WAN 帯域幅の容量を削減します。

マルチポイント ビデオ会議には、マルチポイント コントロール ユニット(MCU)リソースが必要です。これらのリソースは中央サイトにあっても、ローカル会議リソースが必要な場合はリモート サイトに分散していてもかまいません。

レガシー構内交換機(PBX)システムおよびボイスメール システムとの統合機能。PBX やボイスメール システムなど従来の音声サービスへのインターフェイスを中央サイト内に接続できるため、帯域幅または接続に運用コストがかかりません。リモート サイトにある従来のシステムに接続するには、余分な WAN 帯域幅のプロビジョニングに伴う運用コストが必要になる場合があります。

SIP ベースのビデオ ISDN ゲートウェイは、パブリックの ISDN ネットワーク上に公開されているビデオ会議デバイスと通信するために必要です。ISDN ビデオ ゲートウェイは、各リモート サイトで一元的に管理、または配置できます。

Cisco TelePresence Video Communication Server(VCS)は、会議室ベースの TelePresence 会議システム、SIP、H323、およびサードパーティのテレプレゼンス エンドポイントに使用されます。Cisco VCS は、Unified CM と一元化または TelePresence エンドポイントが存在する各サイトでプロビジョニングできます。VCS の一元化はコスト効率がよく、ダイヤル プランを簡素化します。一方、VCS の分散は、会社の WAN のコール アドミッション制御を簡素化しますが、会社のダイヤル プランはより細分化され、追加のハードウェア コストが発生します。Cisco Unified CM および Cisco VCS の配置と統合の詳細については、次の URL にある『 Cisco Unified Communications Manager with Cisco VCS Deployment Guide 』を参照してください。

http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/Cisco_VCS_Cisco_Unified_Communications_Manager_Deployment_Guide_CUCM_8_9_and_X7-2.pdf

Cisco TelePresence Video Communication Server Expressway(VCS Expressway)は、インターネット上の安全な企業間のテレプレゼンスおよびビデオ通信を提供します。VCS Expressway は通常は一元化されますが、各リモート サイトでの一元的に管理、配置も可能です。

システムは、サイト内のデバイス間の広帯域オーディオ(たとえば、G.711 または G.722)の自動選択を異なるサイトのデバイス間の狭帯域オーディオ(たとえば、G.729)選択中に可能にします。

システムは、同じサイト内のデバイス間の広帯域ビデオ(4CIF または 720p での 1.5 Mbps から 1080p での 2 Mbps など)、および異なるサイトのデバイス間の狭帯域ビデオ(448p または CIF での 384 kbps)の自動選択を可能にします。

WAN でビデオを発信するときには、WAN リンク速度を最低でも 1.5 Mbps 以上にする必要があります。

コール アドミッション制御は、Enhanced Locations CAC または RSVP によって実現されます。

音声およびビデオ コールの場合、コール アドミッション制御が、帯域幅不足によるクラスタ内のエンドポイント間でコールを拒否する場合、Automated Alternate Routing(AAR)は、PSTN 経由で自動的にコールを再ルーティングします。AAR は、ゲートウェイを利用して発信側電話機から PSTN へ向かうコールをルーティングし、着信側電話機に接続される別のゲートウェイを利用してリモート サイトで PSTN からのコールを受け付けます。

リモート WAN リンク障害のためにエンドポイントが未登録であると見なされたときには、Call Forward Unregistered(CFUR)機能により、PSTN 経由で自動的にコールを再ルーティングできます。CFUR は、ゲートウェイを利用して呼び出し元の電話機から PSTN へ向かうコールをルーティングし、呼び出し先の電話機に接続される別のゲートウェイを利用してリモート サイトで PSTN からのコールを受け付けます。

ビデオ用 Survivable Remote Site Telephony(SRST)。WAN 接続で障害が発生すると、リモート サイトにある SCCP ビデオ エンドポイントが音声だけのデバイスになります。

SRST ルータの代わりに Cisco Unified Communications Manager Express(Unified CME)を使用して、リモート サイトのサバイバビリティ(呼処理の継続)を確保することもできます。

Cisco Unified Communications Manager Express(Unified CME)は、支社またはリモート サイトで Cisco Unity サーバと統合が可能です。Cisco Unity Connection サーバは、中央サイトの Unified CM に通常モードで登録され、Unified CM が到達不能の場合や WAN の障害時は、Unified CME に SRST モードでフォール バックできます。これにより支社のユーザは、MWI を使用してボイスメールにアクセスできます。

マルチ サイト集中型呼処理モデルを使用している場合、本社およびリモート サイト ゲートウェイの両方を経由した PSTN ルーティングがサポートされています。ローカル PSTN ブレークアウト用にリモート サイトのローカル ゲートウェイを提供することは、リモート サイトのユーザーに緊急サービスを提供する場合にその国の要件を満たす必要があります。この場合、リモート サイトのローカル ゲートウェイは、緊急コール用のローカル PSAP にコール ルーティングを提供します。PSTN から IP テレフォニー ネットワークを分離する必要がある規制の厳しい国には、リモート サイトのローカル PSTN ブレークアウトも必要な場合があります。規制で許可されていれば、リモート サイト ゲートウェイを経由するローカル PSTN ブレークアウトを使用して、トール バイパスまたは Tail-end Hop Off(TEHO; テールエンド ホップ オフ)を有効にできます。

Business Edition 3000 は、設定された PSTN ゲートウェイへのルーティングを有効にするための国ベースのダイヤル プラン設定、および PSTN アクセス制限を制御するポリシー メカニズムを提供します(当該国の規制に基づきます)。Business Edition 3000 は、MGCP で制御された Cisco 2901 Integrated Services Router(ISR)を経由するローカル PSTN ブレークアウトのみをサポートします。リモート サイトのローカル ブレークアウトは、Cisco SPA8800 IP テレフォニー ゲートウェイを使用してアナログ トランク経由で、あるいは Cisco SPA8800 または SPA8900 IP テレフォニー ゲートウェイ上の Cisco Unified Border Element(「CUBE Lite」と呼ばれることがあります)を使用して SIP トランク経由で提供することもできます。

Business Edition 3000 は、SRST またはリモート サイトのサバイバビリティはサポートしません。

IP WAN の接続オプションは、次のとおりです。

専用回線

フレーム リレー

非同期転送モード(ATM)

ATM とフレーム リレーのサービス インターワーキング(SIW)

マルチプロトコル ラベル スイッチング(MPLS)バーチャル プライベート ネットワーク(VPN)

音声およびビデオ対応 IP セキュリティ プロトコル(IPSec)VPN(V3PN)

WAN エッジに置かれているルータには、プライオリティ キューイングやトラフィック シェーピングなどの Quality of Service(QoS)メカニズムが装備されていて、WAN の帯域幅が恒常的に不足している場合に、データ トラフィックから音声トラフィックおよびビデオ トラフィックを保護しています。加えて、音声トラフィックおよびビデオ トラフィック、またはこの一方による WAN リンクのオーバーサブスクリプションや確立されたコールの品質低下を防止するために、コール アドミッション制御方式が必要です。集中型呼処理配置の場合は、Unified CM 内に設定された拡張ロケーション CAC または RSVP ロケーションは、コール アドミッション制御(CAC)を提供します。(ロケーションの詳細については、「コール アドミッション制御」の章を参照してください)。

さまざまな Cisco ゲートウェイは、TDM または IP ベースの PSTN アクセスをリモート サイトで提供できます。IP WAN で障害が発生した場合や、IP WAN 上で使用可能な帯域幅がすべて消費されてしまった場合でも、リモート サイトのユーザからのコールは、PSTN 経由で再ルーティングできます。Cisco Unified Survivable Remote Site Telephony(SRST)機能は、SCCP および SIP 電話機の両方で使用可能です。Cisco Unified IP Phone が、リモートの 1 次、2 次、および 3 次 Unified CM への接続を失った場合、または WAN 接続がダウンした場合に、支社での呼処理を提供します。Cisco Unified SRST 機能は、SRST 機能を実行する Cisco IOS ゲートウェイ、または SRST モードで動作する Cisco Unified CME で使用できます。SRST モードで動作する Unified CME では、Cisco IOS ゲートウェイの SRST よりも多くの機能が電話機に提供されます。

集中型呼処理モデルのベスト プラクティス

マルチサイトの集中型呼処理配置を実装する際は、次のガイドラインおよびベスト プラクティスに従ってください。

音声のカットスルー遅延(クリッピングとも呼ばれます)を減らすために、Unified CM とリモート ロケーション間の遅延を最小限に抑えます。

リモート ブランチとの間でコール アドミッション制御をやり取りするために、Unified CM で Enhanced Locations CAC または RSVP を設定します。このメカニズムをさまざまな WAN トポロジに適用する方法については、「コール アドミッション制御」の章を参照してください。

各リモート サイトでの Survivable Remote Site Telephony(SRST)モードでサポートされている IP Phone およびライン アピアランスの数は、その支社内にあるルータのプラットフォーム、取り付け済みメモリ容量、および Cisco IOS Release により異なります。Cisco IOS ゲートウェイの SRST では最大 1,500 台の電話機がサポートされますが、SRST モードで動作する Unified CME の場合は、最大 450 台です (SRST または Unified CME プラットフォームおよびコード仕様に関する詳細は、 http://www.cisco.com から入手できる SRST および Unified CME の文書を参照してください)。一般的には、特定サイトに対して集中型呼処理か、分散呼処理かを決定するには、次に示す種々の要素によります。

IP WAN 帯域幅、または遅延制限

音声ネットワークに関する臨界状況

フィーチャ セットの必要性

拡張性

管理の容易性

コスト

お客様のビジネス ニーズに分散型呼処理モデルがふさわしいと判断する場合は、2 つの選択肢があります。各サイトに Unified CM クラスタをインストールする方法と、リモート サイトで Unified CME を稼働する方法です。

リモート サイトでは、次の機能を使用して、WAN 障害が発生した場合の呼処理のサバイバビリティを確保します。

SCCP 電話機の場合は、Cisco IOS ゲートウェイの SRST を使用するか、SRST モードで動作する Unified CME を使用します。

SIP 電話機の場合は、SIP SRST を使用します。

集中型ボイス メールの配置の場合、Survivable Remote Site Voicemail(SRSV)を使用します。

SRST または SRST モードの Unified CME、SIP SRST、SRSV および MGCP ゲートウェイ フォールバックは、同一の Cisco IOS ゲートウェイに相互に存在することができます。

リモート サイトのサバイバビリティ(呼処理の継続)

集中型呼処理モデルで WAN を介した Cisco Unified Communications を配置する場合、リモート サイトのデータ サービスと音声サービスのハイ アベイラビリティを確保するために、追加の処置が必要です。 表 10-3 では、リモート サイトでのハイ アベイラビリティを実現するためのさまざまな方法をまとめています。これらの方法のいずれを選択するかは、ビジネスまたはアプリケーションの特殊な要件、可用性が高いデータ サービスと音声サービスに関連した優先順位、コストの考慮事項などの複数の要素によって異なります。

表 10-3 リモート サイトのハイ アベイラビリティを実現する方法

方法
データ サービスのハイ アベイラビリティ
音声サービスのハイ アベイラビリティ

支社ルータにおける冗長 IP WAN リンク

Yes

Yes

支社ルータの冗長プラットフォーム + 冗長 IP WAN リンク

Yes

Yes

データのみの ISDN バックアップ + SRST または Unified CME

Yes

Yes

データと音声の ISDN バックアップ

Yes

Yes(下記の規則を参照)

Cisco Unified Survivable Remote Site Telephony(SRST)または SRST モードの Unified CME

No

Yes

表 10-3 にリストされている最初の 2 つのソリューションは、IP WAN アクセス ポイントに冗長性を追加して、リモート IP Phone と中央の Unified CM との間の IP 接続を常に保持することによって、ネットワーク インフラストラクチャ層に高い可用性を提供します。これらのソリューションは、データ サービスと音声サービスの両方に適用され、呼処理層からはまったく見えません。このオプションは、支社ルータでの冗長 IP WAN リンクの追加から、冗長 IP WAN リンクを備えた別の支社ルータ プラットフォームの追加までにわたります。

表 10-3 の 3 番めと 4 番めのソリューションでは、ISDN バックアップ リンクを使用して、WAN 障害時の存続可能性を提供します。ISDN バックアップ用には、次の 2 つの配置オプションがあります。

データのみの ISDN バックアップ

このオプションでは、ISDN はデータのみの存続可能性の確保に使用され、一方 SRST または SRST モードの Unified CME は音声のサバイバビリティの確保に使用されます。Skinny Client Control Protocol(SCCP)、H.323、メディア ゲートウェイ コントロール プロトコル(MGCP)、Session Initiation Protocol(SIP)などのテレフォニー シグナリング プロトコルからのトラフィックが ISDN インターフェイスに入らないように支社ルータにアクセス コントロール リストを設定して、IP Phone からの信号が中央サイトの Unified CM に到達しないようにする必要があることに注意してください。これにより、支社にあるテレフォニー エンドポイントは WAN の障害を検出し、ローカル SRST リソースを利用するようになります。

データと音声の ISDN バックアップ

このオプションでは、ISDN はデータと音声の両方の存続性を確保するのに使用されます。この場合、IP Phone は常に Unified CM クラスタとの IP 接続を保持するので、SRST または SRST モードの Unified CME は使用されません。しかし、データと音声のトラフィックの転送に ISDN を使用するのは、次の条件がすべて満たされる場合だけにすることをシスコは推奨します。

ISDN リンク上で音声トラフィックに割り当てられた帯域幅が、IP WAN リンク上で音声トラフィックに割り当てられた帯域幅と同じである。

ISDN リンクの帯域幅が固定されている。

必要なすべての QoS 機能が、ルータの ISDN インターフェイスに配置されている。QoS の詳細については、「ネットワーク インフラストラクチャ」の章を参照してください。

表 10-3 にリストされている 5 番目のソリューションでは、WAN 障害が検出された場合、Survivable Remote Site Telephony(SRST)または SRST モードの Unified CME が、リモート オフィスのルータ内で呼処理機能のサブセットを提供し、IP Phone を拡張して、ローカル ルータ内の呼処理機能に「re-home」機能を提供することによって、音声サービスのみのハイ アベイラビリティを提供します。図 10-3 では、SRST または SRST モードの Unified CME を使用した典型的なコールのシナリオを示しています。

図 10-3 Survivable Remote Site Telephony(SRST)または SRST モードの Unified CME

 

図 10-3の左側に表示されている通常の動作では、支社は、データ トラフィック、音声トラフィック、およびコール シグナリングを伝送する IP WAN を経由して、中央サイトに接続されます。支社の IP Phone は、中央サイトの Unified CM クラスタとコール シグナリング情報を交換し、IP WAN を介してコールを発信します。支社のルータまたはゲートウェイは、両方のタイプのトラフィック(コール シグナリングと音声)を透過的に転送し、IP Phone を認識しません。

支社との WAN リンクに障害が起きた場合、またはその他の何らかのイベントにより、Unified CM クラスタとの接続が失われた場合、支社の IP Phone は支社のルータに SRST モードで再登録されます。支社のルータ、SRST、または SRST モードで動作する Unified CME は、設定について IP Phone に照会し、この情報を使用して独自の設定を自動的に作成します。支社の IP Phone は、支社のネットワーク内か、または PSTN を介してコールの発信と受信を行うことができます。電話機は「Unified CM fallback mode」というメッセージを表示し、Unified CM の一部の拡張機能が利用不能になり、電話機のディスプレイでグレー表示されます。

中央サイトとの WAN 接続が再度確立されると、支社の IP Phone は、Unified CM クラスタに自動的に再登録され、正常な動作に戻ります。支社の SRST ルータは、IP Phone についての情報を削除し、標準のルーティングまたはゲートウェイ設定に戻ります。SRST モードで動作する支社の Unified CME では、自動プロビジョニング オプションを使用することで、取得した電話機および回線の設定を、Unified CME ルータの実行コンフィギュレーションに保存できます。 auto-provision none が設定されている場合、自動でプロビジョニングされた電話機または回線の設定情報は、Unified CME ルータの実行コンフィギュレーションに保存されません。そのため、IP Phone を交換して MAC アドレスが変更された場合でも、Unified CME での設定変更は必要ありません。


) 中央サイトとの WAN 接続が再度確立された場合、または Unified CM が再度到達可能になった場合でも、アクティブ コールを持つ SRST モードの電話機がただちに Unified CM に再登録されるわけではありません。再登録されるのは、そのようなアクティブ コールが終了してからです。



上記で説明したリモート サイトのサバイバビリティ機能は、Business Edition 3000 ではサポートされていません。


SRST モードの Unified CME

Unified CME が SRST モードで使用されている場合、ルータの SRST で使用できる機能よりも多くの呼処理機能が IP Phone に提供されます。コール プリザベーションや自動プロビジョニング、フェールオーバーといった SRST の機能に加え、SRST モードの Unified CME では、SCCP 電話機用に用意されている次のような Unified CME テレフォニー機能のほとんどを使用できます。

ページング

会議

ハント グループ

基本自動着信呼分配(B-ACD)

コール パーク、コール ピックアップ、コール ピックアップ グループ

オーバーレイ DN、ソフトキー テンプレート

Cisco IP Communicator

Cisco Jabber クライアント

Cisco Unified Video Advantage

MWI をサポートする Cisco Unity とのリモートサイトでの統合、および分散型の Microsoft Exchange または IBM Lotus Domino サーバとの統合

SRST モードの Unified CME では、WAN 障害が発生した場合に、SCCP 電話機に対する呼処理がサポートされます。ただし、SRST モードの Unified CME では、MGCP 電話機またはエンドポイントに対するフォールバックはサポートしていません。SIP プロキシ サーバまたは Unified CM への接続が失われた場合や、WAN 接続に障害が発生した場合に、SIP 電話機および MGCP 電話機がフォールバックできるようにするために、SRST フォール バック サーバとして動作している Unified CME サーバに、SIP SRST 機能と MGCP ゲートウェイ フォールバック機能の両方を追加で設定できます。

SRST モードの Unified CME のベスト プラクティス

Unified CM での SRST 参照の IP アドレスとして、Unified CME の IP アドレスを使用します。

Connection Monitor Duration は、SRST から Unified CM へのフォールバックを開始するまでに、電話機が WAN リンクをモニタする時間を指定するタイマーです。ほとんどの場合は、デフォルト設定の 120 秒を使用します。ただし、SRST モードの電話機が、フラッピングが発生しているリンクで Unified CM にフォールバックしたり復帰したりするのを防ぐために、Unified CM の Connection Monitor Duration パラメータをより長い期間に設定できます。これにより、電話機が SRST ルータと Unified CM の間で登録と再登録を繰り返すことがなくなります。電話機が長期間にわたって SRST から Unified CM にフォールバックしなくなるため、この値を極端に長い期間に設定しないでください。

SRST フォールバック モードの電話機は、アクティブ状態になっても Unified CM に復帰しません。

SRST フォールバック モードの電話機は、セキュア会議から非セキュア モードに戻ります。

auto-provision none を設定し、取得された ephone-dn または ephone 設定が、Unified CME ルータの実行コンフィギュレーションに書き込まれないようにします。これにより、IP Phone が交換された場合や、MAC アドレスが変更された場合に、設定を変更する必要がなくなります。

SRST モードの Unified CME の使用に関する詳細については、次の Web サイトで入手可能な『 Cisco Unified Communications Manager Express System Administrator Guide 』を参照してください。

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

SIP SRST の詳細については、次の Web サイトで入手可能な『 Cisco Unified SIP SRST System Administrator Guide 』を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps2169/products_installation_and_configuration_guides_list.html

MGCP ゲートウェイ フォールバックの詳細については、次の Web サイトで入手可能な『 Cisco CallManager and Cisco IOS Interoperability Guide 』の MGCP ゲートウェイに関する情報を参照してください。

http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/interop/ccm_c.html

SRST ルータのベスト プラクティス

次の配置シナリオでは、SRST モードの Unified CME ではなく、Cisco Unified SRST ルータを使用します。

1 台の SRST ルータで、最大 1,500 台の電話機をサポートする場合。(SRST モードの Unified CME では、最大 450 台の電話機がサポートされます)。

最大 3,000 台の電話機をサポートする場合は、2 台の SRST ルータを使用します。各 SRST ルータ間でコールが相互にルーティングされるように、ダイヤル プランを正しく設定する必要があります。

基本的な SRST 機能の、単純な 1 回限りの設定を行う場合。

Cisco Unified SRST(セキュア SRST)でのみ使用可能な SRTP メディア暗号化を使用する場合。

Cisco VG248 音声ゲートウェイをサポートする場合。

到達不能または SRST ルータに登録されていない電話機のコールをルーティングする場合は、 alias コマンドを使用。

Cisco Unified Survivable Remote Site Telephony Manager

Cisco Unified Survivable Remote Site Telephony(SRST)Manager は、支社の SRST、または従来の SRST を実行する Cisco Unified CME の配置を簡素化します。(図 10-4 を参照)。これは、シスコがサポートする仮想プラットフォーム(たとえば、Cisco UCS)の仮想マシン内で実行される Linux ベースのソフトウェアです。Cisco Unified SRST Manager は、Cisco Unified CM クラスタが中央のロケーションで動作する集中型呼処理配置モデルのみをサポートしています。Cisco Unified SRST Manager は、Cisco Unified CM クラスタとともに中央ロケーションで、またはリモート支社ロケーションで展開できます。図 10-4 は、中央ロケーションにある Cisco Unified SRST Manager の展開を示しています。通常の動作中に、Cisco Unified SRST Manager は Cisco Unified CM から定期的に設定(たとえば、コーリング サーチ スペース、パーティション、ハント グループ、コール パーク、コール ピック アップなど、設定されている場合)を取得し、SRST モードの使用についても同様の機能の支社ルータをプロビジョニングするためにアップロードします。したがって、Cisco Unified SRST Manager は支社の SRST ルータで必要な手動の設定を減らし、SRST と通常モードでも同様のコール操作を実現できるようにします。

図 10-4 中央ロケーションに配置された Cisco Unified Survivable Remote Site Telephony マネージャ

 

Cisco Unified SRST Manager は支社ルータをプロビジョニングするために Unified CM 設定をアップロードするときに WAN リンクからの帯域幅を消費します。Cisco Unified SRST Manager ソフトウェアはパケットのマーキングを実行しないため、Cisco Unified SRST Manager のトラフィックは、ネットワークのベスト エフォートとして伝送されます。シスコでは、このベストエフォート型マーキングを維持することを推奨します。これは IP Precedence 0(DSCP 0 または PHB BE)であり、リアルタイムの高優先度音声トラフィックに干渉しません。Cisco Unified SRST Manager トラフィックによる輻輳の発生を回避し、パケットのドロップ率を軽減するために、ピーク時以外の間(夜間や週末など)に設定のアップロードをスケジュールすることを推奨します。設定のアップロード スケジュールは、Cisco Unified SRST Manager の Web インターフェイスから設定できます。

Cisco Unified SRST Manager を配置する場合は、次の注意事項に従ってください。

Cisco Unified SRST Manager は、Cisco Unified Communications 500 シリーズ プラットフォームまたは、Cisco Business Edition 3000 および 5000 プラットフォームではサポートされません。

支社の音声ゲートウェイは、SRST ルータと共存する(ルータに存在する)必要があります。

Cisco Unified SRST Manager は、冗長化には対応していません。Cisco Unified SRST Manager が使用できない場合、設定のアップロードは不可能です。

Cisco Unified SRST Manager は、NAT が本社と支社の間で使用される展開ではサポートされていません。

集中型呼処理のバリエーションとしての Voice Over the PSTN

集中型呼処理配置は、サイト間音声メディアが WAN の代わりに PSTN を介して送信されるように調整できます。このように設定された場合、すべてのテレフォニー エンドポイントのシグナリング(呼制御)は、引き続き中央の Unified CM クラスタによって制御されます。したがって、この Voice over the PSTN(VoPSTN)モデル バリエーションでも、シグナリング トラフィック用に設定された適切な帯域幅を持つ、QoS 対応の WAN が必要になります。

VoPSTN が魅力的なオプションとなりえるであろう配置状況は、IP WAN 帯域幅が不足しているか、または PSTN 料金と比較して高価である場合や、Cisco Unified Communications システムがすでに配置されている状況で IP WAN 帯域幅のアップグレードを計画している場合などです。

VoPSTN 配置オプションの詳細情報および設計ガイドラインについては、次の URL にある『 Cisco Unified Communications System 9.0 SRND 』の「 Unified Communications Deployment Models 」の章の「VoPSTN」の項を参照してください。

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/models.html

分散型呼処理を使用するマルチサイト

分散型呼処理を使用するマルチサイト配置のモデルは、複数の独立したサイトから構成されています。各サイトには独自の呼処理エージェント クラスタがあり、そのエージェント クラスタは、分散されたサイト間の音声トラフィックを伝送する IP WAN に接続されます。図 10-5 は、標準的な分散型呼処理配置を示しています。

図 10-5 分散型呼処理を使用するマルチサイト配置

 

分散型呼処理モデルの各サイトは、次のいずれかになります。

独自の呼処理エージェントを使用する単一サイト。呼処理エージェントは、次のいずれかになります。

Cisco Unified Communications Manager(Unified CM)

Cisco Business Edition 6000

Cisco Unified Communications Manager Express(Unified CME)

その他の IP PBX

集中型呼処理サイトと、それに関連したすべてのリモート サイト。

Voice over IP(VoIP)ゲートウェイを備えたレガシー PBX。

分散型呼処理を使用するマルチサイト モデルの設計上の特長は、次のとおりです。

集中型トランクとダイヤル プランの集約プラットフォーム。このプラットフォームには、マルチ サイトの分散型呼処理配置におけるクラスタ間コール ルーティングおよびダイヤル プランを集約するために Session Initiation Protocol(SIP)プロキシ サーバも使用できますが、通常は Cisco Unified Communications Manager Session Management Edition(SME)のクラスタです。

集中型サービスには以下のものがあります。

集中型 PSTN アクセス

集中型ボイス メール

集中型会議

これらのサービスは中央に配置できるため、一元管理とスケール上の利点があります。エンド ユーザの状態を常に把握する必要のある IM およびプレゼンス機能に関しては、ユーザーは Unified CM クラスタと接続されていることに注意してください。

会議室ベースの TelePresence 会議システム用の Cisco VCS が Unified CM と連携して集中するマルチ サイト集中呼処理のリーフ システムでは、Unified CM および VCS 統合用に次の 2 つのオプションがあります。

VCS が Unified Communications ネットワークに新しく追加された場所では、各 VCS クラスタは、同じ場所にある Unified CM クラスタに直接接続できます。他の VCS へのコールと Unified CM クラスタは SME 経由でルーティングされます。同様に、VCS サーバが TelePresence エンドポイントが存在する各サイトに配置されている場合は、VCS 間コールが SME クラスタ経由でルーティングされるため、VCS Director は必要ありません。

一部の既存の VCS クラスタが VCS Director クラスタを介してだけ(つまり、VCS から Unified CM への接続なし)相互接続される場所では、コールが Unified CM と VCS エンドポイント間でルーティングできるように、VCS Director が SME クラスタと相互接続する必要があります。

同じサイト内のデバイス間の広帯域オーディオ(G.711 または G.722 など)、異なるサイトのデバイス間の狭帯域オーディオ(G.729 など)。

同じサイト内のデバイス間の広帯域ビデオ(4CIF または 720p での 1.5 Mbps から 1080p での 2 Mbps など)、異なるサイトのデバイス間の狭帯域ビデオ(448p または CIF での 384 kbps)。

最大 1.5 Mbps 以上の WAN リンク速度。速度が 1.5 Mbps 未満の WAN 接続ではビデオを 推奨しません

コール アドミッション制御は、Enhanced Locations CAC または RSVP によって実現されます。

IP WAN は、分散型呼処理のサイトをすべて相互接続します。一般に、PSTN は、IP WAN 接続に障害が起きたか、使用可能な帯域幅がすべて消費されてしまった場合に、サイト間のバックアップ接続の役目を果たします。PSTN のみで接続されているサイトは、独立サイトであり、分散型呼処理モデルには含まれません (「キャンパス」を参照)。

IP WAN の接続オプションは、次のとおりです。

専用回線

フレーム リレー

非同期転送モード(ATM)

ATM とフレーム リレーのサービス インターワーキング(SIW)

マルチプロトコル ラベル スイッチング(MPLS)バーチャル プライベート ネットワーク(VPN)

音声およびビデオ対応 IP セキュリティ プロトコル(IPSec)VPN(V3PN)

分散型呼処理モデルのベスト プラクティス

分散型呼処理を使用するマルチサイト配置には、単一サイトと同じ、または集中型呼処理を使用するマルチサイト配置と同じ要件が少なからずあります。分散型呼処理モデルについては、ここでリストされているベスト プラクティスに加えて、他のモデルのベスト プラクティスにも従ってください (「キャンパス」および 「集中型呼処理を使用するマルチサイト」を参照)。

分散型呼処理配置のダイヤル プラン集約プラットフォーム

Cisco Unified Communications Manager Session Management Edition クラスタ、または Session Initiation Protocol(SIP)プロキシ サーバは、マルチ サイト分散型呼処理配置におけるクラスタ間コール ルーティングおよびダイヤル プランの集約を提供するために使用できます。これらのダイヤル プラン集約デバイスの使用には、次のベスト プラクティスが適用されます。

Unified CM Session Management Edition クラスタ

Cisco Unified Communications Manager Session Management Edition は、分散型呼処理配置におけるクラスタ間コール ルーティングおよびダイヤル プランの集約で一般的に使用されています。クラスタ間コール ルーティングは、標準の数字ルート パターンの使用に基づく数値、またはクラスタ間のルックアップ サービス(ILS)の使用に基づく URI にすることができます。Unified CM Session Management Edition は複数のプロトコル(SIP、H.323、MGCP、および SCCP)をサポートし、複雑なトランクおよび数字操作機能を持ち、Enhanced Locations CAC および RSVP をサポートし、Unified CM と同じコードとユーザ インターフェイスを使用します。Unified CM Session Management Edition クラスタ配置は、通常は多くのトランクで構成され、Unified Communications エンドポイントはまったくないか、ほとんどありません。Unified CM Session Management Edition クラスタでは、Unified CM クラスタに利用できるすべてのハイ アベイラビリティ機能(WAN を介したクラスタリング、CallManager グループ、すべての Unified CM ノードでの実行など)を使用できます。

Unified CM Session Management Edition クラスタの配置の詳細については、次の URL の『 Cisco Unified Communizations Manager Session Management Edition Deployment Guide 』を参照してください。

http://www.cisco.com/en/US/products/ps10661/products_implementation_design_guides_list.html

SIP プロキシの配置

Cisco Unified SIP Proxy など、SIP プロキシは、コール ルーティングおよび SIP シグナリング正規化を提供します。

SIP プロキシの使用には、次のベスト プラクティスが適用できます。

SIP プロキシの適切な冗長性を確保します。

SIP プロキシのキャパシティが、ネットワークに必要なコール レートおよびコール数に対応していることを保証します。

分散型呼処理モデルのリーフ ユニファイド コミュニケーション システム

呼処理エージェントの選択は、多くの要素によって異なります。設計での主な要素は、サイトの規模および機能要件です。

分散型呼処理配置の場合、各サイトには独自の呼処理エージェントが存在する場合があります。各サイトの設計は、呼処理エージェント、必要な機能、および必要な耐障害性によって変わります。たとえば、500 台の電話機を備えたサイトでは、2 台のサーバを含む Unified CM クラスタは、1 対 1 の冗長性を提供することができ、バックアップ サーバは、パブリッシャおよびトリビアル ファイル転送プロトコル(TFTP)サーバとして使用されます。

IP ベース アプリケーションの要件も、呼処理エージェントの選択に大きな影響を与えます。これは、多くの Cisco IP アプリケーションをサポートするのは、Unified CM だけであるからです。

表 10-4 は、推奨される呼処理エージェントを示しています。

表 10-4 推奨される呼処理エージェント

呼処理エージェント
推奨規模
コメント

Cisco Unified Communications Manager Express(Unified CME)

最大 450 台の電話機

小規模なリモート サイト用

キャパシティは Cisco IOS プラットフォームに依存する

Cisco Business Edition 6000

最大 1,200 台の電話機

小中規模サイト用

集中型または分散型呼処理をサポートする

Cisco Unified Communications Manager(Unified CM)

50 ~ 40,000 台の電話機

Unified CM クラスタの規模に応じて、小規模から大規模までのサイト

集中型または分散型呼処理をサポートする

VoIP ゲートウェイを備えた従来の PBX

PBX に依存する

IP WAN コール数と機能は、PBX と VoIP ゲートウェイを接続するプロトコルおよびゲートウェイ プラットフォームによって異なる

Unified CM Session Management Edition

Cisco Unified CM Session Management Edition(SME)は基本的に、トランク インターフェイスだけを使用し、IP エンドポイントを使用しない Unified CM クラスタです。このクラスタには、リーフ システムと呼ばれる、複数のユニファイド コミュニケーション システムを集約できます。

Session Management Edition の配置は、複数の PBX 配置とそれに関連する電話を、IP フォンがあり比較的少数のトランクを持つ Unified CM クラスタに移行するために使用できます。Session Management Edition クラスタをサードパーティの PBX を相互接続する多数のトランクで開始し、何千もの IP フォンを持つ Unified CM クラスタ配置に徐々に移行することも可能です。

Cisco Unified CM Session Management Edition は、次の機能をサポートします。

H.323 Annex M1 クラスタ間トランク

SIP クラスタ間トランク

SIP トランク

H.323 トランク

MGCP トランク

ボイスコール

ビデオ コール

暗号化されたコール

FAX コール

また、Unified CM Session Management Edition を使用して、PSTN 接続、PBX、集中型のユニファイド コミュニケーション アプリケーションなど、サードパーティのユニファイド コミュニケーション システムに接続できます。(図 10-6 を参照)。ただし、標準の Unified CM クラスタと同様に、サードパーティ デバイスからの Unified CM Session Management Edition への接続は、実稼働環境で使用する前に相互運用性をテストしたシステムである必要があります。

図 10-6 Unified CM Session Management Edition を使用したマルチサイト配置

 

Unified CM Session Management Edition を配置する状況

次のいずれかの操作を行う場合は、Unified CM Session Management Edition を配置することを推奨します。

集中型ダイヤル プランの作成および管理

他のすべてのユニファイド コミュニケーション システムに接続するために各ユニファイド コミュニケーション システムに別個のダイヤル プランおよびトランクを設定するのではなく、Unified CM Session Management Edition を使用すると、Session Management クラスタを指す簡潔なダイヤル プランおよびトランクをリーフのユニファイド コミュニケーション システムに設定できます。Unified CM Session Management Edition には、集中型ダイヤル プランと、他のすべてのユニファイド コミュニケーション システムに到達するためのこのプランに対応する情報が含まれています。

集中型 PSTN アクセスの提供

Unified CM Session Management Edition を使用すると、1 つ(または複数)の集中型 PSTN トランクに PSTN アクセスを集約できます。集中型 PSTN アクセスには一般に、ブランチベースの PSTN 回線の削減または排除を伴います。

アプリケーションの集中化

Unified CM Session Management Edition の配置によって、会議やビデオ会議などの一般に使用されるアプリケーションを直接 Session Management クラスタに接続できるため、複数のトランクの管理によるリーフ システムへのオーバーヘッドが軽減されます。

Unified Communications システムに移行するために PBX を集約

Unified CM Session Management Edition は、レガシー PBX から Cisco Unified Communications システムへの移行の一環として、複数の PBX の集約ポイントを提供できます。

Unified CM Session Management Edition と標準の Unified CM クラスタの相違

Unified CM Session Management Edition ソフトウェアは、Unified CM と同じです。ただし、このソフトウェアは、この新しい配置モデルの要件と制約を満たすために大幅に強化されています。Unified CM Session Management Edition は、多数のトランクツートランク接続をサポートするように設計されているため、次に示す設計上の考慮事項に従う必要があります。

容量(Capacity)

Unified CM Session Management クラスタは、リーフの Unified Communications システム間(Unified CM クラスタと PBX など)、集中型 PSTN 接続間、および集中型アプリケーションへの予想される BHCA トラフィック ロードに基づいて正確にサイジングすることが重要です。使用している Unified Communications システムでのユーザの平均的な BHCA およびコール保留時間を判断し、その情報をシスコ アカウント システム エンジニア(SE)またはシスコ代理店と共有して、Unified CM Session Management Edition クラスタの規模を適切に決定してください。

トランク

可能な場合は、Unified CM トランク上での静的な MTP の使用は回避します(リーフ Unified CM または Unified CM Session Management Edition クラスタの SIP または H.323 トランク上で [MTP required] を有効にしてはなりません)。[MTP required] を使用しないトランクの場合、コーデックの選択の幅が広がり、音声、ビデオ、および暗号化がサポートされ、トランク コールは MTP リソースにアンカリングされません。トランクでは、動的に挿入された MTP を使用できます(たとえば、インバンドからアウトオブバンドに DTMF を変換する場合など)。サードパーティのユニファイド コミュニケーション システムで SIP アーリー オファーが必要とされる場合は、Unified CM SIP トランクで [Early Offer support for voice and video calls (insert MTP if needed)] を使用するか、Cisco Unified Border Element と一緒に [Delayed Offer to Early Offer] 機能を使用します。

WAN を介したクラスタリング

Unified CM 9.1 以降のリリースでは、SME の配置は、WAN を介したクラスタリングを使用する最長 500 ミリ秒のクラスタ ノード間のラウンドトリップ時間(RTT)をサポートします。この拡張 RTT は SME クラスタのみに適用され(標準の Unified CM クラスタ設計の最長 RTT は 80 ミリ秒です)に適用され、次の設計上の制限があります。

WAN を介したクラスタリングの拡張ラウンドトリップ時間使用した SME の配置は、SIP トランクだけでサポートされます。すべての SIP トランクは、コールが SME クラスタ内のノード間でルーティングされないように すべての Unified CM で実行 機能を使用する必要があります。(詳細については、「すべてのアクティブな Unified CM ノードでのルート リストの実行」の項を参照してください)。H.323 クラスタ間トランクおよび MGCP、SCCP、H323 の各ゲートウェイはサポートされません。

エンドポイントまたは CTI デバイスは SME クラスタに設定、または登録されません。

MTP、信頼されたリレー ポイント(TRP)、RSVP エージェント、トランスコーダなどのメディア リソースは、SME クラスタに設定または登録されません。

サイト間の Intra-Cluster Communication Signaling(ICCS)トラフィックに最低 1.544 Mbps(T1)の帯域幅が必要です。

Intra-Cluster Communication Signaling(ICCS)トラフィックに必要な帯域幅に加え、リモートからパブリッシャとなるあらゆるサブスクライバ サーバに対するデータベースおよびその他のサーバ間トラフィック用に、最低でも 1.544 Mbps(T1)の帯域幅が必要になります。

他のすべての SME 設計と同様に、SME 設計は、配置前にシスコの SME チームによる確認と承認が必要になります。


) SME クラスタのアップグレード プロセスは 2 つの主要部分で構成されています。1 つめはバージョンのスイッチオーバーで、呼処理ノードがリブートされ、新しいソフトウェア バージョンで初期化され(サーバあたり約 45 分かかります)。2 つめはデータベースの複製で、サブスクライバのデータベースがパブリッシャ ノードのデータベースと同期化されます。このデータベース複製フェーズの完了にかかる時間は、パブリッシャ ノードとサブスクライバ ノードの間の RTT とクラスタ内のサブスクライバの数によって異なります。データベース複製プロセスにはサブスクライバの呼処理機能への影響はほとんどなく、通常の SME クラスタ処理中にバックグラウンド処理として実行できます。


Unified CM バージョン

Unified CM Session Management Edition と Unified CM リーフ クラスタの両方とも、Cisco Unified CM 7.1(2) 以降のリリースと一緒に配置する必要があります。Cisco Unified CM 8.5 以降のリリースは、これらのバージョンが Unified CM および Session Management Edition クラスタを介してコール ルーティングを改善および簡素化する機能を含んでいるため推奨されます。それよりも前のバージョンの Unified CM も配置できますが、クラスタを Unified CM 7.1(2) 以降のリリースにアップグレードしないと解決できない問題が発生する可能性があります。

相互運用性

ほとんどのベンダーが標準に準拠していますが、各ベンダーによるプロトコルの実装には相違があります。標準の Unified CM クラスタの場合と同様に、実稼働環境にシステムを配置する前に、サードパーティの未検証のユニファイド コミュニケーション システムとのエンドツーエンドの相互運用性テストを実施することを強く推奨します。相互運用性テストでは、Unified CM Session Management クラスタを介したシスコおよびサードパーティのリーフ システムからのコール フローと機能を検証します。シスコの相互運用性チームによってテストされたサードパーティのユニファイド コミュニケーション システムの情報を得るには、次の Cisco Interoperability Portal サイトで提供している情報を参照してください。

http://www.cisco.com/en/US/solutions/ns340/ns414/ns728/interOp_ucSessionMgr.html

着信コールと発信コールのロード バランシング

Session Management クラスタ内の Unified CM サーバ間に着信コールと発信コールが均等に分散されるよう、Unified CM Session Management Edition およびリーフのユニファイド コミュニケーション システムのトランクを設定します。トランク コールのロード バランシングの詳細については、「Cisco Unified CM トランク」の章を参照してください。

設計のガイドラインとサポート

Unified CM Session Management Edition の設計と配置の詳細については、次の URL の『 Cisco Unified Communications Manager Session Management Edition Deployment Guide 』を参照してください。

http://www.cisco.com/en/US/products/ps10661/products_implementation_design_guides_list.html

Unified CM Session Management Edition の設計は、担当のシスコ SE が Cisco Unified CM Session Management チームと一緒に確認します。

デュアル呼制御配置の設計上の考慮事項

一般に、エンドポイントが Cisco Unified CM とサードパーティ呼制御プラットフォームに登録された配置は、ダイヤル プランおよびコール アドミッション制御に関する任意のコラボレーション ソリューションの設計を複雑なものにします。これらのデュアル呼制御配置では、Unified CM とサードパーティ呼制御プラットフォームは、いずれもコール アドミッション制御に独立した機能を使用し、独立したダイヤル プランがあるため、複雑さの度合いは使用される配置モデルによって決まります。

デュアル呼制御を備えたキャンパス配置では、コール アドミッション制御は必要なく、各呼制御システムのダイヤル プランは比較的単純です。つまり、エンドポイントが 1 台のシステムで検出できない場合は、コールは別のシステムに転送されます。(図 10-7 を参照)。

図 10-7 集中型および分散型サードパーティ システムを使用したデュアル呼制御配置

 

マルチ サイトの集中型呼処理配置では、通常、コール アドミッション制御とダイヤル プランの複雑さはトレードオフで示されます。Unified CM クラスタとサードパーティ呼制御プラットフォームが中央サイトのみに配置されている場合、ダイヤル プランは比較的単純ですが、各システムでコール アドミッション制御に使用される WAN 帯域幅を考慮する必要があります。サードパーティ製エンドポイントがあるリモートサイトに追加でサードパーティ製呼制御サーバーを配置する場合、コール アドミッション制御の複雑さは、ダイヤル プランをより細分化すると回避されます。こうしたトレードオフについては、次の項で詳しく説明します。

デュアル呼制御配置のコール アドミッション制御に関する考慮事項

コール アドミッション制御では、呼処理コンポーネントの全体的なコール キャパシティおよびネットワーク帯域幅に基づいて、所定の時間にネットワーク上で許可するコール数を制限することにより、ネットワーク帯域幅のオーバーサブスクリプションを回避するメカニズムを提供します。

デュアル呼制御配置では、Unified CM とサードパーティ呼制御プラットフォームは、いずれもコール アドミッション制御に独立した機能を使用します。

Unified CM クラスタとサードパーティ呼制御プラットフォームが中央サイトのみに配置されたマルチ サイトの集中型呼処理配置では、各プラットフォームがコール アドミッション制御に使用する帯域幅の WAN に考慮する必要があります。サードパーティ製エンドポイントがローカルに配置されたサードパーティ製呼制御システムに登録されたリモート サイトでは、これらのコール アドミッション制御の考慮事項を回避できます。

分散サードパーティ呼制御によるマルチ サイト集中型 Unified CM 配置

サードパーティ エンドポイントが存在するすべてのサイトで、サードパーティ製呼制御システムを使用するデュアル呼制御配置モデルは、Unified CM コール アドミッション制御と強固に統合できます。これは、サードパーティ呼制御システムから Unified CM への SIP トランクを各サイトに使用し、そのサイトにある Unified CM エンドポイントと同じ Unified CM ロケーションでこの SIP トランクを設定することによって実行できます。しかし、この方法で Unified CM とサードパーティ呼制御のコール アドミッション制御の問題を解決する一方で、多数のサードパーティ製呼制御システムがプロビジョニングされ、ネットワークのダイヤル プランが細分化します。

集中型サードパーティ呼制御によるマルチ サイト集中型 Unified CM 配置

Unified CM のように WAN を介して複数のサイトに存在するサードパーティ エンドポイントを提供するため、サードパーティ呼制御システムが中心になる場合があります。このタイプの配置では、サードパーティ呼制御システムは異なるサイトのサードパーティ製エンドポイント間のコールにコール アドミッション制御を提供します。同様に、集中型 Unified CM クラスタが、異なるサイトの Unified CM エンドポイント間のコールにコール アドミッション制御を提供します。Unified CM クラスタとサードパーティ製呼制御システムは独立したコール アドミッション制御機能を使用するため、Unified CM とサードパーティ製エンドポイントの両方が集中型呼制御配置にあるサイトで、Unified CM コール アドミッション制御とサードパーティ呼制御用の WAN に別々の帯域幅の量をプロビジョニングする必要があります。コールが同じサイトの Unified CM エンドポイントとサードパーティ製のエンドポイント間で発信された場合、コール アドミッション制御の帯域幅は、コールのメディア パスが WAN を通過しない場合でも、サードパーティ製呼制御システムと Unified CM クラスタの両方で減少します。この集中型コール処理設計は、コール アドミッション制御の点から見ると理想的ではありませんが、ハードウェアに関して、(エンドポイントが集中型 Unified CM クラスタまたは集中型サードパーティ製呼制御システムのみに登録されるため)コスト効率が高く、ダイヤル プランの細分化が軽減されます。

各環境は実際的なアプローチを実施する必要があります。戦略的な観点から、あらゆる支社にサードパーティ製呼制御システムを配置することは、現在では商用的に意味を成さない場合があります。ただし正確なコール アドミッション制御が設計の優先順位の場合、この配置モデルが適切なことがあります。同様に、集中型サードパーティの呼制御および集中型 Unified CM クラスタを使用した配置の場合、独立したコール アドミッション制御ドメインの問題は WAN のプロビジョニング帯域幅を超えた方法で対応できます。

デュアル呼制御配置におけるダイヤル プランに関する考慮事項

配置内に呼制御システムが 2 つしかなく、エンドポイントに対し番号が使用され、着信番号がローカル Unified CM クラスタまたはサードパーティ製呼制御システムのローカル パターンに一致した場合、コールはローカルに接続されたエンドポイントに送信されます。番号が別の(リモート)呼制御のパターンに一致した場合、コールは相互接続 SIP トランクを介した非ローカル エンドポイントに送信する必要があります。重複するダイヤル プランの場合、Unified CM クラスタとサードパーティ呼制御システムの両方が、内部に登録されているどのエンドポイントにも一致しないコールを他の呼制御クラスタに送信することができます。

配置内の呼制御システムが増加すると、ダイヤル プランの細分化も進みます。この問題は、複数の呼制御からのエンドポイントが同じサイト内に存在し、このエンドポイントに別の、または簡単な集約番号の範囲が設定されていない場合にさらに状況が悪化する可能性があります。この場合、デフォルト ルートは使用できず、各呼制御に関連付けられた番号の範囲の明示ルートを設定する必要があります。

英数字 URI が Unified CM とサードパーティ製呼制御システムに登録されたエンドポイントのアドレス指定とコールに使用される場合、コール ルーティングは配置に応じて、次のいずれかの方法で実施されす。

単一のサードパーティ製呼制御システムのみが、単一の SIP トランク経由で Unified CM クラスタとなって配置されている場合、1 つの呼制御にないエンドポイントへのコールが他の呼制御に送信されるように、デフォルト SIP ルートは Unified CM とサードパーティ製呼制御システムで設定できます。

複数のサードパーティ製呼制御システムを配置する場合は、URI ベースのコール ルーティング用に Unified CM クラスタでクラスタ間検索サービス(ILS)を使用します。Unified CM ユーザが URI にダイヤルし、Unified CM が URI がクラスタに登録されているかどうかを確認し、登録されていない場合は、Unified CM は、着信側 URI および対応するルート文字列がないかどうか ILS を検索します。ルート文字列は、URI が存在する呼制御クラスタを識別し、SIP ルート パターンとの照合に使用され、その後宛先 URI へ SIP トランクを介してコールを転送します。サードパーティ製呼制御システムに登録された URI ベースのエンドポイントの場合、サードパーティ製呼制御システムの対応ルート文字列とともに、サードパーティ呼制御システムに登録された URI のリストを ILS にインポートする必要があります。

IP WAN を介したクラスタリング

QoS 機能に対応している IP WAN によって相互接続される複数サイト間で、単一の Unified CM クラスタを配置できます。ここでは、WAN を介したクラスタリングの概要を簡潔に説明します。詳細については、「呼処理」の章を参照してください。

WAN を介したクラスタリングでは、次の 2 種類の配置方法がサポートされます。

「ローカル フェールオーバー配置モデル」

ローカル フェールオーバーでは、Unified CM サブスクライバ サーバとバックアップ サーバを同じサイトに配置し、これらのサーバ間に WAN を置かないことが必要です。このタイプの配置は、Unified CM を備えた 2 ~ 4 つのサイトに理想的です。

「リモート フェールオーバー配置モデル」

リモート フェールオーバーでは、WAN を介して分割されたプライマリとバックアップの呼処理サーバを配置できます。このタイプの配置を使用すると、Unified CM サブスクライバを備えた複数のサイトを、別のサイトにある Unified CM サブスクライバでバックアップすることが可能です。


) リモート フェールオーバーの配置では、サブスクライバ サーバ間で大量のクラスタ内トラフィックが流れるため、広い帯域幅が必要になる場合があります。


また、2 つの配置モデルを組み合わせて、特定のサイト要件を満たすことも可能です。たとえば、2 つのメイン サイトにプライマリ サブスクライバとバックアップ サブスクライバを配置し、別の 2 つのサイトにはそれぞれプライマリ サーバのみを配置し、2 つのメイン サイトにある共用バックアップまたは専用バックアップのどちらかを使用できます。

WAN を介したクラスタリングの主な利点として、次のようなものが挙げられます。

クラスタ内の全サイトに対してユーザを 1 箇所で管理

機能の透過性

シェアド ライン アピアランス

クラスタ内のエクステンション モビリティ

統一ダイヤル プラン

これらの機能により、このソリューションは、ビジネスが継続して行われるサイトのディザスタ リカバリ プランとして、または複数の中小規模サイト用の単一ソリューションとして理想的なものになります。

WAN の考慮事項

WAN を介したクラスタリングが成功するには、WAN 自体のさまざまな特性を慎重に計画し、設計し、実装する必要があります。Unified CM サーバ間の Intra-Cluster Communication Signaling(ICCS)は、複数のトラフィック タイプから構成されます。ICCS のトラフィック タイプは、優先またはベストエフォートのどちらかとして分類されます。優先 ICCS トラフィックには、IP Precedence 3(DSCP 24 または PHB CS3)が付けられます。ベストエフォート型 ICCS トラフィックには、IP Precedence 0(DSCP 0 または PHB BE)が付けられます。さまざまなタイプの ICCS トラフィックについては、「クラスタ内通信」で説明されています。この項では、プロビジョニングについてのさらに詳しいガイドラインも記述されています。WAN の特性には、次の設計上のガイドラインが適用されます。

遅延

任意の 2 台の Unified CM サーバ間の片方向の最大遅延は 40 ミリ秒、つまり 80 ミリ秒ラウンドトリップ時間(RTT)以下でなければなりません。遅延の測定については、「遅延のテスト」を参照してください。2 つのサイト間の伝搬遅延は、他のネットワーク遅延を考慮しない場合、1 キロメートルあたり 6 マイクロ秒になります。これは、40 ミリ秒遅延に対して理論的な最大距離約 6,000 km、つまり約 3,720 マイルに相当します。この距離は、相対的なガイドラインとしてのみ記載されています。実際には、ネットワーク内の他の遅延により、これより短くなります。

ジッタ

ジッタは、処理、キュー、バッファ、輻輳、またはパス変動遅延により、パケットがネットワークを介して受ける変動遅延です。IP Precedence 3 ICCS トラフィックのジッタは、Quality of Service(QoS)機能を使用して最小限に抑える必要があります。

パケット損失とエラー

ネットワークは、すべての ICCS トラフィック、特に優先 ICCS トラフィックに対して、十分な優先順位付き帯域幅を提供するように設計される必要があります。標準的な QoS メカニズムを実装して、輻輳とパケット損失を回避する必要があります。回線エラーや他の「現実的な」状況によってパケットが損失した場合、ICCS パケットは再送信されます。これは、高信頼性伝送のために TCP プロトコルが使用されているからです。再送信が行われると、セットアップ、接続解除(終了)、または他の付加サービスの実行中に、コールが遅延する場合があります。パケット損失の状況によっては、コールが失われる可能性があります。ただし、このシナリオ以上に、T1 または E1 上でエラーが発生することが考えられます。このエラーは、トランクを介した PSTN /ISDN へのコールに影響を及ぼします。

帯域幅

予想されるコール ボリューム、デバイスのタイプ、およびデバイス数に対して、各サーバ間で適切な帯域幅を提供してください。この帯域幅は、サイト間の音声や映像のトラフィックを含めて、ネットワークを共有する他のアプリケーション用のその他の帯域幅とは別に必要です。提供される帯域幅では、さまざまなクラスのトラフィックに優先順位付けとスケジューリングを行うために、QoS が使用可能になっていなければなりません。帯域幅は、一般的に多めに設定し、少なめにサブスクライブします。

Quality of Service

ネットワーク インフラストラクチャは、QoS 技術を使用して、一貫した予測可能なエンドツーエンド レベルのサービスをトラフィックに提供します。QoS も帯域幅も、それだけでは解決法になりません。QoS が使用可能になった帯域幅を、ネットワーク インフラストラクチャに設計する必要があります。

クラスタ内通信

一般に、クラスタ内通信とは、サーバ間のすべてのトラフィックを意味します。Intra-Cluster Communication Signaling(ICCS)と呼ばれるリアルタイム プロトコルもあります。このプロトコルは、クラスタ内の各サーバまたはノードにおける呼処理の中心である、Cisco CallManager Service プロセスとの通信を提供します。

サーバ間のクラスタ内トラフィックは、次のものから構成されます。

主な設定情報を提供する IBM Informix Dynamic Server(IDS)データベースからのデータベース トラフィック。IDS トラフィックは、Cisco QoS の推奨事項に沿って再優先順位付けが行われ、より高い優先順位のデータ サービスになります(たとえば、特定のビジネス ニーズによって必要な場合は IP Precedence 1)。この一例は、IDS データベース設定を使用する、エクステンション モビリティの拡張使用です。

サブスクライバをパブリッシャに認証し、パブリッシャのデータベースにアクセスするために使用されるファイアウォール管理トラフィック。管理トラフィックは、クラスタ内のすべてのサーバ間を通過します。管理トラフィックは、Cisco QoS の推奨事項に沿って優先順位付けが行われ、より高い優先順位のデータ サービスになります(たとえば、特定のビジネス ニーズによって必要な場合は IP Precedence 1)。

ICCS リアルタイム トラフィック。このトラフィックは、シグナリング、コール アドミッション制御、および開始と終了時のコールについてのその他の情報から構成されます。ICCS は、Cisco CallManager Service が使用可能になっているすべてのサーバ間で、伝送制御プロトコル(TCP)接続を使用します。この接続は、これらのサーバ間でフルメッシュです。このトラフィックは、優先 ICCS トラフィックであり、Cisco CallManager リリースおよびサービス パラメータ設定に応じてマークされます。

CTI Manager リアルタイム トラフィック。このトラフィックは、コールに関係する CTI デバイスに使用されるか、Unified CM サーバ上のその他のサードパーティ製デバイスの制御またはモニタに使用されます。このトラフィックは、優先 ICCS トラフィックとしてマークされ、CTI Manager を備えた Unified CM サーバと、CTI デバイスを備えた Unified CM サーバとの間に存在します。


) Unified CM サーバ間のトラフィックの種類について詳しくは、http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html の TCP および UDP のポートの使用に関するドキュメントを参照してください。


Unified CM パブリッシャ

パブリッシャ サーバは、部分的なマスター データベースの読み取り専用コピーをクラスタ内の他のすべてのサーバに複製します。データベースのほとんどの変更は、パブリッシャで行われます。クラスタ内の別のサーバが到達不能である期間に、パブリッシャのマスター データベースに管理目的の更新などの変更が加えられた場合、パブリッシャは、通信が再確立されたときに、更新されたデータベースを複製します。ユーザ方向の呼処理機能に対するデータベースの変更は、IP Phone が登録されるサブスクライバ サーバで行われます。これらの機能には、次のものがあります。

Call Forward All(CFA)

メッセージ待機インジケータ(MWI)

プライバシーの有効/無効

Do Not Disturb(DND)の有効/無効

エクステンション モビリティ(EM)のログイン

モニタ(将来的に使用、現在ユーザ レベルの更新はありません)

ハント グループのログアウト

デバイス モビリティ

エンド ユーザおよびアプリケーション ユーザの CTI Certificate Authority Proxy Function(CAPF)ステータス

クレデンシャルのハッキングと認証

各サブスクライバ サーバは、これらの変更をクラスタ内の他のすべてのサーバに複製します。パブリッシャが到達不能またはオフラインの間は、他のいかなる設定変更もデータベースに加えることはできません。パブリッシャに障害が発生している場合でも、次のものをはじめとするクラスタの通常の操作の大部分は、影響を 受けません

呼処理

フェールオーバー

設定済みデバイスの登録

これ以外のサービスやアプリケーションも影響を受ける場合があります。したがって、パブリッシャなしで機能するかどうかを配置時に確認する必要があります。

コール詳細レコード(CDR)およびコール管理レコード(CMR)

コール詳細レコードとコール管理レコードが使用可能である場合、各サブスクライバによって収集され、定期的にパブリッシャにアップロードされます。パブリッシャが到達不能である期間中、CDR および CMR は、サブスクライバのローカル ハードディスクに保存されます。パブリッシャとの接続が再確立されると、未処理の CDR はすべて、パブリッシャにアップロードされます。パブリッシャは、レコードを CDR 分析とレポート(CAR)データベースに格納します。

遅延のテスト

任意の 2 台のサーバ間の最大ラウンドトリップ時間(RTT)は、80 ミリ秒以下でなければなりません。この制限には、この 2 台のサーバ間の伝送パスの遅延がすべて含まれる必要があります。Unified CM サーバで ping ユーティリティを使用してラウンドトリップの遅延を確認しても、正確な結果は得られません。ping は、ベストエフォート型のパケットとして送信されます。ICCS トラフィックと同じ QoS 対応パスを使用して転送されません。したがって、遅延を確認するには、Unified CM サーバに最も近いネットワーク デバイスを使用することを推奨します。理想的には、サーバが接続されているアクセス スイッチです。Cisco IOS は、ICCS トラフィックが通過するのと同じ QoS 対応パス上で ping パケットが送信されるように、レイヤ 3 タイプ オブ サービス(ToS)ビットを設定できる拡張 ping を備えています。拡張 ping によって記録される時間は、ラウンドトリップ時間(RTT)、つまり通信パスを通過して戻るのに要する時間です。

次に、IP precedence を 3 に設定した Cisco IOS 拡張 ping の例を示します(ToS バイトは 96 に設定)。

Access_SW#ping
Protocol [ip]:
Target IP address: 10.10.10.10
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]: 96
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
 

エラー率

予想されるエラー率はゼロでなければなりません。エラー、パケットのドロップ、または IP ネットワークに対するその他の障害は、クラスタの呼処理パフォーマンスに影響を与える可能性があります。これは、ダイヤル トーンの遅延、IP Phone 上のキーやディスプレイの反応の遅れ、またはオフフックしてから音声パスの接続までの遅れによって気付く場合があります。Unified CM はランダム エラーに対する許容性がありますが、クラスタのパフォーマンス低下を避けるために、エラーを回避する必要があります。

トラブルシューティング

クラスタ内の Unified CM サブスクライバが、予想より高い遅延、エラー、またはパケットのドロップにより、ICCS 通信の障害を検出する場合、次の症状のいくつかが発生する場合があります。

クラスタ内のリモート Unified CM サーバ上にある IP Phone、ゲートウェイ、またはその他のデバイスが、一時的に通信不能になることがあります。

コールの接続が切断されたり、コールのセットアップ中に失敗する場合があります。

ユーザにダイヤル トーンが聞こえるまでに、予想以上に長い遅延が起こる場合があります。

Busy Hour Call Completions(BHCC)が低い場合があります。

ICCS(SDL セッション)がリセットされたり、接続が切断されることがあります。

ユーザをアップグレードし、パブリッシャとデータベースの同期をとることにかかった時間が増加します。

要約すると、ICCS 通信の問題のトラブルシューティングを行うには、次のタスクを実行します。

サーバ間の遅延を検証する

エラーやパケットのドロップがないかどうか、すべてのリンクを調べる

QoS が正常に設定されていることを確認する

すべてのトラフィックをサポートするために、キューに対して、WAN を介した十分な帯域幅が提供されることを確認する

ローカル フェールオーバー配置モデル

ローカル フェールオーバー配置モデルは、WAN を介したクラスタリングに対する最大の復元性があります。このモデルの各サイトには、少なくとも 1 つのプライマリ Unified CM サブスクライバと 1 つのバックアップ サブスクライバがあります。この設定では、最大 4 つのサイトをサポートできます。電話機および他のデバイスの最大数は、配置されているサーバの数とタイプによって異なります。全サイトの IP Phone の最大総数は 40,000 です。(図 10-8 を参照)。

図 10-8 ローカル フェールオーバー モデルの例

 

リモート フェールオーバー モデルを実装する場合は、次のガイドラインに従ってください。

少なくとも 1 つのプライマリ Unified CM サブスクライバと 1 つのバックアップ サブスクライバを含むように、各サイトを設定します。

Unified CM の グループ デバイス プール を設定して、サイト内のデバイスが、あらゆる状況でそのサイトのサーバだけに登録されるようにします。

各サイトで主要なサービス(TFTP、DNS、DHCP、LDAP、および IP Phone サービス)、すべてのメディア リソース(会議ブリッジと保留音)、およびゲートウェイを複製します。複製を確実に行い、最大レベルの復元性を得るよう、シスコは強く推奨します。また、この方法を拡張して、各サイトにボイスメール システムを組み込むこともできます。

WAN 障害が発生した場合、パブリッシャ データベースへのアクセスがないサイトでは、いくつかの機能を使用できないことがあります。たとえば、リモート サイトのシステム管理者は、設定を一切追加、変更、または削除することができません。ただし、ユーザは、「Unified CM パブリッシャ」 の項にリストされているユーザ方向の機能に、引き続きアクセスできます。

WAN 障害が発生した状態では、コールを発信するサブスクライバと現在通信していない電話番号にコールを発信すると、ファストビジー トーンが聞こえるか、またはコール転送されます(ボイスメールまたは Call Forward Unregistered で設定された宛先に転送される可能性があります)。

Unified CM クラスタ内の任意の 2 台のサーバ間に可能な最大ラウンドトリップ時間(RTT)は、80 ミリ秒です。


) ラウンドトリップ遅延時間が長く、最繁時呼数(BHCA)が多い状況では、音声のカットスルー遅延が大きくなる場合があり、音声コール確立時の初期音声クリッピングの原因となる場合があります。


WAN を介してクラスタリングされている各サイトと他のすべてのサイト間の Intra-Cluster Communication Signaling(ICCS)に最低 1.544 Mbps(T1)の帯域幅が必要です。たとえば、3 か所のサイトが WAN を介してクラスタリングされると、各サイトで呼制御トラフィック用の WAN 帯域幅の 2 * 1.544 Mbps が必要です。呼制御トラフィック用のこの最小帯域幅要件は、1 つのサイトから別のサイトへの最大 10,000 の最繁時呼数(BHCA)から構成され、電話番号が WAN を介してクラスタリングされるサイト間で共有されない配置にのみ適用されます。特定の遅延が発生している共有されていないディレクトリ番号間での、10,000 BHCA を超えるトラフィックの帯域幅を計算する場合は、次の計算式をガイドラインとして使用できます。

合計帯域幅(Mbps)=(合計 BHCA/10,000)∗(1 + 0.006 ∗ 遅延)、遅延 = RTT 遅延(ミリ秒単位)

この呼制御トラフィックは、優先トラフィックに分類されます。優先 ICCS トラフィックには、IP Precedence 3(DSCP 24 または PHB CS3)が付けられます。

Intra-Cluster Communication Signaling(ICCS)トラフィックに必要な帯域幅に加え、リモートからパブリッシャとなるあらゆるサブスクライバ サーバに対するデータベースおよびその他のサーバ間トラフィック用に、最低でも 1.544 Mbps(T1)の帯域幅が必要になります。

WAN を介して CTI Manager も配置するお客様の場合(図 10-9 を参照)、次の式を使用して、CTI Manager サービスが実行されている Unified CM サブスクライバと CTI エンドポイントの登録先 Unified CM サブスクライバ間の CTI Intra-Cluster Communication Signaling(ICCS)トラフィックの帯域幅(Mbps)を計算できます。

Unified CM 8.6(1) 以前のリリース:CTI ICCS 帯域幅(Mbps)
= (合計 BHCA/10,000) ∗ 1.25

Unified CM 8.6(2) 以降のリリース:CTI ICCS 帯域幅(Mbps)
= (合計 BHCA/10,000) ∗ 0.53

図 10-9 WAN を介した CTI

 

J/TAPI アプリケーションが Unified CM サブスクライバから離れている配置では(図 10-10 を参照)、次の式を使用して、Unified CM 8.6(2) 以降のリリースの一般的な J/TAPI アプリケーションの Quick Buffer Encoding(QBE)J/TAPI 帯域幅を計算できます。

J/TAPI 帯域幅(Mbps)=(合計 BHCA/10,000) ∗ 0.28

帯域幅は、J/TAPI アプリケーションによって異なる場合があります。帯域幅要件については、アプリケーションの開発者またはプロバイダーに確認してください。

図 10-10 WAN を介した J/TAPI

 

例 10-1 2 つのサイトの帯域幅の計算

Unified CM を配置した 2 つのサイト(サイト 1、サイト 2)があると仮定します。2 つのサイトは WAN を介してクラスタリングされており、ラウンドトリップ時間は 80 ミリ秒です。サイト 1 にはパブリッシャが 1 つと、TFTP および保留音(MoH)を組み合わせたサーバが 1 つ、そして 2 つの Unified CM サブスクライバ サーバが配置されています。サイト 2 には TFTP/MoH サーバが 1 つと、Unified CM サブスクライバ サーバが 2 つ配置されています。サイト 1 には 5000 台の電話機があり、それぞれ 1 つの DN を持っています。サイト 2 にも 5000 台の電話機があり、それぞれ 1 つの DN を持っています。最繁時は、サイト 1 の 2500 台の電話機がサイト 2 の 2500 台の電話機を呼び出します。それぞれのコールは、3 BHCA です。同じ最繁時に、サイト 2 の 2500 台の電話機もサイト 1 の 2500 台の電話機を呼び出します。それぞれのコールは、3 BHCA です。この場合、次のように計算します。

最繁時の合計 BHCA = 2500 ∗ 3 + 2500 ∗ 3 = 15,000

サイト間に必要な合計帯域幅 = 合計 ICCS 帯域幅 + 合計データベース帯域幅

合計 BHCA が 15,000 であり、10,000 を超えているため、合計 ICCS 帯域幅 =(15,000/10,000)∗(1 + 0.006 ∗ 80)= 2.22 Mbps という計算式を使用できます。

合計データベース帯域幅 =(パブリッシャからリモートとなるサーバの数)∗ 1.544 = 3 ∗ 1.544 = 4.632 Mbps

サイト間で必要な帯域幅 = 2.22 Mbps + 4.632 Mbps = 6.852 Mbps(およそ 7 Mbps)

WAN を介してクラスタリングされているサイト間でディレクトリ番号が共有されている場合は、さらに帯域幅を確保する必要があります。最低限必要な 1.544 Mbps の帯域幅に加え、このようなオーバーヘッドと追加帯域幅が必要になります。共有 DN 間での 10,000 BHCA のトラフィックの場合、次の計算式を使用して計算できます。

オーバーヘッド =(0.012 ∗ 遅延 ∗ シェアド ライン)+(0.65 ∗ シェアド ライン)、各値の意味は次のとおりです。

遅延 = IP WAN を介した RTT 遅延(ミリ秒単位)

シェアド ライン = WAN 経由でディレクトリ番号が共有されている追加の電話機の平均数

特定の遅延が発生している共有されているディレクトリ番号間での、10,000 BHCA を超えるトラフィックの帯域幅を計算する場合は、次の計算式をガイドラインとして使用できます。

合計帯域幅(Mbps)=(合計 BHCA/10,000)∗(1 + 0.006 ∗ 遅延 + 0.012 ∗ 遅延 ∗ シェアド ライン + 0.65 ∗ シェアド ライン)、各値の意味は次のとおりです。

遅延 = RTT 遅延(ミリ秒単位)

シェアド ライン = WAN 経由でディレクトリ番号が共有されている追加の電話機の平均数

例 10-2 ディレクトリ番号を共有する 2 つのサイトの帯域幅の計算

Unified CM を配置した 2 つのサイト(サイト 1、サイト 2)があると仮定します。2 つのサイトは WAN を介してクラスタリングされており、ラウンドトリップ時間は 80 ミリ秒です。サイト 1 にはパブリッシャが 1 つと、TFTP および保留音(MoH)を組み合わせたサーバが 1 つ、そして 2 つの Unified CM サブスクライバ サーバが配置されています。サイト 2 には TFTP/MoH サーバが 1 つと、Unified CM サブスクライバ サーバが 2 つ配置されています。サイト 1 には 5000 台の電話機があり、それぞれ 1 つの DN を持っています。サイト 2 にも 5000 台の電話機がありますが、それぞれがサイト 1 の 5000 台の電話機と DN を共有しています。そのため、各 DN は WAN 経由で共有され、平均して 1 台の追加の電話機を持つことになります。最繁時は、サイト 1 の 2500 台の電話機がサイト 2 の 2500 台の電話機を呼び出します。それぞれのコールは、3 BHCA です。これにより、サイト 1 の電話機も呼び出すことになります。同じ最繁時に、サイト 2 の 2500 台の電話機がサイト 1 の 2500 台の電話機を呼び出します。それぞれのコールは、3 BHCA です。これにより、サイト 2 の電話機も呼び出すことになります。この場合、次のように計算します。

最繁時の合計 BHCA = 2500 ∗ 3 + 2500 ∗ 3 = 15,000

サイト間に必要な合計帯域幅 = 合計 ICCS 帯域幅 + 合計データベース帯域幅

合計 BHCA が 15,000 であり、10,000 を超えているため、合計 ICCS 帯域幅 = (15,000/10,000) ∗ (1 + 0.006 ∗ 80 + 0.012 ∗ 80 ∗ 1 + 0.65 ∗ 1) = 4.635 Mbps という計算式を使用できます。

合計データベース帯域幅 =(パブリッシャからリモートとなるサーバの数)∗ 1.544 = 3 ∗ 1.544 = 4.632 Mbps

サイト間で必要な帯域幅 = 4.635 Mbps + 4.632 Mbps = 9.267 Mbps(およそ 10 Mbps)


) 上記の帯域幅は、ICCS、データベース、およびその他のサーバ間トラフィックに限定したものです。コールが IP WAN を経由する場合は、コールに使用する音声コーデックに応じて、音声またはメディア トラフィック用に追加の帯域幅をプロビジョニングする必要があります。


クラスタ内のサブスクライバ サーバは、ローカル データベースを読み取ります。データベースの変更は、変更のタイプに応じて、ローカル データベースとパブリッシャのデータベースの両方で発生する可能性があります。クラスタ内のさまざまなサーバの同期には、Informix Dynamic Server(IDS)のデータベース複製が使用されます。そのため、長期間にわたる WAN 接続の喪失など、障害状態から回復する場合は、障害時に行われた可能性があるあらゆる変更と Unified CM データベースを同期する必要があります。このプロセスは、パブリッシャとクラスタ内のその他のサーバへのデータベース接続が復元されると、自動的に実行されます。低帯域幅のリンクや遅延が大きいリンクでは、このプロセスに時間がかかる場合があります。また、まれなケースですが、手動によるリセットやサーバ間でのデータベース複製の修復が必要になる場合もあります。この操作は、コマンドライン インターフェイス(CLI)で utils dbreplication repair all utils dbreplication reset all などのコマンドを使用して実行します。WAN を経由して、リモートのサブスクライバでデータベース複製の修復またはリセットを実行すると、クラスタ内のすべての Unified CM データベースが再同期されます。この場合、1.544 Mbps を超える帯域幅が必要になる場合があります。パブリッシャおよびサブスクライバ ノード間の長い遅延、低帯域幅では、データベース複製の修復またはリセットが完了するまで時間がかかることがあります。


) 同一のリモート ロケーションにある複数のサブスクライバに対して、データベース複製の修復またはリセットを実行すると、データベース複製の完了に時間がかかる場合があります。このようなリモートのサブスクライバのデータベース複製を修復またはリセットする場合は、1 つずつ実行することを推奨します。異なるリモート ロケーションにあるサブスクライバのデータベース複製を修復またはリセットする場合は、同時に実行できます。


集中型呼処理を使用するリモート支社を、WAN を介したクラスタリングを使用してメイン サイトに接続する場合は、WAN を介したクラスタリングに使用されるリンクがオーバーサブスクリプションにならないよう、慎重にコール アドミッション制御を設定します。

WAN を介したクラスタリングに使用されるリンク上で帯域幅が制限されていない場合(つまり、リンクへのインターフェイスが OC-3s または STM-1s で、コール アドミッション制御に関する要件がない場合)は、リモート サイトがメイン サイトのいずれかに接続される場合があります。これは、すべてのメイン サイトでロケーションを Hub_None として設定する必要があるためです。この設定が行われても、コール アドミッション制御に使用するハブアンドスポーク トポロジは保持されます。

マルチプロトコル ラベル スイッチング(MPLS)バーチャル プライベート ネットワーク(VPN)機能を使用している場合は、Unified CM ロケーションとリモート サイトにあるすべてのサイトが、メイン サイトのいずれかに登録される場合があります。

メイン サイト間の帯域幅が制限されている場合は、サイト間でコール アドミッション制御を使用し、ロケーションが Hub_None として設定されているメイン サイトにすべてのリモート サイトを登録する必要があります。このメイン サイトはハブ サイトと見なされ、それ以外のリモート サイトと、クラスタオーバー WAN サイトはすべて、スポーク サイトとなります。

ソフトウェア アップグレード時は、ソフトウェア リリース ノートで説明されている標準のアップグレード手順を使用して、クラスタ内のすべてのサーバを同じ保守期間内にアップグレードする必要があります。IP WAN 経由のラウンドトリップ遅延時間が大きい場合は、ソフトウェア アップグレードにかかる時間が長くなります。また、1.544 Mbps(T1 リンク)などの低帯域幅でも、ソフトウェア アップグレード プロセスの完了に時間がかかる場合があります。このような状況でアップグレード プロセスの速度を向上させるには、1.544 Mbps を超える帯域幅が望ましい場合があります。

ローカル フェールオーバーに対する Unified CM のプロビジョニング

ローカル フェールオーバー モデルに対する Unified CM クラスタのプロビジョニングは、「呼処理」の章で説明されているキャパシティについての設計上のガイドラインに従う必要があります。WAN を介してサイト間の音声コールまたはビデオ コールが可能である場合、サイト間のコール アドミッション制御を提供するために、他のサイトのデフォルト ロケーションに加えて、Unified CM の ロケーション も設定する必要があります。デバイス数に対して帯域幅が余分にプロビジョニングされる場合でも、ロケーションに基づくコール アドミッション制御を設定するのが最良の方法です。ロケーションベースのコール アドミッション制御によってコールが拒否された場合は、自動代替ルーティング(AAR)機能によって PSTN への自動フェールオーバーを行うことができます。

冗長性とアップグレード時間を改善するために、2 台の Unified CM サーバで Cisco Trivial File Transfer Protocol(TFTP)サービスを使用可能にすることを推奨します。クラスタ内には 3 台以上の TFTP サーバを配置できますが、そのような構成ではすべての TFTP サーバ上ですべての TFTP ファイルを再構築するために時間がかかります。

サイトやサーバの利用可能なキャパシティに応じて、パブリッシャ サーバまたはサブスクライバ サーバのどちらかで、TFTP サービスを実行できます。TFTP サーバ オプションは、サイトごとに DHCP サーバ上で正しく設定する必要があります。DHCP を使用していないか、TFTP サーバが手動で設定される場合、ユーザが、サイトの正しいアドレスを設定する必要があります。

WAN の障害時に Unified CM の正常な動作に影響を与える可能性がある他のサービスも、連続したサービスを確保するために、すべてのサイトで複製されなければなりません。これらのサービスには、DHCP サーバ、DNS サーバ、社内電話帳、および IP Phone サービスがあります。各 DHCP サーバで、ロケーションごとに DNS サーバ アドレスを正しく設定してください。

IP Phone は、サイト間のシェアド ライン アピアランスを備えている場合があります。WAN の障害時に、各ライン アピアランスの呼制御は分割されますが、WAN が回復された後、呼制御は 1 つの Unified CM サーバに戻ります。WAN の回復中に、2 つのサイト間には追加のトラフィックがあります。コール量が多い時期にこの状態が起きると、その期間中、シェアド ラインが予想どおりに動作しない場合があります。この状態が数分以上続くことはありませんが、これが問題になる場合は、影響を最小限に抑えるために、追加の優先順位付き帯域幅を設定できます。

ローカル フェールオーバー用のゲートウェイ

ゲートウェイは、通常、どのサイトにも配置されていて、PSTN へのアクセスに対応しています。ゲートウェイを同一サイトの Unified CM サーバに登録するために、デバイス プールを設定する必要があります。サイトのローカル ゲートウェイを PSTN アクセス用の第一選択肢として選択し、他のサイトのゲートウェイをオーバーフロー用の第二選択肢として選択するために、コール ルーティング(ルート パターン、ルート リスト、およびルート グループ)も設定する必要があります。各サイトで緊急用サービスへのアクセスを確保するように特に注意してください。

WAN 障害時にアクセスが必要のない場合、および WAN を介したコール数に対して十分な追加帯域幅が設定される場合、PSTN ゲートウェイへのアクセスを集中させることができます。E911 要件に対応するために、各サイトで追加のゲートウェイが必要な場合があります。

ローカル フェールオーバー用のボイスメール

Cisco Unity Connection や他のボイスメール システムは、すべてのサイトに配置が可能で、Unified CM クラスタに組み込むことができます。この設定では、WAN 障害時に PSTN を使用しなくても、ボイスメールにアクセスできます。ボイスメール プロファイルを使用すると、同じロケーションにある IP Phone に、サイトに適したボイスメール システムを割り当てることができます。SMDI プロトコルを使用するボイスメール システム、サブスクライバ上の COM ポートに直接接続されたボイスメール システム、および Cisco Messaging Interface(CMI)を使用するボイスメール システムを、クラスタごとに最大 4 つ設定できます。

ローカル フェールオーバーに対する保留音とメディア リソース

各サイトでは、保留音(MoH)サーバや、他の会議ブリッジなどのメディア リソースに、ユーザのタイプおよび数に十分なキャパシティをプロビジョニングする必要があります。メディア リソース グループ(MRG)とメディア リソース グループ リスト(MRGL)の使用により、メディア リソースは、オンサイト リソースによって提供され、WAN 障害時に使用できます。

リモート フェールオーバー配置モデル

リモート フェールオーバー配置モデルでは、バックアップ サーバを柔軟に配置できます。各サイトには、少なくとも 1 つのプライマリ Unified CM サブスクライバを含め、バックアップ サブスクライバを必要に応じて配置します。このモデルでは、「呼処理」の章で説明されている 1:1 冗長性と 50/50 ロード バランシングを使用する場合、IP Phone と他のデバイスが通常ローカル サブスクライバに登録されている複数のサイトを配置できます。バックアップ サブスクライバは、他の 1 つ以上のサイトで、WAN を介して配置されます (図 10-11 を参照)。

図 10-11 4 サイト構成のリモート フェールオーバー モデル

 

リモート フェールオーバー モデルを実装する場合は、ローカル フェールオーバー モデルのガイドライン(「ローカル フェールオーバー配置モデル」を参照)と、次の変更点に従ってください。

少なくとも 1 つのプライマリ Unified CM サブスクライバと、必要に応じてオプションのバックアップ サブスクライバを含むように、各サイトを設定します。IP WAN を経由したバックアップ サブスクライバを設定しない場合は、Survivable Remote Site Telephony(SRST)ルータをバックアップの呼処理エージェントとして使用できます。

Unified CM の グループ デバイス プール を設定して、デバイスが第 2 または第 3 の選択肢として WAN を越えたサーバに登録できるようにします。

デバイスが、WAN を介して同じクラスタ内のリモート Unified CM サーバに登録される場合、シグナリング トラフィックまたは呼制御トラフィックのために帯域幅を追加する必要があります。この帯域幅は、ICCS トラフィックより大きくなる場合があります。また、シグナリングに関する帯域幅のプロビジョニング計算を使用して計算する必要があります(「帯域幅のプロビジョニング」を参照)。


) ディザスタ リカバリを目的として、これら 2 つのタイプの配置の機能を組み合わせることもできます。たとえば、Unified CM のグループでは、最大 3 台のサーバ(1 次、2 次、3 次)を設定できます。そのため、同一のサイトに 1 次および 2 次のサーバを配置し、ターシャリ サーバを WAN 経由でリモート サイトに配置するように Unified CM のグループを設定できます。


Cisco Business Edition 6000 の WAN を介したクラスタリング

Cisco Business Edition 6000 は、WAN を介したクラスタリングの呼処理ローカル フェールオーバー モデルを使用して配置できます。このタイプの配置では、Unified CM 呼処理アプリケーションの地理的冗長性を提供するために、2 つの各サイトで 2 つの Business Edition 6000 サーバ ノードが配置されます。2 つの Business Edition 6000 サーバ ノードを両方とも UCS C200 ラックマウント サーバにすることができます。また、いずれかのサーバを通常の Cisco Media Convergence Server(MCS)にすることもできます。

Business Edition 6000 の WAN を介した呼処理クラスタリングの展開は、これまでに説明した WAN を介した通常の Unified CM クラスタリングと同じガイドラインおよび要件に従う必要があります。ローカル フェールオーバー モデルを使用して WAN を介して Business Edition 6000 をクラスタリングする場合は、次のガイドラインに従ってください。

Unified CM のグループとデバイス プールを設定して、各サイト内のデバイスが、あらゆる状況でそのサイトのサーバだけに登録されるようにします。

各サイトで主要なサービス(TFTP、DNS、DHCP、LDAP、および IP Phone サービス)、すべてのメディア リソース(会議ブリッジと保留音)、およびゲートウェイを複製します。複製を確実に行い、最大レベルの復元性を得るよう、シスコは強く推奨します。

WAN 障害が発生した場合、パブリッシャ データベースへのアクセスがないサイトでは、いくつかの機能を使用できないことがあります。たとえば、セカンダリ サイトのシステム管理者は、設定を一切追加、変更、または削除することができません。ただし、ユーザは、「Unified CM パブリッシャ」 の項にリストされているユーザ方向の機能に、引き続きアクセスできます。

WAN 障害が発生した状態では、コールを発信するサブスクライバと現在通信していない電話番号にコールを発信すると、ファストビジー トーンが聞こえるか、またはコール転送されます(ボイスメールまたは Call Forward Unregistered で設定された宛先に転送される可能性があります)。

2 つのサイトの 2 つの Business Edition 6000 サーバ ノード間で許可される最大ラウンドトリップ時間(RTT)は 80 ミリ秒です。

WAN を介してクラスタリングされている 2 つのサイト間の Intra-Cluster Communication Signaling(ICCS)最繁時呼数(BHCA)には、1.544 Mbps(T1)の帯域幅が必要です。これは、呼制御トラフィックに必要な帯域幅であり、WAN を介してクラスタリングされているサイト間でディレクトリ番号が共有されていない配置に適用されます。 この呼制御トラフィックは、優先トラフィックに分類されます。優先 ICCS トラフィックには、IP Precedence 3(DSCP 24 または PHB CS3)が付けられます。

Intra-Cluster Communication Signaling(ICCS)トラフィックに必要な帯域幅以外に、2 つの Business Edition 6000 サーバ ノード間のデータベースおよび他のトラフィックに追加の 1.544 Mbps(T1)の帯域幅が必要です。

WAN を介したクラスタリングにリモート フェールオーバー モデルを使用した 2 つのサイトよりも高い地理的冗長性を提供するために、Business Edition 6000 配置で 2 つを超える UCS C200 ラックマウント サーバをクラスタリングできます(「リモート フェールオーバー配置モデル」を参照)。ただし、Business Edition 6000 クラスタ全体でユーザの合計数が 1,000 を超えることはできず、クラスタ全体で設定されたデバイスの合計数が 1,200 を超えることはできません。ユーザ数が 1,000、設定済みデバイス数が 1,200 を超えるクラスタでの UCS C200 ラックマウント サーバの配置は、通常の Unified CM クラスタと見なされ、通常の Unified CM クラスタのすべての要件と設計ガイダンスに従います。

WAN を介したクラスタリングのリモート フェールオーバー モデルで 2 つを超える UCS C200 ラックマウント サーバを使用する Business Edition 6000 の配置では、次の追加ガイドラインに従う必要があります。

WAN を介してクラスタリングされている各サイト間の Intra-Cluster Communication Signaling(ICCS)最繁時呼数(BHCA)には、1.544 Mbps(T1)の帯域幅が必要です。これは、呼制御トラフィックに必要な帯域幅です。

Intra-Cluster Communication Signaling(ICCS)トラフィックに必要な帯域幅以外に、Business Edition 6000 パブリッシャ ノードからリモートの任意のサーバ ノード間のデータベースおよび他のサーバ間トラフィックに追加の 1.544 Mbps(T1)の帯域幅が必要です。

Business Edition 6000 と共存するアプリケーションのための WAN を介したクラスタリング

WAN を介した呼処理サービスのクラスタリング以外に、WAN を介して Cisco Business Edition 6000 共存アプリケーション(Cisco Unity Connection、Cisco IM and Presence、および Cisco Unified Contact Center Express)をクラスタリングすることもできます。ただし、これらの配置は、個々のシステムで実行されているこれらのアプリケーションに適用されるものと同じガイドラインおよび制限に従っている場合に限ります。

各共存アプリケーションは、最大遅延および帯域幅要件に厳密に従っている必要があります。さらに、最大遅延の見積もりはすべてのアプリケーションに適用され、クラスタリングされた各アプリケーション(呼処理など)に必要な WAN 帯域幅を追加して、適切な WAN 帯域幅要件を導き出す必要があることを理解することが重要です。

Cisco Business Edition 6000 共存アプリケーションおよびサービスをクラスタリングする場合は、次の一般的なガイドラインに従ってください。

WAN のラウンドトリップ遅延は、80 ミリ秒を超えることはできません。この値は、呼処理などのすべてのアプリケーションでサポートされている最大ラウンドトリップ遅延であるからです。

WAN 上の帯域幅要件は、WAN を介したクラスタリングにおける各アプリケーションの帯域幅要件の合計に基づきます。たとえば、すべてのアプリケーション(Cisco Unified CM、IM and Presence、Unity Connection、および Unified Contact Center Express)が WAN を介してクラスタリングされる場合、WAN で必要な合計帯域幅は次のように計算されます。

(必要な WAN 帯域幅の合計)=(Unified CM に必要な帯域幅)+(IM and Presence に必要な帯域幅)+(Unity Connection に必要な帯域幅)+(Unified Contact Center Express に必要な帯域幅)

各共存アプリケーションのクラスタリング遅延および帯域幅要件については、次の情報を参照してください。

Cisco IM and Presence については、「WAN を介したクラスタリング」を参照してください。

Cisco Unity Connection については、「Cisco Unity Connection の冗長性と WAN を介したクラスタリング」を参照してください。

Cisco Unified Contact Center Express については、「IP WAN を介したクラスタリング」を参照してください。

仮想サーバでの Unified Communications の配置

Cisco Unified Communications のアプリケーションは、VMware ESXi ハイパーバイザを使用して、仮想環境で仮想マシンとして実行できます。2 つのハードウェア オプションから選択できます。

Tested Reference Configuration(TRC):Cisco Unified Computing System(UCS)プラットフォームに基づいて選択されたハードウェア設定

仕様ベースのハードウェア:ハードウェアの柔軟性が向上します。また、たとえば、VMware ハードウェア互換性リスト( http://www.vmware.com/resources/compatibility/search.php で入手可能)に記載されている他の Cisco UCS、Hewlett-Packard、および IBM プラットフォームのサポートを追加します

ここでは、Cisco Unified Computing System(UCS)アーキテクチャ、アプリケーション仮想化のためのハイパーバイザ テクノロジー、およびストレージ エリア ネットワーキング(SAN)の概念について説明し、あわせて各製品が企業向け Cisco Virtualized Unified Communications ソリューションのどの位置に納まるかを示します。また、仮想サーバで Unified Communications アプリケーションを配置するための設計考慮事項も示します。

ここでの説明は、次の場所で入手できる製品固有の詳細な設計ガイドラインに置き換わるものではありません。

http://www.cisco.com/en/US/products/ps10265/index.html

http://www.cisco.com/go/uc-virtualized

仮想サーバでの Unified Communications システムのサイジングについては、Cisco Unified Communications Sizing Tool を使用してください。このツールは、(有効なログイン認証を持つ)シスコ代理店および従業員が次の URL から入手できます。

http://tools.cisco.com/cucst

Cisco Unified Computing System

Unified Computing は、コンピューティング リソース(CPU、メモリ、および I/O)、IP ネットワークキング、ネットワークベースのストレージ、および仮想化を単一のハイ アベイラビリティ システムに統合するアーキテクチャです。このレベルの統合により、電力および冷却の費用を節約し、ネットワークへのサーバ接続を簡易化し、物理ホスト間でアプリケーション インスタンスを動的に再配置し、ディスク ストレージ容量をプールできます。

Cisco Unified Computing System は、多くのコンポーネントで構築されています が、サーバの観点からすると、UCS アーキテクチャは次の 2 つのカテゴリに分割されます。

「Cisco UCS B シリーズ ブレード サーバ」

「Cisco UCS C シリーズ ラックマウント サーバ」

Cisco Unified Computing System アーキテクチャの詳細については、次の URL から入手可能な資料を参照してください。

http://www.cisco.com/en/US/netsol/ns944/index.html

Cisco UCS B シリーズ ブレード サーバ

Cisco Unified Computing System(UCS)機能ブレード サーバは、x86 アーキテクチャに基づいています。ブレード サーバは、コンピューティング リソース(メモリ、CPU、および I/O)をオペレーティング システムおよびアプリケーションに提供します。ブレード サーバは、メザニン フォーム ファクタの統合型ネットワーク アダプタ(CNA)を介してユニファイド ファブリックにアクセスできます。

このアーキテクチャでは、Fibre Channel over Ethernet(FCoE)などの技術を利用して、単一のインフラストラクチャで LAN、ストレージ、および高性能コンピューティング トラフィックを転送するユニファイド ファブリックを採用しています (図 10-12 を参照)。シスコのユニファイド ファブリック技術は 10 Gbps イーサネットを基盤とするため、LAN、SAN、およびハイパフォーマンス コンピューティング ネットワークのためにアダプタ、ケーブル、およびスイッチをいくつも用意する必要がありません。

図 10-12 Cisco UCS B シリーズ ブレード サーバでのユニファイド コミュニケーションの基本的なアーキテクチャ

 

ここでは、プライマリ UCS コンポーネントと、そのコンポーネントが Unified Communications ソリューションで機能する方法について簡単に説明します。Cisco UCS B シリーズ ブレード サーバの詳細については、次の URL で入手可能なモデル比較を参照してください。

http://www.cisco.com/en/US/products/ps10280/prod_models_comparison.html

Cisco UCS 5100 シリーズ ブレード サーバ シャーシ

Cisco UCS 5100 シリーズ ブレード サーバ シャーシは、B シリーズ ブレード サーバをホストするだけでなく、Cisco UCS ファブリック エクステンダによってアップリンク ファブリック インターコネクト スイッチへの接続を提供します。

Cisco UCS 2100 および 2200 シリーズ ファブリック エクステンダ

Cisco UCS 2100 および 2200 シリーズ ファブリック エクステンダは、B シリーズ シャーシに挿入され、Cisco UCS 5100 シリーズ ブレード サーバ シャーシを Cisco UCS ファブリック インターコネクト スイッチに接続します。ファブリック エクステンダは、Fibre Channel over Ethernet(FCoE)プロトコルを使用して、ブレード サーバの FCoE 対応 CNA 間のトラフィックをファブリック インターコネクト スイッチに渡すことができます。

Cisco UCS 6100 および 6200 シリーズ ファブリック インターコネクト スイッチ

Cisco UCS 6100 および 6200 シリーズ ファブリック インターコネクト スイッチは、10 ギガビット FCoE 対応スイッチです。B シリーズ シャーシ(およびブレード サーバ)はファブリック インターコネクトに接続し、ファブリック インターコネクトはデータセンター内の LAN または SAN スイッチング要素に接続します。

Cisco UCS Manager

管理がシステムのすべてのコンポーネントに統合されるため、Cisco UCS Manager を使用して UCS システム全体を単一のエンティティとして管理できます。Cisco UCS Manager では、直観的なユーザ インターフェイスを使用して、すべてのシステム設定操作を管理できます。

ハイパーバイザ

ハイパーバイザはサーバ ハードウェアで直接動作してハードウェアを制御するシン ソフトウェア システムであり、複数のオペレーティング システム(ゲスト)がサーバ(ホスト コンピュータ)で同時に動作できます。このため、ゲスト オペレーティング システム(Cisco Unified CM のオペレーティング システムなど)はハイパーバイザ上の別のレベルで動作します。ハイパーバイザはクラウド コンピューティングおよび仮想化テクノロジーの基盤要素のいずれかであり、アプリケーションを統合するサーバの数が少なくて済みます。

ストレージ エリア ネットワーキング

ストレージ エリア ネットワーキング(SAN)を使用すると、リモート ストレージ デバイスまたはストレージ アレイをサーバに接続して、ストレージがサーバにローカルに接続されているようにオペレーティング システムに認識させるようにできます。SAN ストレージは、複数のサーバ間で共有できます。

B シリーズ ブレード サーバ上で仮想 Unified Communications アプリケーションを実行する場合の設計上の考慮事項

ここでは、仮想サーバで Unified Communications サービスを実行する場合に従う必要がある設計規則および考慮事項を示します。次のような多くの Cisco Unified Communications アプリケーションが B シリーズ ブレード サーバで仮想化をサポートします。

Cisco Unified Communications Manager(Unified CM)

Cisco Unified CM Session Management Edition(SME)

Cisco Unity Connection

Cisco IM and Presence

Cisco Unified Contact Center Express

Cisco Unified Contact Center Enterprise

Cisco TelePresence Video Communication Server(VCS)

サポートされている Cisco Unified Communications アプリケーションの完全な一覧については、次の URL で入手可能な資料を参照してください。

http://www.cisco.com/go/uc-virtualized

ブレード サーバ

Cisco B シリーズ ブレード サーバは、複数の CPU ソケットをサポートし、各 CPU ソケットは複数のマルチコア プロセッサをホストできます。たとえば、1 つの B200 ブレードには、最大 2 つのマルチコア プロセッサをホストできる CPU ソケットが 2 つあります。また、1 つのブレード サーバで複数の Unified Communications アプリケーションを実行する機能もあります。

Cisco Unified Communications アプリケーションは、Unified Communications 以外のアプリケーションは実行しない専用のブレードで実行する必要があります。各 Unified Communications アプリケーションは、専用の CPU およびメモリ リソースに割り当てて、リソースがオーバーサブスクリプションにならないようにする必要があります。

ハイパーバイザ

仮想 Unified Communications アプリケーションを実行するには、VMware ESXi ハイパーバイザが必要です。ブレード サーバに接続されているローカル ハード ドライブは、仮想マシンの格納には使用できません。これらは、ESXi ハイパーバイザ ソフトウェアのインストールにだけ使用できます。Unified Communications アプリケーションは、仮想マシンのテンプレートおよび設定についてそれぞれのガイドラインに従う必要があります。

Tested Reference Configuration を使用する場合、VMware vCenter は必須ではありませんが、大規模な配置では複数の ESXi ホストを管理するために強く推奨します。

仮想マシンの特定の設定とサイジング要件については、次の URL で入手可能な各製品マニュアルを参照してください。

http://www.cisco.com/go/uc-virtualized

SAN およびストレージ アレイ

Cisco UCS B シリーズ プラットフォームに基づいた Tested Reference Configuration では、ファイバ チャネル SAN ストレージ アレイから実行するために仮想マシンが必要になります。SAN ストレージ アレイは、VMware ハードウェア互換リストの要件を満たす必要があります。iSCSI、FCoE SAN、および NFS NAS などのその他のストレージ オプションは、仕様ベースのハードウェア サポートによりサポートされています。詳細については、次の URL で入手可能なマニュアルを参照してください。

http://www.cisco.com/go/uc-virtualized

Cisco UCS C シリーズ ラックマウント サーバ

B シリーズ ブレード サーバだけでなく、Cisco Unified Computing System(UCS)も、x86 アーキテクチャに基づいた汎用ラックマウント サーバを特徴としています。C シリーズ ラックマウント サーバは、コンピューティング リソース(メモリ、CPU、および I/O)およびオプションのローカル ストレージをオペレーティング システムおよびアプリケーションに提供します。C シリーズ サーバの詳細については、次の Web サイトにある資料を参照してください。

http://www.cisco.com/en/US/products/ps10493/index.html

C シリーズ ラックマウント サーバ上で仮想 Unified Communications アプリケーションを実行する場合の設計上の考慮事項

Tested Reference Configuration は、Cisco UCS C200、C210、C260 などの Cisco UCS C シリーズ ラック マウント サーバでも利用できます。

次のような多くの Cisco Unified Communications アプリケーションが C シリーズ ラックマウント サーバで仮想化をサポートします。

Cisco Unified Communications Manager(Unified CM)

Cisco Unified CM Session Manager Edition

Cisco Unity Connection

Cisco IM and Presence

Cisco Unified Contact Center Express

Cisco Unified Contact Center Enterprise

Cisco TelePresence Video Communication Server(VCS)

サポートされている Cisco Unified Communications アプリケーションの完全な一覧については、次の URL で入手可能な資料を参照してください。

http://www.cisco.com/go/uc-virtualized

UCS B シリーズとは異なり、ハイエンドの UCS C シリーズ ラック マウント サーバ(たとえば、C210 や C260)に基づいた Tested Reference Configuration では、直接接続されたストレージ ドライブでのローカルな仮想マシンの保存、または FC SAN ストレージ アレイでの仮想マシンの保存がサポートされています。複数の Unified Communications アプリケーションを同じ C シリーズ サーバに配置できます。ローエンドの UCS C シリーズ ラック マウント サーバ(たとえば、C200)では、Cisco Unified Communications 仮想マシンのローカル保存のみ可能です。

UCS C210 サーバは、UCS C200 サーバよりも多くのユーザ領域をサポートします。

UCS C シリーズ ラックマウント サーバ上で Cisco Unified Communications アプリケーションを仮想サーバとして実行するには、満たしておかなければならない特定の要件があります。これらの要件については、次の資料を参照してください。

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/ps5748/ps378/solution_overview_c22-597556.html

仮想サーバが配置モデルに及ぼす影響

仮想サーバでの Cisco Unified Communications アプリケーションの配置では、物理サーバを使用するときと同じ配置モデルがサポートされます。「ネットワーク インフラストラクチャ」の章では、Cisco UCS B ブレード仮想サーバの QoS 機能をネットワークに統合する方法に関する設計ガイドラインを示します。また、多くの場合、物理サーバ(Cisco MCS サーバなど)と Cisco UCS 仮想サーバの統合もサポートされます。たとえば、保留音(MoH)サーバは、Cisco MCS サーバ プラットフォームで実行できるほか、他のメンバー サーバが Cisco UCS 仮想サーバで実行されるクラスタのメンバーになることもできます。

この章で説明するすべての呼処理配置モデルが、Cisco UCS 仮想サーバ プラットフォームでサポートされます。

Service Advertisement Framework の呼制御ディスカバリ(CCD)を使用したコール ルーティングおよびダイヤル プラン配信(SAF)

Cisco Service Advertisement Framework(SAF)は、呼処理プラットフォームの間でコール ルーティングおよびダイヤル プラン情報を自動的に共有するために使用できる Cisco IOS サービス ルーティング プロトコルです。SAF を使用すると、シスコ以外の呼処理プラットフォーム(TDM PBX など)も Cisco IOS ゲートウェイを介して相互接続して Service Advertisement Framework に参加させることができます。

Service Advertisement Framework(SAF)を使用すると、ネットワーキング アプリケーションで IP ネットワーク内のネットワーク サービスに関する情報をアドバタイズしたり検出したりできます。SAF は、次の機能コンポーネントおよびプロトコルで構成されています。

SAF クライアント:サービスに関する情報をアドバタイズしたり消費したりします。

SAF フォワーダ:SAF サービスの可用性情報を配布したり維持したりします。

SAF クライアント プロトコル:SAF クライアントと SAF フォワーダ間で使用されます。

SAF フォワーダ プロトコル:SAF フォワーダ間で使用されます。

アドバタイズされたサービスの特性は、SAF フォワーダのネットワークにとって重要ではありません。SAF フォワーダ プロトコルは、サービスの可用性に関する情報を、SAF ネットワークに登録されている SAF クライアント アプリケーションに動的に配布するように設計されています。

SAF でアドバタイズできるサービス

理論上は、どのサービスでも SAF を介してアドバタイズできます。SAF を使用する最も重要なサービスは、Cisco Unified Communications の Call Control Discovery(CCD; 呼制御ディスカバリ)です。CCD は SAF を使用して、Cisco Unified CM、Unified CME などの呼制御エージェントによってホストされる内部ディレクトリ番号(DN)の可用性に関する情報を配布および維持します。また、CCD は、これらの内部ディレクトリ番号に PSTN から到達できるようにする対応した番号プレフィックスも配布します(「To PSTN」プレフィックス)。

SAF の動的な特性、およびコール エージェントがホストする DN 範囲と To PSTN プレフィックスの可用性を SAF ネットワーク内の他のコール エージェントにアドバタイズできることにより、静的でより労働集約的な他のダイヤル プラン配布方式を大幅に上回るメリットを提供します。

この章では、SAF 対応 Unified Communications ネットワークでの Call Control Discovery(CCD; 呼制御ディスカバリ)の配置について説明します。SAF 自体の詳細については、「Service Advertisement Framework(SAF)」を参照してください。

次のシスコ製品が、SAF に対応した Call Control Discovery(CCD; 呼制御ディスカバリ)サービスをサポートしています。

Cisco Unified Communications Manager(Unified CM)Release 8.0(1) 以降

Cisco Integrated Services Router(ISR)上の Cisco Unified Communications Manager Express(Unified CME)

Cisco ISR プラットフォーム上の Survivable Remote Site Telephony(SRST)

Cisco ISR プラットフォーム上の Cisco Unified Border Element

Cisco ISR プラットフォーム上の Cisco IOS ゲートウェイ

CCD は、Cisco IOS Release 15.0(1)M 以降で動作する Cisco ISR プラットフォームでサポートされます。

Unified Communications ネットワーク内の SAF CCD の詳細情報については、次の URL にある『 Cisco Unified Communications System 9.0 SRND 』の「 Unified Communications Deployment Models 」の章の「SAF」の項を参照してください。

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/models.html

SAF 自体の詳細については、「Service Advertisement Framework(SAF)」を参照してください。

SAF CCD 配置の考慮事項

次のスケーラビリティ制限が、Unified CM および Cisco IOS SAF CCD 製品に適用されます。

アドバタイズする DN パターンは Unified CM クラスタあたり最大 2,000

学習する DN パターンは Unified CM クラスタあたり最大 20,000

アドバタイズする DN パターンは Unified CME、Cisco Unified Border Element、または Cisco IOS ゲートウェイあたり最大 125

学習する DN パターンは Unified CME、Cisco Unified Border Element、Cisco IOS ゲートウェイ、または SRST あたり最大 6,000(プラットフォーム依存)


) 単一の SAF AS を使用して Cisco Unified CM および Cisco IOS SAF CCD システムで構成されている SAF 配置では、SAF CCD のシステム全体のスケーラビリティが 6,000 の学習 DN パターンに制限されます。


Cisco Intercompany Media Engine

Cisco Intercompany Media Engine(IME)は、分散呼処理を使用したマルチサイト展開の一例ですが、IME を使用する場合、各サイトは個別の企業組織です。Unified Communications では、この技術を説明するために 境界なし という用語が使用されます。高忠実度のコーデック、拡張発信者 ID、企業ネットワーク外部のビデオ テレフォニーなどの Unified Communications 機能を企業間に広げていくことができるためです。ソリューションは、動的かつ安全な方法でルートを学習し、インターネットを介して組織同士が安全に通信できるようにします。他の組織と密接に連携し、高度な企業間通信を備えた組織であれば、IME が提供する拡張通信の恩恵を最大限に享受できます。ここでは、ソリューションのコンポーネントと高度なアーキテクチャについて説明し、あわせて IME を配置するための設計上の考慮事項も示します。

IME ソリューションのコンポーネント、上位レベル アーキテクチャ、IME 配置に関係する設計上の考慮事項の詳細については、『 Cisco Unified Communications System 9.0 SRND 』の「 Unified Communications Deployment Models 」の章の「IME」の項を参照してください。

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/models.html