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

目次

呼処理

この章の新規情報

呼処理アーキテクチャ

呼処理ハードウェア

UnifiedCM クラスタのサービス

クラスタ サーバ ノード

Enterprise License Manager

クラスタ内通信

クラスタ内セキュリティ

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

Cisco TelePresence VCS クラスタリング

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

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

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

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

呼処理の冗長性

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

TFTP の冗長性

CTIManager の冗長性

仮想化された呼処理の冗長性

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

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

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

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

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

仮想プラットフォームでの Unified CM のキャパシティ プランニング

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

メガクラスタ

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

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

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

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

CTI のアーキテクチャ

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

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

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

CTI Manager

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

実装

UnifiedCM と UnifiedCM Express の相互運用性

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

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

保留音(Music on Hold)

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

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

ベスト プラクティス

設計上の考慮事項

分散型呼処理を使用したマルチサイト配置における H.323 経由の 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 のプロビジョニングとキャパシティ プランニングについて説明します。

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

ここでは、分散型呼処理配置における Cisco Unified CM と Cisco Unified Communications Manager Express(Unified CME)間での H.323 と SIP での統合について説明します。

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

ここでは、Cisco Unified CM と Cisco TelePresence VCS 間の統合について説明します。

この章の新規情報

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

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

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

Cisco TelePresence Video Communication Server(VCS)

この章の各項で説明

2013 年 4 月 2 日

Cisco IOS ゲートキーパーに関する情報の削除

この情報については、次の Web サイトから入手可能な『 Cisco Unified Communications System 9.0 SRND 』の「 Call Processing 」の章を参照してください。

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

2013 年 4 月 2 日

Cisco Business Edition のマイナー アップデート

この章の各項で説明

2012 年 10 月 31 日

CTI リモート デバイス

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

2012 年 6 月 28 日

Enterprise License Manager

「Enterprise License Manager」

2012 年 6 月 28 日

呼処理アーキテクチャ

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

Cisco Unified Communications Manager Express(Unified CME)

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

Cisco Business Edition

Cisco Business Edition は、小規模な単一サイト配置または小規模な分散マルチサイト配置に、呼処理サービスを提供します。Cisco Business Edition には、Business Edition 3000 と Business Edition 6000 という 2 つのバージョンがあります。これらの 2 つのバージョンの違いを次に示します。

Cisco Business Edition が配置されるハードウェア、および共存して実行できるアプリケーションとサービスの数。Business Edition 3000 は、共存する Cisco Unified CM 呼処理サービスおよび Cisco Unity Connection メッセージング サービスを提供します。Business Edition 6000 は、単一の UCS サーバ上で 5 つの共存アプリケーションをサポートします。サポートされるアプリケーションは、Cisco Unified CM、Cisco Unified Provisioning Manager、Cisco Unity Connection、Cisco IM and Presence、Cisco Unified Contact Center Express(Unified CCX)、Cisco Unified Attendant Console サービスと Cisco TelePresence Video Communication Server(VCS)です。

システムのキャパシティ。Cisco Business Edition 3000 は、最大 300 人のユーザと 400 個のエンドポイントをサポートしますが、Cisco Business Edition 6000 は最大 1,000 人のユーザと 1,200 個のエンドポイントをサポートします。

インストールおよびアップグレードの手順。Business Edition 3000 は、1 つのソフトウェア イメージを使用して、サポートされる Cisco MCS プラットフォーム上で Unified CM および Unity Connection のインストールやアップグレードをネイティブに実行します。Business Edition 6000 は個別のソフトウェア イメージを使用して、VMware 上に共存する各アプリケーションをインストールおよび/またはアップグレードします。

Cisco Unified Communications Manager(Unified CM)

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

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 Video Communication Server Control(VCS Control)として Cisco VCS を配置し、外部通信に使用するために、Cisco TelePresence Video Communication Server Expressway(VCS Expressway)として Cisco VCS を配置できます。VCS Expressway により企業間のコミュニケーションが可能になり、リモートおよび自宅ベースのワーカーに利便性を提供できます。また、サービス プロバイダーは、顧客にビデオ コミュニケーション機能を提供できます。Cisco VCS Expressway には、Cisco VCS Control の機能に加えて、非常にセキュリティ レベルが高いファイアウォール トラバーサル機能を有します。

主要な呼処理エージェントとして Unified CM を配置するときに、Cisco VCS も配置して、H.323 テレプレゼンス エンドポイントとのすべての機能を持つ相互運用性、SIP とのインターワーキング、サードパーティ ビデオ エンドポイントとの統合、テレプレゼンス会議ソリューション、および VCS Expressway との組み合わせによる NAT/ファイアウォール トラバーサルといった機能を提供することができます。

Cisco TelePresence Video Communication Server(VCS)Starter Pack Express は豊富な機能を持つオンプレミス ソリューションであり、初めてテレプレゼンス システムを配置する中小企業(SMB)を対象にしています。Cisco VCS アーキテクチャとして作られており、ファイアウォールのトラバーサルと企業間の通信用にスケールダウンされた Cisco TelePresence Video Communication Server Expressway ソリューションが組み込まれています。Cisco TelePresence Video Communication Server(VCS)Starter Pack Express の詳細については、次の Web サイトから入手できるマニュアルを参照してください。

http://www.cisco.com/en/US/prod/collateral/ps7060/ps11305/ps11315/ps11337/data_sheet_c78-697075.html

ここでは、さまざまな呼処理ハードウェア オプションについて説明した後、Cisco Unified CM and VCS クラスタリングの概要を示します。

呼処理ハードウェア

さまざまなタイプのプラットフォームで、次の 4 つのエンタープライズ呼処理タイプがサポートされています。

Cisco Unified CME は Cisco Integrated Services Routers(ISR)上で実行します。

Cisco Business Edition 3000 は、Cisco Media Convergence Server(MCS)上でアプライアンスとして直接実行されます。Cisco Business Edition 6000 は、Cisco Unified Computing System(UCS)の C シリーズ サーバの VMware Hypervisor 上の仮想化アプリケーションの組み合わせとして動作します。

