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

目次

呼処理

この章の新規情報

呼処理アーキテクチャ

呼処理の仮想化

呼処理ハードウェア

UnifiedCM クラスタのサービス

クラスタ サーバ ノード

UnifiedCM OVA テンプレートの混合

Cisco Prime License Manager

クラスタ内通信

クラスタ内セキュリティ

クラスタリングに関する一般的なガイドライン

Cisco TelePresence VCS クラスタリング

呼処理のハイ アベイラビリティ

ハードウェア プラットフォームのハイ アベイラビリティ

ネットワーク接続のハイ アベイラビリティ

UnifiedCM のハイ アベイラビリティ

呼処理の冗長性

呼処理サブスクライバの冗長性

TFTP の冗長性

CTIManager の冗長性

仮想マシンの配置およびハードウェア プラットフォームの冗長性

Cisco Business Edition のハイ アベイラビリティ

Cisco TelePresence VCS のハイ アベイラビリティ

呼処理のキャパシティ プランニング

UnifiedCME のキャパシティ プランニング

UnifiedCM のキャパシティ プランニング

Unified CM のキャパシティ プランニング ガイドラインおよびエンドポイントの制限

メガクラスタ

Cisco Business Edition のキャパシティ プランニング

Cisco TelePresence VCS キャパシティ プランニング

呼処理の設計上の考慮事項

コンピュータ テレフォニー インテグレーション(CTI)

CTI のアーキテクチャ

WAN を介した CTI アプリケーションおよびクラスタリング

CTI のキャパシティ プランニング

CTI のハイ アベイラビリティ

CTI Manager

冗長性、フェールオーバー、およびロード バランシング

実装

複数の呼処理エージェントの統合

UnifiedCM と UnifiedCM Express の相互運用性

UnifiedCM と UnifiedCME 間の相互運用性の概要

分散型呼処理を使用したマルチサイト配置における SIP 経由の UnifiedCM と UnifiedCME の相互運用性

Cisco TelePresenceVCS と UnifiedCM の相互運用性

ダイヤル プランの統合

設計上の考慮事項

呼処理

音声コールとビデオ コールの処理は、IP テレフォニー システムによって提供される重要な機能です。この機能は、特定のタイプの呼処理エンティティまたは呼処理エージェントによって処理されます。呼処理の操作は重要であるため、ユニファイド コミュニケーションの配置を設計して、呼処理システムが、必要なユーザ数およびデバイス数を処理するのに十分なスケーラビリティと、ネットワークおよびアプリケーションのさまざまな異常または障害を処理するのに十分な復元性を持つようにすることが重要です。

この章では、シスコの呼処理製品によってスケーラブルで復元性のある呼処理システムを設計するためのガイドラインを示します。このような製品には、Cisco Unified Communications Manager(Unified CM)、Cisco Business Edition、Cisco Unified Communications Manager Express(Unified CME)、および Cisco TelePresence Video Communication Server(VCS)などがあります。主に次の要素を中心に説明します。

規模:ユーザ、ロケーション、ゲートウェイ、アプリケーションなどの数

パフォーマンス:コールのレート

復元性:冗長性の規模

この章では、特に次のトピックについて説明します。

「呼処理アーキテクチャ」

ここでは、一般的な呼処理アーキテクチャおよびさまざまな呼処理ハードウェア オプションについて説明します。また、Unified CM クラスタリングおよび Cisco TelePresence VCS クラスタリングについても説明します。

「呼処理のハイ アベイラビリティ」

ここでは、ネットワークの冗長性、サーバの冗長性、ロード バランシングなど、呼処理のハイ アベイラビリティに関する考慮事項について説明します。

「呼処理のキャパシティ プランニング」

ここでは、呼処理配置のサイジングの概要を示します。

「呼処理の設計上の考慮事項」

ここでは、基本設計のガイドラインと呼処理を配置するためのベスト プラクティスの要約リストを示します。

「コンピュータ テレフォニー インテグレーション(CTI)」

ここでは、Cisco コンピュータ テレフォニー インテグレーション(CTI)アーキテクチャについて説明し、CTI のコンポーネントとインターフェイス、CTI 機能、CTI のプロビジョニングとキャパシティ プランニングについて説明します。

「複数の呼処理エージェントの統合」

ここでは、Cisco Unified CM Session Management Edition(SME)で通常実行される、複数の呼処理エージェントの統合について説明します。また、Cisco Unified Communications Manager Express(Unified CME)との Cisco Unified CM の直接的統合、および Cisco TelePresence Video Communication Serve(VCS)との Cisco Unified CM の統合についても説明します。

この章の新規情報

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

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

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

呼処理アプリケーションの仮想化

この章の各項で説明

2013 年 11 月 19 日

Tested Reference Configuration(TRC)

「呼処理ハードウェア」

2013 年 11 月 19 日

この章から Cisco Media Convergence Server(MCS)情報を削除。Cisco Unified CM 10. x は、これらのハードウェア上で直接実行されません。

この章のすべての項で説明

2013 年 11 月 19 日

Cisco Unified CM および Unified CME 間の H.323 統合に関する情報の削除

H.323 統合の詳細については、次の Web サイトで入手可能な『 Cisco Collaboration 9.x SRND 』を参照してください。

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

2013 年 11 月 19 日

呼処理アーキテクチャ

ユニファイド コミュニケーション システムの設計と配置を成功させるには、コール ルーティング機能を提供する基盤の呼処理アーキテクチャを理解することが重要です。この機能は、次のシスコの呼処理エージェントによって提供されます。

Cisco Unified Communications Manager Express(Unified CME)

Cisco Unified CME は、小規模な単一サイト配置、大規模な分散マルチサイト配置、および Cisco Unified CM の集中型呼処理配置でリモート サイトにおいてローカル呼処理をバックアップする機能を提供するために呼処理サービスを提供します。

Cisco Business Edition 6000

Cisco Business Edition 6000 は、小規模な単一サイト配置または小規模な分散マルチサイト配置に、呼処理サービスを提供します。

Cisco Business Edition 6000 は、VMware vSphere Hypervisor を使用して別の仮想マシンとして実行される複数の共存 Collaboration アプリケーションをサポートします。呼処理サービスは、Cisco Unified Communications Manager(Unified CM)および Cisco TelePresence Video Communication Server(VCS)仮想マシン、またはどちらか一方で提供されます。Cisco Business Edition 6000 は、Cisco Unified Computing System(Cisco UCS)サーバの 2 つのサーバ ハードウェア オプションが用意されています。中密度サーバは、Cisco Prime Collaboration Provisioning および最大 4 つの共存アプリケーションをサポートしますが、高密度サーバは Cisco Prime Collaboration Provisioning および最大 8 つの共存アプリケーションをサポートします。中密度および高密度サーバの詳細については、次の Web サイトを参照してください。

http://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware#UC_on_UCS_Tested_Reference_Configurations

Cisco Business Edition 6000 の一部であるコラボレーション アプリケーションは、たとえば、Cisco Unified Communications Manager(Unified CM)、Cisco Unity Connection、Cisco IM and Presence、Cisco Unified Contact Center Express(Unified CCX)、Cisco Unified Attendant Console Services、Cisco TelePresence Video Communication Server(VCS)Control、Cisco Emergency Responder、および Cisco Paging Server です。Cisco Business Edition 6000 の一部でないサードパーティ製コラボレーション アプリケーションまたは Cisco Collaboration アプリケーションを同じサーバに追加できますが、次の制約事項があります。サーバごとには 3 つ、配置ごとには 6 つを超えるアプリケーションを追加できません。共存のポリシーの詳細については、次の Web サイトで入手可能な Cisco Business Edition 6000 のマニュアルを参照してください。

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

Cisco Unified Communications Manager(Unified CM)

Cisco Unified CM は、小規模~非常に大規模な単一サイト配置、マルチサイト集中型呼処理配置、およびマルチサイト分散呼処理配置に、呼処理サービスを提供します。Unified CM は Cisco Collaboration ソリューションの中心にあり、音声、ビデオ、TelePresence、IM and Presence、メッセージング、モビリティ、Web 会議、およびセキュリティの基盤として機能します。

リモート アクセスおよび安全な Business-to-Business Telepresence を実現するために企業コラボレーション ネットワークおよび Unified CM へのアクセスが、VPN および Cisco Expressway などのさまざまなコラボレーション エッジ ソリューションでも使用できます。

Cisco TelePresence Video Communication Server(VCS)

Cisco TelePresence VCS は、ビデオ エンドポイントの登録、呼処理、および SIP および H.323 エンドポイントの帯域幅管理を提供するビデオ アプリケーションです。VCS は SIP レジストラ、SIP プロキシ サーバ、H.323 ゲートキーパー、および SIP - H.323 間のゲートウェイ サーバとして機能し、SIP と H.323 デバイスの間にインターワーキングを提供します。また Cisco TelePresence VCS Control は、VCS Expressway と組み合わせることによって、NAT/ファイアウォール トラバーサルを使用した外部通信を提供します。

主要な呼処理エージェントとして Unified CM で配置するときに、Cisco VCS も配置して、H.323 テレプレゼンス エンドポイントとの間で、すべての機能の相互運用性、SIP とのインターワーキング、サードパーティ ビデオ エンドポイントとの統合、別のテレプレゼンス会議ソリューションを提供することができます。ただし、デュアル呼制御によって生じるダイヤル プランおよびコール アドミッション制御の複雑さを回避するには(「デュアル呼制御配置の設計上の考慮事項」を参照)、SIP を使用して、Cisco Unified Communications Manager にすべての TelePresence エンドポイントとルームベースの TelePresence 会議システムを登録することを推奨します。

呼処理の仮想化

Cisco Collaboration との仮想化により、ハイパーバイザを介して同じ物理サーバの仮想マシンとして 1 台または複数の Cisco Collaboration アプリケーション インスタンスを実行する配置が可能になります。これは、アプリケーションがハードウェア プラットフォーム上で直接動作している従来のソリューションと比べて、明らかなメリットがあります。たとえば、コスト(サーバ、電力、冷却、ラック スペースのコストなど)を大幅に削減できます。そして、ハードウェア プラットフォームの運用および保守を簡素化できます。

Cisco Collaboration に必要なハイパーバイザは、VMware ESXi Hypervisor です。仮想マシンとして動作する Cisco Collaboration アプリケーションは ゲスト と呼ばれ、仮想マシンが稼働するハードウェア プラットフォームまたは物理サーバは ホスト と呼ばれます。

各仮想マシンは、仮想 CPU、仮想メモリ、仮想ディスクなどの仮想ハードウェア リソースを関連付けています。これらのリソースは、仮想マシン テンプレートをパッケージおよび配布するオープン スタンダード ベースの方式である Open Virtualization Archive(OVA)を介して配布される事前定義されたテンプレートの各 Collaboration アプリケーションに定義されます。さまざまな容量を提供するために、多数の Cisco Collaboration アプリケーションに各種の OVA テンプレートのサイズを使用できます。Cisco Collaboration アプリケーションをインストールするときは、正しい仮想ハードウェア リソースを定義するためだけでなく、ホストの物理ディスクによって仮想ディスクに不整合が生じないようにするために(ストレージのパフォーマンスに影響します)、OVA テンプレートを使用する必要があります。

Cisco Collaboration 呼処理エージェントの仮想化サポートは、次のとおりです。

Cisco Unified CME は Cisco IOS ソフトウェア内で動作し、仮想化をサポートしません。

Cisco TelePresence VCS は物理アプライアンスに直接導入するか、仮想化を使用して導入できます。

Cisco Unified CM は、仮想アプリケーションとしてのみ動作します。たとえば、Cisco MCS または UCS サーバに直接配置できません。

Cisco Business Edition 6000 は、Cisco Business Edition 6000 ハードウェア プラットフォームで仮想マシンとして動作する Cisco Collaboration アプリケーションの組み合わせで仮想化だけで動作します。

Cisco Unified Communications アプリケーションの仮想化の設計上および配置上の考慮事項については、次の URL で入手可能な情報を参照してください。

http://docwiki.cisco.com/wiki/Before_You_Buy_or_Deploy_-_Considerations_for_Design_and_Procurement

呼処理ハードウェア

一般に、Cisco Collaboration アプリケーションを展開するには、2 つのハードウェア構成オプションがあります。

テスト済みリファレンス構成(TRC)

TRC は、Cisco Unified Computing System(UCS)サーバに基づいて選択されたハードウェア構成です。テストされ、具体的に保証された性能、キャパシティ、Unified Communications 仮想マシンを満載して稼働するアプリケーションの組み合わせシナリオが文書化されています。TRC は、特定の配置シナリオ用に事前に作成されたシスコのパッケージ ソリューションをご希望のお客様、または必ずしも仮想化を経験していないお客様(または両方)を対象としています。

必要な容量によって、使用可能な TRC プラットフォームが異なります。たとえば、大規模の TRC プラットフォームはより多くの容量を提供し、多数の仮想マシンをホストできます。

各 TRC のハードウェア構成が明確に定義され、このハードウェア構成から逸脱することは非常に限られています。たとえば、CPU モデルやコア数の変更、RAID 設定の変更、または B シリーズ TRC で SAN Fibre Channel(FC)から iSCSI へのストレージ タイプの変更は、サーバ資格を変更し、サーバは、TRC として考慮されなくなり、仕様ベースのハードウェアとして考慮されます。

仕様ベースのハードウェア

仕様ベースのハードウェア(単純に「仕様ベース」とも呼ばれます)は、より柔軟なハードウェア構成を提供します。たとえば、Cisco UCS TRC に基づいてプラットフォームを選択したり、CPU モデル、コア数、および RAID 構成を変更したり、iSCSI または NAS ストレージを使用したりできます。必要に応じて、シスコ以外のサーバ ベンダーも使用できます。シスコ製品かどうかに関係なく、仕様ベースのハードウェア サーバが、次の『 VMware Compatibility Guide 』に記載されている必要があります。

http://www.vmware.com/resources/compatibility/search.php

仕様ベースのハードウェアはより柔軟なハードウェア構成を提供しますが、一部の要件も満たす必要があります。たとえば、CPU のモデルおよび最小 CPU 速度に関して要件があり、ログおよび統計情報を収集するために vCenter が必要となります。仕様ベースのハードウェアでは、シスコによって Cisco Collaboration アプリケーションのハードウェア構成が明示的に検証されていない点に注意してください。そのためハードウェアの互換性を保証できず、Cisco Collaboration アプリケーションのパフォーマンスを予測または保証できません。仕様ベースのハードウェアによる Cisco Collaboration アプリケーションのパフォーマンスのガイダンス情報を得るには、TRC を参考にしてください。

サポートされているプラットフォーム、TRC、および使用ベースのハードウェアの詳細については、次の Web サイトで入手可能な資料を参照してください。

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

シスコの呼処理エージェントは、次のハードウェア プラットフォームをサポートします。

Cisco Unified CME は Cisco Integrated Services Routers(ISR)上で実行します。また、仮想アプリケーションとして動作しません。

Cisco Unified CM は、VMware Hypervisor を使用して仮想化アプリケーションとしてのみ動作します。また、VMware Hypervisor を使用せずに、サーバ上で直接動作しません。テスト済みリファレンス構成(TRC)および仕様ベースのハードウェアの両方の仮想化ハードウェア プラットフォーム オプションがサポートされています。Unified CM での仮想化プラットフォームの使用に関する詳細については、次の URL から入手可能な最新バージョンの『 Cisco Unified Communications Manager on virtualized servers 』を参照してください。

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

Cisco TelePresence Video Communication Server(VCS)は、物理アプライアンスで直接的に、または VMware の仮想化アプリケーションとして動作します。Unified CM と同様に、仮想化されている場合、Cisco VCS は TRC と仕様ベースのハードウェアの両方をサポートします。仮想アプリケーションとして Cisco VCS を実行する方法の詳細については、次の Web サイトから入手可能な『 Cisco TelePresence Video Communication Server Virtual Machine Deployment Guide 』を参照してください。

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

Cisco Business Edition 6000 は、Cisco Unified Computing System(UCS)の C シリーズ サーバに基づいた特定のテスト済みリファレンス構成上で仮想化アプリケーションの組み合わせとして動作します。

表 9-2 に、4 つのエンタープライズ呼処理タイプ、これらの呼処理アプリケーションが置かれるサーバまたはプラットフォームのタイプ、およびそれらのプラットフォームの全般的な特性の概要を示します。

 

