Cisco Unity 設計ガイド Release 4.0
ネットワークとインフラストラクチャ に関する検討事項
ネットワークとインフラストラクチャに関する検討事項
発行日;2012/02/06 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 2MB) | フィードバック

目次

ネットワークとインフラストラクチャに関する検討事項

概要

インフラストラクチャの要件

Cisco Unity サーバの設置場所

ケーブルの配線と接続

ネットワーク リソースのアベイラビリティ

ネーム解決

ドメイン コントローラへのアクセスとアベイラビリティ

メッセージ ストア サーバのアベイラビリティ

メッセージ ストアのパフォーマンスとキャパシティに関する計画

ディレクトリ アクセスとアベイラビリティ

ゲートウェイへのアクセス

配置の要件

Cisco Unity サーバの規模の決定とスケーリング

ユーザの最大数

専用 Domino サーバまたは Exchange サーバ上のユーザ最大数

ボイスメール用記憶域のキャパシティ

ボイス ポートの数

サーバの配置とその要件

有効な配置モデルの選択

中央集約型

分散型

ハイブリッド型またはメッシュ型

ネットワーク トラフィックと帯域幅の要件

WAN 経由での Cisco Unity と Domino の接続

WAN 経由での Cisco Unity と Exchange の接続

WAN 経由での Cisco Unity と他のネットワーク リソースの接続

コーデック

Cisco Unity でのファイアウォールの使用方法

Cisco Unity サーバにインストールされるサード パーティ アプリケーションによる影響への対処

Cisco TAC へのアクセス

ネットワークとインフラストラクチャに関する検討事項

概要

この章では、Cisco Unity を配置して運用するための、インフラストラクチャに関する要件および検討事項について詳しく説明します。Cisco Unity のインストールが完了したら、Cisco Unity のパフォーマンスや機能に影響を及ぼすような方法でインフラストラクチャを変更しないように注意する必要があります。たとえば、ネットワークが輻輳すると、Cisco Unity ユーザがボイスメールを電話で確認するときの応答時間が長くなることがあり、ドメイン コントローラの動作が不安定になると、Cisco Unity が管理者やユーザをただちに認証できなくなることがあります。

次の項を参照してください。

「インフラストラクチャの要件」:物理 Cisco Unity サーバの設置場所、ケーブルの配線と接続、DNS や Windows インターネット ネーム サービス(WINS)などのネットワーク リソース、ドメイン コントローラ、およびディレクトリとメッセージ ストアに関する推奨事項を示します。

「配置の要件」:ネットワーク内での Cisco Unity サーバの配置、Cisco Unity サーバの規模とスケーリング、および配置モデルに関する推奨事項を示します。

インフラストラクチャの要件

Cisco Unity の場合、「インフラストラクチャ」とは、Cisco Unity が依存するサーバおよびゲートウェイを指します。Cisco Unity はインフラストラクチャおよびネットワーク リソースに深く依存するため、システムを設計する際は、Cisco Unity のインストール先となるインフラストラクチャについて入念に検討する必要があります。

次の項を参照してください。

「Cisco Unity サーバの設置場所」

「ケーブルの配線と接続」

「ネットワーク リソースのアベイラビリティ」

Cisco Unity サーバの設置場所

Cisco Unity は、他の基幹業務サーバを取り扱う場合と同様に、次のように取り扱う必要があります。

Cisco Unity サーバは、Cisco Unity サーバ、関連サーバ、および関連ハードウェアを収容できるラック収納スペースが確保され、セキュリティで保護されたサーバ室またはコンピュータ室に設置してください。たとえば、ボイス カード用の拡張シャーシ、Cisco Unity フェールオーバー用のセカンダリ サーバ、Cisco Unity Bridge サーバ、メッセージ ストア サーバ、ドメイン コントローラ/グローバル カタログ(GC/DC)サーバなどを収容できるラック収納スペースが必要になります。

Cisco Unity サーバへの適切な電源供給を確保してください。

Cisco Unity サーバに対する適切な換気および空調を確保してください。

ケーブルの配線と接続

Cisco Unity をネットワークに接続し、次のサーバにアクセスできるようにするには、適切なケーブル配線が必要です。

CallManager サーバまたは SIP プロキシ サーバ(Cisco Unity を IP 電話システムと連動させる場合)

メッセージ ストア サーバ(ユニファイド メッセージ コンフィギュレーションの場合、およびメッセージ ストアが別サーバにあるボイスメール コンフィギュレーションの場合)

セカンダリ サーバ(Cisco Unity フェールオーバーのコンフィギュレーションを行う場合)

Cisco Unity Bridge サーバ(Cisco Unity を Avaya ボイスメール システムに接続する場合)

ネットワーク バックアップ サーバおよびその他のネットワーク リソース(必要な場合)

Cisco Unity を回線交換電話システムと連動させる場合は、電話システムと Cisco Unity サーバ内のボイス カードの間をつなぐケーブル配線も必要です。シリアル連動の場合は、電話システムと Cisco Unity サーバの間をつなぐシリアル ケーブルが必要です。ボイス カードを拡張シャーシに装着する場合は、Cisco Unity サーバと拡張シャーシの間をつなぐケーブルが必要です。

ケーブル配線とハブまたはスイッチが、確実かつ完全に機能することを確認してください。ケーブル配線が適切でない場合、Cisco Unity とネットワーク(または電話システム)との間が断続的に不通になることがあります。この場合、トラブルシューティングは困難です。

ネットワーク リソースのアベイラビリティ

次のネットワーク リソースは、常時利用可能になっている必要があります。これらが利用不能になると、Cisco Unity の機能が損なわれます。

一般的な Windows 2000 ネットワークが使用するネーム解決ホスト。DNS ホストや WINS(Windows NT ネットワークが存在する場合)など。「ネーム解決」を参照してください。

Cisco Unity サービス アカウントを認証するドメイン コントローラ。「ドメイン コントローラへのアクセスとアベイラビリティ」を参照してください。

