複数のデータ センターを持つ大規模な組織の Lync Server 2013 向けの関連トポロジ

トピック最終更新日時: 2012-10-22

複数のデータ センターをサポートする大規模な組織向けの関連トポロジは、規模にかかわらず、複数の中央サイトを備えた組織に適しています。 次の図のトポロジは、中央サイト A で 20,000 ユーザー、中央サイト B で 20,000 ユーザー、中央サイト C とブランチ サイトで合計 10,000 ユーザーをサポートする、50,000 ユーザーの組織向けのものです。 この図に示されているタイプのトポロジで、任意の数のユーザーを持つ組織に対応できます。

このトポロジでは、フロントエンド サーバーのプールによって提供される高可用性に加えて、ディザスター リカバリーのサポートが追加されます。 中央サイト A と B のフロントエンド プールはペアになります。 一方のプールがダウンした場合は、影響を受けるユーザーのサービスを、影響を受けないサイトにあるペアのプールに切り替えることができます。

このトポロジを複数の図で示します。最初は概要を示し、次に中央サイトの詳細を示します。

複数のデータ センターを持つ大規模な組織向けの関連トポロジの概要

大規模な組織向けの関連トポロジ: 中央サイト A の詳細表示

大規模な組織向けの関連トポロジ: 中央サイト B の詳細表示

大規模な組織向けの関連トポロジ: 中央サイト C の詳細表示

• フロント エンド プールは、ディザスター リカバリーを有効にするためにペアリングされます。   サイト A とサイト B のフロント エンド プールは、ディザスター リカバリーのサポートを提供するために、互いにペアになります。 一方のサイトのプールで障害が発生した場合、管理者はそのサイトのユーザーを他のサイトのペアのフロントエンド プールにフェールオーバーできます。ユーザーのサービス中断は最小限です。 Each of these two Front End pools has six servers, which is enough for all 40,000 users in both pools in case of failover. 詳細については、「 Lync Server 2013 での高可用性とディザスター リカバリーの計画」を参照してください。

• バックエンド サーバーがミラー化されている 基本的なユーザー機能の高可用性を高めるために、組織は、各フロントエンド プールにミラー化されたバック エンド サーバーのペアを展開しました。 これは省略可能なトポロジであり、代わりに 1 つのバックエンド サーバーをデプロイすることもできます。

• ブランチ サイトで Standard Edition サーバーを使用する。   This organization considers Site C as a branch site because it has only 600 employees. However, the users there have many A/V conferences among themselves. Lync Server にブランチ サイトとして展開された場合、これらの会議のメディアは、フロントエンド サーバーが展開されている中央サイトとの間で、ワイド エリア ネットワーク (WAN) 全体で実行されます。 この潜在的な帯域幅負荷を回避するために、このサイトには Standard Edition サーバーのペアがインストールされており、これらの会議がホストされます。 また、Standard Edition サーバーはそこにインストールされているため、Lync Server は定義上、それを中央サイトと見なし、トポロジ ビルダーや計画ツールではそのように扱われます。

  ここでは、1 台の Standard Edition サーバーだけで十分ですが、1 台のサーバーがダウンした場合に高可用性を提供するために、組織は 2 つをデプロイしてペアにしました。

  サイト C は中央サイトと見なされますが、このサイトにエッジ サーバーを展開する必要はありません。 この例では、サイト C では、サイト A に展開されているエッジ サーバーを使用します。

• 監視とアーカイブ この組織は、監視とアーカイブの両方を展開しました。 監視またはアーカイブを展開すると、すべてのフロントエンド サーバーで実行されます。 これらの機能のデータベースは、バックエンド データベースと併置することも、別のサーバーに配置することもできます。 この組織は、これらのデータベースを、セントラル サイト B のバックエンド サーバーとは別のサーバーに配置しています。ここで示すデータベースは、すべてのサイトのフロントエンド サーバーから監視データとアーカイブ データを受け取ります。

• ブランチ サイト展開のオプション。   この組織には実際には 50 を超えるブランチ サイトがあり、そのうちの 3 つだけが詳細な図に示されています。 ブランチ サイト 1 とブランチ 3 には、中央サイトへの回復性の高い WAN リンクがないため、中央サイトへの WAN リンクがダウンした場合に電話サービスを提供するために、存続可能なブランチ アプライアンスが展開されています。 ただし、ブランチ サイト 2 には回復性の高い WAN リンクがあるため、必要なのは公衆交換電話ネットワーク (PSTN) ゲートウェイのみです。 そこに展開された PSTN ゲートウェイはメディア バイパスをサポートしているため、ブランチ サイト B では仲介サーバーは必要ありません。ブランチ サイトに何をインストールするかを決定する方法の詳細については、「計画」のドキュメントの「Lync Server 2013 でのエンタープライズ VoIP回復性の計画」を参照してください。

