Cisco IP テレフォニー ネットワーク デザイン ガイド
Cisco CallManager クラスタ
Cisco CallManager クラスタ
発行日;2012/01/13 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

Cisco CallManager クラスタ

クラスタのオペレーションとスケーラビリティについてのガイドライン

デバイスの重み

クラスタ内通信

Cisco CallManager の冗長性

冗長性グループの構成

デバイス プールの設定

キャンパスのクラスタ化ガイドライン

クラスタ間通信

キャンパスに対するクラスタのプロビジョニング

分散型コール処理を行う複数サイト WAN のクラスタ

中央集中型コール処理を行う複数サイト WAN のクラスタ

クラスタ内およびクラスタ間の機能の透過性

Cisco CallManager クラスタ

この章では、Cisco CallManager クラスタの概念、プロビジョニング、および設定について説明します。Cisco CallManager Release 3.0 で導入されたクラスタは、コンバージした IP ネットワーク インフラストラクチャ全体に、シームレスに分散型コール処理を行うメカニズムを提供して、IP テレフォニーをサポートします。またこのクラスタは、冗長性を実現するとともに、機能の透過性とスケーラビリティを提供します。

ここでは、キャンパスおよび WAN の両方の環境におけるクラスタのオペレーションについて説明し、実装する上で参考となる設計案を提示します。次のセクションでこれらの内容を説明します。

「クラスタのオペレーションとスケーラビリティについてのガイドライン」

「Cisco CallManager の冗長性」

「キャンパスのクラスタ化ガイドライン」

「クラスタ間通信」

「クラスタ内およびクラスタ間の機能の透過性」

クラスタのオペレーションとスケーラビリティについてのガイドライン

Cisco CallManager Release 3.0(5) を使用すると、1 つのクラスタには、コール処理に使用できる 6 台のサーバを含め、8 台のサーバを割り当てられます。残りの 2 台のサーバは、それぞれ専用のデータベース パブリッシャ、および専用の TFTP サーバとして設定できます。

データベース パブリッシャを使用して、設定に関するすべての変更を実行するだけでなく、コール詳細レコードも作成します。TFTP サーバを使用すれば、コンフィギュレーション ファイル、デバイスのロード(操作コード)、およびリング タイプのダウンロードを容易にできます。

大規模なシステムには、専用のデータベース パブリッシャ、および専用の TFTP サーバの使用をお勧めします。小規模なシステムの場合は、データベース パブリッシャと TFTP サーバの機能の組み合わせが可能です。表 3-1は、
Cisco CallManager クラスタを使用する、スケーリング デバイスのガイドラインを示しています。

 

表 3-1 Cisco CallManager クラスタ ガイドライン

クラスタ内に必要とされる
IP 電話台数
Cisco CallManager の推奨数
Cisco CallManager 当たりの最高 IP 電話台数

2,500

合計 3 台のサーバ

パブリッシャと TFTP の結合

1 プライマリ Cisco CallManager

1 バックアップ Cisco CallManager

2,500

5,000

合計 4 台のサーバ

パブリッシャと TFTP の結合

2 プライマリ Cisco CallManager

1 バックアップ Cisco CallManager

2,500

10,000

合計 8 台のサーバ

データベース パブリッシャ

TFTP サーバ

4 プライマリ Cisco CallManager

2 バックアップ Cisco CallManager

2,500

前述の推奨事項が最適のソリューションを提供します。冗長性の量を減らして、使用するサーバーの台数をより少なくできます。小規模なシステムでは、データベース パブリッシャ、TFTP サーバ、および Cisco CallManager バックアップの機能を結合することができます。

1 台のCisco CallManager に登録できるデバイスの最大数は、MCS-7835 の場合は 5000 です。この数には、最高 2500 台の IP 電話、ゲートウェイ、およびトランスコーディングや電話会議用のリソースなどの、デジタル信号プロセッサ(DSP)が含まれます。クラスタ内の Cisco CallManager の 1 つが故障した場合でも、1 台の Cisco CallManager に登録可能なデバイスの最大数は、MCS-7835 の場合、5000 のまま変わりません。