メッセージ ストア サーバおよびそれに対応するディレクトリ。Cisco Unity ユーザのホームとなる各メッセージ ストア サーバは、Cisco Unity にアクセスできる必要があります。メッセージ ストア サーバに対応するディレクトリも常時利用可能にし、Cisco Unity がローカルのデータとディレクトリを同期化できるようにする必要があります。「メッセージ ストア サーバのアベイラビリティ」「メッセージ ストアのパフォーマンスとキャパシティに関する計画」、および 「ディレクトリ アクセスとアベイラビリティ」を参照してください。

ネーム解決ホスト、ドメイン コントローラ、メッセージ ストア、ディレクトリなどの必須リソースへのアクセスを Cisco Unity に提供するゲートウェイすべて。「ゲートウェイへのアクセス」を参照してください。

ネーム解決

Cisco Unity は、ネットワークに接続しない場合を除いて、データをやり取りするサーバの名前を IP アドレスに解決し、相手のサーバを特定できる必要があります。たとえば、Cisco Unity は、外部の発信者からメッセージを受け取る場合、それを受信者のメールボックスがあるメッセージ ストア サーバに送信しますが、これは Cisco Unity がメッセージ ストア サーバを特定できた場合に限られます。ネーム解決は、次の場合にも使用されます。

ユーザが Cisco Unity 電話ユーザ インターフェイス(TUI)を使用して、メッセージを聞いたり、他のユーザにメッセージを送信したりする場合。

管理者が他のサーバから Cisco Unity システム管理にアクセスする場合。

ユーザが Cisco Unity Assistant または Cisco Unity Inbox にアクセスする場合。

DNS と WINS のいずれかまたは両方を Cisco Unity で使用するかどうかを決めるときは、Cisco Unity のアクセスするディレクトリおよびメッセージ ストアがネイティブに対応しているネーム解決を使用するようにします。また、次の推奨事項も考慮してください。

Cisco Unity サーバが Windows 2000 ドメイン内にある場合、Cisco Unity サーバでは、ダイナミック DNS(DDNS)か、ダイナミック アップデートをサポートするバージョンの DNS を使用する必要があります。Cisco Unity サーバ上にホスト ファイルを作成するだけでは不十分です。


) ダイナミック サーバ アップデートに対応し、Windows 2000 サーバを完全にサポートする DNS ホストを使用している場合は、既存の DNS ホストを使用するのが最適です。それ以外の場合は、Cisco Unity およびサポート インフラストラクチャが Windows 2000 DNS ホストを利用できるようにし、Cisco Unity をサポートするためのドメイン コントローラやメッセージ ストア サーバを含め、すべてのシステムが適切に動作するようにする必要があります。


メッセージ クライアントが使用するものと同じネーム解決を使用します。これは、通常は DNS ですが、DNS と WINS を両方とも使用する場合もあります。たとえば、Outlook クライアントが DNS を使用している場合は、Cisco Unity でも DNS を使用する必要があります。同様に、Notes クライアントが Notes ネーム解決を使用している場合は、Cisco Unity サーバにインストールされる Notes クライアントを通じて、Cisco Unity でも Notes ネーム解決を使用する必要があります。


) Cisco Unity 4.0(Domino 版)の初期リリースでは、Cisco Unity サーバを Windows 2000 ドメインにインストールする必要があるため、Notes ネーム解決に加えて Windows DDNS も使用する必要があります。


Cisco Unity を Windows 2000 ドメインにインストールする場合、DDNS を完全にはサポートしていないバージョンの DNS(Microsoft の Web サイトを参照)を使用しているときは、Cisco Unity をサポートするには、DDNS サーバをインストールする必要があります。Cisco Unity を Windows 2000 ドメインにインストールする場合は、Cisco Unity のサービス提供先に応じて、次の要件があります。

DUCS を通じて Domino Notes クライアントにサービスを提供する場合は、Cisco Unity サーバの属するドメインの Windows 2000 ドメイン コントローラ上に、DDNS が必要です。

Exchange 2000 メールボックスにサービスを提供する場合は、Cisco Unity とサポートする Exchange 2000 サーバからアクセスできる DDNS サーバが必要です。

Exchange 5.5 メールボックスにサービスを提供する場合は、Cisco Unity からアクセスできる DDNS サーバが必要です。Exchange 5.5 は DDNS を使用しませんが、DDNS はドメイン内でネーム解決とレコード ロケータ情報に使用されます。

Cisco Unity を Windows NT ドメインにインストールし、Exchange 5.5 メールボックスにサービスを提供する場合(Cisco Unity サーバを Windows NT ドメインにインストールできるのは、この状況のみ)には、Cisco Unity は DDNS を必要としませんが、WINS は必要であり、静的 DNS へのアクセスも必要になることがあります。

Windows DNS サービスを Cisco Unity サーバにインストールできるのは、次の場合に限られます。

Domino を使用していて、Cisco Unity サーバをユニファイド メッセージ コンフィギュレーションの Windows 2000 ドメイン コントローラとして設定し、DUCS を通じて Domino Notes クライアントにサービスを提供する場合。Cisco Unity サーバは、自身が属する Domino 専用のドメインをサポートします。

Exchange 2000 または Exchange 5.5 を使用していて、Cisco Unity をボイスメール コンフィギュレーションの Windows 2000 ドメイン コントローラとして設定し、ドメイン内の他のサーバは、すべて Cisco Unity のサポート用としてだけ使用される(たとえば、Cisco Unity フェールオーバー用のセカンダリ サーバ、メッセージ ストア サーバ、DC/GC サーバなど)場合。このコンフィギュレーションでは、Cisco Unity サーバは自身が属する Exchange 2000 専用のドメイン(新規 Cisco Unity 4.0 システムの場合や Cisco Unity 2.x または 3.x からアップグレードされたシステムの場合)または Exchange 5.5 専用のドメイン(Cisco Unity 2.x または 3.x からアップグレードされたシステムのみ)をサポートします。

Cisco Unity サーバが Windows 2000 ドメインのメンバー サーバになっていて、ユニファイド メッセージ コンフィギュレーションの Exchange 2000 または Exchange 5.5 にサービスを提供する場合は、Windows DNS サービスを Cisco Unity サーバにインストールしないでください。

