次の方法で共有


中央サイトの音声の復元の計画

 

トピックの最終更新日: 2011-03-23

世界中に複数のサイトを持つ企業はますます増えています。 どのエンタープライズ VoIP 復旧ソリューションでも、緊急サービス、ヘルプ デスクへのアクセス、および重要なビジネス タスクの遂行能力を中央サイトのサービス停止中に保つことが必要不可欠です。 中央サイトを利用できなくなった場合、以下の条件を満たすことが求められます。

  • ボイス フェールオーバーを備えることが必要です。

  • 通常、中央サイトのフロント エンド プールに登録しているユーザーは、別のフロント エンド プールに登録可能である必要があります。 それには、複数の DNS SRV レコードを作成して、それぞれが各中央サイトのディレクター プールまたはフロント エンド プールに解決されるようにします。 SRV レコードの優先順位と重みを調整することで、その中央サイトで処理されるユーザーが、他の SRV レコードのディレクター プールとフロント エンド プールよりも先に、対応するディレクターおよびフロント エンド プールを得るようにすることができます。

  • 他のサイトに存在するユーザーとの通話を、PSTN に再ルーティングする必要があります。

このトピックでは、中央サイトの音声復元をセキュリティ保護するための推奨ソリューションについて説明します。

アーキテクチャおよびトポロジ

中央サイトでの音声復元を計画する場合、Microsoft Lync Server 2010 Registrar がボイス フェールオーバーを実現する上で担う中心的な役割について基礎的な事柄を理解しておく必要があります。 Lync Server 2010 Registrar は、クライアント登録と認証を可能にする新しいサーバーの役割で、ルーティング サービスを提供します。 Standard Edition サーバー、エンタープライズ フロント エンド サーバー、ディレクター、または存続可能ブランチ アプライアンス上に他のコンポーネントと共に存在します。 レジストラー プールは、Lync Server プール上で稼働し、同じサイトにあるレジストラー サービスで構成されます。 プールは負荷分散する必要があります。 DNS 負荷分散をお勧めしますが、ハードウェア負荷分散でも十分です。 クライアントは、DNS SRV レコードで Lync Server プールを検出します。 クライアントがプールに接続すると、そのクライアントはロード バランサーにより、プール内のフロント エンド サーバーの 1 つにダイレクトされます。 次に、フロント エンド サーバーは、プール内で優先されるレジストラーにクライアントをリダイレクトします。

エンタープライズ VoIP が有効にされている各ユーザーは、プライマリ レジストラー プールになる特定のレジストラー プールに割り当てられます。 通常、数百、数千人のユーザーが特定のサイトで、1 つのプライマリ レジストラー プールを共有します。 プレゼンス、会議、またはフェールオーバーの実行を中央サイトに頼っているすべてのブランチ サイトのユーザーによる中央サイトのリソース消費に対応するには、各ブランチ サイトのユーザーを、中央サイトに登録されたユーザーとしてみなすことをお勧めします。 現在のところ、存続可能ブランチ アプライアンスに登録されたユーザーを含めた、ブランチ サイトのユーザー数には制限はありません。

中央サイトの障害時に音声を確実に復元するには、プライマリ レジストラー プールで、別のサイトに配置された単一のバックアップ レジストラー プールを指定しておく必要があります。 バックアップは、トポロジ ビルダーの復元設定を使用して構成できます。 2 つのサイト間の WAN リンクが復元できている場合は、プライマリ レジストラー プールを使用できなくなったユーザーは自動的にバックアップ レジストラー プールにダイレクトされます。

以下のステップでは、クライアントの検出と登録のプロセスについて説明します。

  1. クライアントは DNS SRV レコードで Lync Server を検出します。 Lync Server 2010 では、複数の FQDN を DNS SRV クエリに戻すように DNS SRV レコードを構成できます。 たとえば、企業 Contoso に 3 つの中央サイト (北米、欧州、およびアジア太平洋) があり、各中央サイトにディレクター プールがある場合、DNS SRV レコードは 3 つそれぞれの場所のディレクター プールの FQDN をポイントできます。 これらの場所のいずれかのディレクター プールが使用可能な限り、クライアントは最初のホップである Lync Server に接続できます。

    note注:
    ディレクター プールの使用はオプションです。 代わりに、フロント エンド プールを使用できます。
  2. ディレクター プールは、ユーザーのプライマリ レジストラー プールとバックアップ レジストラー プールの情報をクライアントに通知します。

  3. クライアントはまず、ユーザーのプライマリ レジストラー プールに接続を試行します。 プライマリ レジストラー プールが使用可能な場合、レジストラーは登録を受け入れます。 プライマリ レジストラー プールが使用できない場合、クライアントはバックアップ レジストラー プールへの接続を試行します。 バックアップ レジストラー プールが使用可能で、(指定したフェールオーバーの間隔でハートビートが送信されないことを検出して) ユーザーのプライマリ レジストラー プールが使用不可と判断した場合、バックアップ レジストラー プールはユーザーの登録を許可します。 バックアップ レジストラーは、プライマリ レジストラーが再び使用可能になったことを検出すると、フェールオーバー クライアントをプライマリ プールにリダイレクトします。

以下の図に、中央サイトの復元を確実にするための推奨トポロジを示します。 2 つのサイトは復元 WAN リンクで接続されています。 中央サイトが使用できなくなると、そのプールに割り当てられているユーザーは、バックアップ サイトにダイレクトされて登録が行われます。

