次の方法で共有


大都市サイト復元トポロジのサーバー

 

トピックの最終更新日: 2011-10-18

大都市サイト復元トポロジには、次のようなさまざまな種類のサーバーの役割を含めることができます。

フロント エンド プール

このプールでは、すべての Lync Server ユーザーがホストされます。北と南の各サイトには、まったく同じように構成された 4 台のフロント エンド サーバーがあります。バックエンド データベースは、Windows Server 2008 R2 フェールオーバー クラスタリング サービス上で実行される、地理的に分散したアクティブ/パッシブ モードの 2 つの SQL Server 2008 クラスター ノードとして展開されます。2 つのバックエンド データベース サーバー間では同期データ レプリケーションを行う必要があります。

使用したテスト トポロジでは、仲介サーバーをフロント エンド サーバーと併置しました。スタンドアロンの仲介サーバーを使用するトポロジもサポートされています。

テスト トポロジでは、DNS 負荷分散を使用してプール内の SIP トラフィックを分散し、HTTP トラフィック用にハードウェア ロード バランサーを展開しました。

サイトの復元では、ハードウェア ロード バランサーのみを使用してすべての種類のトラフィックを分散するトポロジもサポートされています。

音声ビデオ会議プール

各サイトに 2 台ずつ、4 台の音声ビデオ会議サーバーを使用して、単一の音声ビデオ会議プールを展開しました。

ディレクター プール

各サイトに 2 つずつ、4 つのディレクターを使用して、単一のディレクター プールを展開しました。

エッジ プール

エッジ サーバーでは、すべてのサービス (アクセス エッジ サービス、音声ビデオ会議エッジ サービス、および Web 会議エッジ サービス) を実行しましたが、テストはリモート ユーザーのシナリオでのみ行いました。フェデレーションおよびパブリック IM 接続は、このドキュメントの対象範囲外です。

エッジ プールには DNS ロード バランシングを使用することをお勧めしますが、ハードウェア ロード バランサーの使用もサポートされています。内部エッジ インターフェイスと外部エッジ インターフェイスでは、同じ種類のロード バランシングを使用する必要があります。1 つのエッジ インターフェイスで DNS ロード バランシングを使用し、もう 1 つのエッジ インターフェイスでロード バランサー機器を使用することはできません。エッジ プールにハードウェア ロード バランサーを使用する場合は、一方のサイトのハードウェア ロード バランサーがプライマリ ロード バランサーとなり、該当するエッジ サービスの仮想 IP アドレスを使用して要求に応答します。プライマリ ロード バランサーが使用できない状態になると、もう一方のサイトのセカンダリ ハードウェア ロード バランサーが処理を引き継ぎます。各サイトには独自の IP サブネットが割り当てられます。境界ネットワークは北サイトと南サイトの間で拡張されませんでした。

グループ チャット サーバー

各サイトでチャネル サービスと参照サービスの両方をホストしていますが、これらのサービスは一度にどちらか一方のサイトでのみアクティブにすることができます。もう一方のサイトでは、チャネル サービスと参照サービスを停止するか無効にする必要があります。サイトのフェールオーバーが発生した場合は、手動で操作を行って、フェールオーバー サイトでこれらのサービスを開始する必要があります。

各サイトではコンプライアンス サーバーもホストしていますが、一度にアクティブにできるサーバーはどちらか 1 つだけです。サイトのフェールオーバーとフェールバックが発生した場合は、手動で操作を行ってサービスを復元する必要があります。詳細については、「操作」のドキュメントの「Compliance Server のバックアップ」を参照してください。

グループ チャット バックエンド データベースは、Windows Server 2008 R2 フェールオーバー クラスタリング上で実行される、地理的に分散したアクティブ/パッシブ モードの 2 つの SQL Server 2008 クラスター ノードとして展開しました。2 つのバックエンド データベース サーバー間のデータ レプリケーションは同期である必要があります。グループ チャットとコンプライアンス データの両方に 1 つのデータベース インスタンスを使用します。

監視サーバーおよびアーカイブ サーバー

監視サーバーとアーカイブ サーバーには、ホット スタンバイ展開を使用することをお勧めします。各サイトにサーバーを 1 台ずつ配置して、これらのサーバーの役割を両方のサイトに展開します。一方のサーバーのみをアクティブにし、展開内のプールをすべてのそのアクティブなサーバーに関連付けます。もう一方のサーバーも展開してインストールしますが、プールには関連付けません。

プライマリ サーバーが使用できない状態になった場合は、トポロジ ビルダーを使用してスタンバイ サーバーにプールを手動で関連付けます。これにより、スタンバイ サーバーがプライマリ サーバーになります。

ファイル サーバー クラスター

ファイル サーバーは、Windows Server 2008 R2 フェールオーバー クラスタリングを使用して、地理的に分散した 2 つのノードのクラスター リソースとして展開しました。同期データ レプリケーションが必要でした。ファイル共有を必要とし、2 つのサイトに分かれている Lync Server の機能では、このファイル共有クラスターを使用する必要があります。たとえば、次のような機能が挙げられます。

  • 会議コンテンツの場所

  • 会議メタデータの場所

  • 会議アーカイブの場所

  • アドレス帳サーバーのファイル ストア

  • アプリケーション データ ストア

  • クライアント更新データ ストア

  • グループ チャット コンプライアンス ファイル リポジトリ

  • グループ チャット アップロード ファイルの場所

リバース プロキシ

リバース プロキシ サーバーは各サイトに展開されます。テスト トポロジでは、これらのサーバーで Microsoft Forefront Threat Management Gateway を実行しました。Microsoft Forefront Threat Management Gateway を実行する各サーバーを互いに独立して実行しました。ハードウェア ロード バランサーを各サイトに展開しました。