 |
この章では、Cisco CallManager クラスタの概念、プロビジョニング、および設定について説明します。Cisco CallManager Release 3.0 で導入されたクラスタは、コンバージした IP ネットワーク インフラストラクチャ全体に、シームレスに分散型コール処理を行うメカニズムを提供して、IP テレフォニーをサポートします。またこのクラスタは、冗長性を実現するとともに、機能の透過性とスケーラビリティを提供します。
ここでは、キャンパスおよび WAN の両方の環境におけるクラスタのオペレーションについて説明し、実装する上で参考となる設計案を提示します。次のセクションでこれらの内容を説明します。
Cisco CallManager Release 3.0(5) を使用すると、1 つのクラスタには、コール処理に使用できる 6 台のサーバを含め、8 台のサーバを割り当てられます。残りの 2 台のサーバは、それぞれ専用のデータベース パブリッシャ、および専用の TFTP サーバとして設定できます。
データベース パブリッシャを使用して、設定に関するすべての変更を実行するだけでなく、コール詳細レコードも作成します。TFTP サーバを使用すれば、コンフィギュレーション ファイル、デバイスのロード（操作コード）、およびリング タイプのダウンロードを容易にできます。
大規模なシステムには、専用のデータベース パブリッシャ、および専用の TFTP サーバの使用をお勧めします。小規模なシステムの場合は、データベース パブリッシャと TFTP サーバの機能の組み合わせが可能です。
Cisco CallManager クラスタ ガイドライン
は、
Cisco CallManager クラスタを使用する、スケーリング デバイスのガイドラインを示しています。
前述の推奨事項が最適のソリューションを提供します。冗長性の量を減らして、使用するサーバーの台数をより少なくできます。小規模なシステムでは、データベース パブリッシャ、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 リソースのそれぞれが、異なる重みをもちます。 デバイス タイプ別の重み は、リソースのタイプごとの重みを、メモリと CPU リソースの消費に基づいて表しています。
|
144 1 |
|||
|
144 1 |
|||
単一の Cisco CallManager が制御できるデバイス ユニットの合計は、サーバのプラットフォームに応じて異なります。 サーバ プラットフォーム当たりの最大デバイス数 は、プラットフォーム当たりの最大デバイス数の詳細を示しています。
|
MCS-7835-1000
2
|
||
|
MCS-7825-800
2
|
||
単一の Cisco CallManager に登録できる IP 電話の合計数は、IP 電話だけを登録する場合でも、MCS-7835 では 2500 までに制限されています。Cisco CallManager に登録できる IP 電話の数を計算するには、当該プラットフォームに許容されるデバイス ユニットの最大数から IP 電話以外のリソースの重み値を引きます。MCS-7835 の場合、デバイス ユニットの最大数は 5000 です。
Cisco CallManager クラスタ内には、2 種類の主要なクラスタ内通信があります（ クラスタ内通信 ）。最初の通信は、すべてのデバイス設定情報を含むデータベースを分配するメカニズムです。設定データベース（Microsoft SQL 7.0）は、パブリッシャ上にストアされ、クラスタのサブスクライバ メンバーに複写されます。パブリッシャ上で実行された変更は、サブスクライバの データベースに送信され、データベースの空間的な冗長化を行うとともに、クラスタのメンバー全体で設定情報が一致するようにします。
2 番目のクラスタ内通信は、IP 電話、ゲートウェイ、および DSP リソースの登録など、実行時データの伝搬と複製です。この情報は、クラスタ内のすべてのメンバーで共有され、クラスタのメンバーと関連ゲートウェイ間のコールの最適なルーティングを保証します。
クラスタ内では、登録した各 IP 電話には、最高 3 つまでの Cisco CallManager で構成されている優先順位リストが割り当てられ、各 IP 電話は、コール処理のために CallManager に登録できます。Skinny Gateway Protocol を使用するゲートウェイのような共有リソースも、この冗長性の方式を使用できます。メディア ゲートウェイ コントロール プロトコル（MGCP）も同様の方法で動作し、コール処理に必要な空間的な冗長性を提供します。H.323 のようなピアツーピアのプロトコルも冗長性を実現します。
Cisco CallManager の冗長性グループ は、3 つの Cisco CallManager を使用する冗長性の方式を表しています。
各 IP 電話は、自身のプライマリおよびセカンダリの Cisco CallManager を使用して、アクティブな TCP セッションを維持します。この構成は、プライマリの
Cisco CallManager が故障したときの切り替えを容易にします。プライマリ Cisco CallManager の復元と同時に、デバイスはそのプライマリに復帰します。
お客様は、ご自身のシステムを設計して、Cisco CallManager の冗長性グループを構成し、コール処理の冗長性を実現できます、 Cisco CallManager の冗長性グループとは、最高 3 つまでの Cisco CallManager で構成されている優先順位リストのことです。個別のデバイスを特定の Cisco CallManager の冗長性グループに割り当てられます。Cisco CallManager の冗長性グループは、クラスタのサブセットで、冗長性グループのすべてのメンバーもクラスタのメンバーです。
次の推奨事項は、Cisco CallManager Release 3.0(5) の冗長性グループの構成に適用します。
上記の構成では、単一の Cisco CallManager 冗長性グループだけが、サーバ B とサーバ C に必要となります。
上記の構成では、2 つの Cisco CallManager 冗長性グループがサーバ B と D 、そしてサーバ C と D に必要となります。
上記の構成では、4 つの Cisco CallManager 冗長性グループが、サーバ C と E、サーバ D と E、サーバ F と H、そしてサーバ G と H に必要となります。
大規模システムの冗長性グループ
は、この構成を示しています。冗長性グループを、CEH、DEH、FHE および GHE のように構成すれば、3 段の冗長性も可能です。
デバイス プールを使用して、Cisco CallManager 冗長性グループの分散を拡張し、簡素化できます。デバイス プールを使用することで、次の 3 つの主要な属性をグローバルにデバイスへ割り当てることができます。
デバイス プールの設定画面
は、デバイス プールの設定画面の例です。Calling Search Space for
Auto-registration は、IP 電話の自動登録が使用できる場合にだけ関係します。これは、たとえば、自動登録デバイスへの PSTN のアクセス制限に使用できます。自動登録は、IP 電話の初期プロビジョニングで重要なツールです。
デバイス プールの設定画面 では、Branch 1 G.711 ADE と呼ぶデバイス プールを次の特性で設定します。
Branch 1 G0.729 ADE と呼ぶ 2 番目のデバイス プールを次の特性で設定できます。
同じ Cisco CallManager グループを両方のデバイス プールに使用します。ただし、ここで次のような地域間通信コーデックの要件を指定できます。
正確なクラスタ化モデル（およびその結果使用されるデバイス プール）は、配置モデルで駆動されます。ただし、典型的なデバイス プールの設定には、次の特性があります。
Cisco CallManager クラスタのすべてのメンバーは、LAN 上で相互接続されている必要があります。Cisco CallManager Release 3.0(5) クラスタは、WAN を介した動作がサポートされていません。
キャンパス IP テレフォニー ネットワークを設定するときは、次の考慮事項を適用します。
スイッチ型キャンパス インフラストラクチャ内では、通常、音声アプリケーションに対して帯域幅が適切であると想定できます。この帯域幅を利用できるかどうかは、 キャンパス インフラストラクチャでの考慮事項 で説明した信頼境界の設定と必須キューイングに加えて、キャンパス内の適切な設計とキャパシティ計画に依存します。キャンパス クラスタ内では、コール アドミッション制御に対する要件はありません。
Cisco CallManager サーバは、キャンパス内に分散させて、空間的な冗長性と復元力を備える必要があります。メトロポリタンの多くのサイト、およびキャンパスのビルディングには、IP 接続をクラスタの他のメンバーに提供するコンジットが、1 本しかない可能性があります。この場合、IP 接続が故障すると、ローカル コール処理は、ローカル サーバによって維持する必要があります。PSTN アクセスに使用されるゲートウェイ リソースを同様に戦略的に配置し、最大限に可能なアベイラビリティを提供する必要があります。
キャンパスあるいは MAN（メトロポリタン エリア ネットワーク）のクラスタ は、典型的なキャンパス、あるいはメトロポリタン エリア ネットーク（MAN）のクラスタの配置を示しています。
キャンパスあるいは MAN（メトロポリタン エリア ネットワーク）のクラスタ では、Cisco CallManager が、5 つのビルディングあるいはサイトのそれぞれに配置されています。この構成は、故障時、ローカル コール処理が各サイトで可能であることを保証します。光ファイバ ケーブルの多様なルーティングによって、ローカル Cisco CallManager が不要になる場合、すべてのコール処理を 1 つあるいは複数のデータ センターに集約できます。
トランスコーディング、および電話会議用 DSP のようなリソースは、共有リソースではないため、Cisco CallManager ごとに提供される必要があります。フォールト トレランスが必須の場所では、これらリソースの複製を作成しておくことが必須であり、空間的な冗長性を考慮しておくことをお勧めします。このことは、これらのリソースを戦略的に配置されているマルチレイヤ スイッチに置くことで、実現できます。
次のセクションではクラスタ間通信について説明します。また、離れたキャンパスでの配置、分散型コール処理を行う複数サイト WAN、および中央処理型コール処理を行う複数サイト WAN での配置に、クラスタをプロビジョニングする上での問題点についても説明します。
キャンパス ネットワークに対する要件が 10,000 ユーザを超える場所には、クラスタを追加する必要があります。同様に、各サイトあるいは各ビルディングでのローカル コール処理が、1 つのクラスタに許されている Cisco CallManager の最大数以上を必要としている場合、クラスタを追加する必要があります。
クラスタ間の通信は、標準ベースの H.323 信号方式を使用して行われます。帯域幅の供給は過剰で、サブスクライブは不足している典型的な大規模キャンパス、あるいは MAN では、クラスタ間コール アドミッション制御は不要です。 H.323 を使用したキャンパス クラスタ間通信 は、ローカル エリア環境内でのクラスタ間通信を示しています。
H.323 を使用したキャンパス クラスタ間通信 では、点線が 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 上で相互接続されていて、クラスタ間に輻輳に対するピンチ ポイントがある場合、音声トラフィックの必要量を許容するようにネットワークを設計する必要があります。このような場合、コール アドミッション制御を提供する方法が必要です。H.323 を使用してクラスタを相互接続しているため、Cisco IOS ゲートウェイを追加して、このゲートキーパー機能を促進できます。おのおののクラスタは、音声コール用に最大設定帯域幅を持つゾーンとして指定できます。
ゲートキーパーを使用する場合、Cisco CallManager は、G.711 クラスタ間コール当たり 128 Kbps の帯域幅、および G.729a クラスタ間コール当たり 20 Kbps の帯域幅を必要とします。通常、シスコは、WAN を越えて移動するコールに対して単一のコーデックを設定することをお勧めしています。この方法を使用すると、非常に簡単に帯域幅をプロビジョニングできるからです。
G.729 を使用したクラスタ間コールに対して推奨される帯域幅設定 と G.711 を使用したクラスタ間コールに対して推奨される帯域幅設定 には、クラスタ間コールに対する帯域幅設定についての推奨事項が記載されています。
ゲートキーパーを使用すれば、送受信の両方にコール アドミッション制御が提供できます。Cisco CallManager Release 3.0(5) を使用して、最高 100 の
Cisco CallManager を 1 つのゲートキーパーに登録できます。このコール アドミッション制御の方法には、ネットワーク当たりアクティブなゲートキーパーは 1 つという制限があります。冗長性は、ホットスタンバイ ルーティング プロトコル（HSRP）を 2 つのゲートキーパー間で使用して、実現できます。
ゲートキーパー コール アドミッション制御は、ポリシーベースの方式です。この方式には使用可能なリソースの静的な設定が必要で、ネットワーク トポロジには無関係です。したがって、ゲートキーパー コール アドミッション制御方式は、冗長なゲートキーパー、あるいは（HSRP を使用する）ハブに配置されている複数のゲートキーパーを使用する、ハブアンドスポーク トポロジに限定して使用する必要があります。前記に従って WAN を設定し、すべての許可コールをサポートするように、音声プライオリティ キューの大きさを決める必要があります。
ゲートキーパーを使用したクラスタ間通信 は、この配置モデルを示しています。
前述したように、クラスタ内の Cisco CallManager は、ローカル エリア ネットワーク全体にわたって相互接続される必要があります。Cisco CallManager は、ロケーションベースのコール アドミッション制御も行います。これにより、小規模な営業所のプロビジョニング、およびリモート コール処理を許容するテレコミュータ ソリューションを提供できるようになります。 ロケーションベースのコール アドミッション制御 は、このモデルを表しています。
ロケーションベースのコール アドミッション制御 で説明した方式では、コール処理は中央サイトだけで行われ、各営業所にあるデバイスは、ロケーションに付属のものとして設定されます。たとえば、営業所 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 だけが一度にアクティブになるようにするには、すべてのデバイスを、単一の Cisco CallManager 冗長性グループに割り当てる必要があります。この Cisco CallManager 冗長性グループは、最高 3 つまでの
Cisco CallManager が記載されている優先順位リストのことです。中央集中型コール処理のクラスタには、単一の Cisco CallManager 冗長性グループだけを置くことが推奨され、そのグループをデフォルトのグループとする必要があります。
Cisco CallManager 冗長性グループの構成
で示されている例では、冗長性グループは、A がプライマリ、B がセカンダリ、そして C がターシャリの Cisco CallManager である、3 つの Cisco CallManager で構成されています。
典型的な中央集中型コール処理の 1 つのモデルとして、配備する
Cisco CallManager を 2 つだけとすることも可能です。この場合、シスコは、通常アクティブではない（セカンダリ）Cisco CallManager を、パブリッシャとすることをお勧めします。3 つの Cisco CallManager を持つクラスタについては、IP 電話とゲートウェイをプライマリとセカンダリの Cisco CallManager に割り当て、そして専用パブリッシャをターシャリの Cisco CallManager に割り当てることをお勧めします。
中央集中型コール処理クラスタと 2 つのクラスタ間の相互接続 は、キャンパス クラスタが、中央集中型コール処理を実行する 2 つのクラスタと相互接続されている、ハイブリッド配備モデルを示しています。この例は、複数の中央集中型コール処理クラスタを配備し、H.323 を使用して相互接続できることを示しています。キャンパス クラスタへの接続も H.323 を使用して行われます。クラスタ間コール アドミッション制御が必要な場合は、ゲートキーパーを割り当てます。
Cisco CallManager クラスタの分散アーキテクチャには、コール処理に際して主に次のような利点があります。
さらに、クラスタは、クラスタ内のすべてのデバイスに対して、ユーザ機能を透過的にサポートします。これにより、分散型 IP 電話をそのすべての機能と共にキャンパス全体、あるいは高速のメトロポリタン エリア ネットワークに拡張することができます。
H.323 が提供するクラスタ間通信により、機能のサブセットをクラスタ間に拡張することが可能です。現在、次のような機能をクラスタ間で利用できます。
All contents copyright (C) 1992--2003 Cisco Systems K.K.