デバイスの重み

多くのタイプのデバイスを Cisco CallManager に登録できます。IP 電話、音声メール ポート、テレフォニー アプリケーション プログラミング インターフェイス(TAPI)デバイス、Java テレフォニー API(JTAPI)デバイス、ゲートウェイ、およびトランスコーディングと電話会議などの DSP リソースのそれぞれが、異なる重みをもちます。表 3-2は、リソースのタイプごとの重みを、メモリと CPU リソースの消費に基づいて表しています。

 

表 3-2 デバイス タイプ別の重み

デバイス タイプ
セッション当たりの
重み/音声チャネル
デバイス当たりの
セッション/DS0
累積した
デバイスの重み

IP 電話

1

1

1

アナログ ゲートウェイ ポート

3

可変

DS0 当たり 3

T1 ゲートウェイ

3

24

T1 当たり 72

E1 ゲートウェイ

3

30

E1 当たり 90

トランスコーディング リソース

3

可変

セッション当たり 3

ソフトウェア MTP

3

48

1441

電話会議用リソース
(ハードウェア)

3

可変

セッション当たり 3

電話会議用リソース
(ソフトウェア)

3

48

1441

CTI ポート(TAPI と JTAPI)

20

1

20

Cisco SoftPhone

20

1

20

メッセージ(音声メール)装置

3

可変

セッション当たり 3

クラスタ間トランク

3

可変

セッション当たり 3

1.Cisco CallManager と同じサーバにインストールする場合、最大セッション数は 48 です。

単一の Cisco CallManager が制御できるデバイス ユニットの合計は、サーバのプラットフォームに応じて異なります。表 3-3は、プラットフォーム当たりの最大デバイス数の詳細を示しています。

 

表 3-3 サーバ プラットフォーム当たりの最大デバイス数

サーバ プラットフォームの特性
サーバ当たりの最大
デバイス ユニット数
サーバ当たりの
最大 IP 電話数

MCS-7835-10002
PIII 1000MHz, 1G RAM

5000

2500

MCS-7835
PIII 733MHz, 1G RAM

5000

2500

MCS-7830
PIII 500MHz, 1G RAM

3000

1500

MCS-7830
PIII 500MHz, 512M RAM

1000

500

MCS-7825-8001
PIII 800MHz, 512M RAM

1000

500

MCS-7822
PIII 550MHz, 512M RAM

1000

500

MCS-7820
PIII 500MHz, 512M RAM

1000

500

2.このサーバ プラットフォームは、2001 年の第一四半期まで利用できません。

単一の Cisco CallManager に登録できる IP 電話の合計数は、IP 電話だけを登録する場合でも、MCS-7835 では 2500 までに制限されています。Cisco CallManager に登録できる IP 電話の数を計算するには、当該プラットフォームに許容されるデバイス ユニットの最大数から IP 電話以外のリソースの重み値を引きます。MCS-7835 の場合、デバイス ユニットの最大数は 5000 です。

クラスタ内通信

Cisco CallManager クラスタ内には、2 種類の主要なクラスタ内通信があります(図 3-1)。最初の通信は、すべてのデバイス設定情報を含むデータベースを分配するメカニズムです。設定データベース(Microsoft SQL 7.0)は、パブリッシャ上にストアされ、クラスタのサブスクライバ メンバーに複写されます。パブリッシャ上で実行された変更は、サブスクライバの データベースに送信され、データベースの空間的な冗長化を行うとともに、クラスタのメンバー全体で設定情報が一致するようにします。

2 番目のクラスタ内通信は、IP 電話、ゲートウェイ、および DSP リソースの登録など、実行時データの伝搬と複製です。この情報は、クラスタ内のすべてのメンバーで共有され、クラスタのメンバーと関連ゲートウェイ間のコールの最適なルーティングを保証します。

図 3-1 クラスタ内通信

 

Cisco CallManager の冗長性