ドメイン コントローラへのアクセスとアベイラビリティ

どのコンフィギュレーションを使用する場合でも、またどのメッセージ ストアを使用する場合でも、Cisco Unity は、サービス アカウントを認証する Windows ドメイン コントローラに アクセスできる必要があります。Exchange 2000 および Exchange 5.5 を使用する場合、Cisco Unity は、ユーザを認証するドメイン コントローラにもアクセスできる必要があります。Domino を使用する場合、ユーザは、Windows 認証または Domino 認証を使用して認証を受けることで、Cisco Unity に GUI ベースでアクセスできます。Domino 認証では、Windows ドメイン コントローラへのアクセスは必要ありません。

メッセージ ストア サーバのアベイラビリティ

Cisco Unity をインストールするときに、インストールの担当者は Cisco Unity の接続先となる Domino サーバまたは Exchange サーバを 1 台指定します。このサーバは、パートナー Domino サーバおよびパートナー Exchange サーバと呼ばれます。パートナー サーバは、Cisco Unity システム メールボックス(エイリアスは Unity_<サーバ名>)のホームです。このメールボックスは、外部の発信者からのボイスメールの発信元になります。パートナー サーバは、インストール中に作成されるデフォルトのメールボックスおよび同報グループ(Cisco Unity 同報リスト)のホームにもなります。Cisco Unity ユーザが、パートナー サーバ以外のサーバをホームにしている場合、外部の発信者からのメッセージはすべて、パートナー サーバを介して Cisco Unity ユーザのホーム サーバに渡されます。

ユーザがホームにしているパートナー サーバまたはメッセージ ストア サーバが利用不能になると、Cisco Unity の動作に次のような影響があります。

外部の発信者からのメッセージは、Cisco Unity サーバの Unity Message Repository(UMR)に格納されるので、サーバ ダウン中は UMR から取得できます。ただし、サーバ ダウン以前に受信されたボイスメールは参照できません。

発信しようとするユーザのホーム サーバがダウンしている場合、そのユーザからのメッセージは、すべて Cisco Unity サーバの UMR に格納され、受信者は、サーバ ダウン中は UMR からメッセージを取得できます。

メッセージ受信者のホーム サーバがダウンしている場合は、受信者のホーム サーバが再び利用可能になるまで、発信するユーザのホーム サーバがメッセージを保管します。受信者は、このメッセージを取得することはできません。

メッセージ ウェイティング インジケータおよびメッセージ到着通知も影響を受ける可能性があります。

パートナー サーバが再び利用可能になった後で、Cisco Unity の再起動が必要になることがあります。


ヒント Cisco Unity サーバをインストールする際、特に別サーバ上のメッセージ ストアにサービスを提供する Cisco Unity サーバをインストールする場合は、メッセージ ストアのアベイラビリティの重要性について、事前に十分理解しておいてください。


メッセージ ストアのパフォーマンスとキャパシティに関する計画

すべてのメッセージ ストアは、すべて常に利用可能な状態にしておく必要があり、さらに、各メッセージ ストアの応答時間を短くする(40 ms 以下にする)必要もあります。ユーザが電話でメッセージを再生または録音するときには、Cisco Unity はリアルタイムで処理を行います。このため、ユーザがデスクトップから Notes や Outlook を使用してメッセージを再生および録音するときには発生しない、メッセージ ストアの遅延が生じることがあります。クライアントがメッセージ ストア サーバにアクセスしてメッセージを取得するときに、すでに遅延が感じられる場合は、Cisco Unity のインストール前にこの遅延を解消しておく必要があります。

メッセージ ストア サーバをホームとするユーザごとに、Cisco Unity はメールボックスにログオンし、ユーザに代わってメールを送受信し、ユーザ メールボックスの内容をクエリーします。Cisco Unity がメールボックスにログオンしてメッセージを取得するときにかかる時間が長くなると、ユーザが電話を使用してログオンし、メッセージを聞くためにかかる時間も長くなります。

メッセージ ストア サーバが Domino である場合は IBM Lotus の要件を満たし、Exchange である場合は Microsoft の要件を満たす必要があります。要件には次のような項目が含まれますが、これらがすべてではありません。

サーバ 1 台あたりの最大ユーザ数

メモリ容量

プロセッサの種類と速度

ハード ディスクの速度

データベースとログ ファイルの格納場所

Cisco Unity は、ハード ディスクが遅い、メモリが十分にないなど、パフォーマンス上のボトルネックを抱えるメッセージ ストア サーバはサポートできません。たとえば、ハード ディスクが遅いことやトランザクション ログ専用ミラーの不足が原因となって、MAPI のレコーディング ログ トランザクションが遅延すると、トランザクション バッファが一定のレベルまで消去されるまで、MAPI アクセスが一時的に中断します。この中断により、Cisco Unity への電話アクセスで著しい遅延が発生する可能性があります。

Cisco Unity は、各ユーザ メールボックスのメッセージをフィルタリングして、メッセージ ウェイティング インジケータをオンにする必要のある新しいボイスメールを見つけます。フィルタリングは、小さなメールボックスを対象にするときの方が、大きなメールボックスを対象にするときよりもはるかに速くなります。このため、メールボックスのサイズが 100 MB を超えないようにすることを推奨します。

ディレクトリ アクセスとアベイラビリティ

ユニファイド メッセージ コンフィギュレーションでは、ディレクトリ アクセスとアベイラビリティが主な問題となります。

Cisco Unity はディレクトリに少量の情報を格納します。これは主にユーザ情報です。この情報は、Cisco Unity サーバ上の SQL Server(または MSDE)データベースにも格納されます。Cisco Unity サービスによって、ディレクトリ内のデータは SQL Server データベース内のデータと同期した状態に保たれます。Cisco Unity サーバが複数ある場合、各 Cisco Unity サーバ上の SQL Server データベースには、他の Cisco Unity サーバをホームとするユーザに関する少量の情報も保持されます。

