Cisco CallManager システム ガイド リリース 3.3(2)

クラスタ化

---

Cisco CallManager のクラスタ化機能は、コール処理をコンバージド IP ネットワークのインフラストラクチャ全体にシームレスに分散させるメカニズムです。クラスタ化により、冗長化が容易になり、クラスタ内のリソースとフィーチャは透過的に共有ができるようになり、システムのスケーラビリティが得られます。

この章の構成は、次のとおりです。

• 「クラスタ」

• 「イントラクラスタ間の通信」

• 「冗長化」

• 「クラスタ間の通信」

• 「コール処理の負荷バランス」

• 「クラスタ設定チェックリスト」

• 「参考情報」

クラスタ

クラスタとは、同じデータベースとリソースを共有している Cisco CallManager サーバ群をグループ化したものです。クラスタ内の Cisco CallManager サーバは、その設定内容により、次に示す機能を実行します。

• データベース パブリッシャ サーバ

• TFTP サーバ

• アプリケーション ソフトウェア サーバ

• プライマリ コール処理サーバ

• バックアップ コール処理サーバ

Cisco CallManager ソフトウェアをサーバ群にインストールする際に、どのサーバと Cisco CallManagers を同じクラスタに所属させるかを指定します。
Cisco CallManager Serviceability アプリケーションの Service Activation ページを使用して、そのクラスタに対してどのサーバがどの機能を実行するかを指定します。システムの規模と必要な冗長性のレベルに応じて、特定のサーバを特定の機能専用にすることや、1 台のサーバに複数の機能を組み合せることができます。

各クラスタには、データベース パブリッシャ 1 台と、通常は TFTP サーバ 1 台を別個、または組み合せて設定できます。クラスタ内のその他のサーバは、パブリッシャ データベースのサブスクライバになりますが、そのサブスクライバ自体もパブリッシャ データベースのローカル コピーを独自に保持します。図 5-1では、3 台の Cisco CallManager を使用しての簡単なクラスタの例を示しています。

クラスタ サイズと推奨構成の詳細については、『 Cisco IP Telephony Network Design Guide 』を参照してください。

Service Activation ページの詳細については、『 Cisco CallManager Serviceability System Guide 』および『 Cisco CallManager Serviceability アドミニストレーション ガイド 』を参照してください。

図 5-1 Cisco CallManager 3 台で構成されるクラスタ例

イントラクラスタ間の通信

Cisco CallManager のクラスタでは、2 種類の方法で通信が行われています。第 1 の方法は、すべてのデバイス コンフィギュレーション情報を含むデータベースを配布するメカニズムです。Cisco CallManager Administration 内でコンフィギュレーションを変更すると、パブリッシャ サーバはその変更内容をまずローカル データベースに保存します。その後、パブリッシャはクラスタ内のサブスクライバ サーバすべてに新しいデータを送信し、サブスクライバ サーバはデータベースのローカル コピーを更新します。このメカニズムにより、コンフィギュレーション データベースの一貫性はクラスタ内のサーバ全体で保たれます。また、何らかの理由でパブリッシャが使用不能になる場合も、サブスクライバ サーバはデータベースのローカル コピーを使用して動作を継続できるため、データベースの冗長性も提供されます。パブリッシャが使用不能になった場合は、データベースのサブスクライバ コピーを更新できません。したがって、パブリッシャが使用不能になった場合は、電話機の更新およびコール転送の修正を行うことができず、メッセージ受信のステート情報が失われます。

第 2 の方法は、IP Phone、ゲートウェイ、digital signal processor（DSP; デジタル シグナル プロセッサ）リソースの登録など、実行時のデータを伝搬および複製します。クラスタ内のサーバはすべてこの実行時データを共有するので、クラスタおよび関連したゲートウェイのメンバー間でコールの最適なルーティングが可能になります。

冗長化

クラスタは、IP テレフォニー ネットワークにおける次の 2 種類の冗長化を容易にします。

• データベースの複製

• デバイスのフェールオーバーとフェールバック

前述したように、データベースを冗長化するには、クラスタ内のすべてのサーバにわたるパブリッシャ データベースを複製する必要があります。サーバは、パブリッシャとの通信が失われた場合でも、パブリッシャ データベースのローカル コピーを使用して動作を継続できます。

Cisco CallManager のフェールオーバーとフェールバックのメカニズムにより、IP Phone やゲートウェイなどのデバイスのコール処理を冗長化できます。Cisco CallManager グループを使用して、必要なレベルの冗長性が得られるようにシステムを設定できます。グループは、3 台までの Cisco CallManager を優先順に並べたリストを示します。プライマリ（1 次）、セカンダリ（2 次）、ターシャリー（3 次）の順です。また、デバイス プールを設定して、クラスタ内の Cisco CallManager グループの 1 つに特定のデバイスを割り当てます。

通常の動作時には、各デバイスは、割り当てられたグループのプライマリ Cisco CallManager に登録されています。プライマリ Cisco CallManager が何らかの理由で故障した場合は、グループ内のデバイスはすべて、そのグループのセカンダリ Cisco CallManager にフェールオーバーします。セカンダリ Cisco CallManager も故障した場合は、デバイスは 3 次（ターシャリー） Cisco CallManager にフェールオーバーします。通常動作が再開されると、デバイスはプライマリ Cisco CallManager にフェールバックします。

Cisco CallManager グループとデバイス プールはさまざまな方法で設定でき、クラスタに必要なレベルの冗長性と負荷バランシングを提供できます。冗長性の設定に関する例と推奨事項についての詳細は、『Cisco IP Telephony Network Design Guide』を参照してください。

クラスタ間の通信