Cisco Unified CM は、MCS(または同等の)サーバ上でアプライアンスとして直接実行されるか、または VMware Hypervisor で仮想アプリケーションとして実行されます。Unified CM が仮想マシンとして配置されている場合、Tested Reference Configurations と仕様ベースのハードウェア サポートの 2 つのハードウェア オプションを使用できます。Tested Reference Configurations(TRC)は、Cisco UCS ハードウェアをベースにハードウェアの構成が指定されているものです。テストされ、具体的に保証された性能、キャパシティ、Unified Communications 仮想マシンを満載して稼働するアプリケーションの組み合わせシナリオが文書化されています。TRC は、特定の配置シナリオ用に事前に作成されたシスコのパッケージ ソリューションをご希望のお客様、またはハードウェア仮想化の経験のないお客様(または両方)を対象としています。TRC の詳細については、次の Web サイトにあるマニュアルを参照してください。

http://docwiki.cisco.com/wiki/Tested_Reference_Configurations_(TRC)

また、仕様ベースのハードウェア サポートによって、より柔軟なハードウェア構成を使用することもできます。たとえば、VMware ハードウェア互換性リスト( http://www.vmware.com/resources/compatibility/search.php )に一覧されている Cisco UCS、Hewlett-Packard、および IBM プラットフォームのサポートや、iSCSI、FCoE、および NAS(NFS)ストレージ システムのサポートなどが追加されます。仕様ベースのハードウェア サポートは、仮想化およびサーバとストレージのサイジングに関する深い専門知識を持っており、独自のハードウェア標準の使用を希望するお客様を対象としています。仕様ベースのハードウェア サポートの詳細については、次の Web サイトにあるマニュアルを参照してください。

http://docwiki.cisco.com/wiki/Specification-Based_Hardware_Support

Cisco TelePresence Video Communication Server(VCS)も、アプライアンスとして、あるいは VMware 上の仮想化アプリケーションとして実行されます。Unified CM と同様に、仮想化される場合、Cisco VCS は Cisco Unified Computing System(UCS)サーバまたは他のサーバ上で仕様ベースのハードウェア サポートを使用して実行できます。仮想化アプリケーションとしての Cisco VCS の実行の詳細については、次のマニュアルを参照してください。

Cisco Unified Communications の仮想化を設計および配置する際の考慮事項は、次の Web サイトから入手できます。

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

次の 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

表 9-2 に、4 つのエンタープライズ呼処理タイプ、これらの呼処理アプリケーションが置かれるサーバまたはプラットフォームのタイプ、およびそれらのプラットフォームの全般的な特性の概要を示します。表には、Cisco UCS プラットフォーム用の Tested Reference Configurations が含まれていますが、仕様ベースのハードウェア サポートでサポートされるプラットフォームは含まれていません。

 

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

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

Cisco Unified CME

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

Cisco Business Edition

Business Edition 3000(仮想化されない Unified CM):

MCS アプライアンス(MCS 7890-C1)

Business Edition 6000(仮想化された Unified CM および VCS):

特定の UCS C シリーズのテスト済みファレンス構成(TRC)

Cisco Unified CM

Unified CM が仮想化されていない場合の MCS サーバ

Unified CM が仮想化された場合の2ハードウェア オプション:

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

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

Cisco VCS

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

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

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

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

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

2.UCS B シリーズおよび C シリーズ サーバは、Cisco Unified Communications アプリケーションにベア メタル サポートを提供しません。UCS B シリーズおよび C シリーズ サーバは、VMware ESXi Hypervisor を実行する必要があります。

サポートされている MCS サーバまたは同等品の全リストについては、次の Web サイトで入手可能な資料を参照してください。

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

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

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

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

Unified CM クラスタのサービス

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

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


クラスタ内のすべてのサーバに対して同じサーバ モデルを使用することを推奨しますが、個別のハードウェア バージョンがすべてサポートされており、すべてのサーバで同じバージョンの Unified CM が実行されている場合、クラスタ内にサーバ モデルを混在させることもサポートされます。ただし、クラスタ内のさまざまなサーバ モデル間でのキャパシティの相違を考慮する必要があります。クラスタの全体的なキャパシティは、最終的にはクラスタ内の最小のサーバのキャパシティによって決まる場合があるためです。クラスタ内のすべてのサーバが同じモデル タイプの場合、異なるベンダーのサーバをクラスタ内に混在させることもサポートされ、キャパシティに悪影響はありません。同様に、仮想配置の場合、クラスタ内のすべての Unified CM ノードに同じ OVA を使用することをお勧めします。呼処理キャパシティの詳細については、「呼処理のキャパシティ プランニング」の項を参照してください。


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

クラスタ サーバ ノード

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

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

 

パブリッシャ

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

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

パブリッシャ用のハードウェア プラットフォームは、クラスタで必要な規模とパフォーマンスを基準として選択する必要があります。パブリッシャは、呼処理サブスクライバと同等のサーバ パフォーマンスを持つものにすることを推奨します。可能な場合には、パブリッシャをハイ アベイラビリティサーバにして、ハードウェアの障害による影響を最小限に抑えるようにします。

サブスクライバ

ソフトウェアを初期インストールしたときに使用可能になるのは、データベース サービスとネットワーク サービスだけです。すべてのサブスクライバ ノードは、パブリッシャにサブスクライブして、データベース情報のコピーを取得します。ただし、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 サブスクライバのハードウェア プラットフォームには、呼処理サブスクライバと同じものを使用することを推奨します。

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

メディア リソース サブスクライバまたはサーバ ノードは、会議や保留音などのメディア サービスをエンドポイントとゲートウェイに提供します。これらのタイプのメディア リソース サービスは、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 アプリケーション」の章を参照してください。

Enterprise License Manager

Cisco Unified Communications システム 9. x は、デバイスではなくユーザに基づいてソフトウェア ライセンスを管理する Enterprise License Manager(ELM)を採用しています。お客様は、ユーザ ライセンスを購入して ELM アプリケーションに追加します。ELM アプリケーションはすべてのアプリケーションから要件を収集して集約し、すべての使用可能なユーザ権限付与と比較します。

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

Cisco Unified Communications Manager(Unified CM)

Cisco Unity Connection

ライセンスは、シスコから購入し、電子メールによって提供され、次に ELM にロードされます。登録されているアプリケーションにライセンスが必要なときはいつでも、ライセンスは ELM ライセンス プールから差し引かれます。ライセンスが不要になった場合は同様に、ELM ライセンス プールに将来使用するために戻ります。

ELM ライセンス プール内に十分なライセンスがない場合でも、60 日間の猶予期限内は、管理者がユーザを追加できます。もし十分なライセンスがないまま 60 日間の猶予期限が経過した場合、Unified Communications アプリケーションはそれ以降一切の変更を許可しなくなります。ただし、アプリケーションがサービスを失うことなく、機能し続けます。

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

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

配置例

ELM は Unified Communications アプリケーションと一緒に自動的にインストールされるものを実行させることも、あるいは専用のサーバまたは仮想マシンに ELM だけをインストールすることも可能です。運用中、ELM は非常に少量のリソースだけを消費します。その結果、サーバまたは仮想マシンのサイジングに影響がないと見なされます。さらに、ELM は非冗長アプリケーションとして展開されます。ELM のアプリケーションが使用不能になる場合(たとえば、アプリケーションが存在するサーバに致命的なハードウェア障害が発生している場合)、お客様には、アプリケーションを復元するための猶予期間が 60 日間、付与されます。この猶予期間を経過しても、アプリケーションがサービスを停止せずに機能し続けることに留意してください。

配置の推奨事項

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

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

異なる仮想マシンまたはサーバで ELM を実行します。この方法を推奨します。

ライセンス プーリングを必要とせず、集中型ライセンス管理を望まない場合、各アプリケーション サーバに異なる ELM を実行します。

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

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

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

企業またはグローバル

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

地域、または事業部

世界に複数の Unified Communicatios を配置する企業では、複数の ELM インスタンスを各地域ごとに設定することが可能です(たとえば、北米に 1 つ目、EMEA に 2 つ目、APAC に 3 つ目)。このモデルでは、企業は会計基準の異なる地域ごとに、ライセンスのコストをより簡単に計算できます。

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

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

クラスタ内通信

クラスタ内通信(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 クラスタに次のガイドラインが適用されます。


) 1 つのクラスタに複数のサーバ プラットフォームまたは仮想マシンをさまざまな OVA テンプレートに基づいて組み合わせることができますが、クラスタ内のすべてのサーバでは、同じ Unified CM ソフトウェア リリースを実行する必要があります。詳細については、「Unified CM クラスタのサービス」の項のを参照してください。


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

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

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

Cisco MCS 7816 または同等のサーバで Unified CM を配置するときは、配置内には最大 2 台のサーバという制限があります。1 台をパブリッシャ、TFTP、およびバックアップ呼処理サブスクライバ ノードにし、もう 1 台をプライマリ呼処理サブスクライバにします。Cisco MCS 7816 または同等のサーバでは、この構成で最大 500 台の電話機がサポートされます。

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

Business Edition 3000 は MCS 7890-C1 専用アプライアンスで実行されます。Business Edition 3000 は Unified CM の単一のインスタンス(パブリッシャとシングル サブスクライバの複合インスタンス)を提供します。セカンダリ サブスクライバ インスタンスは設定できません。

Business Edition 6000 は、UCS C200 または C220 ラックマウント サーバ上で動作し、Unified CM の単一のインスタンス(パブリッシャとシングル サブスクライバの複合インスタンス)を提供します。増設の UCS C200 または C220 サーバは、アクティブ/スタンバイ方式またはロード バランシング方式で、Cisco Business Edition 呼処理やその他の共存するアプリケーションにサブスクライバの冗長性を提供するために配置できます。負荷を 2 つの UCS サーバ間で分散できるよう、ロード バランシングを使用する冗長サーバを配置することを推奨します。また、MCS サーバを使用して、アクティブ/スタンバイ方式またはロード バランシング方式で Unified CM サブスクライバの冗長性を提供できます。

Unified CM を仮想アプリケーションとして配置するときは、MCS サーバのクラスタの場合のように、各 Unified CM ノード インスタンスは、パブリッシャ ノード、呼処理サブスクライバ ノード、TFTP サブスクライバ ノード、またはメディア リソース サブスクライバ ノードのいずれかになります。Unified CM クラスタと同様に、クラスタごとに 1 つのパブリッシャ ノードだけがサポートされます。

Cisco UCS B シリーズ ブレード サーバおよび C シリーズ ラックマウント サーバは、DB9 シリアル ポート、Video Graphics Array(VGA)モニタ ポート、および 2 つの Universal Serial Bus(USB)ポートを提供するローカルのキーボード、ビデオ、およびマウス(KVM)ケーブル接続をサポートしますが、Unified CM VMware 仮想アプリケーションはこれらの USB ポートおよびシリアル ポートにアクセスできません。そのため、オーディオ カード(MOH-USB-AUDIO=)、シリアル/USB コネクタ(USB-SERIAL-CA=)、またはフラッシュ ドライブなどの USB デバイスは、これらのサーバに接続できません。代わりに、次のオプションを利用できます。

MoH ライブ オーディオ ソース フィードの場合は、ライブ オーディオ ソース接続に Cisco IOS ベースのマルチキャスト MoH を使用するか、または Unified CM クラスタの一部として 1 台の MCS サーバに Unified CM サブスクライバ ノードを配置して、USB MoH オーディオ カード(MOH-USB-AUDIO=)を接続できるようにすることを検討します。

SMDI シリアル接続の場合は、Unified CM クラスタの一部として 1 台の MCS サーバに Unified CM サブスクライバ ノードを配置して、USB シリアル接続に使用します。

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

Cisco TelePresence VCS クラスタリング

Cisco VCS Control と VCS Expressway は、スタンドアロン インスタンスとして配置することも、最大 6 つの 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 や 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 ネットワークへの接続性も、最大限のパフォーマンスとハイ アベイラビリティにとって重要な考慮事項です。呼処理プラットフォームを可能な最高速度でネットワークに接続し、最大のスループットを確保します。通常は、プラットフォームに応じて 1000 Mbps または 100 Mbps 全二重です。可能な場合は常に、全二重を使用してプラットフォームをネットワークに接続してください。全二重接続は、ネットワーク スイッチ ポートおよびプラットフォーム インターフェイス ポートの設定で 100 Mbps が可能です。1000 Mbps の場合は、プラットフォーム インターフェイス ポートおよびネットワーク スイッチ ポートの両方で、速度とデュプレックス モードの設定に Auto/Auto を使用することを推奨します。


) プラットフォーム インターフェイス ポートまたはネットワーク スイッチ ポートのいずれか一方が Auto モードのままであり、もう一方のポートが手動で設定される場合、ミスマッチが生じます。ベスト プラクティスは、プラットフォーム ポートとネットワーク スイッチ ポートの両方を手動で設定することです。ただし、ギガビット イーサネット ポートの場合は、Auto/Auto に設定する必要があります。


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

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

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

