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

目次

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

この章の新規情報

Unified Communications および Collaboration の配置

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

Unified Communications 配置モデルの概要

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

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

共通の設計基準

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

サービスの集中化

サービスの分散化

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

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

配置モデルの設計上の特徴とベスト プラクティス

キャンパス配置

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

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

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

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

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

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

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

分散型呼処理モデルのリーフ Unified Communication システム

UnifiedCM Session Management Edition

クラスタ間検索サービス(ILS)および Global Dial Plan Replication(GDPR)

コラボレーション エッジの配置

VPN 企業アクセスの配置

VPN-less 企業アクセスおよび B2B 配置

IP PSTN の配置

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

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

分散サードパーティ呼制御によるマルチ サイト集中型 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 シリーズ I/O モジュール

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

CiscoUCS Manager

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

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

ブレード サーバ

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

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

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

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

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

SAF が Call Control Discovery(CCD)をアドバタイズできるサービス

SAF CCD 配置の考慮事項

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

この章では、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 新規情報、またはこのマニュアルの以前のリリースからの変更情報

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

コラボレーション エッジ

「コラボレーション エッジの配置」、およびこの章の各項で説明

2013 年 11 月 19 日

クラスタ間検索サービス(ILS)および Global Dial Plan Replication(GDPR)

「クラスタ間検索サービス(ILS)および Global Dial Plan Replication(GDPR)」、およびこの章の各項で説明

2013 年 11 月 19 日

仮想配置

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

2013 年 11 月 19 日

Unified CM の SIP ベースの VCS エンドポイントを登録するための推奨事項

この章の各項で説明

2013 年 11 月 19 日

Cisco Collaboration システム リリース 10.0 の他のアップデート

この章の各項で説明

2013 年 11 月 19 日

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 アーキテクチャを緊密に統合する必要が生じました。シスコの Unified Communications および Collaboration アーキテクチャは、急速に変化し拡大を続ける Unified Communications 環境の要件に対応できる柔軟性とスケーラビリティを備えています。Unified Communications 環境では、複数の Unified Communications デバイスを持つユーザを通信の形式に関係なく単一のユーザ名で識別したいと考えるため、より URI が中心となってきています。

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

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 Telepresence

Cisco WebEx Messenger

WebEx 会議、WebEx TelePresence、および WebEx Messenger は、WebEx クラウド サービスとして導入する、または、Cisco Unified CM、Cisco WebEx Meetings Server、Cisco Expressway、および Cisco IM and Presence を使用してオンプレミス サービスとして導入することができます。

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

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

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

Cisco Unified Communications Manager(音声およびビデオに対する呼制御)

Cisco Unity Connection(ボイスメール)

Cisco Jabber(インスタント メッセージング、プレゼンス、およびソフト エンドポイント)

Nokia、iPhone、Google Android クライアント用の Cisco Unified Mobility

Cisco Unified Attendant Console Enterprise Edition

Cisco Contact Center Enterprise(カスタマー コラボレーション)

Cisco WebEx(Web 会議)

Cisco TelePresence(ポイントツーポイントおよびマルチポイント ビデオ会議)

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 によって相互接続される複数のリモート サイトに分散されます。

分散型配置モデル

複数のキャンパスおよび集中型配置、またはこの一方が、Cisco Unified Communications Manager Session Management Edition クラスタなどのトランクとダイヤル プランの集約プラットフォームで 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)や拡張 SRST などのローカル サバイバビリティ機能を設定できます。同様に、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 でプロビジョニングした分散型呼処理サービスを SIP または H.323 トランクでインターネットワーク化して、サイト間で 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 Unity Express

No

Yes

Yes(Voice Profile for Internet Mail(VPIM)ネットワーキングを介して)

No

Cisco Unity Connection

Yes

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

Yes(VPIM ネットワーキングを介して)

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 Expressway

Yes

Yes

Yes

Yes

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

配置モデルの設計上の特徴とベスト プラクティス

ここでは、Cisco Collaboration と Unified Communications システムの基本的な配置モデルを説明し、各モデルのベスト プラクティスを示します。

キャンパス配置

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

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

 

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

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

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

Unified CM クラスタごとに最大 40,000 の設定済みおよび登録済み Skinny Client Control Protocol(SCCP)または Session Initiation Protocol(SIP)IP Phone、ソフトフォン、アナログ ポート、ビデオ エンドポイント、SIP ベースの TelePresence エンドポイント、ルームベースの TelePresence 会議システム、モバイル クライアント、および Cisco Virtualization Experience Clients(VXC)。

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

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

マルチポイント会議には、マルチポイント コントロール ユニット(MCU)リソースが必要です。

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

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

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

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

Cisco Expressway C および Cisco Expressway E は、安全な Business-to-Business Telepresence およびビデオ コミュニケーションを実現するコラボレーション エッジ機能のほか、インターネット経由のリモートおよびモバイル ワーカーに対する企業アクセスを提供します。

Cisco TelePresence Video Communication Server(VCS)は、レガシー H.323 およびサードパーティ製 TelePresence エンドポイントの登録にも使用できます。ただし、デュアル呼制御によって生じるダイヤル プランおよびコール アドミッション制御の複雑さを回避するには(「デュアル呼制御配置の設計上の考慮事項」を参照)、SIP を使用して、Cisco Unified Communications Manager にすべての TelePresence エンドポイントとルームベースの TelePresence 会議システムを登録することを推奨します。

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