表 9-2 呼処理プラットフォームのタイプ

呼処理タイプ
プラットフォーム タイプ

Cisco Unified CME

Cisco サービス統合型ルータ(1800、2900、および 3900 シリーズ)1

Cisco Business Edition 6000

UCS C シリーズ テスト済みリファレンス構成(TRC)の特定のサブセット 2 種類のプラットフォームを使用できます。

中密度サーバ

高密度サーバ

Cisco Unified CM

UCS テスト済みリファレンス構成(TRC)

仕様ベースのハードウェア サポートでサポートされるその他のサーバ

Cisco VCS

VCS が仮想化されていない場合の Cisco VCS アプライアンス

VCS が仮想化される場合のハードウェア オプション:

UCS テスト済みリファレンス構成(TRC)

仕様ベースのハードウェア サポートでサポートされるその他のサーバ

1.これは、サポートされる Cisco IOS プラットフォームの詳細なリストではありません。

Tested Reference Configurations の完全なリストまたは仕様ベースのハードウェア サポートの詳細については、次の Web サイトで入手可能な資料を参照してください。

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

たとえば、次のプラットフォームが TRC または仕様ベースのハードウェア(またはその両方)としてサポートされます。Cisco Unified Computing System(UCS)B シリーズ、UCS C シリーズ、UCS E シリーズ、およびサードパーティ製サーバ。

必要な規模、パフォーマンス、および冗長性に応じて、特定の配置に適した呼処理タイプとプラットフォームを決定します。一般に、Unified CM ではキャパシティと可用性は向上し、Cisco Unified CME と Cisco Business Edition ではキャパシティと冗長性のレベルは低下します。冗長性とスケーラビリティの詳細については、「呼処理のハイ アベイラビリティ」および「呼処理のキャパシティ プランニング」を参照してください。

Unified CM クラスタのサービス

Cisco Unified CME は、スタンドアロンの呼処理アプリケーションです。ただし、Unified CM は、クラスタリングの概念をサポートします。Unified CM アーキテクチャでは、サーバ ノードのグループを 1 つの呼処理エンティティまたは IP PBX システムとして連携させることができます。このサーバ ノードのグループを クラスタ と呼びます。Unified CM サーバ ノードのクラスタは、設計上の制限事項を遵守している限り、IP ネットワークを介して分散していてもかまわず、空間的な冗長性、およびそれに伴う復元性を Unified Communications システムの設計にもたらすことができます。

Unified CM クラスタの内部には、それぞれ固有のサービスを提供するサーバ ノードが存在します。これらの各サービスは、同じサーバ ノード上で他のサービスと共存できます。たとえば、小規模なシステムでは、データベース サービス、呼処理サービス、およびメディア リソース サービスを単一のサーバ ノードで提供できます。クラスタの規模とパフォーマンスを強化する必要が高まった場合は、これらのサービスの多くを専用サーバ ノードに移行する必要があります。

次の項では、Unified CM クラスタを形成しているサーバ ノードが実行する各種の機能について説明し、必要な規模、パフォーマンス、および復元性を達成するようにサーバ ノードを配置する方法について、ガイドラインを示します。

クラスタ サーバ ノード

図 9-1 に、複数のサーバ ノードで構成された一般的な Unified CM クラスタを示します。パブリッシャとサブスクライバという、2 つのタイプの Unified CM サーバ ノードがあります。これらの用語は、データベース間の関係をインストール時に定義するために使用されています。

図 9-1 一般的な Unified CM クラスタ

 

パブリッシャ

パブリッシャはすべてのクラスタに必要なサーバ ノードであり、図 9-1 に示すように、クラスタごとに 1 つのパブリッシャだけを配置できます。このサーバ ノードは、最初にインストールする必要があります。クラスタ内の他のすべてのサブスクライバに対して、データベース サービスを提供します。パブリッシャ ノードは、コンフィギュレーション データベースに完全な読み取りと書き込みのアクセスができる唯一のサーバ ノードです。

1,250 ユーザを超える大規模なシステムの場合には、管理操作によるテレフォニー サービスへの影響を防止するために、専用パブリッシャを推奨します。専用パブリッシャのノード上で、呼処理または TFTP サービスが提供されることはありません。代わりに、これらのサービスはクラスタ内の他のサブスクライバ ノードによって提供されます。

パブリッシャ用の OVA テンプレートは、クラスタで必要な規模とパフォーマンスを基準として選択する必要があります。パブリッシャは、呼処理サブスクライバと同等のサーバ ノード パフォーマンスを持つものにすることを推奨します。

サブスクライバ

ソフトウェアを初期インストールしたときに使用可能になるのは、データベース サービスとネットワーク サービスだけです。すべてのサブスクライバ ノードは、パブリッシャにサブスクライブして、データベース情報のコピーを取得します。ただし、Unified CM クラスタの初期化時間を短縮するために、クラスタ内のすべてのサブスクライバ ノードは、初期化時にデータベースのローカル コピーを使用しようとします。これにより、Unified CM クラスタの全体的な初期化時間は短縮されます。すべてのサブスクライバ ノードは、パブリッシャまたは他のサブスクライバ ノードからの変更通知によって、データベースのローカル コピーを更新された状態に保ちます。

図 9-1 に示すように、複数のサブスクライバ ノードが同じクラスタのメンバーになることができます。サブスクライバ ノードには、Unified CM 呼処理サブスクライバ ノード、TFTP サブスクライバ ノード、および会議や保留音(MoH)などの機能を提供するメディア リソース サブスクライバ ノードがあります。

呼処理サブスクライバ

呼処理サブスクライバは、Cisco CallManager サービスが使用可能になっているサーバ ノードです。このサービスが使用可能になった時点で、このノードは呼処理機能を実行できるようになります。電話、ゲートウェイ、メディア リソースなどのデバイスが登録やコール発信を実行できるのは、このサービスが使用可能になっているサーバに対してのみです。図 9-1 に示すように、複数の呼処理サブスクライバが同じクラスタのメンバーになることができます。実際、Unified CM は、クラスタごとに最大 8 つの呼処理サブスクライバ ノードをサポートします。

TFTP サブスクライバ

TFTP サブスクライバまたはサーバ ノードは、Unified CM クラスタの一部として、次の 2 つの主要な機能を実行します。

サービスのためのファイルの提供。電話やゲートウェイなどのデバイスのコンフィギュレーション ファイル、電話および一部のゲートウェイのアップグレード用バイナリ ファイル、さまざまなセキュリティ ファイルなど。

コンフィギュレーション ファイルおよびセキュリティ ファイルの生成。通常は署名済みであり、ダウンロード用として提供する前に暗号化されることもあります。

この機能を提供する Cisco TFTP サービスは、クラスタ内の任意のサーバ ノードで使用可能にできます。ただし、何らかの設定を変更すると、TFTP サービスがコンフィギュレーション ファイルを再生成するため、1,250 ユーザを超えるクラスタでは、他のサービスが影響を受ける場合があります。このため、1,250 ユーザを超えるクラスタまたは頻繁な設定変更を伴う機能を備えたクラスタでは、図 9-1 に示すように、特定のサブスクライバ ノードを TFTP サービス専用にすることを推奨します。

TFTP サブスクライバには、呼処理サブスクライバと同じ OVA テンプレートを使用することを推奨します。

メディア リソース サブスクライバ

メディア リソース サブスクライバまたはサーバ ノードは、会議や保留音などのメディア サービスをエンドポイントとゲートウェイに提供します。これらのタイプのメディア リソース サービスは、Cisco IP Voice Media Streaming Application サービスによって提供されます。このサービスは、クラスタ内の任意のサーバ ノードで使用可能にできます。

メディア リソースには、次のものがあります。

保留音(MoH):保留状態になっているデバイス、会議に転送または追加されるデバイスに対して、マルチキャストまたはユニキャストの保留音を提供できます(「保留音(Music on Hold)」を参照)。

アナンシエータ サービス:電話番号を間違えていることや、コール ルーティングが使用不可になっていることを伝える場合に、トーンの代わりに音声アナウンスを流します(「アナンシエータ」を参照)。

会議ブリッジ:アドホック会議と Meet-Me 会議のための、ソフトウェア ベースの会議を提供します(「トランスコーディング」を参照)。

メディア ターミネーション ポイント(MTP)サービス:H.323 クライアント、H.323 トランク、および Session Initiation Protocol(SIP)エンドポイントおよびトランクに機能を提供します(「メディア ターミネーション ポイント(MTP)」を参照)。

クラスタ内でメディア リソースを実行する場合は、メディア リソース サービスの処理とネットワークに関する要件が追加される場合に備えて、すべてのガイドラインに準拠することが重要です。一般に、マルチキャスト MoH とアナンシエータ サービスには専用のメディア リソース サブスクライバを使用せず、ユニキャスト MoH およびソフトウェア ベースの大規模な会議と MTP に、図 9-1 に示すような専用のメディア リソース サブスクライバを使用することを推奨します(これらのサービスが、「メディア リソース」、の章で説明している設計ガイドラインの範囲内にない場合は除きます)。

その他のクラスタ サービス

Unified CM クラスタ内の特定のタイプのサブスクライバ ノード以外に、Unified CM 呼処理サブスクライバ ノードで実行できるその他のサービスもあり、追加機能を提供して使用可能にできます。

Computer Telephony Integration(CTI)Manager

CTI Manager サービスは、Cisco CallManager サービスと TAPI または JTAPI 統合アプリケーションの仲介者として機能します。このサービスは、CTI を利用するアプリケーションのクラスタで必要です。CTI Manager サービスは、CTI アプリケーションの認証を提供し、アプリケーションがエンドポイントの回線をモニタおよび制御できるようにします。CTI Manager は、呼処理サブスクライバ上だけで使用可能にできます。したがって、クラスタ内では最大で 8 つのノードで CTI Manager サービスを実行できます。

CTI Manager の詳細については、「コンピュータ テレフォニー インテグレーション(CTI)」を参照してください。

Unified CM のアプリケーション

Unified CM 上では、Cisco Unified CM Assistant、エクステンション モビリティ、Web Dialer などのさまざまなタイプのアプリケーション サービスを使用可能にできます。これらのアプリケーションに関する設計ガイドラインの詳細については、「Cisco Unified CM アプリケーション」の章を参照してください。Cisco IM and Presence サービスを追加することができます(「Cisco IM and Presence」の章を参照)。

Unified CM OVA テンプレートの混合

クラスタ内のすべての Unified CM ノードに同じ OVA テンプレートを使用することを推奨しますが、小規模な vDisk(60 GB)で 2,500 ユーザの OVA テンプレートなど、Cisco Hosted Collaboration Solution(HCS)に対して Unified CM OVA テンプレートが設計および予約されていれば、クラスタ内で OVA テンプレートを混合させることは可能です。また、Unified CM パブリッシャに使用する OVA テンプレートが同じクラスタ内で使用されている他の Unified CM OVA テンプレートを下回ったり、バックアップ サブスクライバに使用する OVA テンプレートがプライマリ サブスクライバに使用する OVA テンプレートを下回ったりすることがないように推奨します。

クラスタ内で OVA テンプレートを混合させるときは、さまざまな OVA テンプレート間でのキャパシティの相違を考慮する必要があります。クラスタの全体的なキャパシティは、最終的にはクラスタ内の最小の OVA テンプレートを使用して、ノードのキャパシティによって決まる場合があるためです。呼処理キャパシティの詳細については、「呼処理のキャパシティ プランニング」の項を参照してください。

クラスタ内にさまざまなタイプのハードウェア プラットフォームを混合させることも許可されていますが、すべての OVA テンプレートがすべてのサーバ ハードウェアでサポートされていないため、OVA テンプレートが混合することにより、クラスタ キャパシティの全体に影響する場合があります。別のベンダーからのサーバを混合させることはできますが、これは仕様ベースのハードウェアのポリシーである可能性があり、Unified CM パフォーマンスは、このタイプのプラットフォームの組み合わせでは保証されません。

Cisco Prime License Manager

Cisco Collaboration システムでは、集中型ライセンス管理を提供する Cisco Prime License Manager(Cisco Prime LM)を組み込んでいます。お客様がライセンスをご購入いただき、Cisco Prime LM アプリケーションにインストールします。Cisco Prime LM アプリケーションはすべてのアプリケーションから要件を収集して集約し、すべての使用可能なライセンスと比較します。

次の Unified Communications アプリケーションは、Cisco Prime LM を使用します。

Cisco Unified Communications Manager(Cisco Unified CM):Unified CM を介してライセンスを供与する Cisco IM and Presence と Cisco Unified Communications Manager Session Management Edition(SME)を内蔵しています。

Cisco Unity Connection

Cisco Emergency Responder

これらのアプリケーションを Cisco Business Edition 6000 の一部として導入する場合は、Cisco Prime LM も使用します。

ライセンス購入に従って、ライセンスが登録され(Cisco Prime LM で電子的にライセンス取得を行うか、 www.cisco.com/go/license の製品ライセンス登録ポータルで手動でのライセンス取得を行う)、Cisco Prime License Manager にインストールされます。Cisco Prime LM はライセンス管理下のアプリケーション インスタンスに接続され、アプリケーションをポーリングします。ポーリングされると、サブスクライビング アプリケーションは Prime LM にライセンス要求を送信し、Prime LM がアプリケーションの要件を使用可能なライセンスと比較します。アプリケーションの要件であるすべてのアプリケーション インスタンスの合計数が使用可能なライセンス数の範囲内である場合、Prime LM は「準拠」のステータスを返します。同様に、ライセンスの要件が利用可能なライセンスを超えると Prime LM は「違反」のステータスを返します。

ライセンスが不適切な場合、または Prime LM ノードがアプリケーション モードとの通信を失った場合、管理者が変更を加えることができる 60 日の違反がアプリケーションに与えられます。60 日の違反の後、Unified Communications Manager アプリケーションは管理上の変更を受け入れなくなります。ただし、アプリケーションはサービスが停止することなく継続して動作します(呼制御)。60 日の違反の後、Unity Connection アプリケーションは管理上の変更を受け入れます。ただし、アプリケーションは継続して動作しません(ユーザはボイス メッセージングにアクセスできません)。

Cisco Unified Communications ライセンシングに関する詳細については、次の URL を参照してください。

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

配置例

Prime LM はインストールされるときに、Unified CM(SME を含む)および Unity Connection アプリケーションとして同じ仮想マシンに自動的にインストールされます。共存構成のこれらの仮想マシンのいずれかで、アクティブな管理用の Prime LM として、Prime LM の使用を選択できます。または、Prime LM が専用の仮想マシンにインストールされているスタンドアロン構成で Prime LM を実行することを選択できます。

共存構成では、Prime LM はごくわずかなリソースだけを消費します。従って、仮想マシンのサイジングに影響がないと見なされます。たとえば、Prime LM のために、追加の vCPU を仮想マシン構成に追加する必要はありません。共存構成では、Cisco Prime LM はアプリケーションの OVA テンプレートでの使用がサポートされます。

スタンドアロン構成では、Prime LM は、Prime LM アプリケーションで特別作成および管理された、または Prime LM アプリケーション専用の別個の仮想マシンに常駐します。スタンドアロン構成では、Prime LM は Prime LM OVA テンプレートを使用して別個の仮想マシンとしてインストールされます。

共存およびスタンドアロン配置のどちらを選択するかの主な考慮事項は、管理を軸として展開されます。スタンドアロン構成で Prime LM を配置する主な利点は次のとおりです。

スタンドアロン Cisco Prime LM へのアップグレードは、アプリケーション(Unified CM または Unity Connection)のアップグレードとは別に実行されます。その一方で、Cisco Prime LM の共存構成へのアップグレードは共存アプリケーションへのアップグレードによって行われます。これは、アプリケーションと Cisco Prime LM を同時にアップグレードします。

Unified Communications アプリケーション(Unified CM または Unity Connection)へのプラットフォームの変更には、共存 Prime LM アプリケーションへの変更が必要になる場合があります。たとえば、MAC アドレスの変更では、共存 Prime LM のライセンス ファイル登録の転送が必要です。ただし、スタンドアロン Prime LM の場合、アプリケーション仮想マシンの MAC アドレスの変更などのプラットフォーム変更には、ライセンス ファイル登録の転送が必要ありません。