可用性の高いネットワーク インフラストラクチャを配置し、呼処理プラットフォームをネットワーク コンポーネントおよびロケーション間で物理的に分散させる以外に、各呼処理エンティティからネットワークへの可用性の高い物理接続を設定することも推奨します。可能な場合は常に、1 つのアップストリーム ハードウェア ポートまたはスイッチの障害によってプラットフォームのネットワーク接続が失われないように、2 つのネットワーク接続を使用してプラットフォームを 2 つの物理的に別々のネットワーク スイッチ上の 2 つの異なるポートに接続します。Unified CME ルータ プラットフォームには複数の物理ネットワーク インターフェイスを設定でき、ネットワークに二重接続できます。同様に、Unified CM の MCS サーバ プラットフォームも、ネットワーク インターフェイス カード(NIC)チーミングを使用して、ネットワークに二重接続できます。

Cisco VCS Control は 1 つのネットワーク インターフェイスのみを使用します。高セキュリティの配置用に Cisco VCS Expressway で 2 番目のネットワーク インターフェイスを使用できます。たとえば、別個のネットワーク セグメントにある 2 つの別個のファイアウォールの間の DMZ に VCS Expressway を配置する場合などです。

ネットワークの耐障害性に対応する MCS Server を使用した NIC チーミング