クラスタ内では、登録した各 IP 電話には、最高 3 つまでの Cisco CallManager で構成されている優先順位リストが割り当てられ、各 IP 電話は、コール処理のために CallManager に登録できます。Skinny Gateway Protocol を使用するゲートウェイのような共有リソースも、この冗長性の方式を使用できます。メディア ゲートウェイ コントロール プロトコル(MGCP)も同様の方法で動作し、コール処理に必要な空間的な冗長性を提供します。H.323 のようなピアツーピアのプロトコルも冗長性を実現します。

図 3-2は、3 つの Cisco CallManager を使用する冗長性の方式を表しています。

図 3-2 Cisco CallManager の冗長性グループ

 

各 IP 電話は、自身のプライマリおよびセカンダリの Cisco CallManager を使用して、アクティブな TCP セッションを維持します。この構成は、プライマリの
Cisco CallManager が故障したときの切り替えを容易にします。プライマリ Cisco CallManager の復元と同時に、デバイスはそのプライマリに復帰します。

冗長性グループの構成

お客様は、ご自身のシステムを設計して、Cisco CallManager の冗長性グループを構成し、コール処理の冗長性を実現できます、 Cisco CallManager の冗長性グループとは、最高 3 つまでの Cisco CallManager で構成されている優先順位リストのことです。個別のデバイスを特定の Cisco CallManager の冗長性グループに割り当てられます。Cisco CallManager の冗長性グループは、クラスタのサブセットで、冗長性グループのすべてのメンバーもクラスタのメンバーです。


) クラスタと冗長性グループのサイズは、Cisco CallManager の今後のリリースで変更されることがあります。


次の推奨事項は、Cisco CallManager Release 3.0(5) の冗長性グループの構成に適用します。

Cisco CallManager クラスタが 2500 ユーザまでの場合

サーバ A は、専用のデータベース パブリッシャーと TFTP サーバです。

サーバ B は、登録したすべてのデバイスのプライマリ Cisco CallManager です。

サーバ C は、登録したすべてのデバイスのバックアップ Cisco CallManager です。

上記の構成では、単一の Cisco CallManager 冗長性グループだけが、サーバ B とサーバ C に必要となります。

Cisco CallManager クラスタが 5000 ユーザまでの場合

サーバ A は、専用のデータベース パブリッシャーと TFTP サーバです。

サーバ B は、IP 電話 1 ~ 2500 までのプライマリ Cisco CallManager です。

サーバ C は、IP 電話 2501 ~ 5000 までのプライマリ Cisco CallManager です。

サーバ D は、登録したすべてのデバイスのバックアップ Cisco CallManager です。

上記の構成では、2 つの Cisco CallManager 冗長性グループがサーバ B と D 、そしてサーバ C と D に必要となります。

Cisco CallManager クラスタが 10,000 ユーザまでの場合

サーバ A は、専用のデータベース パブリッシャです。

サーバ B は、専用の TFTP サーバです。

サーバ C は、IP 電話 1 ~ 2500 までのプライマリ Cisco CallManager です。

サーバ D は、IP 電話 2501 ~ 5000 までのプライマリ Cisco CallManager です。

サーバ E は、IP 電話 1 ~ 5000 までのバックアップ Cisco CallManager です。

サーバ F は、IP 電話 5001 ~ 7500 までのプライマリ Cisco CallManager です。

サーバ G は、IP 電話 7501 ~ 10,000 までのプライマリ Cisco CallManager です。

サーバ H は、IP 電話 5001 ~ 10,000 までのバックアップ Cisco CallManager です。

上記の構成では、4 つの Cisco CallManager 冗長性グループが、サーバ C と E、サーバ D と E、サーバ F と H、そしてサーバ G と H に必要となります。
図 3-3は、この構成を示しています。冗長性グループを、CEH、DEH、FHE および GHE のように構成すれば、3 段の冗長性も可能です。

図 3-3 大規模システムの冗長性グループ

 


) Cisco CallManager が故障した場合、コールがドロップし、コールを再び開始する必要があることもあります。


デバイス プールの設定

デバイス プールを使用して、Cisco CallManager 冗長性グループの分散を拡張し、簡素化できます。デバイス プールを使用することで、次の 3 つの主要な属性をグローバルにデバイスへ割り当てることができます。