広帯域ビデオ(たとえば、4CIF または 720p では 1.5 Mbps、1080p では 2 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 6000 は、最大 49 のリモート サイトに対応する集中型呼処理構成で配置できます。

Unified CM クラスタごとに最大 40,000 の設定済みおよび登録済み Skinny Client Control Protocol(SCCP)または Session Initiation Protocol(SIP)IP Phone、ソフトフォン、アナログ ポート、ビデオ エンドポイント、SIP ベースの TelePresence エンドポイント、ルームベースの TelePresence 会議システム、モバイル クライアント、および Cisco Virtualization Experience Clients(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 Expressway C および Cisco Expressway E は、安全な Business-to-Business Telepresence およびビデオ コミュニケーションを実現するコラボレーション エッジ機能のほか、インターネット経由のリモートおよびモバイル ワーカーに対し、VPN-less でのエンタープライズ アクセスを提供します。

Cisco TelePresence Video Communication Server(VCS)は、レガシー H.323 およびサードパーティ製 TelePresence エンドポイントの登録にも使用できます。ただし、デュアル呼制御によって生じるダイヤル プランおよびコール アドミッション制御の複雑さを回避するには(「デュアル呼制御配置の設計上の考慮事項」を参照)、SIP を使用して、Cisco Unified Communications Manager にすべての TelePresence エンドポイントとルームベースの TelePresence 会議システムを登録することを推奨します。

システムは、サイト内のデバイス間の広帯域オーディオ(たとえば、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 接続で障害が発生すると、リモート サイトにあるビデオ エンドポイントが音声だけのデバイスになります。ただし、電話機ロード ファームウェア 9.4.1 以降を使用する Cisco IOS Release 15.3(3)M から、Enhanced SRST は、WAN 障害時に SIP ビデオ エンドポイント(たとえば、Cisco Unified IP Phone 9900 シリーズ)でビデオのサバイバビリティを可能にします。特定の電話機モデルでの SRST ビデオ サポートについては、 http://www.cisco.com で入手可能な『Cisco Unified IP Phone Administration Guide』を参照してください。

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

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

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

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 ゲートウェイまたは 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 電話機の場合は、SRST または拡張 SRST を使用します。

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

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

SRST、拡張 SRST、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

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 は音声のサバイバビリティの確保に使用されます。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 が、リモート オフィスのルータ内で呼処理機能のサブセットを提供し、IP Phone を拡張して、ローカル ルータ内の呼処理機能に「リホーム」機能を提供することによって、音声サービスのみのハイ アベイラビリティを提供します。図 10-3 では、SRST または拡張 SRST を使用した典型的なコールのシナリオを示しています。

図 10-3 Survivable Remote Site Telephony(SRST)または拡張 SRST、通常の動作

 

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

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

図 10-4 Survivable Remote Site Telephony(SRST)または拡張 SRST:WAN の障害

 

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


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


拡張 SRST

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

ページング

会議

ハント グループ

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

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

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

Cisco IP Communicator

Cisco Jabber クライアント

Cisco Unified Video Advantage

エンドポイントのビデオ コール

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

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

拡張 SRST のベスト プラクティス

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 の詳細については、次の 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

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

http://www.cisco.com/en/US/docs/ios-xml/ios/voice/cminterop/configuration/15-mt/cminterop-15-mt-book.html

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

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

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

図 10-5 中央ロケーションに配置された Cisco Unified SRST マネージャ

 

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 シリーズ プラットフォームではサポートされません。

リモート オフィスの音声ゲートウェイは、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-6 は、標準的な分散型呼処理配置を示しています。

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

 

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

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

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 アクセス

集中型ボイス メール

集中型会議

これらのサービスは中央に配置できるため、一元管理とスケール上の利点があります。エンド ユーザの状態(たとえば、Cisco IM and Presence)を追跡する必要のあるサービスは、サービスを提供するユーザに対して Unified CM クラスタに接続されている必要があります。

同じサイト内のデバイス間の広帯域オーディオ(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(SME)クラスタまたは Session Initiation Protocol(SIP)プロキシ サーバを使用して、マルチサイト分散型呼処理配置におけるクラスタ間コール ルーティングおよびダイヤル プランの集約を提供できます。これらのトランクおよびダイヤル プラン集約デバイスの使用には、次のベスト プラクティスが適用されます。

Unified CM Session Management Edition クラスタ

Cisco Unified Communications Manager Session Management Edition は、分散型呼処理配置におけるクラスタ間コール ルーティングおよびダイヤル プランの集約で一般的に使用されています。クラスタ間コール ルーティングは、標準の数字ルート パターンの使用に基づく数値、またはクラスタ間検索サービス(ILS)および Global Dial Plan Replication(GDPR)の使用に基づく URI にすることができます(「グローバル ダイヤル プラン レプリケーション(GDRP)」を参照)。Unified CM Session Management Edition は Unified CM と同じコードとユーザ インターフェイスを使用しますが、複数のトランク プロトコル(SIP、H.323、および MGCP)、ならびに高度なトランク、ディジット操作機能、およびコール アドミッション制御機能のサポートを利用します。Unified CM Session Management Edition クラスタ配置は、通常は多くのトランク(SIP トランクを推奨。「Cisco Unified CM トランク」を参照)で構成され、Unified Communications エンドポイントはありません。Unified CM Session Management Edition クラスタでは、Unified CM クラスタに利用できるすべてのハイ アベイラビリティ機能(WAN を介したクラスタリング、および [Run on All Unified CM Nodes] など)を使用できます。

SIP プロキシの配置

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

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

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

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


) Session Management Edition(SME)は Unified CM と同じコードと GUI を使用し、ILS、GDPR、および Enhanced Locations Call Admission Control(ELCAC)などのクラスタ間機能も共有できるため、SME は、マルチサイトの分散型コール処理配置の推奨されるトランクとダイヤル プランの集約プラットフォームです。


分散型呼処理モデルのリーフ Unified Communication システム

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

分散型呼処理配置の場合、各サイトには独自の呼処理エージェントが存在する場合があります。各サイトの設計は、呼処理エージェント、必要な機能、および必要な耐障害性によって変わります。たとえば、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 プラットフォームに依存する

SIP トランクを推奨

Cisco Business Edition 6000

最大 2,500 台の電話機

小中規模サイト用

集中型呼処理をサポートする

分散型呼処理をサポートする

SIP トランクを推奨

Cisco Unified Communications Manager(Unified CM)

50 ~ 40,000 台の電話機

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

集中型呼処理をサポートする

分散型呼処理をサポートする

SIP トランクを推奨

IP PBX

PBX に依存する

一般に IP PBX は、SME への接続に使用できる SIP トランクを使用

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

PBX に依存する

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

SIP トランクは、VoIP ゲートウェイと SME の間で推奨

Unified CM Session Management Edition

Cisco Unified CM Session Management Edition(SME)は、マルチサイト分散型呼処理配置で推奨されるトランクとダイヤル プランの集約プラットフォームです。SME は基本的に、トランク インターフェイスだけを使用し、IP エンドポイントを使用しない Unified CM クラスタです。このクラスタには、リーフ システムと呼ばれる、複数のユニファイド コミュニケーション システムを集約できます。

Cisco Unified CM Session Management Edition は、次のトランク プロトコルをサポートします。

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

SIP クラスタ間トランク

SIP トランク

ゲートウェイへの H.323 トランク

ゲートウェイへの MGCP トランク

SIP が H.323 および MGCP トランクを介して追加の機能を提供するため、SIP トランクは推奨される SME およびリーフ Unified Communications システムです(詳細については、「Cisco Unified CM トランク」の章を参照してください)。

Cisco Unified CM Session Management Edition は、次のコール タイプをサポートします。

ボイスコール

ビデオ コール

暗号化されたコール

FAX コール

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

図 10-7 Unified CM Session Management Edition を使用したマルチサイト分散型呼処理配置

 

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

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

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

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


) SME および Unified CM リーフ クラスタでクラスタ間検索サービス(ILS)および Global Dial Plan Replication(GDPR)を実行すると、ダイヤル プランの管理をさらに簡略化できます。これは、個々のディレクトリ番号、DN に対応する E.164 番号、ルート パターン(たとえば、内線番号範囲および外線番号範囲)、および URI を ILS サービスを使用して配信できるためです。このアプローチでは、必要なルート パターンの数を減らし、それぞれ一意の番号範囲のルート パターンではなく、呼制御システム(Unified CM クラスタなど)ごとに 1 つの SIP ルート パターンにすることで、ダイヤル プランの管理を簡略化します。ILS および GDPR の詳細については、「クラスタ間検索サービス(ILS)および Global Dial Plan Replication(GDPR)」を参照してください。


集中型 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 の集約ポイントを提供できます。ILS GDPR を導入する場合、各サードパーティ製システムでサポートされている番号範囲や URI を ILS GDPR にインポートし、SIP ルート パターンおよび対応する SIP トランクを介して到達できるようにすることもできます。

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 クラスタの規模を適切に決定してください。SME サイジングの詳細については、「コラボレーション ソリューションの設計および配置サイジングに関する考慮事項」の章を参照してください。

トランク

SME は SIP、H.323、および MGCP トランクをサポートしますが、Cisco Unified CM 8.5 およびそれ以降のリリースを実行する SME および Unified CM リーフ クラスタのトランク プロトコルとして SIP を使用することを推奨します。

SIP トランクは、次のようなトランク設計と Unified Communications 配置を大幅に簡素化する独自の機能を多数提供します。

すべての Unified CM ノードで実行

OPTIONS ping

受信オファーのコーデック プリファレンスの受け入れ

相互運用のために SIP メッセージと Session Description Protocol(SDP)の内容の変更を可能にする Lua スクリプト

SME クラスタで SIP トランクのみを使用すると、「メディア トランスペアレント」クラスタを展開できます。ここでは必要に応じて、メディア リソースが SME ではなく、エンドまたはリーフ Unified Communications システムによって挿入されます。WAN を介してクラスタリングする場合、SIP トランクのみを使用すると、SME ノード間で拡張ラウンド トリップ時間(RTT)を使用できるようにもなります。

SME SIP トランクは、[MTP-less Early Offer] トランクとして設定する必要があります。リーフ Unified CM クラスタは、[SIP Delayed Offer] または [SIP Early Offer for Voice and Video (Insert MTP if needed)] に設定できます。詳細については、「Cisco Unified CM トランク」の章を参照してください。

メディア リソース

MTP またはトランスコーダなどのメディア リソースは、コールが正常に続行するために必要で、これらのリソースがリーフ Unified Communications システムで可能な限り割り当てられる必要があります。SME トランク メディア リソースが配置され、SME クラスタを通過するコールに使用される場合、メディア パス コールが SME メディア リソースを介してヘアピンします。SIP トランクのみ、そして [MTP-less Early Offer] を使用して、メディア リソースを使用せずに、SME クラスタを配置できます。メディア リソースが必要な場合は、リーフ Unified Communications システムで割り当てることができます。

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

SME の配置では、SME クラスタ ノード間で最大 500 ミリ秒のラウンドトリップ時間(RTT)をサポートします(図 10-8 を参照)。この拡張 RTT は SME クラスタのみに適用され(標準の Unified CM クラスタ設計の最長 RTT は 80 ミリ秒です)に適用され、次の設計上の制限があります。

WAN を介したクラスタリングによる SME 配置の拡張ラウンドトリップ時間は、SIP トランクのみでサポートされます。すべての SIP トランクは、コールが SME クラスタ内のノード間でルーティングされないように、[MTP-less Early Offer] として設定され、[Run on all Unified CM Nodes] 機能を使用する必要があります(詳細については、「Cisco Unified CM トランク」の章を参照)。MGCP、SCCP、および H.323 プロトコルは、WAN を介したクラスタリングによる SME 配置の拡張ラウンドトリップ時間をサポートしていません。

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

MTP、信頼されたリレー ポイント(TRP)、RSVP エージェント、トランスコーダなどのメディア リソースは、SME クラスタに設定または登録されません。(Unified CM ノードでホストされているメディア リソースを無効にするには、クラスタ内の各ノードの IPVMS サービスを非アクティブにします)。

サイト間の 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 クラスタ処理中にバックグラウンド処理として実行できます。データベース複製フェーズ中に SME クラスタ設定に変更を加えないようにしてください。これにより、複製が完了するまでの時間が遅くなります。

拡張 RTT を使用して SME クラスタを配置する場合、クラスタをアップグレードする前に、パブリッシャ ノードで次の Admin レベル CLI コマンドを実行します。

utils dbreplication setprocess 40

このコマンドは、複製設定のパフォーマンスを向上させ、データベース複製に要する時間が短縮されます。


 

図 10-8 拡張ラウンド トリップ時間を使用した WAN を介した Unified CM Session Management Edition のクラスタリング

 

Unified CM バージョン

すべての Unified CM リーフ クラスタおよび SME クラスタで最新の Cisco Unified Communications システム リリースと SME クラスタを使用すると、Unified Communications 配置が Codec Preference Lists、クラスタ間検索サービス(ILS)、Global Dial Plan Replication(GDPR)、および Enhanced Locations Call Admission Control(ELCAC)などの共通のクロス クラスタ機能から利益を受けることができるようになります。すべてのクラスタ上で最新の Unified Communications バージョンにアップグレードしない場合には、最小推奨バージョンは SIP トランクを使用した Cisco Unified CM 8.5 です。このバージョンには、Unified CM および Session Management Edition クラスタを介したコール ルーティングを改善し、簡略化する機能が含まれているからです。

相互運用性

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

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

SIP トランクの相互運用性の問題に対して、Lua スクリプトは、発着信 SIP メッセージおよび SDP の内容を変更するために使用できます。

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

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

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

Unified CM Session Management Edition の設計と配置のトランク設定の詳細については、「Cisco Unified CM トランク」の章を参照してください。


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


クラスタ間検索サービス(ILS)および Global Dial Plan Replication(GDPR)

Global Dial Plan Replication(GDPR)は、クラスタ間検索サービス(ILS)を使用して、参加している ILS 対応クラスタ間のダイヤル プラン情報を共有します。GDPR を使用すると、関連付けられた URI、+E.164 番号、企業番号、+E.164 パターン、企業パターン、および PSTN フェールオーバー番号に関する情報を各クラスタが配信できるようになります。参加している各クラスタは、番号または URI が存在するクラスタ(またはエンド Unified Communications システム)を識別する GDPR および対応するルート文字列によってアドバタイズされたすべての番号と URI を含む共通の Global Dial Plan カタログを共有します(図 10-9 を参照)。

図 10-9 ILS および GDPR の番号、パターン、および URI 配信

 

GDPR を使用した場合、各クラスタはダイヤル プラン情報(番号と URI)を ルート文字列 として知られるロケーション属性にアドバタイズします。コールが番号または URI に配置されると、番号または URI がクラスタ内のデバイスに関連付けられているかどうかを Unified CM が確認します。関連付けられていない場合、Unified CM は番号または URI について GDPR カタログを検索します。Global Dial Plan カタログで一致が検索されると、GDPR は番号または URI が存在するクラスタに対応するルート文字列を返します。Unified CM は、返されたルート文字列を既存の SIP ルート パターンおよび対応する SIP トランクに照合するための候補として使用します(図 10-10 および図 10-11 を参照)。

図 10-10 ILS および GDPR の番号、パターン、および URI ルックアップ

 

図 10-11 ILS および GDPR のコール ルーティング

 

ILS および GDPR の利点

GDPR を使用することは、数字ルート パターンで標準のダイヤル プランを使用することとは大きく異なります。Unified Communications ネットワーク内でそれぞれの一意の番号範囲のルート パターンを必要とする代わりに、GDPR は、番号、番号パターン、および URI を配信し、1 つの SIP ルート パターンだけが Unified Communications ネットワーク内の各クラスタで必要になります。サードパーティ製ユニファイド コミュニケーション システム(および ILS と GDPR をサポートしない Unified CM クラスタ)に関連付けられた番号および URL は、GDPR にカタログとしてインポートされ、各ユニファイド コミュニケーション システムに対応するルート文字列で ILS を介して配信できます。番号グループに対応する個々の番号とルート パターンの両方が GDPR でアドバタイズできるため、番号と番号範囲をこの数字ルート パターンから取り除くと、GDPR は単純かつ簡潔に、多くの番号範囲で高度に細分化されたダイヤル プランをサポートできます。ILS と GDPR を使用している各クラスタは、参加している他のクラスタからアドバタイズされた個々の番号と番号範囲をブロックし、消去できます。

各 GDPR の番号タイプ(+E.164 番号、企業番号、+E.164 パターン、または企業パターン)は、ILS で学習したときに特定のパーティションに置かれ、ユーザ単位またはデバイス単位のサービス クラスが番号タイプのパーティションおよびコーリング サーチ スペースに基づいて適用されるようにします。

Cisco Unified Border Element は、Unified CM SIP トランクを介したコール セットアップ時に、Cisco Unified Border Element に送信される GDPR ルート文字列値に一致するダイヤル ピアを使用した番号および URI のコール ルーティングもサポートしています。Cisco IOS ダイヤル ピアと一致する GDPR ルート文字列は、Cisco IOS releases 15.3(3)M、15.4(1)T (ISR)、15.3(3)S (ASR) およびそれ以降のリリースでサポートされます。

コラボレーション エッジの配置

Enterprise Unified Communications ネットワークと外部の間の境界は、 コラボレーションエッジ とも呼ばれます。外部から企業ネットワークへのアクセスには、いくつかの形式があります。たとえば、ユーザは自宅勤務の在宅勤務者、企業への Wi-Fi インターネット アクセスが可能なモバイル ワーカー、または IP PSTN 間でコールを発信するユーザやインターネットを介して他のビジネス間でコールを発信するユーザである可能性があります。コラボレーション エッジに必要な Unified Communications 機器は、必要とされる企業アクセスにのタイプに大きく左右されます。これは、大きく 3 つのカテゴリに分類できます。

VPN アクセス

VPN-less モバイル、テレワーカー、および Business-to-Business(B2B)アクセス

IP PSTN アクセス

コラボレーション エッジのこれら 3 つの配置オプションについては、これ以降の項で説明します。

VPN 企業アクセスの配置

企業ネットワークへの VPN アクセスは、今日の最も一般的な企業アクセスの形式で、いくつかの方法で提供することが可能です。

ラップトップ、タブレット、およびスマート フォンなどのモバイル デバイスを企業ネットワーク内の Unified Communications サービス(Unified CM、Cisco IM and Presence、Cisco Unity など)およびビジネス アプリケーション サービス(社内 E メール システムおよび内部 Web サイトなど)にアクセスするように Cisco AnyConnect VPN クライアントを配置できます。この VPN 接続が確立されている状態で、Cisco Jabber および Cisco IP Communicator などの Unified Communications ソフト クライアントは Unified CM に登録し、企業デバイス間で音声、ビデオ、および暗号化されたコールを発信できます。

1 つ以上の企業デバイスを持つホーム オフィス ワーカーは、Cisco Virtual Office(CVO)の Integrated Services Router(ISR)を配置して、VPN を介して企業ネットワークを自宅に拡張できます。CVO VPN 接続は、接続デバイスを企業ネットワーク内の Unified Communications サービス(Unified CM、Cisco IM and Presence、Cisco Unity など)およびビジネス アプリケーション サービス(社内 E メール システムおよび内部 Web サイトなど)にアクセスできるようにします。CVO VPN 接続が確立されている状態で、Unified Communications ソフト クライアントと IP Phone は Unified CM に登録し、企業デバイス間で音声、ビデオ、および暗号化されたコールを発信できます。

Cisco Unified IP Phone の Cisco VPN クライアントは、Cisco Unified IP Phone モデルのサブセットの企業アクセスを提供します。Cisco Unified IP Phone の Cisco VPN クライアントをサポートするデバイスの詳細については、「コラボレーションのエンドポイント」の章を参照してください。電話機の VPN クライアントは電話機専用のトンネルを作成し、Unified CM との登録、さらに企業デバイス間での音声、ビデオ、および暗号化されたコールを発信できるようにします。電話機の PC ポートに接続されたコンピュータは、VPN クライアント ソフトウェアを使用して、企業への独自のトンネルの認証と確立を受け持ちます。

VPN アクセスは、デバイスから VPN ヘッドエンドへの安全で暗号化されたトンネルを作成して、企業内のすべての Unified Communications とビジネス アプリケーションへのアクセスをユーザに与えます。VPN ユーザ間のコールのインターネットおよびメディア宛てのトラフィックを含むすべてのトラフィックは、インターネットを介してデバイスから宛先に直接確立されるのではなく、企業ネットワークを常に通過する必要があります(図 10-12 を参照)。

図 10-12 コラボレーション エッジの VPN アクセス

 

上記のデバイスはすべて VPN クライアントを使用して、Cisco Adaptive Security Appliance(ASA 5500)または Cisco VPN 集約ルータなどの VPN ヘッドエンド プラットフォームを介して企業ネットワークに接続します。

VPN アクセス ソリューションの詳細については、次の URL で入手可能な Teleworking および BYOD ソリューション ガイドを参照してください。

http://www.cisco.com/en/US/netsol/ns982/networking_solutions_program_home.html#~slng

VPN-less 企業アクセスおよび B2B 配置

VPN トンネルを使用する代わりに、VPN-less クライアントは Cisco Expressway または Cisco Unified Border Element などの企業エッジ トラバーサル プラットフォームに安全で暗号化されたシグナリング パスを確立します。VPN-less クライアントは社内で Unified CM に登録し、エッジ トラバーサル プラットフォームへのセキュア チャネルによって、クライアントは他の企業デバイスへのコールに対してインターネット経由の暗号化されたメディア パスを確立できるようになります。メディアはオプションで暗合されたままの状態にしておくことができますが、企業シグナリング内では通常、暗号化されていません。

VPN クライアントとは異なり、VPN-less クライアントは、Unified Communications アプリケーションへのアクセスのみを提供します。企業内のビジネス アプリケーション(社内 E メールおよび内部 Web サイトなど)にはアクセスできず、インターネットへの接続は企業を介さず、デバイスから直接行われます。シスコの VPN-less クライアント アクセスは、エッジ トラバーサル プラットフォームとして Cisco Expressway や Cisco Unified Border Element を使用して配置できます。

リモートやモバイル従業員に企業アクセスを提供することに加えて、Cisco Expressway と Cisco Unified Border Element は、Business-to-Business(B2B)通信に対しても配置できます。すべての VPN-less 配置では、Cisco Unified Border Element は音声コールのみをサポートしますが、Cisco Expressway は音声、ビデオ、および IM and Presence 通信を提供するように設計されています。

サポートされるこれらの VPN-less エッジ トラバーサル オプション、エンドポイント、および機能については、次の項で説明します。

Cisco Expressway との VPN-less アクセス

この配置タイプは、Cisco Expressway C および Expressway E を使用します。Cisco Expressway E は、DMZ または公共のインターネットのどちらかに配置し、Cisco Expressway C から企業ネットワークの Unified CM クラスタで通信できます(図 10-13 を参照)。Cisco Expressway は、主に Cisco Jabber クライアントおよび TelePresence エンドポイントの VPN-less アクセスをサポートしています。音声、ビデオ、暗号化されたコール、および IM and Presence は、企業エンドポイント間でサポートされています。リモート VPN-less デバイス間のコールに対するメディアおよびシグナリングは、Cisco Expressway C と Expressway E を通過します。Cisco Expressway VPN-less 企業アクセスでサポートされているエンドポイント範囲固有の情報については、「コラボレーションのエンドポイント」の章を参照してください。Cisco Expressway の VPN-less クライアント アクセスの詳細については、次のサイトで入手可能なマニュアルを参照してください。

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

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

図 10-13 Cisco Expressway とのコラボレーション エッジの VPN-less アクセス

 

Cisco Unified Border Element との VPN-Less アクセス

この配置タイプは、エッジ トラバーサル プラットフォームとして Cisco Unified Border Element を使用します。Cisco Unified Border Element は DMZ または公共のインターネットのどちらかに配置し、企業ネットワークの Unified CM クラスタと直接通信できます(図 10-14 を参照)。Cisco Unified Border Element は、Unified CM IP Phone の VPN-less アクセスをサポートしています。音声コールだけが Cisco Unified Border Element トラバーサル プラットフォームを経由する企業エンドポイント間でサポートされます。現在、リモート IP Phone 間のコールは、常に Cisco Unified Border Element を通過します。Cisco Unified Border Element の VPN-less 企業アクセスでサポートされているエンドポイントの範囲特有の情報については、「コラボレーションのエンドポイント」の章を参照してください。Cisco Unified Border Element の VPN-less クライアント アクセスの詳細については、次のサイトで入手可能なマニュアルを参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps5640/index.html

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

図 10-14 Cisco Unified Border Element とのコラボレーション エッジの VPN-Less アクセス

 

IP PSTN の配置

IP PSTN の配置はますます増大しており、徐々に既存の TDM ベースの PSTN アクセスを置き換えつつあります。SIP は、IP PSTN アクセス プロトコルとして一般に使用されており、現在多くのサービス プロバイダーが Cisco Unified Border Element などのセッション ボーダー コントローラを介して IP PSTN に音声専用のサービスを提供しています。セッション ボーダー コントローラは、SIP Back-to-Back User Agent(B2BUA)で、通常、各コールの音声メディアと SIP シグナリングの両方が Cisco Unified Border Element を流れるフロースルー モードで使用されます(図 10-15 を参照)。B2BUA がフロースルー モードであることから、Cisco Unified Border Element は、トランスレーティング、暗号化、コール録音アプリケーション用のメディア フォーキング、および相互運用に対して SIP メッセージや SDP 本文の内容を変更できるスクリプトのサポートも提供しながら、高度な QoS マーキングおよびコール アドミッション制御ポリシーを実行できます。Cisco Unified Border Element の機能の詳細については、次のサイトで入手可能な最新バージョンの Cisco Unified Border Element Enterprise Edition データ シートを参照してください。

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

Cisco Unified Border Element は、Cisco 800 シリーズ Integrated Services Router(ISR)から Cisco 1000 シリーズ アグリゲーション サービス ルータ(ASR)までの幅広いシスコのルーティング プラットフォームでサポートされます。Cisco Unified Border Element は、ハードウェア プラットフォームに応じて、4 ~ 16,000 本の同時ボイスコールが可能なセッション拡張性を提供できます。また、Cisco Unified Border Element は、次のプラットフォームで冗長性を提供します。

Cisco ISR-G2 プラットフォーム。安定したアクティブ コールのために、メディア保護によるボックスツーボックス冗長性を提供できます(Cisco IOS Release 15.1.2T 以降の Cisco Unified Border Element Release 8.5)

Cisco ASR プラットフォーム。安定したアクティブ コールのために、メディアおよびシグナリングの保護(ステートフル フェールオーバー)によるボックス間またはボックス内の冗長性を提供できます。


) IP PSTN へのアクセスと VPN-less クライアントの企業へのアクセスを同じ Cisco Unified Border Element プラットフォームに配置できます。


図 10-15 コラボレーション エッジの IP PSTN アクセス

 

IP PSTN の地理的な配置オプション

SIP トランクは、必要なアーキテクチャに応じて、さまざまな方法で IP PSTN サービス プロバイダーに接続されます。この接続における最も一般的なアーキテクチャには、中央集中型トランクと分散型トランクの 2 つがあります。

中央集中型トランクは、Cisco Unified Border Element などのセッション ボーダー コントローラ(SBC)を使用し、1 つの論理接続を通してサービス プロバイダー(SP)に接続します(ただし、冗長性を確保するために複数の物理接続が存在する場合があります)。会社へのすべての IP PSTN コール、および会社からのすべての IP PSTN コールでは、このトランクのセットが使用され、ほとんどのコールに対して、メディアおよびシグナリングは企業 WAN を横断して、企業のデバイスを PSTN に接続します。

分散型トランクは、複数の論理接続経由でサービス プロバイダーに接続します 会社の各支社は、サービス プロバイダーへの独自のローカル トランクを保有しています。分散型トランクでは、支社からのメディアは企業 WAN を通過する必要はなくなりましたが、ローカル SBC 経由でサービス プロバイダーへと直接流れることができます。

これらの接続モデルには、それぞれ利点と欠点があります。通常、中央集中型トランクは、物理的な機器および設定の複雑さの面でより容易に展開できます。分散型トランクには、メディアをローカル ハンドオフできる利点があり、またローカル プロバイダーからの番号の可搬性が高まります。また、一部の集中型および分散型 IP PSTN アクセスを結合するハイブリッド接続モデルでは、IP PSTN 配置形式の両方の利点が実現されます。

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

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

デュアル呼制御を備えたキャンパス配置では、コール アドミッション制御は必要なく、各呼制御システムのダイヤル プランは比較的単純です。つまり、エンドポイントが 1 台のシステムで検出できない場合は、コールは別のシステムに転送されます。標準のダイヤル プラン設定(コーリング サーチ スペースおよびパーティション)は、システム間のルーティング ループを防止するために使用できます。

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

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

 

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

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

デュアル呼制御配置では、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 クラスタとサードパーティ呼制御システムの両方が、内部に登録されているどのエンドポイントにも一致しないコールを他の呼制御クラスタに送信することができます。

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

各呼制御に関連付けられた一意の番号範囲ごとに明示的なルート パターンおよび対応するトランクを使用します。

Unified CM(および使用している場合は、SME)配置内では、クラスタ間検索サービス(ILS)と Global Dial Plan Replication(GDPR)を使用して、各 Unified CM クラスタとサードパーティのユニファイド コミュニケーション システムでサポートされる番号範囲に関する情報を共有します。サードパーティ システムと関連するデバイスの場合、それぞれの一意の番号範囲を GDPR にインポートし、インポートされたそれぞれの番号範囲をルート文字列(呼制御システムを識別するラベル)に関連付けます。Unified CM ユーザが番号にダイヤルすると、Unified CM は番号がクラスタに登録されているかどうかを確認します。番号が Unified CM クラスタに登録されていない場合、Unified CM は着信側番号および対応するルート文字列について ILS を検索します。ルート文字列は、番号が存在する呼制御クラスタを識別し、SIP ルート パターンとの照合に使用され、その後宛先へ SIP トランクを介してコールを転送します。

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

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

複数のサードパーティ製呼制御システムを配置する場合は、クラスタ間検索サービス(ILS)と Global Dial Plan Replication(GDPR)を使用して、各 Unified CM クラスタとサードパーティのユニファイド コミュニケーション システムでサポートされる URI に関する情報を共有します。Unified CM ユーザが URI にダイヤルするときの 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 サブスクライバが、予想より高い遅延、エラー、またはパケットのドロップにより、クラスタ間の通信の障害を検出する場合、次の症状のいくつかが発生する場合があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

少なくとも 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-18 を参照)、次の式を使用して、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-18 WAN を介した CTI

 

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

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

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