• SIP トランキングと仲介サーバー。   中央サイト B では、仲介サーバーはフロントエンド サーバーと併置されません。 これは、SIP トランキングを使用するサイトには、スタンドアロンの仲介サーバーが推奨されるためです。 その他のほとんどのインスタンスでは、仲介サーバーをフロントエンド サーバーと併置することが推奨されます。 仲介サーバー トポロジの詳細については、「計画」のドキュメントの 「Lync Server 2013 の仲介サーバーのコンポーネントとトポロジ 」を参照してください。

• 常設チャットが展開されている。   この組織は、常設チャットを有効にするために必要なサーバーを展開しています。 まず、プール内のユーザーの負荷に対処し、高可用性を実現するために、複数の常設チャット フロントエンド サーバーを展開しています。 また、常設チャットのコンプライアンスを展開し、常設チャット ストアと常設チャット コンプライアンス ストアを別々のサーバーに配置しています。 これらのストアを併置することも、これらをバックエンド サーバーと併置することもできますが、この組織では、パフォーマンスを高めるためにこれらを分離しています。

• DNS 負荷分散。   フロントエンド プールとエッジ サーバー プール。. これにより、エッジ サーバーの内部インターフェイス用のハードウェア ロード バランサーが不要になり、ハードウェア ロード バランサーは HTTP トラフィックにのみ必要になるため、他のプールのハードウェア ロード バランサーのセットアップと保守にかかる時間が大幅に削減されます。 DNS 負荷分散の詳細については、「計画」のドキュメント の「Lync Server 2013 の DNS 負荷分散 」を参照してください。

• Exchange UM の展開。  Lync Server は、Exchange ユニファイド メッセージング (UM) とホストされている Exchange UM の両方のオンプレミス展開で動作します。 セントラル サイト A には、Lync Server ではなくMicrosoft Exchange Serverを実行する Exchange ユニファイド メッセージング (UM) サーバーが含まれています。 Lync Server の Exchange UM 機能は、フロントエンド プールで実行されます。

  中央サイト B では Hosted Exchange が使用されているため、Exchange UM サーバー機能もホストされています。

  Exchange UM の詳細については、「計画」のドキュメント の「Lync Server 2013 での Exchange ユニファイド メッセージング統合の計画 」と 「Lync Server 2013 のホスト型 Exchange ユニファイド メッセージング統合 」を参照してください。

• Office Web Apps サーバー。   Web 会議を使用するすべての組織に Office Web Apps サーバーまたは Office Web Apps サーバー ファームを展開することをお勧めします。 1 つの Office Web Apps サーバー ファームを、すべてのサイトからのトラフィックを処理する 1 つのサイトに展開することも、各サイトに展開することもできます。 Office Web Apps サーバーを使用すると、Web 会議で PowerPoint スライドのプレゼンテーションを行うことができます。 詳細については、「Office Web Apps Server および Lync Server 2013 との統合の構成」を参照してください。

• ディレクターを追加可能。  この組織では、サービス拒否攻撃に対するセキュリティを強化するためにディレクターのプールを展開することもできます。 ディレクターは、Lync Server の個別の省略可能なサーバー ロールであり、ユーザー アカウントをホームにしたり、プレゼンス サービスや会議サービスを提供したりすることはありません。 これは、エッジ サーバーが内部サーバー宛ての受信 SIP トラフィックをルーティングする内部ネクスト ホップ サーバーとして機能します。 ディレクターは受信要求を事前認証し、ユーザーのホーム プールまたはサーバーにリダイレクトします。 ディレクターでの事前認証により、展開にとって不明なユーザー アカウントからの要求を削除できます。 ディレクターは、サービス拒否 (DoS) 攻撃などの悪意のあるトラフィックからフロント エンド サーバーを保護するのに役立ちます。 このような攻撃で無効な外部トラフィックがネットワークにあふれた場合、トラフィックは Director で終了します。

• System Center Operations Manager が展開されます。  エンド ユーザーのサービスの可用性を確保するために、Lync Server 展開の正常性を監視することをお勧めします。 Microsoft から無料でダウンロードできる System Center Operations Manager Management Pack for Lync を使用して Lync を監視できます。 Lync 管理パックを使用すると、問題が発生したときにリアルタイム のアラートを事前に取得したり、代理トランザクションを実行してエンドツーエンドの Lync 機能をテストしたり、サービスの可用性に関するレポートを取得したりできます。  This helps you to proactively respond to issues with your deployment before end-users experience them.

  この組織は、各中央サイトに System Center Operations Manager サーバーを展開しました。