Region(地域):複数の音声コードを企業内で使用している場合にだけ必要

Date/Time Group(日付と時間帯グループ):デバイスに対して日付と時間帯を指定

Cisco CallManager Group(Cisco CallManager 冗長性グループ):優先順位リストを使用したコール処理に使用できる、最高 3 つまでの Cisco CallManager を記載しているリストを指定

図 3-4は、デバイス プールの設定画面の例です。Calling Search Space for
Auto-registration は、IP 電話の自動登録が使用できる場合にだけ関係します。これは、たとえば、自動登録デバイスへの PSTN のアクセス制限に使用できます。自動登録は、IP 電話の初期プロビジョニングで重要なツールです。

図 3-4 デバイス プールの設定画面

 

図 3-4では、Branch 1 G.711 ADE と呼ぶデバイス プールを次の特性で設定します。

このデバイス プールには、Region、Branch 1 G.711 を割り当てます。この Region には、音声メール システム、あるいはコンファレンス ブリッジのような、G.711 の手段だけで通信できるデバイスが含まれます。

Date/Time Group には適切な値を割り当てます。

Cisco CallManager Group には、Cisco CallManager A がプライマリ、D がセカンダリで、E が ターシャリ(第 3)の冗長性グループ ADE を割り当てます。

Branch 1 G0.729 ADE と呼ぶ 2 番目のデバイス プールを次の特性で設定できます。

このデバイス プールには、Region、Branch 1 G0.729 を割り当てます。この地域には、IP 電話のように、G.729 と G.711 の両方の手段で通信できるデバイスが含まれます。

Date/Time Group には適切な値を割り当てます。

Cisco CallManager Group には、Cisco CallManager A がプライマリ、D がセカンダリで、E が ターシャリの冗長性グループ ADE を割り当てます。

同じ Cisco CallManager グループを両方のデバイス プールに使用します。ただし、ここで次のような地域間通信コーデックの要件を指定できます。

地域内通信は G.711 を使用する。

地域間通信は WAN の範囲で G.729 を使用する。

G.711 地域へのすべてのコールは G.711 を使用する。たとえば、この要件は、G.711 だけのアプリケーションにアクセスする時は必須です。

図 3-5は、この設定を表しています。

図 3-5 地域間設定画面

 

正確なクラスタ化モデル(およびその結果使用されるデバイス プール)は、配置モデルで駆動されます。ただし、典型的なデバイス プールの設定には、次の特性があります。

WAN による音声相互接続を使用しない単一サイトのクラスタ

デバイス プールは、Cisco CallManager 冗長性グループにだけ基づいて設定します。

WAN による音声相互接続を使用する単一サイトのクラスタ

デバイス プールを上記のように設定しますが、コーデック選択に必要な地域を追加します。各クラスタには、Cisco CallManager 冗長性グループ別に、G.711 と G.729 の地域を割り当てることが可能です。

デバイス プールの合計は、地域数に Cisco CallManager 冗長性グループ数を乗算したものです。

中央集中型コール処理を使用した複数サイト WAN

単一の Cisco CallManager 冗長性グループだけが存在します。ただし、G.711 地域が 1 つと G.729 地域が 1 つ、ロケーションごとに必要です。これにより、たとえば、営業所内コールを G.711 で行い、営業所間コールを G.729 で行うことができます。

デバイス プール合計は、サイト数に地域数を乗算したものです。

キャンパスのクラスタ化ガイドライン

Cisco CallManager クラスタのすべてのメンバーは、LAN 上で相互接続されている必要があります。Cisco CallManager Release 3.0(5) クラスタは、WAN を介した動作がサポートされていません。

キャンパス IP テレフォニー ネットワークを設定するときは、次の考慮事項を適用します。

Cisco CallManager Release 3.0(5) で使用するサーバ数は、クラスタ当たり最高 8 台

登録できるデバイスの最大合計数は 10,000

故障の状況下で登録したデバイスを含め、Cisco CallManager 当たり登録できる IP 電話数は最高で 2500、デバイス数は最高 3000