図 10-19 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 つずつ実行することを推奨します。異なるリモート ロケーションにあるサブスクライバのデータベース複製を修復またはリセットする場合は、同時に実行できます。


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

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

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

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

ソフトウェア アップグレード時は、ソフトウェア リリース ノートで説明されている標準のアップグレード手順を使用して、クラスタ内のすべてのサーバを同じ保守期間内にアップグレードする必要があります。IP WAN 経由のラウンドトリップ遅延時間が大きい場合は、ソフトウェア アップグレードにかかる時間が長くなります。パブリッシャからサブスクライバへの帯域幅が各サブスクライバ ノードに必要な 1.544 Mbps より低いと、ソフトウェア アップグレード プロセスが完了するまで時間がかかる場合があります。アップグレード時間を短縮するには、アップグレード中にリモート サブスクライバごとに必要な 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 サーバが手動で設定される場合、ユーザが、サイトの正しい 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 に、サイトに適したボイスメール システムを割り当てることができます。Unity Connection および WAN を介したクラスタリングの詳細については、「分散型メッセージングと WAN を介したクラスタリング」を参照してください。

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

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

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

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

図 10-20 WAN を介したクラスタリング: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 次のサーバを配置し、3 次サーバを WAN 経由でリモート サイトに配置するように Unified CM のグループを設定できます。


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