NIC チーミング機能は、Cisco MCS(あるいは HP または IBM の同等のサーバ)を 2 枚の NIC、つまり 2 本の物理ケーブルで IP ネットワークに接続できるようにするものです。NIC チーミングは、障害の発生したポートから正常なポートに作業負荷を転送することによって、ネットワークのダウンタイムを防止します。NIC チーミングは、ロード バランシングまたはインターフェイス速度向上用には使用できません。NIC チーミングは、デュアル NIC の Cisco MCS プラットフォーム(あるいは HP または IBM の同等のプラットフォーム)でサポートされます。

UCS ネットワークの耐障害性

Cisco C シリーズ ラックマウント サーバには、複数の NIC ポートがあります。シスコは、VMware の管理や、特に仮想マシンのトラフィック用に、VMware NIC チーミングを使用して複数のポートを割り当て、それらのポートを別個のアップストリーム物理スイッチに接続することをお勧めします。詳細については、次の Web サイトから入手できる VMware のマニュアルを参照してください。

http://www.vmware.com

Cisco UCS B シリーズ ブレード サーバは、UCS ネットワーク接続インフラストラクチャおよび基盤となるネットワーク接続されたストレージ エリア ネットワーク(SAN)を利用します。このバックエンドの UCS ネットワーク インフラストラクチャ(冗長な並行スイッチング ファブリック エクステンダとファブリック インターコネクトと、ファイバ チャネルまたはギガビット イーサネット アップリンクを含む)は、可用性の高いネットワーク接続およびストレージをこれらのサーバに提供します。UCS ネットワークおよびストレージ インフラストラクチャの可用性の高い仮想データセンター配置の詳細については、次の Web サイトから入手できる『 Designing Secure Multi-Tenancy into Virtualized Data Centers 』を参照してください。

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/Virtualization/securecldg.html

Cisco UCS C シリーズを持つ VMware、または B シリーズを持つ VMware および UCS のアーキテクチャのどちらで管理されている場合でも、C シリーズと B シリーズは両方ともネットワーク接続に高い復元性を提供します。このため、仮想マシンの仮想 NIC(vNIC)レベルで NIC チーミング設定を行う必要ではなく、通常は、1 種類の vNIC のみが OVAs に定義されます。

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 台の登録です。

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


) Cisco TelePresence System EX Series ビデオ エンドポイントなど、一部のエンドポイントは Unified CM 登録の冗長性をサポートしない場合があります。詳細については、「コラボレーションのエンドポイント」の章を参照してください。


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 ソフトウェアを実行しているサブスクライバ サーバにデバイスが登録される期間(登録フェールオーバー期間を除く)がありません。

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 ルータ上の Unified CME をリモート サイトで使用して、中央の Unified CM クラスタへの接続が失われたときに SRST 拡張機能を提供することもできます。Unified CME は、ルータの通常の SRST で使用できる機能よりも多くのバックアップ呼処理機能を IP Phone に提供します。ただし、Unified CME as SRST のエンドポイント キャパシティは、通常は基本的な SRST よりも低下します。

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

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

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

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

 

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


) バックアップ サブスクライバでオーバーロードが生じる可能性があるため、Cisco MCS 7845-I3 サーバ、または 10K-User OVA を使用して配置された仮想マシンを使用する場合、2:1 冗長はサポートされません。


図 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 では示していませんが、MCS 7825 以上のサーバを備えたシングル サーバ クラスタを配置することもできます。MCS 7825 または同等のサーバでは、シングル サーバ クラスタのエンドポイント設定および登録の制限は 500 です。これより可用性の高いサーバを使用する場合も、シングル サーバ クラスタのエンドポイント設定および登録が 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 の配置の場合も、これまでの呼処理、TFTP、および CTI Manager の冗長性方式がすべて適用されます。仮想化を使用する場合、サーバ間にわたる Unified CM サーバ ノードのインストールと常駐という仮想的特徴があるため、冗長性に関する追加の考慮事項があります。

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

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

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

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

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

 

サーバ ノード インスタンスを複数のブレードに分散させる以外に、サブスクライバ ノード インスタンスを複数の Cisco UCS 5100 ブレード シャーシに分散させて、冗長性と拡張性を追加できます。

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

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