Cisco Unity は、ディレクトリにアクセスする許可、およびディレクトリに変更を書き込む許可を必要とします。各 Cisco Unity サーバは、少なくとも次に示すアクセスを実行できる必要があります。これらを実行できない場合、Cisco Unity は適切に機能しません。Cisco Unity が次の処理を実行できる必要があります。

ディレクトリをクエリーして、SQL Server 2000(または MSDE)データベースにも保持されているデータに変更が加えられていないかどうかを確認する。Cisco Unity は、ディレクトリ階層内を最高レベルから検索するか、Cisco Unity ユーザがホームとする全ドメインを検索したときに、ディレクトリ内の全ユーザを見つけることができる必要があります。

Cisco Unity 自身のオブジェクト、および属性が Cisco Unity によって使用されるオブジェクトを対象として、読み取りおよび書き込みを実行する。

他の Cisco Unity サーバが使用するオブジェクトを読み取って、その情報を自身のグローバル テーブルに格納する。

Cisco Unity がサービスを提供する各オブジェクトに関連付けられている、特定の属性に対して書き込む。また、Cisco Unity がサービスを提供する各オブジェクトに関連付けられている、残りの属性を読み取ることもできる必要があります。

ディレクトリ内にある自身のロケーション ドキュメントまたはロケーション オブジェクトを作成し、これらに書き込み、これらに対するフル コントロール権限を持つ。これらのロケーション オブジェクトは、所定の Cisco Unity サーバに固有のものです。

Cisco Unity、および Exchange 2000 と Exchange 5.5 のディレクトリについては、Cisco.com
http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_technical_reference_list.html )から入手可能な『 White Paper: Cisco Unity 3.x Data and the Directory (With Microsoft Exchange) 』を参照してください。なお、このドキュメントは Cisco Unity 4.0 に対応する改訂(改訂箇所は少量)や、Cisco Unity(Domino 版)に対応する改訂は行われていません。

ディレクトリの応答時間が、平均で 150 ms を超えないようにする必要があります。超えている場合は、Cisco Unity のパフォーマンスに影響します。

Cisco Unity は、通常は専用ディレクトリ サーバを必要としません。Cisco Unity がサービスを提供しようとする既存のメッセージ ストア サーバに割り当てられているディレクトリ サーバで、Cisco Unity に十分対応できます。

ゲートウェイへのアクセス

Cisco Unity と依存先のネットワーク リソースがルータによって分離されている場合、たとえば、Cisco Unity と Domino サーバまたは Exchange サーバの間にルータが存在する場合は、ルータが利用不能になると、Cisco Unity が影響を受けます。ネットワーク インフラストラクチャ内に冗長パスを設定しておくと、この点が問題になる可能性は少なくなります。

また、ルータの処理速度が遅いかルータの負荷が大きく、さらにネットワーク リソースが Cisco Unity とは別のセグメントにある場合は、Cisco Unity への電話によるアクセスが影響を受けます。


ヒント Cisco Unity とネットワーク リソースがそれぞれ別のネットワーク セグメントにある場合は、Cisco Unity とそれらのリソース間のラウンドトリップの応答時間を、可能な限り短くします。
150 ms を超えないようにしてください。


配置の要件

Cisco Unity サーバを 1 台以上配置する場合は、かなり大きな計画を立てることになります。また、次の作業も含めて、テストや受け入れ準備が必要になることもあります。

既存のボイスメール システムを Cisco Unity に切り替えて、既存のシステムから移行する。

従来のボイスメール システムと Cisco Unity が、AMIS、Cisco Unity Bridge(Octel アナログ ネットワークの場合)、または VPIM を使用して通信するように設定し、既存のシステムから移行する。

新しいボイスメール インフラストラクチャまたはユニファイド メッセージ インフラストラクチャを構築して、Cisco Unity フェールオーバーなど、以前には使用していなかった機能を導入する。

Exchange 5.5 から Exchange 2000 に移行できるようにする。詳細については、「Exchange 5.5 から Exchange 2000 へのメッセージ ストアの移行」を参照してください。

これらの配置プロジェクトのいずれも、成功させるために必要な計画基準はそれぞれ異なります。これらの配置プロジェクトすべてに共通する計画基準としては、次のものがあります。

別のボイスメール システムを Cisco Unity で置き換える場合は、ユーザが各システムを操作する方法にどのような違いがあるかを考慮します。たとえば、ガイダンスで提供されるオプション(電話ユーザ インターフェイス(TUI))や、操作の実行に使用するキーが異なっている可能性があります。これらの相違点を緩和するため、Cisco Unity には、競合ボイスメール システムの通話内容とキー操作を模した、オプションのガイダンスが用意されています。競合システムを現在使用していて、ガイダンスとキー操作をそのまま使用する場合は、この代替のガイダンスを使用するように Cisco Unity を設定できます。

Cisco Unity の動作が、置き換えようとするボイスメール システムの動作とどの点で異なるかを把握しておく必要があります。たとえば、自動応対機能を現在使用しておらず、Cisco Unity でも同様にする場合は、インストーラで Cisco Unity のコンフィギュレーションが正しく行われるように、そのことを指定する必要があります。Cisco Unity の動作を変更する必要がある場合、たとえばオープニング グリーティングを変更する場合や、パーソナル グリーティングの中でオペレータ オプションに移動させる場合は、これらの変更をカットオーバー日前に実施して、テストしておく必要があります。

ユーザをどのように Cisco Unity に追加するかを検討します。メッセージ ストアからインポートする方法(Domino または Exchange)、テキスト ファイルからインポートする方法(Exchange のみ)、Cisco Unity システム管理を使用して入力する方法(Exchange のみ)があります。テキスト ファイルからインポートする場合や Cisco Unity システム管理を使用して入力する場合は、情報の格納場所も把握しておきます。ユーザを作成する場合は、カットオーバー前の計画とテストが不可欠になります。