中央サイトの音声復元を確保する推奨トポロジ

中央サイトの音声復元のトポロジ

要件と推奨事項

中央サイトで音声復元を実装するための要件と推奨事項は、たいていの組織で適しています。

  • プライマリおよびバックアップ レジストラー プールのあるサイトは、復元 WAN リンクで接続する必要があります。

  • 各中央サイトには、1 つ以上のレジストラーで構成されるレジストラー プールが存在する必要があります。

  • 各レジストラー プールは、DNS 負荷分散またはハードウェア負荷分散を使用して負荷分散する必要があります。

  • 各ユーザーは、Lync Server 管理シェルset-CsUser コマンドレットまたは Lync Server コントロール パネルを使用して、プライマリ レジストラー プールに割り当てる必要があります。

  • プライマリ レジストラー プールは、別の中央サイトに配置されたバックアップ レジストラー プールを 1 つ持つ必要があります。

  • プライマリ レジストラー プールは、バックアップ レジストラー プールにフェールオーバーされるように構成する必要があります。 プライマリ レジストラーは既定により、300 秒の間隔が経過した後でバックアップ レジストラー プールにフェールオーバーされるように設定されています。 この間隔は、Lync Server トポロジ ビルダーを使用して変更できます。

  • 「計画」のドキュメントの「フェールオーバー ルートの構成」の説明に従ってフェールオーバー ルートを構成してください。 ルートを構成する際、プライマリ ルートで指定されたゲートウェイとは別のサイトにあるゲートウェイを指定します。

  • 中央サイトにプライマリ管理サーバーがあり、サイトが長期間ダウンする可能性が高い場合、管理ツールをバックアップ サイトに再インストールする必要があります。そうしないと、どの管理設定も変更できなくなります。

依存関係

Lync Server は、音声復元を確実に実現するために、以下のインフラストラクチャとソフトウェア コンポーネントを使用しています。

コンポーネント

機能

DNS

SRV レコードおよび A レコードを解決して、サーバー間の接続およびサーバーとクライアント間の接続を確立

Exchange および Exchange Web サービス (EWS)

コンタクト ストレージ、予定表データ

Exchange ユニファイド メッセージングおよび Exchange Web サービス

通話ログ、ボイス メール一覧、ボイス メール

DHCP オプション 120

DNS SRV が使用できない場合、クライアントは DHCP オプション 120 を使用してレジストラーを検出しようとします。 この動作を機能させるには、DHCP サーバーを構成するか、Lync Server 2010 DHCP を有効にする必要があります。 詳細については、「ブランチ サイトの復元要件」のセクションにある「Hardware and Software Requirements for Branch-Site Resiliency (ブランチサイトの復元に関するハードウェアおよびソフトウェアの要件)」を参照してください。

存続可能な音声機能

前述の要件と推奨事項が実装されている場合は、以下の音声機能がバックアップ レジストラー プールによって提供されます。

  • PSTN 通話の発信

  • テレフォニー サービス プロバイダーがバックアップ サイトへのフェールオーバー機能をサポートしている場合は、PSTN 通話の着信

  • 同じサイトおよび 2 つの異なるサイト間でのユーザー同士のエンタプライズ通話

  • 通話の保留、取得、転送などの基本的な通話処理

  • 2 者間のインスタント メッセージングおよび同じサイトでのユーザー間のオーディオとビデオの共有

  • 着信の転送、エンドポイントの同時呼び出し、通話委任、およびチーム通話サービス。ただし、通話委任の両者または全チーム メンバーが同じサイトで構成されている場合のみ。

  • 既存の電話およびクライアントは動作し続けます。

  • 通話詳細記録 (CDR)

  • 認証と承認

プライマリ中央サイトがサービス停止になったときに以下の音声機能が動作するかどうかは、その構成方法によります。

  • ボイス メールの預かりと取得

    プライマリ中央サイトがサービス停止になっているときに Exchange UM を使用可能にするには、以下のいずれかを実行する必要があります。

    • 中央サイトの Exchange UM サーバーが別のサイトのバックアップ Exchange UM サーバーをポイントするように、DNS SRV レコードを変更します。

    • 中央サイトとバックアップ サイトの両方の UM サーバーを含めるように各ユーザーの Exchange UM ダイヤル プランを構成します。ただし、バックアップ UM サーバーは無効に指定します。 プライマリ サイトが使用不可になった場合、Exchange の管理者はバックアップ サイトの UM サーバーを有効とマークする必要があります。

    前述のソリューションのいずれも使用できない場合、中央サイトが使用不可になると、Exchange UM は使用できなくなります。

  • すべての種類の会議

    バックアップ サイトにフェールオーバーしたユーザーは、プールを使用できる開催者によって作成またはホストされる会議に出席できますが、使用不可になった自身のプライマリ プールで会議を作成またはホストすることはできません。 他のユーザーも、そのユーザーのプライマリ プールでホストされる会議に参加することはできません。

以下の音声機能は、プライマリ中央サイトが停止しているときには動作しません。

  • 会議自動アテンダント

  • プレゼンスおよび DND ベースのルーティング

  • 着信の転送設定の更新

  • 応答グループ サービスとコール パーク

  • 新しい電話とクライアントのプロビジョニング

関連項目

その他のリソース

ブランチ サイト VoIP の復元の計画