Cisco Business Edition のハイ アベイラビリティに関する主な考慮事項は、ネットワーク接続、電源、および呼処理と登録の冗長性です。

Business Edition 3000 用の MCS 7980-C1 専用アプライアンスの IP インターフェイスは 1 つだけのため、冗長なネットワーク接続または NIC チーミングのサポートは提供していません。

Business Edition 3000 は、それ自体の単一のスタンドアロン プラットフォーム(セカンダリ サブスクライバ インスタンスを設定できない、パブリッシャとシングル サブスクライバの複合インスタンス)に配置されます。これらはノード クラスタリングをサポートしていないため、Unified CM で使用可能な呼処理の冗長性方式を利用できません。したがって、これらの配置タイプのエンドポイントで、呼処理および登録の冗長性を提供する唯一の方法は、SRST または SRST として機能する Unified CME を使用することです。

一方、Business Edition 6000 は、追加の Cisco Unified CM ノードとのクラスタ化によって、呼処理サービスおよび登録サービスに冗長性を提供します。2 つ目の Business Edition 6000 サーバ(UCS C200 または C220 ラックマウント サーバまたは MCS サーバ)は、呼処理とその他のアプリケーションおよびサービスにハイ アベイラビリティを提供するために配置できます。


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


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

Cisco VCS は、最大 6 つの VCS ピアを VCS クラスタに配置できるようにすることで、ハイ アベイラビリティを提供します。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 に関する同じガイドラインも適用できます(「仮想化された呼処理の冗長性」を参照)。

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

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

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 システム内の追加リソースを消費します。

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

特定プラットフォーム用にサポートされている最大量まで、サーバに追加の保証メモリを取り付ける。MCS 7825 および MCS 7835、または同等のサーバ クラスの大規模構成では、これらのサーバの RAM を倍に増やすことを推奨します。このメモリ アップグレードが必要かどうかは、Cisco Real Time Monitoring Tool(RTMT)を使用して検証することでわかります。サーバが物理メモリを最大量近くまで使用すると、オペレーティング システムは、ディスクへのスワップを開始します。このスワッピングが発生した場合は、追加の物理メモリを取り付ける必要があることを示しています。

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

仮想プラットフォームでの Unified CM のキャパシティ プランニング

仮想配置では、Unified CM などの Unified Communications のアプリケーションの大部分は、仮想マシンの仮想ハードウェアの設定を指定する定義済みテンプレートを使用してインストールする必要があります。これらのテンプレートは、仮想マシン テンプレートをパッケージおよび配布するオープン スタンダード ベースの方式である Open Virtualization Archive(OVA)を使用して配布されます。

これらの OVA テンプレートは、仮想 CPU の数、仮想メモリ量、ハード ドライブの数とサイズなどを定義して、アプリケーションのキャパシティを決定します。Unified CM の場合、複数の OVA テンプレートがあり、ほとんどすべてのサーバ クラスに対して、それぞれ 1 つずつ用意されています(ただし MCS 7816 に対応するテンプレートはありません)。対応する OVA テンプレートを使用した場合、通常、仮想マシンとして実行している Unified CM ノードのキャパシティは、Cisco MCS サーバで直接実行される Unified CM ノードのキャパシティと同じになります。たとえば、7,500 のユーザまたはデバイス(または両方)をサポートする Unified CM 用の OVA テンプレートのキャパシティは、MCS 7845-H2/I2 サーバのキャパシティと同じです。

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

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

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

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

VMware で実行されるサーバ ノード インスタンスで構成されているクラスタは、選択された OVA テンプレートに応じて、さまざまなキャパシティをサポートできます。ほとんどの Cisco MCS サーバ クラスには、MCS サーバ クラスと同じキャパシティ(電話機、ゲートウェイ、ロケーション、リージョン、CTI 接続などの数)を持つ Unified CM インスタンスを提供する、対応した OVA テンプレートが用意されています。同一のブレードまたはサーバで複数の仮想マシン インスタンスを実行できるため、ブレードまたはサーバの合計キャパシティは MCS サーバよりも大きくなる場合があります。

Unified CM の推奨される最大トレース設定は、System Diagnostic Interface(SDI)および Signaling Distribution Layer(SDL)の両方のトレースに対して 2 MB のファイルを 2,000 本、合計でファイル 4,000 本です。プロセスごとにファイルの最大数が設定され、各プロセスに許容されるファイル数は SDL に対して 2,000 本、SDI に対して 2,000 本となります。その他すべてのコンポーネントのトレース設定は、126 MB の限度内(たとえば、それぞれ 2 MB のファイルが 63 本)で設定する必要があります。これらの値が上限として推奨されます。コール レートの高い環境での特定のトラブルシューティングでファイルの最大数を増やす必要がある場合を除き、ほとんどの環境ではデフォルト設定で十分なトレースを収集できます。

サイジングの制限や、システム サイジング、キャパシティ プランニング、および配置の考慮事項に関する詳しい説明など、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 台のサーバが含まれることがあります。

サーバ タイプは、Cisco MCS 7845-I3/H3 クラス、または 10K Open Virtualization Archive(OVA)テンプレートを使用した Cisco Unified Computing System(UCS)C シリーズまたは B シリーズのいずれかである必要があります。

冗長性モデルは 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 によってサポートされるユーザおよびエンドポイントの最大数は、それぞれ 1,000 と 1,200 です。Cisco Business Edition でサポートされる BHCA の最大数は 5,000 です。

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

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

Cisco Business Edition 3000

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

Cisco Business Edition 6000

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

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 3000 は、パブリッシャとシングル サブスクライバの複合インスタンスとして、MCS 7890-C1 で実行されます。セカンダリ サブスクライバ インスタンスは設定できません。

Business Edition 6000 は、UCS C200 または C220 ラックマウント サーバ上で、パブリッシャとシングル サブスクライバの複合インスタンスとして動作します。セカンダリ サブスクライバによって呼処理の冗長性を提供するために、2 台目の UCS C200 または C220 サーバを配置できます。また、MCS サーバを冗長性を提供するために使用できます。


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


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