デスクトップへのスイッチ型インフラストラクチャ(共有メディアはサポートされていません)

スイッチ型キャンパス インフラストラクチャ内では、通常、音声アプリケーションに対して帯域幅が適切であると想定できます。この帯域幅を利用できるかどうかは、第 2 章「キャンパス インフラストラクチャでの考慮事項」で説明した信頼境界の設定と必須キューイングに加えて、キャンパス内の適切な設計とキャパシティ計画に依存します。キャンパス クラスタ内では、コール アドミッション制御に対する要件はありません。

Cisco CallManager サーバは、キャンパス内に分散させて、空間的な冗長性と復元力を備える必要があります。メトロポリタンの多くのサイト、およびキャンパスのビルディングには、IP 接続をクラスタの他のメンバーに提供するコンジットが、1 本しかない可能性があります。この場合、IP 接続が故障すると、ローカル コール処理は、ローカル サーバによって維持する必要があります。PSTN アクセスに使用されるゲートウェイ リソースを同様に戦略的に配置し、最大限に可能なアベイラビリティを提供する必要があります。

図 3-6は、典型的なキャンパス、あるいはメトロポリタン エリア ネットーク(MAN)のクラスタの配置を示しています。

図 3-6 キャンパスあるいは MAN(メトロポリタン エリア ネットワーク)のクラスタ

 

図 3-6では、Cisco CallManager が、5 つのビルディングあるいはサイトのそれぞれに配置されています。この構成は、故障時、ローカル コール処理が各サイトで可能であることを保証します。光ファイバ ケーブルの多様なルーティングによって、ローカル Cisco CallManager が不要になる場合、すべてのコール処理を 1 つあるいは複数のデータ センターに集約できます。

トランスコーディング、および電話会議用 DSP のようなリソースは、共有リソースではないため、Cisco CallManager ごとに提供される必要があります。フォールト トレランスが必須の場所では、これらリソースの複製を作成しておくことが必須であり、空間的な冗長性を考慮しておくことをお勧めします。このことは、これらのリソースを戦略的に配置されているマルチレイヤ スイッチに置くことで、実現できます。

クラスタ間通信

次のセクションではクラスタ間通信について説明します。また、離れたキャンパスでの配置、分散型コール処理を行う複数サイト WAN、および中央処理型コール処理を行う複数サイト WAN での配置に、クラスタをプロビジョニングする上での問題点についても説明します。

キャンパスに対するクラスタのプロビジョニング

キャンパス ネットワークに対する要件が 10,000 ユーザを超える場所には、クラスタを追加する必要があります。同様に、各サイトあるいは各ビルディングでのローカル コール処理が、1 つのクラスタに許されている Cisco CallManager の最大数以上を必要としている場合、クラスタを追加する必要があります。

クラスタ間の通信は、標準ベースの H.323 信号方式を使用して行われます。帯域幅の供給は過剰で、サブスクライブは不足している典型的な大規模キャンパス、あるいは MAN では、クラスタ間コール アドミッション制御は不要です。図 3-7は、ローカル エリア環境内でのクラスタ間通信を示しています。

図 3-7 H.323 を使用したキャンパス クラスタ間通信

 

図 3-7では、点線が H.323 クラスタ間リンクを表しています。このリンクはペアで構成され、IP 接続が切断した場合、冗長性をクラスタの任意のメンバーに提供します。必要であれば、これらのリンクをフルメッシュとして構成できます。ただし、シスコはクラスタ間の構成を 2 ピアに制限することをお勧めします。大部分の場合、適切な復元力を提供するにはこれで十分です。ゲートキーパーを使用する配備では、シスコは、クラスタごとに単一の H.323 接続をお勧めします。ゲートキーパーに割り当てた Cisco CallManager 冗長性グループを使用すれば、冗長性を実現できます。

Cisco CallManager の初期のリリースと異なり、リリース 3.0(5) は、H.323 デバイス用の補足サービスを許す MTP の使用は、必要としません。Cisco CallManager 3.0(5) は、H.323v2 の empty capability set を使用して、Cisco CallManager クラスタのような H.323 デバイスと、Cisco IOS Release 12.0(7) あるいはそれ以上を実行する Cisco IOS ゲートウェイとの間で、論理チャネルの開始と終了を容易にします。