Cisco Business Edition 6000 は、WAN を介したクラスタリングの呼処理ローカル フェールオーバー モデルを使用して配置できます。このタイプの配置では、Unified CM 呼処理アプリケーションの地理的冗長性を提供するために、各サイトで 2 つ以上の Business Edition 6000 サーバ ノードが配置されます。Business Edition 6000 サーバ ノードは、UCS C200 または C220 ラックマウント サーバのどちらかになります。

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

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

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

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)トラフィックに必要な帯域幅に加え、パブリッシャと Business Edition 6000 クラスタ内のあらゆるサブスクライバ ノード間のデータベースおよびその他のサーバ間トラフィック用に、さらに 1.544 Mbps(T1)の帯域幅が必要になります。

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

WAN を介したクラスタリングのリモート フェールオーバー モデルで 2 つを超えるサーバを使用する 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、および Cisco Video Communication Server)をクラスタリングすることもできます。ただし、これらの配置は、個々のシステムで実行されているこれらのアプリケーションに適用されるものと同じガイドラインおよび制限に従っている場合に限ります。

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

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

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

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 Collaboration システムのほとんどのアプリケーションは、VMware ESXi ハイパーバイザを使用して、仮想環境で仮想マシンとしてのみ実行できます。2 つのハードウェア オプションから選択できます。