スタンドアロンに必要な Prime LM の管理上の変更は、アプリケーション サーバには影響しません。たとえば、共存構成では、Prime LM のアップグレードまたはリブートを行うには、アプリケーションのアップグレードまたはリブートが必要になります。

ただし、スタンドアロン構成でのトレード オフは、別の仮想マシンを作成および管理する必要がある点です。

配置の推奨事項

単一のノードまたはクラスタで 1 つのアプリケーションだけをインストールする場合、Prime LM 共存を実行します。

非常に少数のアプリケーション インスタンスをインストールする場合、次を実行できます。

別の仮想マシンで Prime LM を実行します。このアプローチ方法では、さらに管理の柔軟性を提供しますが、Prime LM に別の仮想マシンが必要になります。

ライセンス プーリングと集中型ライセンス管理のいずれか一方、もしくは両方が必要な場合でも、Prime LM を実行するための仮想マシンを割り当てたくない場合は、単一の Prime LM を 1 つのアプリケーション仮想マシンと共存させて実行します。

ライセンス プーリングを必要とせず、集中型ライセンス管理を望まない場合は、各アプリケーション インスタンスで別の Prime LM を実行します。

Cisco Business Edition 6000 では、Prime LM は通常、アプリケーション サーバのいずれかで共存します。ただし、必要に応じて、スタンドアロン仮想マシンとして Prime LM を実行することはできますが、Cisco Business Edition 6000 サーバで許可されるアプリケーションの最大数に対してカウントされる必要があります。

中規模から大規模な配置では、別の仮想マシン上で Prime LM を実行します。必要な仮想マシン数の増分の影響は、この場合最小限であり、運用コストと設備投資間のトレード オフは有利です。

Cisco Prime LM は次のいずれかの方法で配置される場合があります。

企業またはグローバル

説明が示すように、1 つの Prime LM インスタンスは、組織全体またはグローバルの配置をサポートできます。このモデルは 1 つの集中型ライセンス プールを Prime LM に接続されたすべての Unified Communications アプリケーションが利用するために最高のシンプルさを提供します。

地域または事業部

世界中に複数の Unified Communications を配置する企業では、複数の Prime LM インスタンスを各地域または事業部ごとに設定することが可能です(たとえば、北米に 1 つ目、ヨーロッパに 2 つ目、アジアに 3 つ目)。このモデルでは、企業は会計基準の異なる地域ごとに、ライセンスのコストをより簡単に計算できます。

個々の Unified Communications アプリケーション

さらに細かさを必要としているお客様の場合、Prime LM のインスタンスは各 Unified Communications アプリケーション用に設定できます。たとえば、お客様に 3 つの Cisco Unified CM クラスタがある場合、3 つの Prime LM インスタンスを設定できます。このシナリオは、より細かい会計費目に沿って運用を行ったり、運用コストやその他の経費をより厳密に管理するために小さなライセンス プールに分割することを希望するお客様にとって役立ちます。

冗長性

Prime LM は非冗長アプリケーションとして展開されます。Prime LM アプリケーションが使用できなくなった場合(たとえば、Prime LM 仮想マシンにオペレーティング システムの問題が発生し、起動できない場合)、ライセンスの強制が行われる前に発生する前に Prime LM アプリケーションを復元するのに 60 日間の猶予があります。アプリケーションは、Prime LM との通信を行わずに 60 日間稼働します。

Prime LM アプリケーションの復元では、別途インストールされている Prime LM アプリケーション(共存インスタンスなど)は、新しい Prime LM アプリケーションに製品のインベントリを再追加することで作成できます。新しい PLM のアプリケーションを実行している仮想マシンの MAC アドレスは異なるので、ライセンス ファイルの登録をこの新しい Prime LM に転送することが必要になります。また、Prime LM は Disaster Recovery System(DRS)のバックアップから復元できます。この場合、新規および元の Prime LM 仮想マシンと同じ MAC アドレスを設定します。そうしない場合は、ライセンス登録を新しい仮想マシンに転送しなければなりません。ライセンスの追加または変更が DRS バックアップ以降に行われている場合は、新しいライセンス ファイルが要求されていなければなりません。Prime LM 共存バックアップは、共存 Prime LM アプリケーションにのみ復元できます。そしてスタンドアロンのバックアップは、スタンドアロン Prime LM にのみ復元することができます。

クラスタ内通信

クラスタ内通信(Unified CM クラスタ内の通信)には、2 種類あります(図 9-2 および図 9-3 を参照)。1 つは、すべてのデバイス設定情報を含んでいるデータベースを配布するためのメカニズムです(図 9-2 の「データベースのレプリケーション」を参照)。コンフィギュレーション データベースは、パブリッシャ ノードに保存され、コピーがクラスタのサブスクライバ ノードに複製されます。データベースの変更のほとんどはパブリッシャで加えられ、サブスクライバ データベースに伝達されます。そのため、クラスタのメンバー全体で設定の一貫性が確保され、データベースの空間的な冗長性が容易になります。

ユーザ方向の呼処理機能に対するデータベースの変更は、エンド ユーザ デバイスが登録されるサブスクライバ ノードで行われます。次にサブスクライバ ノードが、これらのデータベース変更をクラスタにある他のすべてのノードに複製し、ユーザ機能に冗長性を提供します(図 9-2 の「呼処理に関するユーザ機能の複製」を参照)。これらの機能には、次のものがあります。

Call Forward All(CFA)

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

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

エクステンション モビリティのログイン/ログアウト

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

デバイス モビリティ

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

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

図 9-2 データベースおよびユーザ方向機能の複製

 

Intra-Cluster Communication Signaling(ICCS)と呼ばれる、もう 1 つのクラスタ内通信は、デバイスの登録、ロケーションの帯域幅、共有メディア リソースなどのランタイム データの伝搬と複製です(図 9-3 を参照)。この情報は、Cisco CallManager サービス(呼処理サブスクライバ)を実行している、クラスタのすべてのメンバー全体で共有されます。クラスタのメンバーと関連ゲートウェイとの間で、コールの最適なルーティングが確保されます。

図 9-3 Intra-Cluster Communication Signaling(ICCS)

 

クラスタ内セキュリティ

Unified CM クラスタ内の各サーバ ノードが内部で動的ファイアウォールを実行します。Unified CM のアプリケーション ポートは、送信元 IP フィルタリングによって保護されます。動的ファイアウォールは、認証済みサーバまたは信頼できるサーバ ノードに対してだけ、これらのアプリケーション ポートを開きます(図 9-4 を参照)。

図 9-4 クラスタ内セキュリティ

 

このセキュリティ メカニズムは、単一の Unified CM クラスタ内のサーバ ノード間だけに適用できます。Unified CM のサブスクライバは、パブリッシャのデータベースにアクセスする前に、クラスタ内で認証されます。クラスタ内通信およびデータベース複製は、認証済みサーバ ノード間だけで発生します。インストール時にサブスクライバ ノードは、事前共有キー認証メカニズムでパブリッシャに対して認証されます。認証プロセスに必要な手順は次のとおりです。

1. セキュリティ パスワードを使用してパブリッシャ ノードをインストールします。

2. Unified CM Administration を使用することによって、パブリッシャ上にサブスクライバ ノードを設定します。

3. パブリッシャ サーバのインストール時に使用されたのと同じセキュリティ パスワードを使用して、サブスクライバ ノードをインストールします。

4. サブスクライバのインストール後、サーバ ノードは、UDP 8500 を使用する管理チャネル上でパブリッシャとの接続を確立しようとします。サブスクライバは、ホスト名、IP アドレスなどのすべてのクレデンシャルをパブリッシャに送信します。クレデンシャルは、インストール時に使用されたセキュリティ パスワードを使用して認証されます。

5. パブリッシャは、独自のセキュリティ パスワードを使用してサブスクライバのクレデンシャルを確認します。

6. その情報が有効な場合、パブリッシャは、自身の動的ファイアウォール テーブルに、信頼できる送信元としてサブスクライバを追加します。サブスクライバは、データベースへのアクセスを許可されます。

7. サブスクライバは、パブリッシャから他のサブスクライバ ノードのリストを取得します。すべてのサブスクライバが互いに管理チャネルを確立し、メッシュ トポロジが作成されます。

クラスタリングに関する一般的なガイドライン

すべての Unified CM クラスタに次のガイドラインが適用されます。


) クラスタには、さまざまな OVA テンプレートに基づいた仮想マシンの組み合わせが含まれる場合があります。詳細については、「Unified CM OVA テンプレートの混合」の項を参照してください。


通常の環境では、同一 LAN または MAN 内にクラスタのすべてのメンバーを入れます。

クラスタが IP WAN にわたって構築されている場合、「IP WAN を介したクラスタリング」の項を参照して、IP WAN を介したクラスタ化のガイドラインに従ってください。

Unified CM クラスタに、20 のサーバ ノードを組み込めます。20 のサーバ ノードのうち、呼処理サブスクライバ(Cisco CallManager サービスを実行するノード)は最大で 8 つです。クラスタ内の残りのサーバ ノードは、専用データベース パブリッシャ、専用 TFTP サブスクライバ、またはメディア リソース サブスクライバとして設定できます。

ノードが 2 つのクラスタを配置する場合も、クラスタ内のユーザ数が 1,250 を超えないようにすることを推奨します。1,250 ユーザを超える場合は、専用パブリッシャと別個のサーバ ノードをプライマリおよびバックアップの呼処理サブスクライバ用に推奨します。

特定のテスト済みリファレンス構成で動作する Business Edition 6000 は、Unified CM の単一のインスタンス(パブリッシャとシングル サブスクライバの複合インスタンス)を提供します。増設の Business Edition 6000 サーバは、その他の共存するアプリケーションに対して、サブスクライバの冗長性を提供するためにアクティブ/スタンバイ方式またはロード バランシング方式で配置できます。ただし、この Unified CM クラスタ全体でユーザの合計数が 1,000 を超えることはできず、この Unified CM クラスタ全体で設定されたデバイスの合計数が中密度サーバで 1,200、または高密度サーバで 2,500 を超えることはできません。負荷を Unified CM インスタンスで分散できるよう、ロード バランシングを使用する冗長サーバを配置することを推奨します。

各 Unified CM ノード インスタンスは、パブリッシャ ノード、呼処理サブスクライバ ノード、TFTP サブスクライバ ノード、またはメディア リソース サブスクライバ ノードのいずれかになります。クラスタごとに 1 つのパブリッシャ ノードだけがサポートされます。

Cisco UCS B シリーズ ブレード サーバおよび C シリーズ ラックマウント サーバは、シリアル ポート、Video Graphics Array(VGA)モニタ ポート、および 2 つの Universal Serial Bus(USB)ポートを提供するローカルのキーボード、ビデオ、およびマウス(KVM)ケーブル接続をサポートしますが、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)サービスの代替オプションはありません。

Cisco TelePresence VCS クラスタリング

Cisco VCS は、スタンドアロン インスタンスまたは最大 6 つの VCS ノード(VCS ピア)のクラスタとして配置できます。クラスタ内の各 VCS ノードは、同じキャパシティを持つ必要があります。たとえば、仮想アプリケーションとして配置される場合は、各 VCS ノードが同じ OVA テンプレートを使用する必要があります。これらのルールは、VCS Control および VCS Expressway に適用されます(Expressway C および Expressway E にも適用されます)。ただし、VCS クラスタのすべての VCS ピアを同じタイプにする必要があります。たとえば、VCS Expressway ノードおよび VCS Control のノードは同じ VCS クラスタの一部として配置することはできません。

VCS クラスタは、Cisco VCS インストールの復元力および容量を拡張するように設計されています。クラスタの VCS ピアは、帯域幅使用率に加え、ルーティング、ゾーン、FindMe、およびその他の設定を共有します。エンドポイントは、クラスタの任意のピアに登録できます。エンドポイントは、初期ピアとの接続を失っても、クラスタの別のピアに再登録できます。

コールのライセンスは、クラスタごとに実行されます。クラスタ ピアにインストールされたトラバーサルまたは非トラバーサル コールのライセンスは、クラスタ全体で使用できます。クラスタ ピアが使用できなくなった場合、そのピアにインストールされたコールのライセンスは、ピアへの接続をクラスタが失った時から 2 週間の猶予期間中、残りのクラスタ ピアにそのまま使用できます。これにより、クラスタの全体的なライセンス キャパシティが維持されます。

クラスタ内のすべての VCS ピアに、同じルーティング機能がなければなりません。VCS がコールを宛先にルーティングできる場合、そのクラスタのすべての VCS ピアが、コールをその宛先にルーティングできると見なされます。ルーティングが VCS ピア間で異なる場合、個別の VCS/VCS クラスタを使用する必要があります。

1 つの VCS が、クラスタの VCS 設定マスター ピアとして指定される必要があります。この VCS 設定マスター ピアがクラスタ設定を保持し、クラスタ データベースを管理します。クラスタ全体の設定は、設定マスターのみで実行できます。また、クラスタ内の他のすべての VCS ピアは、マスターから定期的に設定を複製します。VCS 設定マスターは Peer 1 として設定され、VCS クラスタ設定ページにはクラスタ内の VCS コール エージェントがリストされています。

VCS クラスタを形成する手順は、Cisco VCS Control、VCS Expressway、Expressway C、Expressway E、および VCS Directory の場合と同じです。

設定マスターを実行している VCS ノードも呼処理を実行しますが、Unified CM パブリッシャは Cisco Business Edition または小規模な配置に対する場合を除き、通常、呼処理を実行しません。

Cisco VCS を配置するときは、次のガイドラインに従ってください。

VCS クラスタは、最大 6 つの VCS ピアで構成できます。

クラスタ内の各 VCS がクラスタ内の他のすべての VCS のピアです。

クラスタ内の任意の 2 つの VCS ピア間の往復時間は 30 ミリ秒未満である必要があります。

すべての VCS が固定 IP アドレスを使用する必要があります。

各 VCS ピアは一意のシステム名を持つ必要があります。

各 VCS ピアには別の DNS サーバを含めることができます。

クラスタ内のすべての VCS ピアで同じソフトウェア バージョンである必要があります。

クラスタ内のすべての VCS ピアで、同一のオプション キーがインストールされている必要があります。ただし、呼処理ライセンス数に関しては各ピアで異なっていても問題ありません。

H.323 は、クラスタ内のすべてのエンドポイントが SIP のみである場合でも、すべての VCS ピアで有効になっている必要があります。H.323 は VCS ピア間の内部クラスタリングに使用されます。

VCS クラスタは、アプライアンスで実行している VCS ノードと、仮想アプリケーションとして実行している VCS ノードを組み合わせて形成できます。

Cisco VCS クラスタの詳細については、次の Web サイトから入手可能な『 Cisco TelePresence Video Communication Server Cluster Creation and Maintenance Deployment Guide 』の最新バージョンを参照してください。

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

呼処理のハイ アベイラビリティ

呼処理サービスは、可用性が高くなるように Unified Communications システム内に配置して、1 つの呼処理コンポーネントの障害によってすべての呼処理サービスが使用不可にならないようにする必要があります。

ハードウェア プラットフォームのハイ アベイラビリティ

呼処理のプラットフォームは、特定の配置のサイズとスケーラビリティだけでなく、プラットフォーム ハードウェアの冗長性にも基づいて選択する必要があります。

可能な場合は二重化電源を備えたプラットフォームを選択して、1 つの電源の障害によってプラットフォームが失われないようにします。二重化電源を備えたプラットフォームを 2 つの異なる電力源に接続して、1 つの電源回路が故障しただけでプラットフォーム全体に障害が発生することを回避します。二重化電源の使用と無停電電源(UPS)の使用を組み合わせると、電力の可用性は最大になります。二重化電源プラットフォームを実現できない配置でも、建物の電力が必要なレベルの電力の可用性を備えていない状況では、UPS の使用を推奨します。

プラットフォームで障害が発生すると、そのハードウェア プラットフォームで実行しているすべての仮想マシンで障害が発生する可能性があるため、仮想化を導入するときは、ハードウェア プラットフォームのハイ アベイラビリティを提供することがさらに重要になります。可能であれば、同じ物理サーバ上で同様の機能を持つ同じアプリケーションのインスタンスを複数実行することは避けます。代わりに、Cisco UCS B-Series Blade Server を使用している場合は、それらの仮想マシンを複数のサーバに割り振り、可能であれば複数のシャーシにも割り振ります。

ネットワーク接続のハイ アベイラビリティ