分散型コール処理を行う複数サイト WAN のクラスタ

クラスタが WAN 上で相互接続されていて、クラスタ間に輻輳に対するピンチ ポイントがある場合、音声トラフィックの必要量を許容するようにネットワークを設計する必要があります。このような場合、コール アドミッション制御を提供する方法が必要です。H.323 を使用してクラスタを相互接続しているため、Cisco IOS ゲートウェイを追加して、このゲートキーパー機能を促進できます。おのおののクラスタは、音声コール用に最大設定帯域幅を持つゾーンとして指定できます。

ゲートキーパーを使用する場合、Cisco CallManager は、G.711 クラスタ間コール当たり 128 Kbps の帯域幅、および G.729a クラスタ間コール当たり 20 Kbps の帯域幅を必要とします。通常、シスコは、WAN を越えて移動するコールに対して単一のコーデックを設定することをお勧めしています。この方法を使用すると、非常に簡単に帯域幅をプロビジョニングできるからです。

表 3-4表 3-5には、クラスタ間コールに対する帯域幅設定についての推奨事項が記載されています。

 

表 3-4 G.729 を使用したクラスタ間コールに対して推奨される帯域幅設定

クラスタ間コールの数
コール当たりの必要帯域幅
WAN リンクに必要な帯域幅(LLQ/CBWFQ3
ゲートキーパー上に設定される帯域幅
cRTP なし4
cRTP あり
cRTP なし
cRTP あり
cRTP なし
cRTP あり

2

24 Kbps

12 Kbps

48 Kbps

24 Kbps

40 Kbps

40 Kbps

5

24 Kbps

12 Kbps

120 Kbps

60 Kbps

100 Kbps

100 Kbps

10

24 Kbps

12 Kbps

240 Kbps

120 Kbps

200 Kbps

200 Kbps

3.WFQ(均等化キューイング)に基づく低遅延キューイング/クラス

4.圧縮リアルタイム転送プロトコル

 

表 3-5 G.711 を使用したクラスタ間コールに対して推奨される帯域幅設定

クラスタ間コールの数
コール当たりの
必要帯域幅
WAN リンクに必要な帯域幅(LLQ/CBWFQ)
ゲートキーパー上に設定される帯域幅

2

80 Kbps

160 Kbps

256 Kbps

5

80 Kbps

400 Kbps

640 Kbps

10

80 Kbps

800 Kbps

1280 Kbps

ゲートキーパーを使用すれば、送受信の両方にコール アドミッション制御が提供できます。Cisco CallManager Release 3.0(5) を使用して、最高 100 の
Cisco CallManager を 1 つのゲートキーパーに登録できます。このコール アドミッション制御の方法には、ネットワーク当たりアクティブなゲートキーパーは 1 つという制限があります。冗長性は、ホットスタンバイ ルーティング プロトコル(HSRP)を 2 つのゲートキーパー間で使用して、実現できます。

ゲートキーパー コール アドミッション制御は、ポリシーベースの方式です。この方式には使用可能なリソースの静的な設定が必要で、ネットワーク トポロジには無関係です。したがって、ゲートキーパー コール アドミッション制御方式は、冗長なゲートキーパー、あるいは(HSRP を使用する)ハブに配置されている複数のゲートキーパーを使用する、ハブアンドスポーク トポロジに限定して使用する必要があります。前記に従って WAN を設定し、すべての許可コールをサポートするように、音声プライオリティ キューの大きさを決める必要があります。

図 3-8は、この配置モデルを示しています。

図 3-8 ゲートキーパーを使用したクラスタ間通信

 

中央集中型コール処理を行う複数サイト WAN のクラスタ

前述したように、クラスタ内の Cisco CallManager は、ローカル エリア ネットワーク全体にわたって相互接続される必要があります。Cisco CallManager は、ロケーションベースのコール アドミッション制御も行います。これにより、小規模な営業所のプロビジョニング、およびリモート コール処理を許容するテレコミュータ ソリューションを提供できるようになります。図 3-9は、このモデルを表しています。

図 3-9 ロケーションベースのコール アドミッション制御

 

図 3-9 で説明した方式では、コール処理は中央サイトだけで行われ、各営業所にあるデバイスは、ロケーションに付属のものとして設定されます。たとえば、営業所 1 に 12 台の IP 電話を設置する場合、それぞれの IP 電話をロケーション営業所 1 に属するものとして設定します。Cisco CallManager は、その後、ロケーション別の使用済みおよび未使用の帯域幅を追跡し、それに応じて WAN のコールを許可、あるいは拒否できます。

この方式は、Cisco CallManager Release 3.0(5) で拡張され、2500 台までのリモート デバイスに対する中央集中型コール処理が可能となりました。このタイプのソリューションを、Cisco CallManager Release 3.0(5) を使用して実装するには、単一のアクティブな Cisco CallManager を含む専用の Cisco CallManager クラスタを使用して、コールの状態とコール アドミッション制御を維持する必要があります。


) このタイプの中央集中型構成では、クラスタ内の Cisco CallManager の数(1 つ、あるいは冗長性を目的として 2 つ、または 3 つ)に関係なく、クラスタ当たり最高 2500 のユーザがあります。さらに、一度にアクティブにできるのは、中央集中型クラスタにある 1 つの Cisco CallManager だけです。