インストールやサーバの数が多いほど、カットオーバー日前にユーザ登録作業を実施する必要性も大きくなります。多数のユーザが同時に登録を実行しようとすると、一部のユーザ(利用可能なボイス ポートの数まで)は Cisco Unity サーバにアクセスして登録を実行できますが、残りのユーザは通話中信号を受け取ります。

ユーザのこのような不便を防ぐには、システムを稼動させる数日前に、ユーザを小さなグループに分けて、そのグループに順次、登録用の番号の呼び出し方法と Cisco Unity への登録方法を通知します。

既存のボイスメール システムに特殊な音声/テキスト変換アプリケーションを設定してある場合は、カットオーバー前に、Cisco Unity で使用する同等製品を準備して設定する必要があります。Cisco Unity は音声/テキスト変換アプリケーションをサポートしており、それらを設計および設定するためのツールを提供しています。

Cisco Unity はグループ メールボックスをサポートしていませんが、コール ハンドラのグリーティングで、発信者に「鈴木さんの場合は 1 を、田中さんの場合は 2 を押してください」などと求めるように設定することにより、同等の機能を利用できます。

Cisco Unity 専用の、または Cisco Unity で使用されるサポート インフラストラクチャ(メッセージ ストア サーバなど)について、アベイラビリティと応答性能を評価する必要があります。そのためには、Cisco Unity がこれらのインフラストラクチャに依存していることや、これらの依存先外部インフラストラクチャへの接続が失われた場合に、Cisco Unity のパフォーマンスと機能が影響を受けることを利用者に説明して理解してもらいます。何らかの問題がある場合は、Cisco Unity のインストール前に解決する必要があります。Cisco Unity は、ネットワーク上の利用可能リソースを使用する方法が独特であるため、ネットワーク上に問題があればすぐに明らかになります。

Cisco Unity の設計をラボ試験を通じて決定し、検証するときは、負荷をシミュレートしたテストを実施し、アプリケーションのテスト計画を実行して、カットオーバー前に Cisco Unity の機能もテストする必要があります。

さらに、次の事項も考慮してください。

「Cisco Unity サーバの規模の決定とスケーリング」

「サーバの配置とその要件」

「有効な配置モデルの選択」

「ネットワーク トラフィックと帯域幅の要件」

「コーデック」

「Cisco Unity でのファイアウォールの使用方法」

「Cisco Unity サーバにインストールされるサード パーティ アプリケーションによる影響への対処」

「Cisco TAC へのアクセス」

Cisco Unity サーバの規模の決定とスケーリング

Cisco Unity サーバの規模を決定するときは、次の項のガイドラインに従ってください。

「ユーザの最大数」

「専用 Domino サーバまたは Exchange サーバ上のユーザ最大数」

「ボイスメール用記憶域のキャパシティ」

「ボイス ポートの数」