IP ネットワークへの接続性も、最大限のパフォーマンスとハイ アベイラビリティにとって重要な考慮事項です。Cisco Unified CME では、ネットワーク接続に最低 2 つ以上のポートを使用します。Unified CM では、ネットワーク接続のハイ アベイラビリティは、複数のアップリンクを介してハイパーバイザ仮想スイッチを設定し、ハードウェア プラットフォーム上で複数の物理ポートを使用することにより実現されます。そのため、OVA 設定に定義された 1 つの仮想 NIC で十分です。たとえば VMware vSphere 仮想スイッチを使用している場合は、スイッチ アップリンクに対して NIC チーミングを設定します。また、複数のこれらのポートを最低 2 台のアップストリーム スイッチに接続して、アップストリーム スイッチで障害が発生したときに復元力を提供します。Cisco VCS Control は、仮想化されているかどうかに関係なく、1 つのネットワーク インターフェイスだけを使用します。高セキュリティの配置用に Cisco VCS Expressway で 2 番目のネットワーク インターフェイスを使用できます。たとえば、別個のネットワーク セグメントにある 2 つの別個のファイアウォールの間の DMZ に VCS Expressway を配置する場合などです。VCS Control と Expressway が仮想化されている場合、Unified CM の構成と同様に、ハードウェア プラットフォーム上の複数の物理ポートを介してホスト レベルでネットワーク接続の冗長性を提供します。

最高速度でプラットフォームをネットワークに接続し、最大スループット(大規模な VCS 設定を使用する場合、または UCS B シリーズ プラットフォームを使用する場合は、通常 1 Gbps または 10 Gbps)を確保します。プラットフォームが全二重でネットワークに接続されていることを確認します。

IP ネットワーク接続の速度とデュプレックス モード以外に、このネットワーク接続の復元性も同じように重要です。ユニファイド コミュニケーションの配置は、実際の冗長性に関して、基盤となるネットワーク接続に大きく依存します。このため、復元性が高い方法で基盤となるネットワーク インフラストラクチャを配置および設定することが重要です。可用性の高いネットワーク インフラストラクチャの設計の詳細については、「ネットワーク インフラストラクチャ」の章を参照してください。すべての場合で、インフラストラクチャ内でスイッチまたはルータの障害が発生しても、ほとんどのユーザは配置内で提供されているほとんどのサービスにアクセスできるように、ネットワークを設計する必要があります。

呼処理の可用性を最大にするには、可能な場合は呼処理プラットフォームを別々の建物および別々のネットワーク スイッチに置いて接続し、建物またはネットワーク インフラストラクチャ スイッチの障害が発生したときの呼処理への影響を最小にします。Unified CM 呼処理では、このことは、可能な場合は常に、クラスタ サーバ ノードを LAN または MAN 配置内の複数の建物またはロケーション間で分散させることを意味します。最低限でも、同じロケーション内の異なる物理ネットワーク スイッチ間でネットワーク接続を物理的に分散させることを意味します。

さらに、Cisco Unified CME がスタンドアロンの呼処理エンティティであっても、物理的な分散とこの呼処理エンティティによる冗長性を提供することは、複数の呼処理エンティティを配置する場合にやはり意味を持ちます。そのようなシナリオで可能な場合は常に、Unified CME の各インスタンスをネットワーク内の異なる物理ロケーションにインストールするか、または最低限でも異なるネットワーク スイッチに物理的に接続します。

Unified CM のハイ アベイラビリティ

基盤となる Unified CM クラスタリングメカニズムのため、Unified Communications システムには、ハードウェア プラットフォームのディスクおよび電力コンポーネントの冗長性、物理ネットワーク ロケーション、および接続の冗長性以外にも、ハイ アベイラビリティに関する考慮事項があります。ここでは、呼処理サブスクライバの冗長性の考慮事項、呼処理のロード バランシング、およびその他のクラスタ サービスの冗長性について説明します。

呼処理の冗長性

Unified CM には、次の呼処理の冗長性設定オプションまたは冗長性方式があります。

2:1 冗長性方式:プライマリ呼処理サブスクライバ 2 台ごとに、1 つの共用セカンダリまたはバックアップ呼処理サブスクライバを設置します。

1:1 冗長性方式:プライマリ呼処理サブスクライバごとに、1 つのセカンダリまたはバックアップ呼処理サブスクライバを設置します。

これらの冗長性方式は、Unified CM クラスタ アーキテクチャ内の組み込み登録フェールオーバー メカニズムによって実施され、エンドポイントのプライマリ呼処理サブスクライバ ノードに障害が発生したときに、エンドポイントはバックアップ呼処理サブスクライバ ノードに再登録されます。この登録フェールオーバー メカニズムは、Skinny Client Control Protocol(SCCP)IP Phone のフェールオーバー レート、毎秒約 125 台の登録を実現できます。Session Initiation Protocol(SIP)電話機の登録フェールオーバー レートでは、毎秒約 40 台の登録です。

選択した呼処理の冗長性方式によって、配置の耐障害性だけでなく、アップグレードの耐障害性も決まります。

1:1 冗長性方式では、プライマリ呼処理サブスクライバで複数の障害が発生しても、呼処理機能に影響はありません。それに対して 2:1 冗長性方式では、バックアップ呼処理サブスクライバを共用する 2 つのプライマリ呼処理サブスクライバのうちの 1 つだけで障害が発生した場合、呼処理に影響はありません。ただし、両方のプライマリ サブスクライバに登録されているエンドポイントの合計数と、それら 2 つのプライマリ サブスクライバが処理するトラフィック量が、バックアップ サブスクライバのキャパシティ制限以内である場合、バックアップ サブスクライバで両方のプライマリ サブスクライバの障害を処理できます。


) 2 つのプライマリ サブスクライバの合計キャパシティ使用率がバックアップ サブスクライバのキャパシティを超える場合は、2:1 冗長性を導入しないでください。たとえば、呼処理キャパシティまたはエンドポイント キャパシティ使用率が両方のプライマリ サブスクライバで 50% を超えると、両方のプライマリ サブスクライバに障害が発生した場合、バックアップ サブスクライバは呼処理サービスを適切に処理できなくなります。これらのシナリオでは、バックアップ サブスクライバ システムのキャパシティが超過したことが原因で、一部のエンドポイントが登録できない、一部の新しいコールを処理できない、一部のサービスおよび機能が適切に機能しないなどの状況が生じる可能性があります。


同様に、1:1 冗長性方式では、クラスタのアップグレードは、1 つのエンドポイント登録フェールオーバー期間だけが呼処理サービスに影響するように実行できます。それに対して 2:1 冗長性方式では、クラスタのアップグレードには複数の登録フェールオーバー期間が必要になる場合があります。

Unified CM クラスタは、サービスへの影響を最小限に抑えてアップグレードできます。2 つのバージョン(リリース)の Unified CM を同じサーバ ノード上に置いて、一方をアクティブ パーティションに、もう一方を非アクティブ パーティションに入れることができます。すべてのサービスとデバイスで、すべての Unified CM 機能に対して、アクティブ パーティションの Unified CM バージョンが使用されます。アップグレード時に、クラスタ操作はアクティブ パーティションにある現在のリリースの Unified CM を使用して続行されながら、アップグレード バージョンが非アクティブ パーティションにインストールされます。アップグレード プロセスの完了後は、サーバ ノードをリブートし非アクティブ パーティションをアクティブ パーティションに切り替えて、新しいバージョンの Unified CM を実行できます。

1:1 冗長性方式では、次の手順を使用して、ダウンタイムを最小限に抑えてクラスタをアップグレードできます。


ステップ 1 新しいバージョンの Unified CM を非アクティブ パーティションにインストールします。最初にパブリッシャにインストールしてから、すべてのサブスクライバ(呼処理サブスクライバ、TFTP サブスクライバ、およびメディア リソース サブスクライバ)にインストールします。リブートはしないでください。

ステップ 2 パブリッシャをリブートして、新しいバージョンに切り替えます。

ステップ 3 TFTP サブスクライバ ノードを 1 つずつリブートして、新しいバージョンに切り替えます。

ステップ 4 専用メディア リソース サブスクライバ ノードを 1 つずつリブートして、新しいバージョンに切り替えます。

ステップ 5 バックアップ呼処理サブスクライバを 1 つずつリブートして、新しいバージョンに切り替えます。

ステップ 6 プライマリ呼処理サブスクライバを 1 つずつリブートして、新しいバージョンに切り替えます。デバイス登録は、前にアップグレードおよびリブートされたバックアップ呼処理サブスクライバにフェールオーバーします。各プライマリ呼処理サブスクライバがリブートされると、デバイスはプライマリ呼処理サブスクライバへの再登録を開始します。


 

このアップグレード方法では、異なるバージョンの Unified CM ソフトウェアを実行しているサブスクライバ ノードにデバイスが登録される期間(登録フェールオーバー期間を除く)がありません。これらの手順はすべて Cisco Prime Collaboration を使用して自動化することができます。

2:1 冗長性方式では、クラスタ内のサーバ ノード数を少なくできますが、アップグレード時の登録フェールオーバーの発生頻度が多くなり、アップグレードの全体的な時間および特定のエンドポイントの呼処理サービスが使用不可になる時間が長くなります。プライマリ呼処理サブスクライバのペアごとにバックアップ呼処理サブスクライバは 1 つだけであるため、1 つのバックアップ呼処理サブスクライバのオーバーサブスクリプションを回避するために、一度にペアのうちの 1 つのプライマリ呼処理サブスクライバだけで新しいバージョンへリブートできます。その結果、各ペアの最初のプライマリ呼処理サブスクライバが新しいバージョンに切り替わった後、エンドポイント登録をバックアップ サブスクライバから新しくアップグレードされたプライマリ サブスクライバに移動するための時間が発生し、その後で 2 番めのプライマリ サブスクライバでのエンドポイント登録をバックアップ サブスクライバに移動して新しいバージョンへリブートできるようになります。この間、2 番めのプライマリ呼処理サブスクライバのエンドポイントは、バックアップ サブスクライバへの再登録中に使用不可になるだけでなく、新しいバージョンを実行するノードに再登録されるまでは、すでにアップグレード済みの他のサブスクライバ ノード上のエンドポイントに到達することもできません。


) アップグレードを行う前に、ディザスタ リカバリ フレームワークを使用して、Unified CM およびコール詳細レコード(CDR)データベースを外部ネットワーク ディレクトリにバックアップすることを推奨します。このようにしておくと、アップグレードが失敗した場合のデータ損失を防止できます。



) Unified CM クラスタのアップグレードでは、一部またはほとんどのデバイスから一時的に登録サービスおよび呼処理サービスが失われるため、アップグレードは前もって計画し、定期保守時に実装する必要があります。1:1 冗長性方式を選択すると、デバイスのダウンタイムおよびサービス停止を最小にできますが、それでも、一部またはすべてのユーザが呼処理サービスを使用できない時間が発生します。


Unified CM のアップグレードの詳細については、次の URL で入手可能なインストールおよびアップグレード ガイドを参照してください。

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

Survivable Remote Site Telephony(SRST)による Unified CM の冗長性

Cisco IOS SRST は、Unified CM クラスタから離れたロケーションにあるエンドポイントに、可用性の高い呼処理サービスを提供します。Unified CM クラスタリングの冗長性方式は確かに、LAN または MAN 環境内の呼処理などのアプリケーション サービスに高レベルの冗長性をもたらします。ただし、WAN などの低速リンクによって中央の Unified CM クラスタから分離されたリモート ロケーションの場合、冗長性方式として SRST を使用すると、リモート サイトと中央サイトの間でネットワーク接続が失われたときに、基本的な呼処理サービスをこれらのリモート ロケーションに提供できます。 呼処理サービスが重要であり、Unified CM クラスタへの接続が失われた場合にも呼処理サービスを維持する必要がある各リモート サイトには、SRST 対応の Cisco IOS ルータを配置することを推奨します。これらのリモート ロケーションのエンドポイントは、Unified CM 内の適切な SRST リファレンスとともに設定する必要があります。Unified CM サブスクライバへの接続を使用できない場合に、呼処理サービス用にどのアドレスを使用して SRST ルータに接続するかをエンドポイントが認識するようにするためです。

Cisco IOS ルータの Cisco Unified 拡張 SRST(E-SRST)は、中央の Unified CM クラスタへの接続が失われると、バックアップ コール処理機能を提供するためにリモート サイトで使用することもできます。E-SRST は、ルータの通常の SRST で使用できる機能よりも多くのテレフォニー機能を IP Phone に提供します。ただし、Unified E-SRST のエンドポイント キャパシティは、通常は基本的な SRST よりも低下します。SRST および E-SRST の両方が Cisco Unified SRST Manager でサポートされています。これは、SRST および E-SRST で Unified CM から設定を同期するので、支社の SRST または E-SRST ルータに必要な手動の設定が減り、ユーザが SRST および通常モードでも同様のコール操作を行えるようにします。

呼処理サブスクライバの冗長性

選択した冗長性方式に応じて(「呼処理の冗長性」を参照)、呼処理サブスクライバは、プライマリ(アクティブ)サブスクライバまたはバックアップ(スタンバイ)サブスクライバのどちらかになります。ロード バランシングを実装する場合は、サブスクライバがプライマリ サブスクライバとバックアップ サブスクライバの両方を兼ねることもあります。クラスタの設計を計画するときは、通常は呼処理サブスクライバにこの機能を割り当てます。大規模なクラスタや高性能クラスタでは、呼処理サービスをパブリッシャおよび TFTP サブスクライバ ノード上で使用可能にしないでください。1:1 冗長性方式は、プライマリ サブスクライバとバックアップ サブスクライバの専用ペアを使用します。2:1 冗長性方式は、1 つのバックアップ サブスクライバを共用するプライマリ サブスクライバのペアを使用します。

次の図では、Unified CM で呼処理の冗長性を実現するための一般的なクラスタ構成を示しています。

図 9-5 基本的な冗長性方式

 

図 9-5 では、利用できる 2 つの基本的な冗長性方式を示しています。どちらの場合でも、バックアップ サーバ ノードは、障害の発生するプライマリ呼処理サーバ ノード 1 台分以上の処理能力を備えている必要があります。2:1 冗長性方式の場合、バックアップ サーバは、個々の配置の要件に応じて、障害の発生する呼処理サーバ ノード 1 台分、または両方のプライマリ呼処理サーバ ノードに相当する処理能力を備えている必要があります。キャパシティ サイジングと OVA テンプレートの選択の詳細については、「呼処理のキャパシティ プランニング」の項を参照してください。


) 2:1 冗長性では、バックアップ サブスクライバが過負荷の状態になることがあるので、10,000 ユーザの OVA テンプレートでサポートされません。


図 9-6 1:1 冗長構成のオプション

 

図 9-7 2:1 冗長構成のオプション

 

図 9-6 に示した 5 つは、すべて 1:1 冗長性のオプションを示しています。図 9-7 に示した 5 つは、すべて 2:1 冗長性のオプションを示しています。どちらの場合も、オプション 1 は 1,250 人未満のユーザをサポートするクラスタに使用します。オプション 2 ~ 5 は、それぞれの冗長性方式でクラスタを徐々に拡張した様子を示しています。正確な規模は、選択したハードウェア プラットフォームや必要なハードウェア プラットフォームによって異なります。

これらの図では、パブリッシャと呼処理サブスクライバだけを示していることに注意してください。TFTP やメディア リソースなどの他のサブスクライバ ノードは示していません。


) Unified CM グループあたり最大 3 つの呼処理サブスクライバを定義できます。追加のバックアップ用に 3 次サブスクライバを追加すると、上記の冗長性方式は 2:1:1 または 1:1:1 冗長性に拡張されます。ただし、WAN を介したクラスタリングの展開(「リモート フェールオーバー配置モデル」を参照)で 3 次サブスクライバ ノードを使用する場合を除き、リモート サイトに設置するエンドポイント デバイスには 3 次サブスクライバの冗長性は推奨しません。エンドポイントが 3 次サブスクライバへの接続性をチェックする必要があると、SRST へのフェールオーバーがさらに遅延するためです。3 次サブスクライバは、クラスタ内の呼処理サブスクライバの最大数に対してもカウントされます(8 つの呼処理サブスクライバ ノード)。


