Cisco IP テレフォニー ネットワーク デザイン ガイド

デバイスの重み

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

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

単一の 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 の冗長性グループを構成し、コール処理の冗長性を実現できます、 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 です。

–サーバ Ｄ は、登録したすべてのデバイスのバックアップ 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 です。

–サーバ Ｅ は、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 で行うことができます。

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

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

キャンパス ネットワークに対する要件が 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には、クラスタ間コールに対する帯域幅設定についての推奨事項が記載されています。

ゲートキーパーを使用すれば、送受信の両方にコール アドミッション制御が提供できます。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 つのクラスタ間の相互接続