システムが非常に大規模な場合は、コールを処理する際の負荷に対応するために複数のクラスタを設定する必要があります。クラスタ間の通信は、クラスタ間トランクを介して行われます。大規模なシステムでは、複数クラスタ構成として、次の 3 種類からいずれかを使用しています。

• 大規模の単一キャンパス ネットワーク、または metropolitan-area network（MAN; メトロポリタンエリア ネットワーク）

• 分散型コール処理を行う複数サイト WAN（各サイトに 1 つまたは複数の Cisco CallManager を配置）

• 集中型コール処理を行う複数サイト WAN（リモート サイトに Cisco CallManager を配置しない）

MAN のクラスタ間トランクでは、通常、帯域幅に余裕があるので、コール アドミッション制御メカニズムを使用する必要はありません。分散型コール処理を行う複数サイトの WAN では、通常、ゲートキーパ テクノロジーを使用してコール アドミッション制御を行います。集中型コール処理を行う複数サイトの WAN では、Cisco CallManager のロケーション機能を使用してコール アドミッション制御を実現しています。

Cisco CallManager 機能はほとんどの場合、所属するクラスタ内で実行されます。次の機能は例外としてクラスタ間で実行されます。

• 基本コール設定

• G.711 コールおよび G.729 コール

• 複数の参加者による会議

• コール保留

• コール転送

• コール パーク

• 発信側回線 ID

クラスタ間の通信とコール アドミッション制御の詳細については、『 Cisco IP Telephony Network Design Guide 』を参照してください。

コール処理の負荷バランス

Cisco CallManagers をクラスタを構築するようにインストールした後は、クラスタ内の各 Cisco CallManager にデバイス（電話機やゲートウェイなど）を割り当てることによって、コール処理の負荷をシステム全体に分散できます。デバイスを割り当てるには、Cisco CallManager グループおよびデバイス プールを設定し、ユーザの意図する負荷バランシングのタイプに応じた方法でデバイス プールにデバイスを割り当てます。

Cisco CallManager のグループとデバイス プールは、任意の方法で配置できるデバイスの論理グループを表します。管理を容易にするには、グループまたはプール内のデバイスすべてが、簡単に識別できる共通の特性（ネットワーク上での物理的な場所など）を共有するようにします。

また、Cisco CallManager グループを使用して、グループ内のプライマリ Cisco CallManager の冗長化（バックアップ コール プロセッサ）を実現できます。Cisco CallManager グループとは、3 台までの Cisco CallManager サーバを優先順に並べたリストです。通常の動作時は、グループ内の最初の Cisco CallManager がプライマリとして、そのグループに割り当てられたデバイス プールとデバイスをすべて制御します。グループのプライマリ Cisco CallManager が故障した場合、プライマリ Cisco CallManager に登録されているデバイス プールとデバイスの制御は、リスト内の次にあるセカンダリ Cisco CallManager に移されます。

たとえば、クラスタ内に 3 台の Cisco CallManager があり、既存の Cisco IP Phone が 300 台あって、新しい電話機が後で追加されるたびに自動登録を行うように設定されている、単純化されたシステムを想定します。図 5-2では、このシステムのコール処理の負荷を分散させるために、どのように Cisco CallManager グループとデバイス プールを設定するかを例に示しています。

• この設定には、4 グループの Cisco CallManager が含まれます。
Cisco CallManager は 4 グループで構成：グループ G1 はデバイス プール DP1 に割り当てられ、グループ G2 はデバイス プール DP2 に、グループ G3 はデバイス プール DP3 に、グループ G4 はデバイス プール DP4 に割り当てられています。グループ G4 は、自動登録されるデバイスのデフォルト グループになります。

• CCM1 は、DP1 および DP2 のデバイスのプライマリ Cisco CallManager、DP3 の第 1 バックアップ、DP4 のデバイスの第 2 バックアップとして機能する。

• CCM2 は、DP3 および DP4 のデバイスのプライマリ Cisco CallManager、DP1 の第 1 バックアップ、DP4 のデバイスの第 2 バックアップとして機能する。

• CCM3 は、DP2 および DP4 のデバイスの第 1 バックアップ Cisco CallManager、DP1 と DP3 のデバイスの第 2 バックアップとして機能する。

図 5-2 に示しているシステムでは、クラスタ内の各 Cisco CallManager がシステム全体のコール処理の負荷を一部だけ処理することによって、システムのバランスを維持しています。また、図 5-2のシステムでは、プライマリ Cisco CallManager のコール処理の負荷を 2 つの冗長グループ間で分割することにより、冗長性のバランスを維持しています。たとえば CCM1 が故障した場合、デバイス プール DP1 のデバイスは CCM2 にフェールオーバーし、DP2 のデバイスは CCM3 にフェールオーバーします。

図 5-2 Cisco CallManager グループとデバイス プール

クラスタ設定チェックリスト

表 5-1 では、Cisco CallManager クラスタのインストールおよび設定に必要な手順の概要を示しています。

参考情報

関連トピック

• 『 Cisco CallManager アドミニストレーション ガイド 』の 「Cisco CallManager グループの設定」

• 『 Cisco CallManager アドミニストレーション ガイド 』の 「デバイス プールの設定」

• 『 Cisco CallManager アドミニストレーション ガイド 』の 「トランクの設定」

• 『 Cisco CallManager アドミニストレーション ガイド 』の 「ロケーションの設定」

参考資料

• 『Cisco IP Telephone Network Design Guide』

• 『Cisco CallManager Release 3.3 インストレーション ガイド』

• 『Cisco IP IVR Installation Guide』

• 『Cisco CallManager Serviceability System Guide』

• 『Cisco CallManager Serviceability アドミニストレーション ガイド』