図 9-6 または図 9-7 では示していませんが、シングルノード クラスタを配置することもできます。シングルノード クラスタのエンドポイント設定および登録が 1,000 を超えないようにする必要があります。シングル ノード構成では、バックアップ呼処理サブスクライバがないため、クラスタの冗長性メカニズムはありません。このようなタイプの配置では、冗長性メカニズムとして Survivable Remote Site Telephony(SRST)を使用して、Unified CM が使用できない際に最低限の呼処理サービスを提供する必要があります。ただし、シスコでは、実稼働環境でシングルノード配置を採用することは推奨しません。

ロード バランシング

1:1 冗長性方式の Unified CM クラスタでは、プライマリ呼処理サブスクライバとバックアップ呼処理サブスクライバ間で、デバイス登録および呼処理サービスのロード バランシングを行うことができます。

通常、プライマリが使用可能な場合、バックアップ サーバ ノードに登録されたデバイスはありません。このことにより、所定の時間に呼処理の負荷を処理するプライマリ呼処理サブスクライバ ノードは最大で 4 つであるため、配置のトラブルシューティングは容易になります。 さらに、Unified CM の冗長性グループとデバイス プールの数を減らすことにより、構成が簡素化される可能性もあります。

ロードバランスされた配置では、Unified CM の冗長性グループとデバイス プールの設定を使用して、デバイス登録と呼処理にかかる負荷の半分までをプライマリ サブスクライバからセカンダリ サブスクライバに移すことができます。この方法で、各プライマリおよびバックアップ呼処理サブスクライバ ペアは、この呼処理サブスクライバ ペアによってサービスを提供される全デバイスの半数に、デバイス登録および呼処理サービスを提供します。これは、50/50 ロード バランシングと呼ばれます。50/50 ロード バランシング モデルには、次の利点があります。

ロード シェアリング:登録呼処理の負荷が複数のサーバ ノード上に分散され、応答時間をより速くできます。

フェールオーバーとフェールバックが高速:すべてのデバイス(IP Phone、CTI ポート、ゲートウェイ、トランク、ボイスメール ポートなど)がすべてのアクティブ サブスクライバにわたって分散されるため、プライマリ サブスクライバに障害が発生した場合に、セカンダリ サブスクライバにフェールオーバーするデバイスは一部だけです。この方法で、サーバ ノードが使用不能になる影響を 50% 減らすことができます。

50/50 ロード バランシングを計画するには、ロード バランシングを使用しない場合のクラスタのキャパシティを計算し、次に、デバイスおよびコールの量に基づいて、負荷をプライマリ サブスクライバとバックアップ サブスクライバに分散します。プライマリ サーバ ノードやバックアップ サーバ ノードの障害に対処できるようにするには、プライマリとバックアップのサブスクライバの合計負荷が、サブスクライバ ノード 1 台分の負荷を超えないようにします。


) 50/50 ロード バランシングが設定された Unified CM クラスタのアップグレード中、バックアップ呼処理サブスクライバのアップグレードによって、そのサーバに登録されているデバイス(プライマリ サブスクライバとバックアップ サブスクライバのペアによってサービスを提供される全デバイスの半数)は、プライマリ呼処理サブスクライバにフェールオーバーします。


TFTP の冗長性

大規模な Unified CM クラスタには複数の専用 TFTP サブスクライバ ノードを配置して、TFTP サービスの冗長性を提供することを推奨します。通常は 2 つの TFTP サブスクライバで十分ですが、クラスタに 3 つ以上の TFTP サーバ ノードを配置することもできます。

1 つ以上の冗長 TFTP サブスクライバを提供する以外に、これらの冗長 TFTP ノードを利用するためのエンドポイント設定をする必要があります。DHCP を使用するかまたは静的に TFTP オプションを設定する場合、クラスタ内の両方の TFTP サブスクライバ ノードの IP アドレスを含む TFTP サブスクライバ ノード IP アドレス リストを定義します。この方法では、2 つの異なる IP アドレス リストに対応した 2 つの DHCP スコープを作成することによって(または、2 つの異なる TFTP サブスクライバ ノード IP アドレスでエンドポイントを手動で設定することによって)、TFTP サブスクライバ A をプライマリ、TFTP サブスクライバ B をバックアップとして使用する半分のエンドポイント デバイスと、TFTP サブスクライバ B をプライマリ、TFTP サブスクライバ A をバックアップとして使用するもう半分のエンドポイント デバイスを割り当てることができます。1 つの TFTP サブスクライバの障害時の冗長性を提供する以外に、複数の TFTP サブスクライバにわたってエンドポイントを分散させるこの方法はロード バランシングをもたらし、1 つの TFTP サブスクライバですべての TFTP サービス負荷を処理しないようにします。


) 電話やゲートウェイの個々のバイナリまたはファームウェア ロードを追加する場合は、ファイルをクラスタ内の各 TFTP サブスクライバ ノードに追加する必要があります。


CTI Manager の冗長性

すべての CTI 統合アプリケーションは、CTI Manager サービスを実行している呼処理サブスクライバ ノードと通信します。さらに、ほとんどの CTI アプリケーションには、冗長 CTI Manager サービス ノードを指定する機能があります。そのため、クラスタ内の少なくとも 2 つの呼処理サブスクライバで CTI Manager サービスをアクティブにすることを推奨します。プライマリとバックアップ両方の CTI Manager が設定されている場合、障害が発生すると、アプリケーションはバックアップ CTI Manager に切り替えて CTI サービスを受けます。

すでに説明したように、CTI Manager サービスは呼処理サブスクライバ上だけで使用可能にできます。したがって、クラスタごとに最大で 8 つの CTI Manager があります。復元性、パフォーマンス、および冗長性を最大限まで高めるには、CTI アプリケーションの負荷をクラスタ内で使用可能な CTI Manager に分散することを推奨します。

一般に、CTI アプリケーションによって制御またはモニタされるデバイスは、CTI Manager サービスに使用するものと同じサーバ ノード ペアに関連付けることを推奨します。たとえば、音声自動応答装置(IVR)アプリケーションでは 4 つの CTI ポートが必要になります。1:1 冗長性と 50/50 ロード バランシングを使用する場合は、これらを次のように設定します。

2 つの CTI ポートは、サーバ ノード A をプライマリ呼処理サブスクライバ、サーバ ノード B をバックアップ サブスクライバとする Unified CM 冗長性グループを持つようにします。残りの 2 つの CTI ポートは、サーバ ノード B をプライマリ サブスクライバ、サーバ ノード A をバックアップ サブスクライバとする Unified CM 冗長性グループを持つようにします。

IVR アプリケーションは、サブスクライバ A 上の CTI Manager をプライマリ、サブスクライバ B をバックアップとして使用するように設定します。

上の例は、サブスクライバ A 上の CTI Manager で障害が発生した場合の冗長性を備えており、IVR コールの負荷を 2 台のサーバ ノードに分散することもできています。この方法では、Unified CM サブスクライバ ノードの障害による影響も最小限に抑えることができます。

CTI および CTI Manager の詳細については、「コンピュータ テレフォニー インテグレーション(CTI)」を参照してください。

仮想マシンの配置およびハードウェア プラットフォームの冗長性

仮想化を使用する場合、物理サーバ間にわたる Unified CM サーバ ノードのインストールと常駐という仮想的特徴があるため、冗長性に関する考慮事項があります。

図 9-8 に示すように、たとえば、Unified CM を配置して最大レベルの呼処理の冗長性を確保する場合は、次のガイドラインに従ってください。

各プライマリ呼処理サブスクライバ ノード インスタンスは、バックアップ コール処理サブスクライバ ノード インスタンスとは異なる物理サーバ上に存在する必要があります。これにより、プライマリ呼処理ノード インスタンスを含むサーバで障害が発生しても、バックアップ呼処理サブスクライバ ノードへのアクセスをエンドポイントに提供するシステムの機能に影響は及ぼされません。

サービスの冗長性のために複数の TFTP またはメディア リソース サブスクライバ ノード インスタンスを配置する場合は、冗長サブスクライバ ノードを常に複数のサーバに分散させて、1 つのサーバの障害によってそれらのサービスが排除されないようにします。 これにより、TFTP またはメディア リソース サブスクライバを含むブレードで障害が発生しても、エンドポイントは別のサーバ上に存在するサブスクライバ ノードで TFTP およびメディア リソース サービスにアクセスできます。障害のないシナリオでは、エンドポイントも冗長 TFTP およびメディア リソース サブスクライバ ノード インスタンス間で分散させて、システムをロードバランスできます。

CTI アプリケーションを配置する場合は、CTI Manager サービスを実行する呼処理サブスクライバ ノード インスタンスを常に複数のサーバに分散させて、1 つのサーバの障害によって CTI サービスが排除されないようにします。さらに、CTI アプリケーションは、1 つのサーバ上のサブスクライバ ノード インスタンスで実行されている CTI Manager サービスをプライマリ CTI Manager として使用し、別のサーバ上のサブスクライバ ノードで実行されている CTI Manager サービスをバックアップ CTI Manager として使用するように設定する必要があります。

図 9-8 UCS での Unified CM サーバ ノードの分散

 

シャーシでブレード サーバを使用する場合(たとえば、Cisco UCS 5100 ブレード シャーシでは B シリーズ ブレード サーバ)、サーバ ノード インスタンスを複数のブレードに分散させる以外に、複数のブレード シャーシにサブスクライバ ノード インスタンスを分散させて、冗長性と拡張性を追加できます。

仮想マシンのホスト リソースの冗長性とプロビジョニングの詳細については、 http://www.cisco.com/go/uc-virtualized にあるドキュメントを参照してください。

Cisco Business Edition のハイ アベイラビリティ

Cisco Business Edition 6000 は、追加の Cisco Unified CM ノードをクラスタリングすることで、呼処理と登録サービスに対する冗長性を提供します。追加の Business Edition 6000 サーバは、呼処理のほか、その他のアプリケーションおよびサービスに対するハイ アベイラビリティを提供するために配置できます。


) WAN を介したクラスタの展開の場合と同様に、追加の冗長性と地理的な配信、あるいはそのいずれかを提供するために、Business Edition 6000 の展開では 2 台を超える Cisco Business Edition 6000 ハードウェア プラットフォームをクラスタリングできます。ただし、クラスタ全体でユーザの合計数が 1,000 を超えることはできず、クラスタ全体で設定されたデバイスの合計数が中密度サーバで 1,200、または高密度サーバで 2,500 を超えることはできません。これらの制限値を超える配置は、通常の Unified CM クラスタと見なされます。このため、展開は、通常の Unified CM のハイ アベイラビリティ設計ガイダンスに従う必要があります(「Unified CM のハイ アベイラビリティ」を参照)。


Cisco TelePresence VCS のハイ アベイラビリティ

Cisco VCS は、最大 6 つの VCS ピアを VCS クラスタに配置できるようにすることで、ハイ アベイラビリティを提供します。これは、Cisco VCS Control および Cisco VCS Expressway に適用されます。VCS ピアを使用できない場合、エンドポイントは登録や呼処理に VCS クラスタ内の別のピアを使用します。

ハイ アベイラビリティは、エンドポイントの機能に応じてさまざまな方法で実現できます。

SIP アウトバウンド(RFC 5626)をサポートする SIP 対応エンドポイントは複数のピアに同時に登録するように設定できます。同時登録を維持するメリットは、VCS サーバに障害が発生した場合のダウン タイムが回避されることです。エンドポイントが SIP ベースおよび RFC 5626 準拠である場合は、VCS 登録冗長性を提供するためにこの方法を使用することをお勧めします。


) この設定では、SIP エンドポイントが複数の VCS ピアに同時にアクティブに登録されるため、キャパシティと登録ライセンスに関して、それらの各 VCS ピアごとに、その SIP エンドポイントをカウント必要があります。


SIP エンドポイントが SIP アウトバウンドをサポートしていない場合、VCS クラスタのドメイン ネーム サーバ(DNS)レコードを使用してハイ アベイラビリティを実現できます。

H.323 エンドポイントの場合、ハイ アベイラビリティのメカニズムは、エンドポイントが VCS に初めて登録するのか、それ以降に再登録するのかによって異なります。初期登録の冗長性は VCS クラスタの DNS レコードを使用して提供されます。後続の登録に対する冗長性は、初期登録を介して H.323 エンドポイントに VCS によって返される「H.323 Alternate Gatekeepers」リストを介して実行されます。このリストには、VCS クラスタ ピアのメンバーのアドレスが含まれます。エンドポイントが、登録した最初の VCS ピアとの接続を失うと、「Alternate Gatekeepers」リストから別のピアを選択し、その VCS への再登録を試みます。

SIP および H.323 エンドポイントの場合、VCS ピアの 1 つの IP アドレスを設定することもできますが、この方法では登録の冗長性は得られないため、最後の手段としてのみ使用する必要があります。

前述のとおり、Domain Name Server(DNS)レコードを使用して冗長性を提供することもできます。SIP または H.323 エンドポイントは DNS サーバを使用して、以前のノードで初期登録が失敗した場合に登録を試行する別の VCS ノードの IP アドレスを検索します。登録冗長性に対処するために DNS を使用すると、ある程度の遅延が生じます。これは、初期登録要求を送信した後、新しい登録要求を別の VCS ノードに送信する前に、エンドポイントは一定の期間待機する必要があるからです。エンドポイントに応じて、DNS レコード タイプを有効にする方法は 2 種類あります。

DNS SRV(サービス レコード):DNS SRV レコードをサポートするエンドポイントの場合、VCS クラスタの DNS 名に DNS SRV レコードをセットアップして、各クラスタ ピアに同等の重みと優先順位を設定します。エンドポイントは、クラスタの DNS 名で設定する必要があります。起動時に、エンドポイントは DNS SRV 要求を発行し、各 VCS クラスタ ピアのアドレスを受信します。次に、エンドポイントは各ピアを順番に登録しようとします。登録の冗長性を実現するために DNS を使用する場合、エンドポイントによってサポートされているときは DNS SRV レコードが推奨されます。これは、この方法を使用したほうが、DNS A レコード間でラウンド ロビンを使用する場合よりもフェールオーバーの時間が短縮されるからです。

DNS ラウンドロビン: DNS SRV レコードをサポートしないエンドポイントの場合、Cisco VCS クラスタの DNS 名に DNS A レコードをセットアップして、各 VCS クラスタ ペアの IP アドレスのラウンド ロビン リストを提供するように設定します。エンドポイントは、クラスタの DNS 名で設定する必要があります。起動時に、エンドポイントは DNS A レコードのルックアップを実行し、ラウンド ロビン リストから取得したピアのアドレスを受け取ります。エンドポイントはそのピアへの登録を試行します。そのピアを使用できない場合、エンドポイントは別の DNS ルックアップを実行し、サーバはリスト内の次のピアで応答します。このプロセスは、エンドポイントが VCS に登録するまで繰り返されます。

詳細については、次の Web サイトから入手可能な『 Cisco TelePresence Video Communication Server Cluster Creation and Maintenance Deployment Guide 』の最新バージョンを参照してください。

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

Cisco VCS を仮想アプリケーションおよびクラスタリング VCS ノードとして配置する場合、少なくとも 2 つの物理ハードウェア ホストを使用してこれらの別個のホストで VCS ピアを実行することを強く推奨します。Unified CM に関する同じガイドラインも適用できます(「仮想マシンの配置およびハードウェア プラットフォームの冗長性」を参照)。

Cisco VCS Control が Cisco Business Edition 6000 の一部として配置される場合、同じ VCS Control クラスタに他の Cisco VCS Control ピアを追加することでハイ アベイラビリティを実現することもできます。Cisco VCS Expressway が Cisco Business Edition 6000 システムに追加される場合、同じ VCS Expressway クラスタに他の Cisco VCS Expressway ピアを追加することでハイ アベイラビリティを実現することもできます。ハイ アベイラビリティに対して Cisco VCS ピアを追加する場合は、別のホスト上に配置することを推奨します。2 つのノードの VCS Control クラスタおよび 2 つのノードの VCS Expressway クラスタは、各ホスト サーバが 1 つの VCS Control ノードと 1 つの VCS Expressway ノードをホストする状態で、2 つのサーバを配置できます。同じ ESXi ホストへの VCS Control ノードと VCS Expressway ノードの配置の詳細については、次の URL で入手可能な『 Installing Cisco Video Communications Server Expressway on a Business Edition 6000 Server 』のマニュアルを参照してください。

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

呼処理のキャパシティ プランニング