Business Edition 3000 は NIC チーミングをサポートしていません。

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

Cisco Business Edition プラットフォームの一部(MCS 7890-C1 および UCS C200)は、二重化電源を備えていない、あるいはサポートしていないため、無停電電源(UPS)を使用してプラットフォームの可用性を最大限まで高めます。

ハイ アベイラビリティのために 2 台のサーバで Business Edition 6000 を配置する場合(2 台の UCS C200/C220 ラックマウント サーバ、または 1 台の UCS C200/C220 ラックマウント サーバと 1 台の MCS サーバ)、システム負荷を分散するために、2 台めのサーバをスタンバイ冗長として使用するのではなく、2 台のサーバ間でデバイス登録のロードバランシングを行うことが推奨されます。

Business Edition 3000 は、次に示すエンドポイントおよびゲートウェイの特定のタイプのみのサポートを提供します。

Business Edition 3000 がサポートするエンドポイントのセットには、制限があります。サポートされているエンドポイントのリストについては、次の Web サイトから入手可能な『 Administration Guide for Cisco Business Edition 3000 』を参照してください。

http://www.cisco.com/en/US/products/ps11370/prod_maintenance_guides_list.html

Business Edition 3000 PSTN 接続は、Cisco 2901 Integrated Services Router(ISR)を通じてのみ、また MGCP バックホール T1/E1 PRI トランクを使用する場合のみサポートされています。

Business Edition 3000 はクラスタ間トランキングをサポートしていないため、分散型呼処理配置もサポートしていません。

Cisco Unified CM

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

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

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

クラスタ内のすべてのサーバに対して同じサーバ モデルを使用することを推奨します。ただし、個別のハードウェア バージョンがすべてサポートされており、すべてのサーバで同じバージョンの Unified CM が実行されている場合、クラスタ内にサーバ モデルおよび異なるサーバ ベンダーのモデルを混在させることもサポートされます。

バックアップ サブスクライバでオーバーロードが生じる可能性があるため、Cisco MCS 7845-I3 サーバまたは 10K-User OVA を使用する場合、2:1 冗長はサポートされません。

NIC チーミングを使用して MCS サーバをネットワークに二重接続し、ハイ アベイラビリティを最大限まで高めます。

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

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

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

Unified CM を仮想アプリケーションとして配置する場合は、バックアップまたは冗長サブスクライバ ノードがプライマリ サブスクライバ ノードとは異なる物理ブレード上に存在するように、サーバ ノード インスタンスが UCS シャーシ内のラック マウント サーバまたはブレード サーバ間で分散されるようにします。

UCS B シリーズ ブレード サーバとハイエンド C シリーズ ラックマウント サーバの両方(たとえば、C210、C240、および C260)は、複数の Open Virtualization Archive(OVA)テンプレートで設定できます。最も大きい OVA テンプレートは、10,000 のデバイスをサポートし、MCS 7845-I3 サーバと同じキャパシティ(エンドポイント、ゲートウェイ、ロケーション、リージョンなどの数)を提供します。適切な OVA のサイジングと、Cisco Unified Communications Sizing Tool の使い方の詳細については、「コラボレーション ソリューションの設計および配置サイジングに関する考慮事項」の章を参照してください。

UCS B シリーズ ブレード サーバおよび C シリーズ ラックマウント サーバは、KVM ケーブルを介して USB およびシリアル ポートをサポートしますが、Unified CM VMware 仮想アプリケーションはこれらのポートにアクセスできません。そのため、Unified CM を UCS に配置する場合、MoH 用の固定ライブ オーディオ ソースを接続すること、レガシー ボイスメール システムへのシリアル SMDI 接続を行うこと、またはログ ファイルの書き込みのために USB フラッシュ ドライブを接続することはできません。代わりに、次のオプションを利用できます。

MoH ライブ オーディオ ソース フィードの場合は、ライブ オーディオ ソース接続に Cisco IOS ベースのマルチキャスト MoH を使用するか、または Unified CM クラスタの一部として 1 台の MCS サーバに Unified CM サブスクライバ ノードを配置して、USB MoH オーディオ カード(MOH-USB-AUDIO=)を接続できるようにすることを検討します。

SMDI シリアル接続の場合は、Unified CM クラスタの一部として 1 台の MCS サーバに Unified CM サブスクライバ ノードを配置して、USB シリアル接続に使用します。

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

シスコは、一部のサブスクライバ サーバ ノード インスタンスを UCS B シリーズ ブレード サーバで実行し、別の一部を C シリーズ ラックマウント サーバで実行して、その他の残りのサブスクライバ サーバ ノード インスタンスを MCS サーバ プラットフォームで実行する Unified CM クラスタをサポートしています。

Cisco TelePresence VCS

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

アプライアンス上で実行されているか、仮想アプリケーションとして実行されている VCS ノードは同様に実行され、キャパシティ制限は同じです。