Cisco Unity の仕様を満たしているサーバのリストについては、Cisco.com ( http://cisco.com/en/US/products/sw/voicesw/ps2237/products_data_sheets_list.html )から入手可能な『 Cisco Unity Supported Platforms List 』を参照してください。

ユーザの最大数

Cisco Unity がサービスを提供するユーザの数は、当該サーバ モデルで許容されている最大数、およびライセンス取得済みユーザの最大数を超えないようにする必要があります。どちらかの最大数に達しないように、サーバを追加するか、Cisco Unity ライセンスをアップグレードします。許容ユーザ数の 5 ~ 10% を未使用のまま残しておくことを推奨します。たとえば、サーバが 4,000 ユーザに対応可能とされている場合は、現在のサーバがサービスを提供するユーザが 3,600 ~ 3,800 ユーザに達した時点で、サーバを交換するか、追加することを推奨します。

専用 Domino サーバまたは Exchange サーバ上のユーザ最大数

Domino サーバおよび Exchange サーバがサービスを提供する Domino ユーザおよび Exchange ユーザの数は、IBM Lotus および Microsoft が許容している最大数に達しないようにする必要があります。また、Cisco Unity で使用する Exchange メッセージ ストア サーバとしてシスコが認定したサーバには、Exchange ユーザの最大数が定められています。これらのサーバのユーザ数が、この最大数に達しないようにする必要があります。

さらに、インフォメーション ストアのディスク キャパシティを超えないように注意してください。たとえば、インフォメーション ストアが破損した場合に復旧できるようにするには、Exchange 2000 インフォメーション ストアの合計サイズが、インフォメーション ストアがインストールされているディスクのキャパシティの 50% を超えないようにすることを Microsoft では推奨しています。詳細については、Microsoft の Web サイトを参照してください。

ボイスメール用記憶域のキャパシティ

Cisco Unity システムのボイスメール コンフィギュレーションでは、各ユーザ用に必要なボイス記憶分数の合計に基づいて、サーバで必要となるキャパシティが決まります。一般的なハードウェア コンフィギュレーションでは、1 ユーザあたりのメッセージ量を 20 ~ 30 分として、許容するユーザ数を算出します。

Cisco Unity システムのユニファイド メッセージ コンフィギュレーションでは、各ユーザ用に必要なボイス記憶分数の合計に基づいて、サーバで必要となるキャパシティを決めることは不可能です。これは、メッセージ ストアには電子メール メッセージも格納され、さらにファックスが格納されることもあるためです。このため、確保するボイス記憶分数に対して必要となる記憶域の大きさを計算し、それを現在のメールボックス制限値に上乗せするようにします。

既存のボイスメール システムを Cisco Unity に置き換える場合は、ユーザが現在、平均で何分のボイスメールを保持しているかについて、既存システムから情報を得ることができます。この平均の分数を録音 1 分間あたりのサイズで乗算すると、1 ユーザのボイスメールに必要なディスク領域の平均量を求めることができます。録音 1 分間あたりのサイズは、Cisco Unity がメッセージの録音に使用するコーデックによって決まります。

ボイス ポートの数

必要となるボイス ポートの数とコンフィギュレーションを決定するには、既存のボイスメール システムがある場合は、その調査から始めます。この調査により、ボイスメールの受け取り、メッセージ ウェイティング インジケータのオン/オフ、およびメッセージの到着通知に必要なポートの数をおおむね把握できます。

Cisco Unity が備えていて、他のほとんどのシステムにはない機能の 1 つに、電話での録音と再生(TRaP; Telephone Record and Playback)があります。ユニファイド メッセージ コンフィギュレーションで TRaP を利用すると、ボイスメールに Notes または Outlook を使用しているユーザは、スピーカとマイクロフォンを使用する代わりに、電話機でボイスメールを再生および録音できます。これは特に、プライバシーが保護されない簡易間仕切りの小スペースでユーザが作業している場合に有益です。ただし、ユーザが TRaP を使用してメッセージを再生および録音する場合は、Cisco Unity サーバのポートが使用されます(ユーザがスピーカとマイクロフォンを使用してメッセージを再生および録音する場合には、ポートは一切使用されません)。ユーザに TRaP を使用してもらう場合は、必要なボイス ポートの合計数を計算するときに、このことを考慮する必要があります。

Cisco Unity フェールオーバーでは、プライマリ サーバとセカンダリ サーバで同数のポートを使用する必要があります。

既存のボイスメール システムのポート数が、72 を超えていることがあります。72 ポートは、Cisco Unity システムの現時点でのボイス ポート最大数です。この場合は、追加の Cisco Unity サーバを購入し、それらを Cisco Unity デジタル ネットワークを使用して接続します。

サーバの配置とその要件

システム設計時に重要な問題となるのは、Cisco Unity サーバの物理的な設置場所と論理的な配置です。Cisco Unity サーバは、この章で言及しているすべてのリソースを含むネットワーク上のリソースに対して、有効なアクセス権を保持する必要があります。次の推奨事項も考慮してください。

Cisco Unity を回線交換電話システムと連動させる場合は、Cisco Unity サーバが、電話システムの最大許容ケーブル長の範囲内にあることを確認します。Cisco Unity を Cisco CallManager と連動させる場合、サーバ間の距離は回線交換電話システムの場合ほど重要ではありません。

Cisco Unity は、Cisco Unity ユーザのホームとなるメッセージ ストア サーバに可能な限り近い場所にインストールします。Cisco Unity サーバとメッセージ ストア サーバを、同じネットワーク セグメント、同じ Windows 2000 サイト、および同じ Windows 2000 ドメイン(または Windows NT ドメイン)に配置することが望まれますが、このような構成が常に可能であるとは限りません。

Cisco Unity(Exchange 版)の場合、Cisco Unity サーバは、Exchange 2000 サーバが使用するものと同じ DC/GC サーバを使用する必要もあります。Cisco Unity がこれらのリソースと離れるほど、認証にかかる時間や、Cisco Unity データベースと Active Directory 間での変更の同期化にかかる時間が長くなります。

Cisco Unity がサーバ名を IP アドレスに解決できることを確認します。現在のネットワーク セグメントで解決を実行できない場合は、必要なリソースを追加するか、ネーム解決サービスにアクセスしやすいセグメントに Cisco Unity サーバを移動することを検討します。

Cisco Unity サーバは、企業全体に基幹業務用ボイスメール機能を提供するものであるため、ファイアウォールの外側には配置しないでください。Cisco Unity と依存先ネットワーク リソースは、ファイアウォールで分離しないでください。

1 台の Cisco Unity サーバで、ローカルとリモートのユーザにサービスを提供できます。たとえば、Cisco Unity を Cisco CallManager と連動させる場合や、Cisco Unity をボイスメール コンフィギュレーションにする場合です。ボイスメール コンフィギュレーションでは、メッセージ ストア サーバが Cisco Unity サーバと同じロケーションにある必要があります。Cisco Unity は複数のローカル メッセージ ストア サーバにサービスを提供できず、複数のリモート メッセージ ストア サーバに正しくサービスを提供することもできません。

有効な配置モデルの選択

Cisco Unity の配置を成功させるための鍵は、Cisco Unity の機能が失われたり、パフォーマンスが損われたりする原因となる可変要素をできる限り減らすことです。

Cisco Unity の主な配置モデルとしては、中央集約型と分散型の 2 つがあります。3 番目の配置モデルは、これらの 2 つの主要モデルのハイブリッド型です。大規模な配置には、2 つの主要モデルの要素が含まれていることがあります。

詳細については、次の項を参照してください。

「中央集約型」

「分散型」

「ハイブリッド型またはメッシュ型」

中央集約型

中央集約型配置モデルでは、Cisco Unity サーバが、電話システムおよび Cisco Unity ユーザのホームとなる全メッセージ ストア サーバと同じロケーションにあります。Cisco Unity サーバが 1 台の場合、および Cisco Unity フェールオーバー コンフィギュレーションの場合は、1 台のメッセージ ストア サーバにサービスを提供するか、または Domino クラスタや Exchange 2000 クラスタにサービスを提供するかにかかわらず、このモデルに該当します。ユニファイド メッセージ コンフィギュレーションでは、帯域幅の要件が満たされている場合に限り、オフサイトのユーザが存在することがあります。

分散型

分散型配置モデルの場合は、Cisco Unity が、メッセージ ストアと電話システムの一方または両方とは別のロケーションにあります。Cisco Unity が電話システムとは別のロケーションにある場合は、Cisco Unity サーバと電話システム間のケーブル長に関して、物理的な制約があります。Cisco Unity がメッセージ ストアとは別のロケーションにある場合は、帯域幅と応答時間に関して厳しい制約があり、このモデルの採用の可能性を制限しています。Cisco Unity をどの場所にインストールするかにかかわらず、Cisco Unity が依存するすべてのネットワーク リソースは、常に利用可能である必要があります。たとえば、Cisco Unity サーバと、メッセージ ストア サーバ、ドメイン コントローラ、またはグローバル カタログ サーバとの間の WAN リンクの速度が遅い場合や、メッセージ ストア サーバ間の WAN リンクの速度が遅い場合には、Cisco Unity が影響を受けます。

Cisco Unity での最適な分散型配置モデルは、Cisco Unity サーバと CallManager サーバをそれぞれ別のロケーションに配置し、メッセージ ストア サーバなどのリソースは Cisco Unity サーバと同じロケーションに配置することです。WAN リンクの帯域幅が十分にある場合は、比較的容易に Cisco Unity を CallManager とリモートで接続できます。ただし、この配置モデルでは、シングル ポイント障害の発生が大きな問題になります。WAN リンクや依存先ルータが利用不能になると、Cisco CallManager と Cisco Unity 間で実行される機能がただちに失われます。

ハイブリッド型またはメッシュ型

この配置モデルには、中央集約型と分散型の両モデルの要素が含まれています。たとえば、Cisco Unity の配置先となるインフラストラクチャで、広い大学構内にサービスを提供する大部分のサーバは中央のサイトに設置し、リモート ユーザに対してはリモートの Cisco Unity サーバがサービスを提供する場合です。比較的小規模のリモート サイトの場合は、中央サイトの Cisco Unity にアクセスするユーザも存在できます。

ネットワーク トラフィックと帯域幅の要件

Cisco Unity はインストール先のインフラストラクチャに依存します。このため、ネットワーク トラフィックの量と Cisco Unity が利用できる帯域幅の量について、システム設計時に十分に考慮する必要があります。

Cisco Unity は、接続先のメッセージ ストアが適切なタイミングで応答できることを前提としています。電話でメッセージを録音および再生するときに、望ましくない遅延が生じないようにするには、サービスの提供先となるメッセージ ストアのできる限り近くに Cisco Unity をインストールします。Cisco Unity は、接続状態の良好な同じ LAN、および同じ Domino ドメインまたは Windows 2000 ドメインにある必要があります。

エンド ユーザの遅延に対する不満を減らすには、Cisco Unity をサービス提供先のメッセージ ストアと接続する場合に関する次の要件を満たします。

Cisco Unity サーバとパートナー メッセージ ストア サーバの間には、100 Mbps 以上の全二重ネットワーク接続が必要です。

Exchange 2000 環境および Exchange 混在モード環境では、Cisco Unity サーバと、Cisco Unity ユーザのホームとなるメッセージ ストアにサービスを提供する DC/GC との間に、100 Mbps 以上の全二重ネットワーク接続が必要です。

Cisco Unity を Cisco CallManager と連動させる場合は、Cisco Unity サーバと Cisco CallManager サーバの間に、100 Mbps 以上の全二重ネットワーク接続が必要です。

Cisco CallManager に『IPT Design Guide』に従ったコンフィギュレーションが行われると、ユーザは、Cisco Unity と通話することでメッセージを再生および録音できるようになります。

Cisco Unity サーバが 2 枚の NIC を備えている場合、それらの NIC を全二重または半二重でのロード バランシングに使用することはできません。詳細については、「複数のネットワーク インターフェイス コントローラ(NIC)」を参照してください。

Exchange 2000 環境および Exchange 混在モード環境の場合、Cisco Unity サーバは、Cisco Unity ユーザのホームとなるメッセージ ストア サーバ、これらのメッセージ ストア サーバにサービスを提供する DC/GC、および正常な動作に必要なネットワーク リソースとはファイアウォールで分離しないでください。

Cisco Unity サーバをパートナー サーバ以外のメッセージ ストア サーバから WAN 接続で分離する場合は、2 台のサーバ間で 40 ms 以上の遅延が発生しないようにする必要があります。WAN 接続で分離すると、中央の Cisco Unity サーバがリモートの Domino サーバまたは Exchange サーバにサービスを提供できなくなりますが、電話でメッセージを再生および録音するときに、遅延が発生する可能性も大幅に小さくなります。

Cisco Unity フェールオーバー サーバは、別のネットワーク セグメントまたはサブネットに配置してもかまいません。ただし、両方のサーバを同じ Windows 2000 サイトに配置する必要があります。さらに、GC、DC、メッセージ ストア サーバ、および正常な動作に必要なその他のネットワーク リソースに両方のサーバが直接接続しアクセスできる必要があります。

IBM Lotus Domino Unified Communications Services (DUCS) for Cisco Unity または ViewMail for Microsoft Outlook を使用するユーザは、WAN 接続を経由する必要がある場合、電話ではメッセージを再生および録音できません。

Cisco Unity システム管理、Cisco Unity Assistant、および Cisco Unity Inbox を WAN 経由で使用することは、特に通常のボイス トラフィックに少量の帯域幅しか割り当てていない場合には、最小限にとどめる必要があります。

Cisco Unity を WAN 経由で SIP プロキシ サーバに接続する場合の帯域幅の要件は、まだ決定していません。

WAN 経由での Cisco Unity と Domino の接続

Cisco Unity ユーザが、WAN 経由で Cisco Unity サーバと接続されている Domino サーバをホームにしている場合は、パイプのサイズにかかわらず、40 ms 以上の遅延が発生しないようにする必要があります。このようなコンフィギュレーションは一般的ではなく、また推奨されません。Cisco Unity でサービスを提供するのは、通常、ローカルの Domino メッセージ ストアと 1 ~ 2 のリモート メッセージ ストアだけにします。Cisco Unity サーバ、Cisco Unity のパートナー Domino サーバ、および Cisco Unity が必要とするその他のネットワーク リソースは、すべて同じロケーションに配置する必要があります。

WAN 経由での Cisco Unity と Exchange の接続

Cisco Unity ユーザが、WAN 経由で Cisco Unity サーバと接続されている Exchange サーバをホームにしている場合は、パイプのサイズにかかわらず、40 ms 以上の遅延が発生しないようにする必要があります。このようなコンフィギュレーションは一般的ではなく、また推奨されません。通常、Cisco Unity でサービスを提供するのは、通常、ローカルの Exchange メッセージ ストアと 1 ~ 2 のリモート メッセージ ストアだけにします。Cisco Unity サーバ、Cisco Unity のパートナー Exchange サーバ、および Cisco Unity が必要とするその他のネットワーク リソースは、すべて同じロケーションに配置する必要があります。Cisco Unity サーバと、Cisco Unity ユーザのホームとなる Exchange サーバ間の帯域幅は、サービス対象のメールボックス 1 つあたり、少なくとも 24 Kbps 前後(アイドル期間含む)にします。

WAN 経由での Cisco Unity と他のネットワーク リソースの接続

Cisco Unity を DNS ホストなどの他のネットワーク リソースと接続する場合の帯域幅の要件を特定するには、このドキュメントで説明している最小遅延時間を使用してください。

コーデック

コーデックとは、コーダ/デコーダ アルゴリズム、つまり圧縮/圧縮解除アルゴリズムのことです。コーデックは、音声ファイルや映像ファイルなど、そのままではディスク領域を大量に消費する各種データのエンコードとデコード、つまり圧縮と圧縮解除に使用されます。Cisco Unity は、リアルタイムの通話コンテンツとファイル ベースの(WAV ファイル ボイスメールの)コンテンツをストリーミングするときに、オーディオ コーデックを使用します。

Cisco Unity は各種のコーデックをサポートしているため、ボイスメールの品質とボイスメール記憶域のキャパシティのバランスについては、システム管理者が決定できます。保存用のコーデックを選択するときは、メッセージ ストア サーバのハード ドライブのサイズとともに、Notes または Outlook を使用してメッセージをダウンロードするリモート ユーザのことも考慮する必要があります。 表 2-1 に、各種のコーデックを選択した場合のおおよそのメッセージ サイズを示します。

 

表 2-1 各種コーデックでのメッセージのサイズ

コーデック
メッセージのサイズ

G.711

480 KB/分

ADPCM 8K

480 KB/分

ADPCM 6K

360 KB/分

G.729a

60 KB/分

Cisco Unity は複数のコーデックをサポートできますが、システム コーデックとしては 1 つのコーデックだけをサポートします。ある形式で送信されたメッセージを別の形式にコード変換できます。ただし、コード変換は CPU を消費します。Cisco Unity サーバが複数ある場合、それらの間で使用されるコーデックが異なっていると、メッセージ再生中にコード変換が実行されるため、大量の CPU 時間が消費されます。

コーデックを選択するときは、次のガイドラインを参考にしてください。

帯域幅、ディスク領域、および Active Directory に対する潜在的影響に問題がある場合は G.729a コーデックを使用します。それ以外の場合は、最高の録音品質を得るために G.711 コーデックを使用します。

コーデックの選択が Active Directory に及ぼす影響については、Cisco.com
http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_technical_reference_list.html )から入手可能な『 White Paper: Active Directory Capacity Planning 』を参照してください。