呼処理のキャパシティ プランニングは、ユニファイド コミュニケーションの配置を成功させるために重要です。呼処理サービスによって多くの機能が提供され、呼処理エンティティによって多くのタイプのデバイスに登録およびトランザクション サービスを提供できるため、特定の配置のキャパシティ要件を満たすように呼処理インフラストラクチャとその個別のコンポーネントをサイジングすることが重要です。

IP Phone、ソフトウェア クライアント、ボイスメール ポート、CTI(TAPI または JTAPI)デバイス、ゲートウェイ、およびメディア サービスの DSP リソース(トランスコーディングや会議)は、すべて呼処理エンティティに登録されます。これらのデバイスには、登録先の呼処理プラットフォームのリソースが必要です。必要なリソースには、メモリ、プロセッサ使用、およびディスク I/O が含まれます。

呼処理プラットフォームに登録の負荷を追加する以外に、登録後、各デバイスはトランザクション(通常はコールの形態)中に追加のプラットフォーム リソースを消費します。たとえば、1 時間あたり 6 回のコールだけを行うデバイスが消費するリソースは、1 時間あたり 12 回のコールを行うデバイスより少なくなります。

呼処理サイジングの詳細や、システム サイジング、キャパシティ プランニング、および配置の考慮事項に関する詳しい説明については、「コラボレーション ソリューションの設計および配置サイジングに関する考慮事項」の章を参照してください。

Unified CME のキャパシティ プランニング

Unified CME を配置する場合、必要となるサポート対象エンドポイント数という観点で、目的に合ったキャパシティを提供する Cisco IOS ルータ プラットフォームを選択することが重要です。また、Unified CME ルータが、呼処理以外のサービス(IP ルーティング、DNS ルックアップ、Dynamic Host Configuration Protocol(DHCP)アドレス サービス、VXML スクリプトなど)を提供する場合は、プラットフォームのメモリ キャパシティも考慮する必要があります。

Unified CME は、単一の Cisco IOS プラットフォーム上で最大 450 エンドポイントをサポートできます。ただし、各ルータ プラットフォームのエンドポイントのキャパシティは、システムのサイズによって異なります。Unified CME は Cisco Unified Communications Sizing Tool ではサポートされないため、次の Web サイトで入手可能な製品データ シートに記載されているキャパシティ情報に従う必要があります。

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

Unified CM のキャパシティ プランニング

ここでは、Unified CM のキャパシティ プランニングについて説明します。この項で示す推奨事項は、Unified Communications Sizing Tool を、デフォルトのトレース レベルとコール詳細レコード(CDR)を有効にして使用し、その結果として得た計算に基づいています。呼処理に直接関係しない他の機能を使用不可にしたり、縮小したり、再設定したりすると、より高いレベルのパフォーマンスとキャパシティが得られる場合があります。こうした機能の利用を可能にしたり増やしたりすると、システムの呼処理機能に影響を与える可能性があり、全体的なキャパシティを低下させる場合もあります。これらの機能には、トレース、コール詳細レコード、複雑なダイヤル プラン、および Unified CM プラットフォーム上に共存するその他のサービスが含まれます。 複雑なダイヤル プランには、複数のライン アピアランス、多くのパーティション、コーリング サーチ スペース、ルート パターン、変換、ルート グループ、ハント グループ、ピックアップ グループ、ルート リスト、自動転送、共存サービス、およびその他の共存アプリケーションが含まれています。こうした機能はすべて、Unified CM システム内の追加リソースを消費します。

次の手法を使用して、システム パフォーマンスを向上させることができます。

多数のゲートウェイ、ルート パターン、トランスレーション パターン、およびパーティションを含む非常に大きなダイヤル プランを持つ Unified CM クラスタでは、Cisco CallManager サービスの初回始動時に、初期化に長い時間がかかる場合があります。デフォルトの時間内にシステムが初期化されない場合、システム初期化タイマー(Unified CM サービス パラメータ)を変更して、設定を初期化するための時間を追加できます。システム初期化時間の詳細については、Unified CM Administration オンライン ヘルプのサービス パラメータに関する説明を参照してください。

Unified CM のキャパシティ プランニング ガイドラインおよびエンドポイントの制限

Cisco Unified CM には、次のキャパシティ ガイドラインが適用されます。

クラスタ内では、Cisco CallManager サービスを使用して最大 8 つの呼処理サブスクライバ ノードを使用可能にできます。それ以外のサーバ ノードは、パブリッシャ、TFTP サブスクライバ、メディア リソース サブスクライバなどの専用機能に使用できます。

各 Unified CM ノードは、最大 10,000 台のセキュアまたはセキュアでない SCCP または SIP エンドポイントの設定および登録をサポートできます。各クラスタは、最大 40,000 台のセキュアまたはセキュアでない SCCP または SIP エンドポイントの設定および登録をサポートできます。

必要な容量によって、Cisco Unified CM の OVA テンプレートのサイズが異なります。Unified CM OVA テンプレートの名前は、各ユーザが 1 台の電話機を所有していることを前提として、各ノードで最大ユーザ数に対応しています。つまり、各ノードで最大のエンドポイント数に対応しています。使用される BHCA およびフィーチャ セットなどの異なる変数に応じて、実際のユーザまたはエンドポイントの数は下回る場合があります。配置のサイジングを検証するには、次の URL の Cisco Unified Communications Sizing Tool を使用してください。

http://tools.cisco.com/cucst

Cisco Business Edition 6000 では、Unified CM OVA テンプレート名は、各ノードで最大ユーザ数に対応していますが、各ユーザが 1 台の電話機を所有しているという前提条件は、もう適用されません。詳細については、「Cisco Business Edition のキャパシティ プランニング」の項を参照してください。

CallManager サービスのデフォルトのトレース設定は、Signaling Distribution Layer(SDL)トレースで 10 MB の 1,500 ファイルになります。コール レートの高い環境での特定のトラブルシューティングでファイルの最大数を増やす必要がある場合を除き、ほとんどの環境ではデフォルト設定で十分なトレースを収集できます。

サイジングの制限や、システム サイジング、キャパシティ プランニング、および配置の考慮事項に関する詳しい説明など、Unified CM キャパシティ プランニングの考慮事項の詳細については、「コラボレーション ソリューションの設計および配置サイジングに関する考慮事項」の章を参照してください。

メガクラスタ

メガクラスタ という用語は、拡張性をさらに増大させることが可能な特定の Unified CM 配置を定義および識別します。メガクラスタでは、追加の Unified CM サブスクライバ ノードのサポートにより、さらに多くのデバイス キャパシティが提供されます。メガクラスタごとに最大 8 つの Unified CM サブスクライバ ペア(1:1 冗長性)を設定でき、これにより、最大で 80,000 台のデバイスを使用できます。

メガクラスタは、Survivable Remote Site Telephony(SRST)を使わない場合、標準のクラスタ配置では最大 8 サイトまでしか展開できないリモート フェイルオーバー呼処理機能を、メガクラスタあたり最大 16 サイトまで展開できます。たとえば、12 のロケーションがある大きな病院で、各ロケーションに 1,000 個のデバイスしかないとします。この合計 12,000 というデバイス数だけでいうと、標準クラスタの最大デバイス キャパシティが 40,000 であるため、標準クラスタで提供できます。しかし、この場合で必要なのは、メガクラスタ配置を必要とするデバイス キャパシティの追加ではなく、Unified CM サブスクライバの追加です。この例では、Unified CM サブスクライバ ノードは、各ロケーションに配置され、各 Unified CM サブスクライバは、ローカル エンドポイントのプライマリ サブスクライバとして、また、リモート エンドポイントのバックアップ サブスクライバとして動作できます。

メガクラスタ配置を検討する場合、キャパシティに影響を与える主な領域は次のとおりです。

メガクラスタには、16 台のサブスクライバ ノード、2 台の TFTP サーバ ノード、2 台の保留音(MoH)サーバ ノード、および 1 台のパブリッシャ ノードで構成される合計 21 台のサーバ ノードが含まれることがあります。

Unified CM は、OVA の 7,500 ユーザまたは 10,000 ユーザの OVA テンプレートで展開する必要があります。

冗長性モデルは 1:1 である必要があります。

標準クラスタに関連する他のすべてのキャパシティがメガクラスタにも適用されます。メガクラスタ配置のサポートは、Cisco Unified Communications Sizing Tool の結果の送信など、詳細設計の確認が成功した後でのみ与えられることに注意してください。Cisco Unified Communications Sizing Tool および Unified CM 標準クラスタとメガクラスタのサイジングの詳細については、「コラボレーション ソリューションの設計および配置サイジングに関する考慮事項」の章を参照してください。

メガクラスタ配置に関しては複雑な考慮事項が多数あるので、このような配置の実現を望むお客様は、シスコのアカウント チーム、シスコ アドバンスド サービス、または認定された Cisco Unified Communications パートナーに関与してもらう必要があります。


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


Cisco Business Edition のキャパシティ プランニング

Unified CM と同様に、多くのタイプのデバイスを Cisco Business Edition に登録でき、これらの各デバイスには登録先のプラットフォームからの登録とトランザクション リソースが必要です。また、ユーザ数およびユーザの最繁時呼数(BHCA)は、システム リソースをさらに消費します。それぞれの Cisco Business Edition システムには、プラットフォームの利用可能システム リソースに基づく、固有のユーザ、エンドポイント、および BHCA キャパシティのしきい値があります。Cisco Business Edition 6000 では、ユーザの最大数は 1,000 人で、エンドポイントの最大数は中密度サーバで 1,200 人、高密度サーバで 2,500 人です。Cisco Business Edition 6000 は、最大 5,000 BHCA をサポートします。

Cisco VCS が Cisco Business Edition 6000 の一部として展開される場合、非トラバーサル コールの最大数は 100、トラバーサル コールの最大数は 100 です。

サイジングの例およびプラットフォームごとのサイジングの制限や、システム サイジング、キャパシティ プランニング、および配置の考慮事項に関する詳しい説明など、Cisco Business Edition キャパシティ プランニングの考慮事項の詳細については、「コラボレーション ソリューションの設計および配置サイジングに関する考慮事項」の章を参照してください。

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

Cisco Business Edition 6000 データ シート

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

Cisco Business Edition 6000 の共存のポリシー要件

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

Cisco TelePresence VCS キャパシティ プランニング

キャパシティの面では、1 台の Cisco VCS Control のノードで次をサポートできます。

最大 2,500 の登録

最大 500 の非トラバーサル コール

最大 100 のトラバーサル コール

最大 1,000 のサブゾーン

キャパシティを増やすために、最大 6 個の VCS ピアのメンバーを持つ VCS クラスタを配置できます。VCS クラスタは高いスケーラビリティを実現するだけでなく、N+2 設定の冗長性も提供します。1 つのクラスタの最大合計キャパシティは単一の VCS の 4 倍であり、クラスタのキャパシティに影響を与えることなく、最大 2 台の VCS ノードの障害をサポートします。

したがって、6 つの VCS を持つ 1 つのクラスタのキャパシティで次をサポートできます。

最大 10,000 の登録

最大 2,000 の非トラバーサル コール

最大 400 のトラバーサル コール

複数の異なる VCS クラスタを配置することもできます。これらはディレクトリ VCS などを介して相互接続できます。

サイジングの制限や、システム サイジング、キャパシティ プランニング、および配置の考慮事項に関する詳しい説明など、Cisco TelePresence VCS キャパシティ プランニングの考慮事項の詳細については、次の Web サイトから入手可能な Cisco VCS 製品マニュアルを参照してください。

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

呼処理の設計上の考慮事項

シスコの呼処理を配置する際は、次の設計上の推奨事項およびガイドラインに従ってください。

Cisco Unified CME

Unified CME は、最大で 450 のエンドポイントをサポートします。ただし、Cisco IOS ルータ モデルによっては、エンドポイント キャパシティは大幅に低下する場合があります。Unified CME のプラットフォームおよびキャパシティの詳細については、次の Web サイトにある Cisco Unified Communications Manager Express の互換性情報を参照してください。 http://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_device_support_tables_list.html

可能な場合は、複数の IP インターフェイスを使用して Unified CME ルータをネットワークに二重接続し、ネットワークの可用性を最大限まで高めます。 同様に、同じ配置で Unified CME の複数のインスタンスが必要な場合は、複数の物理スイッチまたはロケーションに分散します。

可能な場合は、二重化電源および無停電電源(UPS)を備えた Unified CME ルータを配置し、プラットフォームの可用性を最大限まで高めます。

Cisco Business Edition

Business Edition 6000 は特定のテスト済みリファレンス構成で動作し、Unified CM は、パブリッシャとシングル サブスクライバの複合インスタンスとして配置されます。追加の Business Edition 6000 サーバは、サブスクライバ ノードを追加することで、呼処理の冗長性を提供します。


) さらなる冗長性と地理的な分散、あるいはそのいずれかを提供するために、Business Edition 6000 の展開では 2 台を超える Business Edition 6000 サーバをクラスタリングできます。ただし、クラスタ全体でユーザの合計数が 1,000 を超えることはできず、クラスタ全体で設定されたデバイスの合計数が中密度サーバで 1,200、または高密度サーバで 2,500 を超えることはできません。


Business Edition 6000 は、中密度サーバで 1,200 のエンドポイント、または高密度サーバで 2,500 のエンドポイントをサポートします。ただし、実際のエンドポイント キャパシティは総システム BHCA によって異なりますが、最大で 5,000 を超えることはできません。サイジングの例やプラットフォームごとのサイジングの制限など、Cisco Business Edition のキャパシティの詳細については、「コラボレーション ソリューションの設計および配置サイジングに関する考慮事項」の章を参照してください。

同じ配置で複数の Business Edition 6000 サーバが必要な場合は、複数の物理スイッチに分散します。

特にサーバに電源装置が 1 台しかない場合、可用性を最大限まで高めるために、無停電電源装置(UPS)を使用します。

Business Edition 6000 をハイ アベイラビリティ用に 2 台のサーバで配置する場合は、1 つのサーバに障害が発生した場合にハイ アベイラビリティを提供するように、Unified CM ノードを各サーバで実行する必要があります。さらに、システム負荷を分散させるため、デバイス登録が 2 台の Unified CM ノード間でロードバランスされる必要があります。スタンバイ冗長性のために 2 台めの Unified CM ノードを使用することを推奨します。

Cisco Unified CM

Cisco Unified CM は、VMware Hypervisor 上で仮想化アプリケーションとしてのみ動作します。また、VMware Hypervisor を使用しない場合、ハードウェア プラットフォーム上で直接動作しません。

Cisco Unified CM クラスタ内で最大 8 つの呼処理サブスクライバ ノード(Cisco CallManager サービスを実行するノード)を使用可能にできます。その他のサーバ ノードは、パブリッシャ、TFTP、およびメディア リソース サービス専用で使用できます。承認されたメガクラスタ配置は、最大で 16 個の呼処理サブスクライバ ノードをサポートします。

各 Unified CM クラスタは、最大 40,000 台のセキュアまたはセキュアでないエンドポイントの設定および登録をサポートできます。プラットフォームごとのサイジングの制限など、Unified CM のキャパシティ プランニングの詳細については、「コラボレーション ソリューションの設計および配置サイジングに関する考慮事項」の章を参照してください。

ノードが 2 つのクラスタを配置する場合も、クラスタ内のユーザ数が 1,250 を超えないようにすることを推奨します。1,250 ユーザを超える場合は、専用パブリッシャと別個のノードをプライマリおよびバックアップの呼処理サブスクライバ用に推奨します。

クラスタ内のすべてのノードで同じ OVA テンプレートを使用することを推奨します。

2:1 冗長性では、バックアップ サブスクライバが過負荷の状態になることがあるので、10,000 ユーザの OVA テンプレートでサポートされません。

仮想マシンのネットワーク トラフィックにハードウェア プラットフォームの複数の物理ポートを使用し、最低 2 台のアップストリーム スイッチを使用して、ネットワーク接続の冗長性を提供します。VMware vSphere 仮想スイッチを使用している場合は、VMware NIC チーミングを使用します。

可能な場合は常に、ハードウェア プラットフォームをネットワーク内の複数の物理スイッチおよび同じネットワーク内の複数の物理ロケーションに分散させて、スイッチの障害または特定のネットワーク ロケーションの損失による影響を最小限に抑えます。

