Comments
Description
Transcript
ネットワークとインフラストラクチャ に関する検討事項
C H A P T E R 2 ネットワークとインフラストラクチャ に関する検討事項 概要 この章では、Cisco Unity を配置して運用するための、インフラストラクチャに関する要件および検 討事項について詳しく説明します。Cisco Unity のインストールが完了したら、Cisco Unity のパ フォーマンスや機能に影響を及ぼすような方法でインフラストラクチャを変更しないように注意 する必要があります。たとえば、ネットワークが輻輳すると、Cisco Unity ユーザがボイスメールを 電話で確認するときの応答時間が長くなることがあり、ドメイン コントローラの動作が不安定にな ると、Cisco Unity が管理者やユーザをただちに認証できなくなることがあります。 次の項を参照してください。 • インフラストラクチャの要件（P.2-2） ：物理 Cisco Unity サーバの設置場所、ケーブルの配線と 接続、DNS や Windows インターネット ネーム サービス（WINS）などのネットワーク リソー ス、ドメイン コントローラ、およびディレクトリとメッセージ ストアに関する推奨事項を示 します。 • 配置の要件（P.2-8）：ネットワーク内での Cisco Unity サーバの配置、Cisco Unity サーバの規模 とスケーリング、および配置モデルに関する推奨事項を示します。 Cisco Unity 設計ガイド OL-4011-01-J 2-1 第2章 ネットワークとインフラストラクチャに関する検討事項 インフラストラクチャの要件 インフラストラクチャの要件 Cisco Unity の場合、 「インフラストラクチャ」とは、Cisco Unity が依存するサーバおよびゲートウェ イを指します。Cisco Unity はインフラストラクチャおよびネットワーク リソースに深く依存するた め、システムを設計する際は、Cisco Unity のインストール先となるインフラストラクチャについて 入念に検討する必要があります。 次の項を参照してください。 • Cisco Unity サーバの設置場所（P.2-2） • ケーブルの配線と接続（P.2-2） • ネットワーク リソースのアベイラビリティ（P.2-3） 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 設計ガイド 2-2 OL-4011-01-J 第2章 ネットワークとインフラストラクチャに関する検討事項 インフラストラクチャの要件 ネットワーク リソースのアベイラビリティ 次のネットワーク リソースは、常時利用可能になっている必要があります。これらが利用不能にな ると、Cisco Unity の機能が損なわれます。 • 一般的な Windows 2000 ネットワークが使用するネーム解決ホスト。DNS ホストや WINS （Windows NT ネットワークが存在する場合）など。P.2-3 の「ネーム解決」を参照してください。 • Cisco Unity サービス アカウントを認証するドメイン コントローラ。P.2-4 の「ドメイン コント ローラへのアクセスとアベイラビリティ」を参照してください。 • メッセージ ストア サーバおよびそれに対応するディレクトリ。Cisco Unity ユーザのホームと なる各メッセージ ストア サーバは、Cisco Unity にアクセスできる必要があります。メッセー ジ ストア サーバに対応するディレクトリも常時利用可能にし、Cisco Unity がローカルのデー タとディレクトリを同期化できるようにする必要があります。P.2-5 の「メッセージ ストア サー バのアベイラビリティ」 、P.2-5 の「メッセージ ストアのパフォーマンスとキャパシティに関す る計画」、および P.2-6 の「ディレクトリ アクセスとアベイラビリティ」を参照してください。 • ネーム解決ホスト、ドメイン コントローラ、メッセージ ストア、ディレクトリなどの必須リ ソースへのアクセスを Cisco Unity に提供するゲートウェイすべて。P.2-7 の「ゲートウェイへ のアクセス」を参照してください。 ネーム解決 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 設計ガイド OL-4011-01-J 2-3 第2章 ネットワークとインフラストラクチャに関する検討事項 インフラストラクチャの要件 （注） 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 設計ガイド 2-4 OL-4011-01-J 第2章 ネットワークとインフラストラクチャに関する検討事項 インフラストラクチャの要件 メッセージ ストア サーバのアベイラビリティ 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 の要件を満たす必要があります。要件には次のような項目が含まれますが、これら がすべてではありません。 Cisco Unity 設計ガイド OL-4011-01-J 2-5 第2章 ネットワークとインフラストラクチャに関する検討事項 インフラストラクチャの要件 • サーバ 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 設計ガイド 2-6 OL-4011-01-J 第2章 ネットワークとインフラストラクチャに関する検討事項 インフラストラクチャの要件 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 設計ガイド OL-4011-01-J 2-7 第2章 ネットワークとインフラストラクチャに関する検討事項 配置の要件 配置の要件 Cisco Unity サーバを 1 台以上配置する場合は、かなり大きな計画を立てることになります。また、 次の作業も含めて、テストや受け入れ準備が必要になることもあります。 • 既存のボイスメール システムを Cisco Unity に切り替えて、既存のシステムから移行する。 • 従来のボイスメール システムと Cisco Unity が、AMIS、Cisco Unity Bridge（Octel アナログ ネッ トワークの場合）、または VPIM を使用して通信するように設定し、既存のシステムから移行 する。 • 新しいボイスメール インフラストラクチャまたはユニファイド メッセージ インフラストラク チャを構築して、Cisco Unity フェールオーバーなど、以前には使用していなかった機能を導入 する。 • Exchange 5.5 から Exchange 2000 に移行できるようにする。詳細については、第 6 章 「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 設計ガイド 2-8 OL-4011-01-J 第2章 ネットワークとインフラストラクチャに関する検討事項 配置の要件 存先外部インフラストラクチャへの接続が失われた場合に、Cisco Unity のパフォーマンスと機 能が影響を受けることを利用者に説明して理解してもらいます。何らかの問題がある場合は、 Cisco Unity のインストール前に解決する必要があります。Cisco Unity は、ネットワーク上の利 用可能リソースを使用する方法が独特であるため、ネットワーク上に問題があればすぐに明ら かになります。 Cisco Unity の設計をラボ試験を通じて決定し、検証するときは、負荷をシミュレートしたテストを 実施し、アプリケーションのテスト計画を実行して、カットオーバー前に Cisco Unity の機能もテス トする必要があります。 さらに、次の事項も考慮してください。 • Cisco Unity サーバの規模の決定とスケーリング（P.2-9） • サーバの配置とその要件（P.2-11） • 有効な配置モデルの選択（P.2-11） • ネットワーク トラフィックと帯域幅の要件（P.2-12） • コーデック（P.2-14） • Cisco Unity でのファイアウォールの使用方法（P.2-15） • Cisco Unity サーバにインストールされるサード パーティ アプリケーションによる影響への対 処（P.2-15） • Cisco TAC へのアクセス（P.2-15） Cisco Unity サーバの規模の決定とスケーリング Cisco Unity サーバの規模を決定するときは、次の項のガイドラインに従ってください。 • ユーザの最大数（P.2-9） • 専用 Domino サーバまたは Exchange サーバ上のユーザ最大数（P.2-9） • ボイスメール用記憶域のキャパシティ（P.2-10） • ボイス ポートの数（P.2-10） 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 ユーザの最大数が定められています。これらのサーバのユーザ数が、この最大数に達 しないようにする必要があります。 Cisco Unity 設計ガイド OL-4011-01-J 2-9 第2章 ネットワークとインフラストラクチャに関する検討事項 配置の要件 さらに、インフォメーション ストアのディスク キャパシティを超えないように注意してください。 たとえば、インフォメーション ストアが破損した場合に復旧できるようにするには、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 設計ガイド 2-10 OL-4011-01-J 第2章 ネットワークとインフラストラクチャに関する検討事項 配置の要件 サーバの配置とその要件 システム設計時に重要な問題となるのは、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 つの主要モデルの 要素が含まれていることがあります。 詳細については、次の項を参照してください。 • 中央集約型（P.2-11） • 分散型（P.2-12） • ハイブリッド型またはメッシュ型（P.2-12） 中央集約型 中央集約型配置モデルでは、Cisco Unity サーバが、電話システムおよび Cisco Unity ユーザのホーム となる全メッセージ ストア サーバと同じロケーションにあります。Cisco Unity サーバが 1 台の場 合、および Cisco Unity フェールオーバー コンフィギュレーションの場合は、1 台のメッセージ ス トア サーバにサービスを提供するか、または Domino クラスタや Exchange 2000 クラスタにサービ Cisco Unity 設計ガイド OL-4011-01-J 2-11 第2章 ネットワークとインフラストラクチャに関する検討事項 配置の要件 スを提供するかにかかわらず、このモデルに該当します。ユニファイド メッセージ コンフィギュ レーションでは、帯域幅の要件が満たされている場合に限り、オフサイトのユーザが存在すること があります。 分散型 分散型配置モデルの場合は、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 Unity 設計ガイド 2-12 OL-4011-01-J 第2章 ネットワークとインフラストラクチャに関する検討事項 配置の要件 Cisco CallManager に『IPT Design Guide』に従ったコンフィギュレーションが行われると、ユー ザは、Cisco Unity と通話することでメッセージを再生および録音できるようになります。 • Cisco Unity サーバが 2 枚の NIC を備えている場合、それらの NIC を全二重または半二重での ロード バランシングに使用することはできません。詳細については、P.8-3 の「複数のネット ワーク インターフェイス コントローラ（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 前後（アイ ドル期間含む）にします。 Cisco Unity 設計ガイド OL-4011-01-J 2-13 第2章 ネットワークとインフラストラクチャに関する検討事項 配置の要件 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 設計ガイド 2-14 OL-4011-01-J 第2章 ネットワークとインフラストラクチャに関する検討事項 配置の要件 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 がアクセスをお願いした場合だけケーブルを繋いでください。 Cisco Unity 設計ガイド OL-4011-01-J 2-15 第2章 ネットワークとインフラストラクチャに関する検討事項 配置の要件 Cisco Unity 設計ガイド 2-16 OL-4011-01-J