特定の環境(従来の回線交換 PBX または CallManager を利用するボイスメール コンフィギュレーションやユニファイド メッセージ コンフィギュレーション)では、すべての Cisco Unity サーバが同じシステム コーデックを実行している必要があります。

ボイスの体感品質を重視する場合は、複数のコーデックを混在させると、品質の違いが気になることがあります。たとえば、ある Cisco Unity サーバでは G.729a を実行し、別のサーバでは G.711 を実行するなど、G.729a と G.711 が混在する場合です。

すべてのコード変換を Cisco Unity サーバで実行する場合は、コーデックを混在させないでください。コードを混在させると、Cisco Unity サーバのパフォーマンスが影響を受けます。

WAN 接続またはリモート IPT サイト経由で G.729a を使用する必要がある場合は、Transcoder(シスコ製ハードウェア)を使用して Cisco Unity のためのコード変換を実行します。Cisco Unity ではコード変換を一切実行しないでください。トランスコーダや、CCM サーバ用の G.729a WAN パーティションなど、コーデック用の他のシスコ製リソースを利用します。

Cisco Unity でのファイアウォールの使用方法

Cisco Unity はファイアウォールと共存できます。次のことに注意してください。

Cisco Unity は、ファイアウォールの外側には配置しないでください。配置した場合、Cisco Unity サーバのセキュリティを強化していても、インターネットからの望ましくない侵入にサーバが直面する可能性があります。