Cisco Unified SRST または E-SRST をリモート ロケーションの Cisco IOS ルータに配置して、これらのロケーションで Unified CM クラスタへの接続が失われた場合にフォールバック呼処理サービスを提供します。

Unified CM クラスタ内で音声アクティビティ検出(VAD)を使用不可にしておくことを推奨します。デフォルトでは、Unified CM サービス パラメータで VAD は使用不可になっています。Cisco IOS ゲートウェイで設定されている H.323 および SIP ダイヤル ピア上で使用不可にするには、 no vad コマンドを使用してください。

バックアップまたは冗長サブスクライバ ノードがプライマリ サブスクライバ ノードとは別のサーバ上に置かれるように、Unified CM ノードが異なるサーバに分散されていることを確認します。

UCS B シリーズ ブレード サーバおよびミッドエンドまたはハイエンドの C シリーズ ラックマウント サーバは、すべての Unified CM Open Virtualization Archive(OVA)テンプレートのサイズ(たとえば、10,000 のデバイスをサポートする OVA テンプレート)をサポートします。ただし、一部の小規模なサーバは小規模の OVA テンプレートのサイズのみをサポートします。適切な OVA テンプレートのサイジングと、Cisco Unified Communications Sizing Tool の使い方の詳細については、「コラボレーション ソリューションの設計および配置サイジングに関する考慮事項」の章を参照してください。

ハードウェア プラットフォームの USB ポートおよびシリアル ポートへのアクセスは、Unified CM 仮想マシンではサポートされていません。そのため、MoH 用の固定ライブ オーディオ ソースを接続すること、レガシー ボイスメール システムへのシリアル SMDI 接続を行うこと、またはログ ファイルの書き込みのために USB フラッシュ ドライブを接続することもできません。次の代替オプションを使用できます。

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

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

SMDI シリアル接続に対するサポートはありません。

Cisco TelePresence VCS

Cisco VCS クラスタは、アプライアンスで実行している VCS ノードと、仮想アプリケーションとして実行している VCS ノードを組み合わせて形成できます。

アプライアンス上で実行されているか、仮想アプリケーションとして実行されている VCS ノードは同様に実行され、キャパシティ制限は同じです。ただし、クラスタ内のすべての VCS ノードを同じ OVA テンプレートにする必要があります。

コンピュータ テレフォニー インテグレーション(CTI)

Cisco コンピュータ テレフォニー インテグレーション(CTI)を利用すると、Cisco Unified CM で使用可能な豊富なフィーチャ セットだけでなく、サードパーティ製のアプリケーションも使用できるようになります。Cisco CTI は Cisco VCS で使用できません。CTI 対応アプリケーションによって、ユーザの生産性が向上し、コミュニケーションが活発になるとともに、高品質のカスタマー サービスを提供できるようになります。Cisco CTI を使用すると、サードパーティ製デスクトップ アプリケーションで Microsoft Outlook 内から通話を行ったり、着信コールの発信者 ID に基づいてウィンドウを開いたり、アプリケーションを起動したりできます。また、課金のためにコールと連絡先をリモートで追跡することもできます。Cisco CTI 対応のサーバ アプリケーションでは、企業ネットワーク全体での適切な対応先のルーティングや、自動応答や音声自動応答装置(IVR)などの自動発信者サービスの提供に加えて、対応先の記録および分析に役立つメディアの取り込みも行えます。

CTI アプリケーションは一般に、次の 2 つの主なカテゴリに分類できます。

ファーストパーティのアプリケーション:モニタ、制御、メディア ターミネーション

ファーストパーティの CTI アプリケーションは、コールのセットアップ、終了、およびメディア ターミネーション用の CTI ポートおよびルート ポイントなどのデバイスを登録するように設計されています。これらのアプリケーションはメディア パスに直接配置されているので、インバンド DTMF などのメディア レイヤのイベントに応答できます。ファーストパーティの CTI アプリケーションには音声自動応答装置や Cisco Attendant Console などがあり、これらのアプリケーションはコールをモニタおよび制御しながら、コール メディアとも対話します。

サードパーティのアプリケーション:モニタおよび制御

サードパーティの CTI アプリケーションもコールをモニタおよび制御しますが、メディア ターミネーションは直接制御しません。

モニタリング アプリケーション

Cisco IP デバイスの状態をモニタする CTI アプリケーションは、モニタリング アプリケーションと呼ばれます。オンフックまたはオフフックのステータスを表示する、またはその情報を使用してユーザの可用性をプレゼンスの形式で示すビジーランプフィールド アプリケーションは、どちらもサードパーティ製の CTI モニタリング アプリケーションの例です。

呼制御アプリケーション

Cisco CTI を使用して、アウトオブバンド シグナリングにより Cisco IP デバイスをリモート制御するアプリケーションは、呼制御アプリケーションです。Cisco Jabber は、Cisco IP デバイスをリモート制御するように設定された場合に、呼制御アプリケーションのよい例です。

モニタリング + 呼制御アプリケーション

これらは、Cisco IP デバイスをモニタおよび制御するすべての CTI アプリケーションです。Cisco Unified Contact Center Enterprise は、エージェントのステータスをモニタして、エージェント デスクトップを介してエージェント電話機を制御するため、モニタと制御を兼ね備えたアプリケーションのよい例です。


) ここでモニタリング アプリケーション、呼制御アプリケーション、モニタリング + 呼制御アプリケーションの違いを列挙しましたが、この細かな違いはアプリケーション開発者には見えないようになっています。Cisco CTI を使用するすべての CTI アプリケーションは、モニタリングおよび制御の両方に有効です。


次のデバイスは CTI 経由でモニタまたは制御できます。

CTI ルート ポイント

CTI ポート

CTI をサポートする Cisco Unified IP Phone

CTI リモート デバイス

CTI リモート デバイスにより、従来の PSTN 電話機、携帯電話、サードパーティ電話、またはサードパーティ PBX に接続されている電話機などの、CTI をサポートしない電話機上のモニタリング機能および制限された呼制御機能を CTI アプリケーションが持つことができるようにします。

CTI のアーキテクチャ

Cisco CTI は、次のコンポーネントで構成されます(図 9-9 を参照)。これらは互いに対話し、Cisco Unified CM で使用可能なテレフォニーフィーチャ セットを各アプリケーションで利用できるようにします。

CTI 対応アプリケーション:特定のテレフォニー機能を提供するために作成されたシスコ製またはサードパーティ製のアプリケーション。

JTAPI および TAPI:Cisco CTI でサポートされる 2 つの標準インターフェイス。開発者は、好みの方式のライブラリを使用してアプリケーションを作成できます。

Unified JTAPI および Unified TSP クライアント:外部メッセージを Cisco Unified CM で使用される内部の Quick Buffer Encoding(QBE)メッセージに変換します。

Quick Buffer Encoding(QBE):Unified CM の内部通信メッセージ。

プロバイダー:アプリケーションと CTI Manager との接続の論理的な表現であり、通信を容易にするために使用されます。プロバイダーは、アプリケーションにデバイス イベントおよびコール イベントを送付しながら、アプリケーションによるデバイスのリモート制御を可能にする制御命令を受け付けます。

Signaling Distribution Layer(SDL):Unified CM の内部通信メッセージ。

パブリッシャおよびサブスクライバ:Cisco Unified Communications Manager(Unified CM)サーバ ノード。

CCM:Cisco CallManager サービス(ccm.exe)。テレフォニー処理エンジンです。

CTI Manager(CTIM):プライマリまたはセカンダリ モードで動作する 1 つ以上の Unified CM サブスクライバで実行され、Cisco IP デバイスを制御およびモニタできるようにテレフォニー アプリケーションを認証および許可するサービス。

図 9-9 Cisco CTI のアーキテクチャ

 

アプリケーションを認証および許可すると、CTIM は、テレフォニー アプリケーションと Cisco CallManager サービスの仲介者として機能します(このサービスは呼制御エージェントです。全体の製品名である Cisco Unified Communications Manager と混同しないでください)。CTIM はテレフォニー アプリケーションから送信される要求に応答し、その要求を Unified CM システムで内部的に使用される Signaling Distribution Layer(SDL)メッセージに変換します。Cisco CallManager サービスからのメッセージも CTIM によって受信され、処理のために適切なテレフォニー アプリケーションに転送されます。

CTIM は、Cisco CallManager サービスがアクティブになっているクラスタ内の Unified CM サブスクライバ ノードでアクティブにできます。これによって、Unified CM クラスタ内で 8 つまでの CTIM をアクティブにできます。スタンドアロンの CTIM は現在サポートされていません。

WAN を介した CTI アプリケーションおよびクラスタリング

WAN を介したクラスタリングを採用した配置では、次の 2 つのシナリオがサポートされます。

WAN を介した CTI Manager(図 9-10 を参照)

このシナリオでは、CTI アプリケーションとそれに関連付けられた CTI Manager が WAN の一方の側(サイト 1)に配置され、Unified CM サブスクライバに登録されるモニタおよび制御対象のデバイスが他方の側(サイト 2)に配置されます。WAN を介したクラスタリングのラウンドトリップ時間(RTT)は、現在サポートされている限度値 80 ms を超えることはできません。CTI トラフィックに必要な帯域幅を計算するには、「ローカル フェールオーバー配置モデル」 にある公式を使用します。この帯域幅は、「ローカル フェールオーバー配置モデル」の説明に従って計算した Intra-Cluster Communication Signaling(ICCS)帯域幅や、音声に必要な帯域幅(RTP トラフィック)とは別に必要であることに注意してください。

図 9-10 WAN を介した CTI

 

WAN を介した TAPI および JTAPI アプリケーション(WAN を介した CTI アプリケーション)(図 9-11 を参照)

このシナリオでは、CTI アプリケーションが WAN の一方の側(サイト 1)に配置され、関連付けられた CTI Manager が他方の側(サイト 2)に配置されます。このシナリオでは、CTI アプリケーション開発者またはプロバイダーの責任において、アプリケーションが実際の RTT に適応できるかどうかを確認します。場合によっては、アプリケーションが CTI Manager と同じ場所にある場合よりも、フェールオーバー時間およびフェールバック時間が長くなることがあります。このような場合、アプリケーション開発者またはプロバイダーは、そのような状況におけるアプリケーションの動作に関するガイダンスを示す必要があります。

図 9-11 WAN を介した JTAPI

 


) WAN を介した TAPI および JTAPI のサポートは、アプリケーションに依存します。ユーザとアプリケーション開発者またはプロバイダーの両者が、使用するアプリケーションに WAN を介したクラスタリングが含まれる配置との互換性があることを確認する必要があります。


CTI のキャパシティ プランニング

サポートされている CTI 制御デバイスの最大数は、クラスタごとに 40,000 です。プラットフォームごとのノードおよびクラスタの CTI キャパシティや、CTI リソースの計算式および例など、CTI のキャパシティ プランニングの詳細については、「コラボレーション ソリューションの設計および配置サイジングに関する考慮事項」の章を参照してください。

CTI のハイ アベイラビリティ

ここでは、ハイ アベイラビリティのための CTI プロビジョニングについて、いくつかのガイドラインを提供します。

CTI Manager

CTI Manager は、Unified CM クラスタ内の少なくとも 1 つ(あるいはすべて)の呼処理サブスクライバで有効にする必要があります。クライアント側のインターフェイス(TAPI TSP または JTAPI クライアント)では IP アドレスを 2 つずつ使用できます。これらの IP アドレスは、CTIM サービスを実行している Unified CM サーバ ノードを指します。CTI アプリケーションの冗長性を確保するため、図 9-12 のとおり、クラスタの少なくとも 2 つの Unified CM サーバ ノードで、CTIM サービスをアクティブにすることを推奨します。

冗長性、フェールオーバー、およびロード バランシング

冗長性が必要な CTI アプリケーションでは、TAPI TSP または JTAPI クライアントは 2 つの IP アドレスで設定できるため、障害発生時には代替の CTI Manager を使用できます。ここで注意すべきは、2 つの CTI Manager 間で情報が共有されていないため、この冗長性はステートフルではありません。そのため、フェールオーバーの際に、再初期化が必要になることがあります。

CTI Manager がフェールオーバーした場合、必要な処理は、現在アクティブになっている CTI Manager で CTI アプリケーションのログイン プロセスをやり直すことだけです。ただし、Unified CM サーバ ノード自体に障害が発生した場合は、障害が発生した Unified CM や現在アクティブになっている Unified CM などのすべてのデバイスを再登録し、その後で CTI アプリケーションのログイン プロセスを実行する必要があるため、再初期化プロセスは時間がかかります。

ロード バランシングが必要な CTI アプリケーションや、この設定を利用できる CTI アプリケーションは、図 9-12 に示すように、2 つの CTI Manager に同時に接続できます。

図 9-12 冗長性とロード バランシング

 

図 9-13 は、このタイプの Cisco Unified Contact Center Enterprise(Unified CCE)の設定例を示しています。このタイプの設定には、次の特性があります。

Unified CCE は冗長性のために 2 つの Peripheral Gateway(PG)を使用します。

各 PG は異なる CTI Manager にログインします。

一度に 1 つの PG しかアクティブになりません。

図 9-13 Cisco Unified Contact Center Enterprise での CTI の冗長性

 

図 9-14 は、このタイプの Cisco Unified Contact Center Express(Unified CCX)の設定例を示しています。このタイプの設定には、次の特性があります。

Unified CCX では、各 CTI Manager 用に 1 つずつ、合計で 2 つの IP アドレスを設定できます。

プライマリ CTI Manager への接続が失われた場合、Unified CCX はセカンダリ CTI Manager にフェールオーバーします。

図 9-14 Cisco Unified Contact Center Express での CTI の冗長性

 

実装

アプリケーションの作成に関するガイダンスとサポートについて、アプリケーション開発者は次の Web サイトの Cisco Developer Connection で相談してください。

http://developer.cisco.com/web/cdc/community

複数の呼処理エージェントの統合

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

また、Unified CM Session Management Edition を使用して、PSTN 接続、PBX、集中型のユニファイド コミュニケーション アプリケーションなど、サードパーティのユニファイド コミュニケーション システムに接続できます。

SME の詳細については、「Unified CM Session Management Edition」の項を参照してください。

複数の呼処理エージェントの直接的統合も可能です。次の項では、Cisco Unified Communications Manager Express(Unified CME)との Cisco Unified CM の直接的統合、および Cisco TelePresence VCS との Unified CM の統合についても説明します。

Unified CM と Unified CM Express の相互運用性

この項では、SIP トランキング プロトコルを使用している Cisco Unified CM と Cisco Unified Communications Manager Express(Unified CME)に関して、マルチサイト IP テレフォニー配置における相互運用性およびインターネットワーキングの要件について説明します。ここでは、Unified CM の制御する電話機と Unified CME の制御する電話機との間での推奨する配置を中心に説明します。

この項では、次の項目について説明します。

「Unified CM と Unified CME 間の相互運用性の概要」

「分散型呼処理を使用したマルチサイト配置における SIP 経由の Unified CM と Unified CME の相互運用性」

Cisco Unified CM および Cisco Unified Communications Manager Express(Unified CME)は、H.323 を使用して統合することもできますが、ここではこの統合について詳しく説明しません。H.323 統合の詳細については、次の Web サイトで入手可能な『 Cisco Collaboration 9.x SRND 』を参照してください。

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

Unified CM と Unified CME 間の相互運用性の概要

H.323 または SIP をトランキング プロトコルとして使用して、Unified CM と Unified CME を相互接続できます。本社または中央サイトに Unified CM を配置して、支社の Unified CME システムと連携させる場合、ネットワーク管理者は、プロトコルの仕様と WAN トランク全体でサポートされる機能を慎重に検討して、SIP または H.323 のいずれかのプロトコルを選択する必要があります。以前は、H.323 トランクを使用して Unified CM と Unified CME を接続する方法が主流でしたが、SIP 電話機と SIP トランクのより高度な機能が Unified CM と Unified CME に追加されたことで、この状況は変わりました。この項ではまず、Unified CM と Unified CME の相互運用性のトランキング プロトコルとは無関係のいくつかの機能について説明し、次に SIP トランクを使用するための最も一般的な設計シナリオとベスト プラクティスを紹介します。

コール タイプとコール フロー

一般に、Unified CM と Unified CME のインターワーキングを使用すると、SIP トランクまたは H.323 トランクを介して、SCCP IP Phone から SIP IP Phone へのコール、またはその逆についても、すべての組み合わせでコールが可能です。コールは、Unified CM 配下と Unified CME 配下の SIP、または SCCP IP Phone との間で、転送(ブラインドまたは打診)または自動転送できます。