コンピュータ テレフォニー インテグレーション(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 と Unified CM Express の相互運用性

この項では、H.323 または 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 の相互運用性」

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

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 トランクと H.323 トランクを使用するための最も一般的な設計シナリオとベスト プラクティスを紹介します。

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

一般に、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 ネットワークで自動検出を可能にする方法と、H450.2、H450.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』を参照してください。


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

分散型呼処理を使用したマルチサイト WAN 配置で、H.323 接続経由の Unified CM と Unified CME の相互運用性を実現する配置オプションは 2 つあります。1 番めのオプションは、Cisco Unified Border Element を Unified CM のフロントエンド デバイスとして配置する方法で、リモートの Unified CME システムとはピアツーピア H.323 で接続します。Cisco Unified Border Element が Unified CM と Unified CME との間のダイヤル プラン解決を実行し、同時に両者間のコール シグナリング メッセージを終端し、再発信します。Cisco Unified Border Element は、Cisco Unified Border Element は、Empty Capability Set(ECS)を使用して負荷サービスを呼び出す Unified CM など、H.450 付加サービスをサポートしないシステムのためにプロキシ デバイスとして機能します。また、Cisco Unified Border Element は、Unified CM クラスタ用の PSTN ゲートウェイとしても動作できるため、PSTN ゲートウェイを別に用意する必要がありません。

2 番めのオプションは、中継ゾーン ゲートキーパー経由で配置する方法です。Unified CM、Unified CME、および Cisco Unified Border Element はすべて、VoIP ゲートウェイ デバイスとして中継ゾーン ゲートキーパーに登録されます。中継ゾーン ゲートキーパーが Unified CM と Unified CME 間のダイヤル プラン解決と帯域幅制限を実行します。また、中継ゾーン ゲートキーパーは、中継ゾーン ゲートキーパーは、ECS と H.450 を相互に接続することによって付加サービスをサポートするために、コールパスに Cisco Unified Border Element を挿入します。中継ゾーン ゲートキーパーと Cisco Unified Border Element の詳細については、「コール アドミッション制御」の章を参照してください。

これらの 2 つの配置オプションには、次の相違点があります。

1 番めのオプションでは、Cisco Unified Border Element は H.323 ゲートウェイ デバイスとして Unified CM に登録され、2 番めのオプションでは、VoIP ゲートウェイ デバイスとして中継ゾーン ゲートキーパーに登録されます。

1 番めのオプションでは、Cisco Unified Border Element が Cisco Unified Border Element の VoIP ダイヤル ピア設定に基づくダイヤル プラン解決を実行し、2 番めのオプションでは、中継ゾーン ゲートキーパーがゲートキーパーのダイヤル プラン設定に基づくダイヤル プラン解決を実行します。

1 番めのオプションでは、両方のコール レッグを監視するコール アドミッション制御メカニズムがなく、2 番めのオプションでは、中継ゾーン ゲートキーパーがゲートキーパー ゾーンベースのコール アドミッション制御を実行します。

2 番めのオプションでは、中継ゾーン ゲートキーパーは Unified CM のインフラストラクチャ ゲートキーパーとして機能し、Unified CM クラスタ間、Unified CM クラスタと H.323 VoIP ゲートウェイのネットワーク間、および Unified CM クラスタとサービス プロバイダーの H.323 VoIP ネットワーク間のすべてのダイヤル プラン解決および帯域幅制限を管理することもできます。

図 9-16 は、中継ゾーン ゲートキーパーと Cisco Unified Border Element を使用する Unified CM と Unified CME 間の H.323 統合を示しています。

図 9-16 Cisco Unified Border Element または中継ゾーン ゲートキーパーを使用して Unified CM と Unified CME を接続するマルチサイト配置

 

ベスト プラクティス

この項では、2 番めの配置オプション(中継ゾーン ゲートキーパー)で、図 9-16 に示した配置モデルを使用する場合のガイドラインとベスト プラクティスについて説明します。

Unified CM と中継ゾーン ゲートキーパーとの間にゲートキーパー制御の H.225 トランクを設定します。Media Termination Point(MTP; メディア ターミネーション ポイント)のリソースがトランクに必要になるのは、Unified CME が H.323 fast-start コールを開始しようとしたときのみです。

トランクの両端の H.323 デバイスが、遠端デバイスによって先に TCS が送信されるのを待っていて、H.245 接続が数秒後にタイムアウトになる場合、デッドロック状態が発生しないようにするため、[Wait For Far End H.245 Terminal Capability Set] (TCS)オプションをオフにする必要があります。

Unified CM サービス パラメータ [Send H225 user info message] [H225 info for Call Progress Tone] に設定し、Unified CM から Unified CME に H.225 Info message を送信して、リングバック トーンまたは保留トーンを再生できるようにします。

Unified CM ダイヤル プランの設定(ルート パターン、ルート リスト、およびルート グループ)を使用して、Unified CME を宛先とするコールをゲートキーパー制御の H.225 トランクに送信します。

Unified CME と Cisco Unified Border Element を H.323 ゲートウェイとして中継ゾーン ゲートキーパーに登録します。

Cisco Unified Border Element 上で allow-connection h323 to h323 コマンドを設定して、H.323-to-H.323 コール接続を許可します。このコマンドは、Unified CME に対して設定するためのオプションです。Cisco Unity Connection を Unified CME で使用する場合は、 allow-connection h323 to sip を設定します。

コール転送や自動転送などの付加サービスでは、2 つのエンドポイントが同じ Unified CME 配下に存在する場合に、コールのメディア ヘアピンが発生します。


) 2 つの配置オプションにおける設定の違いは、1 番めのオプションでは、Unified CM で Cisco Unified Border Element を H.323 ゲートウェイ デバイスとして設定する必要があることだけです。上記のその他の設定ガイドラインは、どちらのオプションも同じです。



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


設計上の考慮事項

H.323 配置では、Unified CME はコール転送、H.450.2、および H.450 標準の一部としての H.450.3 を使用した自動転送をサポートします。ただし、Unified CM は H.450 をサポートしません。また、コール転送、自動転送、保留または保留解除などの付加サービスは、Empty Capabilities Set(ECS)を使用して行われます。そのため、コールが Unified CM と Unified CME との間で転送または自動転送されると、Cisco Unified Border Element を使用して、コールはヘアピンされ、ルーティングされます。前の項の 2 つの配置モデルとして説明したように、ゲートキーパーは使用される場合と使用されない場合があります。この項では、H.323 経由の Unified CM と Unified CME の相互運用性の設計上の考慮事項とベスト プラクティスを示します。

コール転送および自動転送などの付加サービス

Unified CME は、H.450.12 プロトコルを使用して H.450. x 機能を自動的に検出することで、H.450 をサポートしない Unified CM を自動検出します。Unified CME は、Unified CM と Unified CME 間のコールに VoIP ヘアピン ルーティングを使用します。Unified CME は Unified CM 電話機からのコールを終端している状態で、そのコールをヘアピンするために、必要に応じて再発信およびコール ルーティングします。


) Unified CME は、Unified CM が H.450 をサポートしないことを検出すると、Unified CME でシグナリングとメディアの両方をヘアピンすることにより、コールをヘアピンします。そのため、コールを WAN を介して転送または自動転送すると、消費される帯域幅の量は 2 倍になります (たとえば、Unified CM 電話機が Unified CME 電話機にコールして、Unified CME 電話機がコールを別の Unified CM 電話機に転送すると、Unified CME は、2 台の Unified CM 電話機間のコールでも、シグナリングとメディアの両方をヘアピンします)。この WAN での 2 倍の帯域幅消費を避けるために、Cisco Unified Border Element を使用して H.450 タンデム ゲートウェイとして機能させ、コール転送または自動転送などの付加サービスで H.450-to-ECS マッピングを可能にすることを推奨します。