テスト済みリファレンス構成(TRC):Cisco Unified Computing System(UCS)プラットフォームに基づいて選択されたハードウェア設定 テストされ、具体的に保証された性能、キャパシティ、Cisco Collaboration システム仮想マシンを満載して稼働するアプリケーションの組み合わせシナリオが文書化されています。

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

ここでは、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 CM のオペレーティング システムなど)はハイパーバイザ上の別のレベルで動作します。ハイパーバイザはクラウド コンピューティングおよび仮想化テクノロジーの基盤要素のいずれかであり、アプリケーションを統合するサーバの数が少なくて済みます。

ほとんどの Cisco Collaboration システム アプリケーションは、仮想化によってのみサポートされます。これは、VMware vSphere ESXi ハイパーバイザを配置するには、これらのアプリケーションで必要であり、サーバ(ベア メタル)に直接インストールすることができないことを意味します。

VMware vCenter は、仮想環境の管理を支援するツールです。テスト済みリファレンス構成では、VMware vCenter は必須ではありません。ただし、多くのホストを配置する場合には強く推奨されます。仕様ベースのハードウェアでは、VMware vCenter が必要になります。

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 E シリーズ サーバ モジュールは、Cisco Integrated Services Routers Generation 2(ISR G2)に配置されるように設計されたブレード サーバです。一部の Cisco Collaboration アプリケーションが Cisco UCS E シリーズでサポートされていますが、サポートが制限されている場合があります(たとえば、TRC ではなく、仕様ベースのハードウェア サポートなど)。

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

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

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