単一の Cisco CallManager だけが一度にアクティブになるようにするには、すべてのデバイスを、単一の Cisco CallManager 冗長性グループに割り当てる必要があります。この Cisco CallManager 冗長性グループは、最高 3 つまでの
Cisco CallManager が記載されている優先順位リストのことです。中央集中型コール処理のクラスタには、単一の Cisco CallManager 冗長性グループだけを置くことが推奨され、そのグループをデフォルトのグループとする必要があります。図 3-10で示されている例では、冗長性グループは、A がプライマリ、B がセカンダリ、そして C がターシャリの Cisco CallManager である、3 つの Cisco CallManager で構成されています。

図 3-10 Cisco CallManager 冗長性グループの構成

 

典型的な中央集中型コール処理の 1 つのモデルとして、配備する
Cisco CallManager を 2 つだけとすることも可能です。この場合、シスコは、通常アクティブではない(セカンダリ)Cisco CallManager を、パブリッシャとすることをお勧めします。3 つの Cisco CallManager を持つクラスタについては、IP 電話とゲートウェイをプライマリとセカンダリの Cisco CallManager に割り当て、そして専用パブリッシャをターシャリの Cisco CallManager に割り当てることをお勧めします。

図 3-11は、キャンパス クラスタが、中央集中型コール処理を実行する 2 つのクラスタと相互接続されている、ハイブリッド配備モデルを示しています。この例は、複数の中央集中型コール処理クラスタを配備し、H.323 を使用して相互接続できることを示しています。キャンパス クラスタへの接続も H.323 を使用して行われます。クラスタ間コール アドミッション制御が必要な場合は、ゲートキーパーを割り当てます。

図 3-11 中央集中型コール処理クラスタと 2 つのクラスタ間の相互接続

 

クラスタ内およびクラスタ間の機能の透過性

Cisco CallManager クラスタの分散アーキテクチャには、コール処理に際して主に次のような利点があります。

空間的な冗長性

復元力

アベイラビリティ

サバイバビリティ

さらに、クラスタは、クラスタ内のすべてのデバイスに対して、ユーザ機能を透過的にサポートします。これにより、分散型 IP 電話をそのすべての機能と共にキャンパス全体、あるいは高速のメトロポリタン エリア ネットワークに拡張することができます。

H.323 が提供するクラスタ間通信により、機能のサブセットをクラスタ間に拡張することが可能です。現在、次のような機能をクラスタ間で利用できます。

基本コール セットアップ

G.711 と G.729 によるコール

複数グループによる電話会議

コールの保留

コールの転送

発信回線 ID

さらに、クラスタ内でコール パークを使用できます。ただし、クラスタ間では使用できません。