サポートされるコール フロー

Unified CME はバックツーバック ユーザ エージェント(B2BUA)なので、コール フローは SCCP 電話機どうしの場合、および SCCP 電話機と SIP 電話機の場合に機能します。SIP 電話機のコールは H.323 トランク経由で機能しますが、付加機能はサポートされません。

セキュリティ

Unified CME は、TLS を使用するセキュア シグナリングと SRTP を使用するメディア暗号化を提供します。Unified CM はまた、TLS 経由でセキュア シグナリング、および SRTP 経由でセキュア メディアをサポートします。ただし、セキュア Unified CM とセキュア Unified CME との間のインターワーキングはサポートされていません。

ビデオ

Unified CME を使用してビデオ機能を実装する場合は、次の設計上の考慮事項に従ってください。

Unified CM と Unified CME のすべてのエンドポイントは、ビデオ対応エンドポイントとして設定する必要があります。ビデオ コーデックとビデオ形式は、すべてのビデオ対応エンドポイントで一致する必要があります。

Unified CM と Unified CME は基本的なビデオ コールをサポートしますが、コール転送や自動転送などの付加サービスは、Unified CM と Unified CME 間のビデオ コールではサポートされません。Unified CME で付加サービスをサポートするには、すべての Unified CME と音声ゲートウェイで H.450 を有効にする必要があります。Unified CM は H.450 をサポートしないため、Unified CM 電話機と Unified CME 電話機間で付加サービスが必要な場合、ビデオ コールは音声のみのコールに戻ります。

電話会議は音声専用に戻ります。

ビデオ トラフィックが WAN を通過するには、WAN 帯域幅は 384 kbps の最小ビデオ ビットレートを満たす必要があります。

ISDN 経由の H.320 ビデオ

ISDN 経由で H.320 ビデオ機能を実装する場合は、次の設計上の考慮事項に従ってください。

PRI または BRI インターフェイス経由で H.320 エンドポイントに直接接続する場合、Unified CME および Cisco IOS ルータは現在、128 kbps のビデオ コールのみをサポートしています。

Unified CME および PSTN ゲートウェイで H.320 を有効にして、Unified CM と相互作用するようにする場合、音声のみのコールと区別するために、ビデオ コールには別個のダイヤル ピアを使用します。Unified CME の voice-port 設定で bear-cap speech を設定します。

H.320 は付加サービスをサポートしません。

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

H.450.12 を使用して Unified CM を自動検出するように Unified CME を設定し、Unified CM 電話機と Unified CME 電話機間のコールをヘアピンします。

SCCP-to-SCCP コールまたは SCCP-to-SIP コールの場合は、H.323 トランクを Unified CM と Unified CME との間に配置できます。

Unified CME は、TLS を使用するセキュア シグナリングと SRTP を使用するセキュア メディアをサポートしますが、会議コール フローは保護できません。さらに、Unified CM 電話機と Unified CME 電話機間のセキュリティの相互運用性もサポートされていません。

ビデオを配置するのは SCCP 電話機用(基本的なコールのみサポート)で、SIP 電話機用ではありません。

MTP 機能はビデオと互換性がありません。ビデオ コールを機能させるには、MTP 機能を無効(オフ)にする必要があります。

Unified CM と Unified CME 間の IP 接続が正常に機能することを確認します。

Unified CME の各ローカル ゾーンと Unified CM のロケーション(ローカル SCCP)で、ローカル ビデオのセットアップが正常に機能することを確認します。

既存の音声ダイヤル プランのインフラストラクチャを使用します。

ビデオ トラフィック シェーピングの場合は、次のガイドラインに従ってください。

リップシンクを維持し、かつ音声のみのコールとビデオを区別するために、ビデオ コールのビデオ チャネルと音声チャネルが CoS4 となるようにします。

音声トラフィックとビデオ トラフィックを異なるキューに配置します。

音声トラフィックとビデオ トラフィックにプライオリティ キューイング(PQ)を使用します。音声のみのコールとビデオ(音声ストリーム + ビデオ ストリーム)コールには、分類に基づいて 2 つの異なるポリシーが必要です。ビデオ コールの音声ストリームには、ビデオ コールのビデオ ストリームと同じマークが付けられているため、音声コールはビデオ コールから保護されています。

ビデオは、帯域幅が 768 kbps 未満のリンクには配置しないでください。

リンク速度が 768 kbps 以上で、オーバーサブスクリプションを防止する適切なコール アドミッション制御を使用している場合は、PQ にビデオ トラフィックを配置しても、音声パケットの遅延が大幅に改善されることはありません。

スピードが 768 kbps 以上の場合はフラグメンテーションを設定する必要はありません。

ビデオ パケットには cRTP は推奨しません (ビデオ パケットは大きいため、cRTP はビデオには役立ちません)。

音声トラフィックとビデオ トラフィックがリンク容量に占める割合が 33% を超えないようにします。

ビデオ帯域幅を計算する場合、オーバーヘッドを考慮して、コールの合計ビデオ データ レートに 20% を加算します。

H.323 を使用して Unified CME を Unified CM に統合する方法の詳細については、次の Web サイトで入手可能な『 Cisco Unified CME Solution Reference Network Design Guide 』を参照してください。

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

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

Cisco Unified CM と Cisco VCS を両方とも配置して、それらを統合すると有用な場合があります。たとえば、主要な呼処理エージェントとして Unified CM で配置するときに、Cisco VCS も追加して、H.323 テレプレゼンス エンドポイントとのすべての機能を持つ相互運用性、SIP とのインターワーキング、サードパーティ ビデオ エンドポイントとの統合、テレプレゼンス会議ソリューション、および VCS Expressway との組み合わせによる NAT/ファイアウォール トラバーサルといった機能を提供することができます。

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

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

図 9-17 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 のルート パターン、変換、およびトランスフォーメーション パターン