H.323 トランク経由で Unified CM に接続していると、Unified CME は Unified CM のコールを自動検出できます。Unified CME で終端されているコールが転送または自動転送されると、Unified CME はコールを再生成し、ヘアピン コールによって他の Unified CME または Unified CM に適切にコールをルーティングします。Unified CME は必要に応じて、Unified CM からのコール レッグを、SIP トランクまたは H.323 トランクを介して VoIP コールへヘアピンします。H.450 に対応していない Unified CM ネットワークで自動検出を可能にする方法と、H.450.2、H.450.3、または SIP の付加サービスを有効または無効にする方法の詳細については、次の Web サイトで入手可能な Unified CME の製品マニュアルを参照してください。

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

SIP トランク経由で Unified CM に接続すると、Unified CME は Unified CM のコールを自動検出しません。デフォルトでは、Unified CME は常に、コール転送の SIP Refer メッセージまたは自動転送の SIP 302 Moved Temporarily メッセージを使用して、コールをリダイレクトしようとします。リダイレクトが失敗すると、Unified CME はヘアピン コールを試みます。

保留音(Music on Hold)

Unified CM では G.711 形式と G.729 形式の両方で MoH ストリームを有効にできますが、Unified CME で MoH をストリームできるのは G.711 形式のみです。そのため、保留になったコールの MoH オーディオを Unified CME で制御する場合は、G.711 MoH ストリームと G.729 コール レッグの間でトランスコーディングするためのトランスコーダが必要です。

アドホックおよび Meet-Me のハードウェア会議

アドホック会議と Meet-Me 会議の両方に、ハードウェアの DSP リソースが必要です。SIP、H.323、PSTN のいずれを経由して接続している場合でも、Unified CM 電話機と Unified CME 電話機は、ネットワークから到達できる限り、アドホック会議に招待または追加されて、会議の参加者になることができます。アクティブな会議のセッション中にコールを保留にしても、その会議のセッションの参加者には MoH オーディオは聞こえません。

アドホック会議と Meet-Me 会議に必要でサポートされる DSP リソースと、会議に参加できる最大人数については、次の Web サイトで入手可能な Unified CME の製品マニュアルを参照してください。

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

分散型呼処理を使用したマルチサイト配置における SIP 経由の Unified CM と Unified CME の相互運用性

Unified CM は、SIP インターフェイスを使用して Unified CME と直接通信できます。図 9-15 に、SIP トランクを使用して Unified CM が Cisco Unified CME と直接ネットワーク接続されている Cisco Unified Communications マルチサイト配置を示します。

図 9-15 SIP トランクを使用して Unified CM と Unified CME を接続したマルチサイト配置

 

ベスト プラクティス

図 9-15 に示した配置モデルを使用する場合は、次のガイドラインに従い、ベスト プラクティスを参考にしてください。

[Accept Replaces Header] を選択した SIP トランク セキュリティ プロファイルを設定します。

作成した SIP トランク セキュリティ プロファイルを使用して SIP トランクを Unified CM 上に設定し、再ルーティング CSS も指定します。再ルーティング CSS は、SIP ユーザ(転送者)が別のユーザ(被転送者)を第三者ユーザ(転送先)に振り向ける際の宛先範囲を指定し、また、SIP 302 Redirection Response と Replaces を持つ INVITE を使用して SIP ユーザがどの機能を呼び出せるかを決定するために使用します。

SIP トランクの場合、Unified CME 上で SCCP エンドポイントを使用しているときに、メディア ターミネーション ポイント(MTP)を使用可能にする必要はありません。ただし、Unified CME 上に SIP エンドポイントがある場合は、メディア ターミネーション ポイントを Unified CM 上で使用して、SIP プロトコルでディレイド オファー/アンサー交換の処理(セッション記述プロトコルなしの INVITE 受信)ができるようにする必要があります。

Unified CM ダイヤル プラン設定(ルート パターン、ルート リスト、ルート グループ)を使用して、SIP トランク経由で Unified CME にコールをルーティングします。

Unified CM のデバイス プールとリージョンを使用して、サイト内では G.711 コーデックを設定し、リモートの Unified CME サイトに対しては G.729 コーデックを設定します。

Unified CME の voice services voip allow-connections sip to sip コマンドを設定して、SIP-to-SIP コール接続を許可します。

SIP エンドポイントの場合は、 voice register global mode cme コマンドを設定し、Unified CME の SIP 電話機ごとに voice register pool コマンドで dtmf-relay rtp-nte を設定します。

SCCP エンドポイントの場合は、Unified CME の telephony-service transfer-system full-consult コマンドと transfer-pattern .T コマンドを設定します。

Unified CME の session protocol sipv2 および dtmf-relay [sip-notify | rtp-nte ] により、SIP WAN インターフェイスの voip ダイヤル ピアを設定し、Unified CM を宛先としてコールを転送またはリダイレクトします。

設計上の考慮事項

この項ではまず、一部の主要な領域における SIP 経由での Unified CM と Unified CME の相互運用性に関するいくつかの特徴と設計上の考慮事項について説明します。主要な領域には、コール転送や自動転送のための付加サービス、スピード ダイヤル ボタンや電話帳のコール リストの Busy Lamp Field(BLF)通知のためのプレゼンス サービス、Out-Of-Dialog Refer(OOD-Refer)によるパートナー アプリケーションとの統合、サードパーティ電話制御による Unified CM 電話機と Unified CME 電話機間でのクリックツーダイヤルなどが含まれます。この項では、SIP 経由での Unified CM と Unified CME の相互運用性に関する設計上の一般的な考慮事項についても説明します。

付加サービス

SIP Refer メッセージや SIP 302 Moved Temporarily メッセージを Unified CME または Unified CM でのコール転送や自動転送などの付加サービスに使用して、転送先または自動転送先に対して新しいコールを開始するよう、被転送者または自動転送される電話機(被転送者)に指示できます。SIP Refer メッセージまたは SIP 302 Moved Temporarily メッセージがサポートされている場合、コール転送や自動転送のシナリオにはヘアピンは不要です。

ただし、DID マッピングがない内線が存在する場合や、Unified CM または Unified CME に、SIP 302 Moved Temporarily メッセージの DID にコールをルーティングするダイヤル プランがない場合は、 supplementary-service を無効にする必要があります。 supplementary-service が無効になっていると、Unified CME はコールをヘアピンするか、re-INVITE の SIP メッセージを Unified CM に送信して、新しい着信者 ID へメディア パスを置き換えます。それ以降のコール転送に複数の Unified CME が関係する場合でも、シグナリングとメディアの両方がヘアピンされます。転送されたコールでも、 supplementary-service は無効にできます。この場合、SIP Refer メッセージは Unified CM に送信されませんが、被転送者と転送先がヘアピンされます。


) 付加サービスを無効にするには、voice service voip または dial-peer voice xxxx voipno supplementary-service sip moved-temporarily コマンドか no supplementary-service sip refer コマンドを実行します。


次の例は、付加サービスが無効になっているときのコール フローを示しています。

Unified CM の電話機 B が Unified CME の電話機 A にコールします。電話機 A は電話機 C(Unified CM 電話機、同一または異なる Unified CME 上にある Unified CME 電話機、PSTN 電話機のいずれか)に自動転送([Forward All]、[Forward Busy]、[Forward No Answer])するように設定されています。

Unified CME は Unified CM に SIP 302 Moved Temporarily メッセージを送信せずに、Unified CM 電話機 B と電話機 C の間でコールをヘアピンします。

Unified CM の電話機 B が Unified CME の電話機 A にコールします。電話機 A はコールを電話機 C(Unified CM 電話機、Unified CME 電話機、PSTN 電話機のいずれか)に転送します。

Unified CME は Unified CM に SIP Refer メッセージを送信せずに、Unified CM 電話機 B と電話機 C の間でコールをヘアピンします。

SIP 経由での Unified CM と Unified CME の相互運用性に関する設計上の一般的な考慮事項

SIP 302 Moved Temporarily メッセージまたは SIP Refer メッセージが Unified CM でサポートされていない場合は、 supplementary-service を無効にします。無効にしないと、Unified CM はコールを転送先または自動転送先にルーティングできません。

SIP-to-SIP コール シナリオでは、Refer メッセージがデフォルトで転送者から被転送者に送信され、被転送者は転送先への新しいコールをセットアップします。コールが転送先につながるまで、転送者にはデフォルトでリングバック トーンが聞こえます。Unified CME の supplementary-service が無効になっている場合、Unified CME は、被転送者と転送先の間でコールが接続されるとすぐにインバンドのリングバック トーンを提供します。

プレゼンス サービスは、SIP トランク経由の Unified CM と Unified CME でのみサポートされます。

OOD-Refer 機能を使用すると、サードパーティ製アプリケーションで SIP REFER メソッドを使用して、Unified CM または Unified CME の 2 つのエンドポイントを接続できます。OOD-Refer を使用する場合は、次の点を考慮してください。

Unified CM と Unified CME はどちらも、OOD-Refer 機能が有効になるよう設定する必要があります。

保留、転送、および会議は、OOD-Refer トランザクション中はサポートされませんが、Unified CME によってブロックされることもありません。

コール転送がサポートされるのは、OOD-Refer コールが接続状態になった後のみで、コールの接続前はサポートされません。そのため、接続前はコールの transfer-at-alert はサポートされません。

TLS のシグナリング制御はサポートされますが、SRTP は SIP トランク経由ではサポートされません。

SIP トランク経由の SRTP は、Unified CM 用 Cisco IOS のゲートウェイ機能です。SRTP サポートは、SIP トランク経由での Unified CM と Unified CME のインターワーキングでは使用できません。


) 複数の PSTN 接続(Unified CM に 1 つと Unified CME に 1 つ)が存在する場合、PSTN エンドポイントに対する Unified CM エンドポイントと Unified CME エンドポイント間の完全在席転送は失敗します。複数の PSTN 接続を使用する場合にはブラインド転送の使用を推奨し、この設定は telephony-servicetransfer-system full-blind として行います。



) Cisco Unified CME は、SIP トランクを介した複数の Unified CME 間のビデオ コールをサポートします。この機能は、Unified CME だけを使用する分散型呼処理配置で適用されます。SIP トランクを介した Unified CM と Unified CME との間のビデオ コールはサポートされていません。設定の詳細については、http://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_installation_and_configuration_guides_list.html で入手可能な『Cisco Unified Communications Manager Express System Administrator Guide』を参照してください。


Cisco TelePresence VCS と Unified CM の相互運用性

主要な呼処理エージェントとして Unified CM で配置するときに、Cisco VCS を追加して、H.323 テレプレゼンス エンドポイントとのすべての機能を持つ相互運用性、SIP とのインターワーキング、サードパーティ ビデオ エンドポイントとの統合、別のテレプレゼンス会議ソリューションを提供することができます。ここでは、Cisco TelePresence VCS との Unified CM の統合について説明します。Cisco Expressway との Unified CM の統合については説明しません。

Unified CM および VCS クラスタは、Unified CM ではトランクと呼ばれ、VCS ではゾーンと呼ばれる 1 つ以上の接続によって結合されます。トランクまたはゾーンは、シグナリング プロトコルとコール ルーティング情報を交換する 2 つの呼処理の間の基本的な接続です。トランクおよびゾーンには SIP プロトコルを使用することを推奨します。

図 9-16 は、SIP トランクを使用して VCS クラスタに接続された Unified CM クラスタを示しています。

図 9-16 SIP トランクを使用して Cisco VCS と統合された Cisco Unified CM

 

Unified CM で Unified CM を Cisco TelePresence VCS と統合するには、IP ネットワーク全体に SIP トランクを設定します。VCS に複数の VCS ピアがある場合、VCS クラスタに DNS SRV レコードを使用できます。あるいは、VCS ピアのホスト名または IP アドレスを使用して、SIP トランク設定に VCS ピアのリストを指定することもできます。また、 vcs-interop 正規化スクリプトを Unified CM SIP トランク設定で実行します。この正規化スクリプトの詳細については、次のサイトで入手可能な最新バージョンの『 Cisco Unified Communications Manager System Guide 』を参照してください。

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

Unified CM SIP トランク設計の詳細については、「Cisco Unified CM トランク」の章を参照してください。

Cisco TelePresence VCS で Unified CM ノードのクラスタへの接続を設定するには、次のいずれかの方法を使用します。

ロケーション ピア アドレスとしてリスト化された Unified CM ノードがある単一のネイバー ゾーンを設定します。

DNS SRV レコードおよび Cisco VCS DNS ゾーンを使用します。

複数のゾーンを、Unified CM ノードごとに 1 つ設定します。優先順位を付けた検索ルールのセットを設定して、任意の順序で各ゾーンにコールをルーティングします。

VCS から Unified CM へ発信するコールの負荷が Unified CM ノード全体に分配されるため、上記の最初と 2 番目の設定方法を使用することをお勧めします。3 番目の方法では、冗長性のみが提供され、ロード バランシングは行われません。

詳細については、次の Web サイトから入手可能な『 Cisco TelePresence Video Communication Server Cisco Unified Communications Manager Deployment Guid 』の最新バージョンを参照してください。

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

ダイヤル プランの統合

数値のダイヤル プランに基づいている場合、Unified CM と VCS の間のダイヤル プラン統合は比較的簡単です。このため、新しい配置では可能な限り Unified CM と VCS 全体で数値ダイヤル プランを使用してください。ただし、部分的に URI ベースの配置がすでに存在するか、新しい配置用に選択されている場合は、英数字 URI を使用します。

Unified CM でサポートされているエンドポイントから Cisco TelePresence Video Communication Server(VCS)のエンドポイントに URI コールを直接ルーティングする最も簡単な方法は、ドメイン ベースの SIP ルート パターンを設定することです。たとえば、cisco.com ドメインにアドレス指定されているコールを、VCS 用に設定されている SIP トランクにルーティングするように cisco.com の SIP ルート パターンを設定できます。

複数の Unified CM クラスタと VCS クラスタを同じドメインを使用して配置する場合は、クラスタ間検索サービス(ILS)を設定して URI ダイヤリングの相互運用性を提供します。各 VCS に対して、呼制御システムに登録されたディレクトリ URI が記載された CSV ファイルを手動で作成します。次に、ILS ネットワークにおけるハブクラスタとしてセットアップされた Unified CM クラスタ(Session Management Edition クラスタでも可能)に、VCS ごとにインポート済みディレクトリ URI カタログを作成し、カタログごとに一意のルート ストリングを割り当てます。csv ファイルを該当するインポート済みディレクトリ URI カタログへインポートすると、ILS はインポート済みディレクトリ URI カタログとルート ストリングを ILS ネットワーク内の他のクラスタへ複製します

Unified CM が、VCS 用に宛先指定されたアウトバウンド トランクにディレクトリ URI をルーティングできるように、インポート済みの各ディレクトリ URI カタログに割り当てられたルート ストリングと一致する SIP ルート パターンを設定します。

詳細については、次の Web サイトで入手可能な最新バージョンの『 Cisco Unified Communications Manager System Guide 』を参照してください。

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

設計上の考慮事項

Unified CM と VCS の両方がコール アドミッション制御を実行できます。ただし、帯域幅情報は Unified CM と VCS 間で交換されません。

VCS と Unified CM クラスタの間の統合は、Cisco Unified Communications Manager Session Management Edition(SME)を使用して実行することもできます。詳細については、「コラボレーションの配置モデル」の章を参照してください。

通常、コール セットアップ中に MTP は必要ないため、SIP ディレイド オファーを推奨します。[SIP Early Offer for Voice and Video (Insert MTP if needed)] を使用する SIP アーリー オファーも使用できますが、MTP が挿入される場合、初期コール セットアップ時にサポートされるのは音声のみである点に注意してください。詳細については、「Cisco Unified CM トランク」の章を参照してください。

Unified CM と VCS のクラスタ間でダイヤル プランを統合する最適な方法は、展開に関する慎重な計画と、各呼処理アプリケーションで利用できる以下のような機構を利用して、ダイヤル プランを正規化(フラットなドメイン、重複しない DN レンジ)することです。

VCS のトランス フォームおよび検索ルール

Unified CM のルート パターン、変換、およびトランスフォーメーション パターン