Cisco Unity は、パートナー Domino サーバやパートナー Exchange サーバ、および Cisco Unity ユーザのホームとなる Domino サーバや Exchange サーバとはファイアウォールで分離しないでください。

ファイアウォールを介して Cisco Unity システム管理、Cisco Unity Assistant、および Cisco Unity Inbox を使用する場合の最適な方法は、バーチャル プライベート ネットワークを使用することです。

特定のポートとプロトコルをフィルタリングしてファイアウォールを開放するように設定することは、非常に困難です。これは、Cisco Unity システム管理、Cisco Unity Assistant、および Cisco Unity Inbox がいずれも DCOM を使用しているためです。ファイアウォールを介して機能するように DCOM を設定するには、膨大な量の設定作業(いくつかのポートおよびポート範囲を開放するなど)とテストが必要になります。さらに、DCOM でサポートされていないため、ネットワーク アドレス変換(NAT)も使用できなくなります。

Cisco Unity は、HTTP 経由で DCOM を使用するように設定できます。このため、HTTP を開放することで、ファイアウォールを経由して Cisco Unity に直接アクセスできます。ただし、この設定により、Web サーバが直面するインターネットからの潜在的な脅威に Cisco Unity サーバが直面することになります。たとえば、サービス拒絶攻撃、ウィルス、機密情報のハッキングなどです。

Cisco Unity サーバにインストールされるサード パーティ アプリケーションによる影響への対処

ウィルス スキャン ソフトウェアやバックアップ ソフトウェアなどのサード パーティ アプリケーションを Cisco Unity サーバにインストールする場合は、通常の通話トラフィック負荷の下で、システムの CPU 使用率が 70% 未満になってからこれらのアプリケーションを起動することを推奨します。

Cisco TAC へのアクセス

シスコの Technical Assistance Center(TAC)からサポートを受けるには、サポート担当者が必要に応じてサーバにリモート アクセスできるように、Cisco Unity サーバに Windows ターミナル サービスとモデムをインストールしておく必要があります。このモデムは、電話回線に常に接続しておく必要はありません。Cisco TAC がアクセスをお願いした場合だけケーブルを繋いでください。