図 10-21 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 シリーズ I/O モジュール

Cisco UCS 2100 および 2200 シリーズ I/O モジュール(またはファブリック エクステンダ)は、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 では、直観的なユーザ インターフェイスを使用して、すべてのシステム設定操作を管理できます。

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

ストレージ エリア ネットワーキング(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 Expressway

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

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

ブレード サーバ

Cisco B シリーズ ブレード サーバは、複数の CPU ソケットをサポートし、各 CPU ソケットは複数のマルチコア プロセッサをホストできます。たとえば、1 つの B200 ブレードには、最大 2 つのマルチコア プロセッサをホストできる CPU ソケットが 2 つあります。また、1 つのブレード サーバで複数の Unified Communications アプリケーションを実行する機能もあります。各 Unified Communications アプリケーションは、専用の処理およびメモリ リソースに割り当てて、リソースがオーバーサブスクリプションにならないようにする必要があります。

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 アプリケーションを実行する場合の設計上の考慮事項

テスト済みリファレンス構成(TRC)は、Cisco UCS C220 および C240 などの Cisco UCS C シリーズ ラック マウント サーバでも利用できます。

次のようなほとんどの Cisco Collaboration システム アプリケーションが 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 Expressway

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

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

UCS B シリーズとは異なり、UCS C シリーズに基づいた Tested Reference Configuration では、直接接続されたストレージ ドライブでのローカルなハイパーバイザおよびアプリケーションの仮想マシンの保存がサポートされています。FC SAN ストレージ アレイではサポートされていません。C シリーズ サーバで外部ストレージ アレイを使用することができますが、サーバは TRC ではなく、仕様ベースのハードウェアとして見なされるようになります。

詳細については、次の URL で入手可能なマニュアルを参照してください。

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

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

仮想サーバでの Cisco Unified Communications アプリケーションの配置では、物理サーバが使用されるときと同じ配置モデルがサポートされます。ただし、仮想化にはいくつかの考慮事項があります。「ネットワーク インフラストラクチャ」の章では、Cisco UCS B ブレード仮想サーバの QoS 機能をネットワークに統合する方法に関する設計ガイドラインを示します。たとえば、Unified CM VMware 仮想アプリケーションは、ホスト USB およびシリアル ポートにアクセスできません。そのため、Unified CM は、Simplified Message Desk Interface(SMDI)統合の Cisco Messaging Interface (CMI) サービス、オーディオ カード(MOH-USB-AUDIO=)を使用したライブ MoH オーディオ フィードの固定 MoH オーディオ ソースの統合、またはこれらのサーバへのフラッシュ ドライブをサポートしなくなっています。次の代替オプションを使用できます。

MoH ライブ オーディオ ソース フィードの場合は、ライブ オーディオ ソース接続に Cisco IOS ベースのマルチキャスト MoH を使用することを検討してください。

システムのインストール ログの保存には、仮想フロッピー ソフトメディアを使用します。

Simplified Message Desk Interface(SMDI)の統合に対する Cisco Messaging Interface(CMI)サービスの代替オプションはありません。

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 が Call Control Discovery(CCD)をアドバタイズできるサービス

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


) SAF CCD は、社内 DN 範囲、外部(PSTN)DN 範囲、および URI の配信をサポートする GDPR とは異なり、社内 DN 範囲の配信のみをサポートします。


SAF の動的な特性、およびコール エージェントがホストする DN 範囲と To PSTN プレフィックスの可用性を 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 自体の詳細については、次の URL にある『 Cisco Collaboration 9.x Solution Reference Network Designs (SRND) 』の「 Network Infrastructure 」の章の「 Service Advertisement Framework (SAF) 」の項を参照してください。

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/collab09/netstruc.html

SAF CCD 配置の考慮事項

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

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

学習する DN パターンは Unified CM クラスタあたり最大 100,000(デフォルト値 = 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 IOS プラットフォームで実行される Cisco Unified CM および SAF CCD で構成されている SAF 配置では、SAF CCD のシステム全体のスケーラビリティが 6,000 の学習 DN パターンに制限されます。