Lync Server 2013 のハードウェア ロード バランサーの要件

 

トピックの最終更新日: 2015-05-11

Lync Server 2013 のスケーリングされた統合エッジ トポロジは、主に Lync Server を使用する他の組織とフェデレーションする新しい展開の DNS 負荷分散用に最適化されています。 次のいずれかのシナリオで高可用性が必要な場合は、次の場合は、Edge Server プールでハードウェア ロード バランサーを使用する必要があります。

  • Office Communications Server 2007 R2 または Office Communications Server 2007 を使用する組織とのフェデレーション

  • Exchange UM を SP1 で Exchange 2010 より前に使用するリモート ユーザー向けの Exchange UM

  • パブリック IM ユーザーとの接続

大事な

1 つのインターフェイスでハードウェア負荷分散を使用し、もう 1 つのインターフェイスで DNS 負荷分散を使用することはできません。 両方のインターフェイスでハードウェア負荷分散を使用するか、両方で DNS 負荷分散を使用する必要があります。

注意

ロード バランサー機器を使用している場合は、内部ネットワークとの接続用に展開されているロード バランサーを構成して、アクセス エッジ サービスおよび音声ビデオ サービスを実行しているサーバーへのトラフィックのみを負荷分散する必要があります。 内部の Web 会議エッジ サービスまたは内部 XMPP プロキシ サービスへのトラフィックを負荷分散することはできません。

注意

ダイレクト サーバーリターン (DSR) NAT は、Lync Server 2013 ではサポートされていません。

ハードウェア ロード バランサーが Lync Server 2013 で必要な機能をサポートしているかどうかを確認するには、「Lync Server 2010 Load Balancer パートナー」をhttps://go.microsoft.com/fwlink/p/?linkId=202452参照してください。

音声ビデオ エッジ サービスを実行するエッジ サーバーに対するロード バランサー機器の要件

A/V Edge サービスを実行するエッジ サーバーのハードウェア ロード バランサー要件を次に示します。

  • 内部と外部の両方のポート 443 に対して TCP のネーグル処理がオフになっていること。 ネーグル処理はいくつかの小さなパケットを 1 つの大きなパケットにまとめて転送効率を向上させるプロセスです。

  • 外部ポート範囲 50000 ~ 59999 の TCP のネーグル処理がオフになっていること。

  • 内部または外部のファイアウォールで NAT が使用されていないこと。

  • エッジ内部インターフェイスは、Edge Server 外部インターフェイスとは異なるネットワーク上にある必要があり、それらの間のルーティングを無効にする必要があります。

  • A/V Edge サービスを実行しているエッジ サーバーの外部インターフェイスでは、パブリックにルーティング可能な IP アドレスを使用する必要があり、エッジ外部 IP アドレスに NAT またはポート変換は使用されません。

ロード バランサー機器の要件

Lync Server 2013 for Web サービスでは、Cookie ベースのアフィニティ要件が大幅に削減されます。 Lync Server 2013 を展開していて、Lync Server 2010 フロントエンド サーバーまたはフロントエンド プールを保持しない場合は、Cookie ベースの永続化は必要ありません。 ただし、Lync Server 2010 フロントエンド サーバーまたはフロントエンド プールを一時的または永続的に保持する場合は、Lync Server 2010 用に展開および構成されているため、Cookie ベースの永続化を引き続き使用します。

注意

展開では不要だが、Cookie ベースのアフィニティを使用する場合でも、悪影響はありません。

Cookie ベースのアフィニティを使用しない展開の場合

  • リバース プロキシのポート 4443 に対する公開ルールで、[ホスト ヘッダーを転送する] を True に設定します。 これにより、元の URL が確実に転送されます。

Cookie ベースのアフィニティを使用する展開の場合

  • リバース プロキシのポート 4443 に対する公開ルールで、[ホスト ヘッダーを転送する] を True に設定します。 これにより、元の URL が確実に転送されます。

  • ロード バランサー機器 Cookie が httpOnly とマークされていないこと

  • ロード バランサー機器 Cookie に有効期限がないこと

  • ロード バランサー機器 Cookie の名前が MS-WSMAN であること (これは Web サービスが受け取ることを想定している値であり、変更できません)

  • ハードウェア ロード バランサー Cookie は、同じ TCP 接続に対する以前の HTTP 応答が既に Cookie を取得したかどうかに関係なく、受信 HTTP 要求に Cookie がなかったすべての HTTP 応答で設定する必要があります。 ロード バランサーが TCP 接続ごとに 1 回だけ行われるように Cookie 挿入を最適化する場合、その最適化は使用しないでください

注意

一般的なハードウェア ロード バランサーの構成では、ソースアドレスアフィニティと 20 分を使用します。 TCP セッションの有効期間。これは Lync Server および Lync 2013 クライアントでは問題ありません。これは、クライアントの使用状況やアプリケーションの相互作用によってセッション状態が維持されるためです。

モバイル デバイスを展開する場合、ロード バランサー機器で、TCP セッション内の個々の要求を負荷分散できるようにする必要があります (実際には、ターゲット IP アドレスに基づいて個々の要求を負荷分散できる必要があります)。

警告

F5 ハードウェア ロード バランサーには OneConnect という機能があります。これにより、TCP 接続内の各要求が個別に負荷分散されます。 モバイル デバイスをデプロイする場合は、ハードウェア ロード バランサー ベンダーが同じ機能をサポートしていることを確認します。 最新の Apple iOS モバイル アプリでは、トランスポート層セキュリティ (TLS) バージョン 1.2 が必要です。 F5 では、これに固有の設定が提供されます。
サード パーティ製ハードウェア ロード バランサーの詳細については、次を参照してください。 https://go.microsoft.com/fwlink/p/?linkId=230700

ディレクターおよびフロントエンド プールの Web サービスに対するロード バランサー機器の要件は次のとおりです。

  • 内部 Web サービスの VIP で、ロード バランサー機器の送信元アドレスの永続性 (内部ポート 80、443) が設定されていること。 Lync Server 2013 の場合、Source_addr永続化とは、セッション状態を維持するために、1 つの IP アドレスから送信される複数の接続が常に 1 つのサーバーに送信されることを意味します。

  • TCP アイドル タイムアウトが 1800 秒に設定されていること

  • リバース プロキシと次ホップ プールのロード バランサー機器間のファイアウォールで、リバース プロキシからロード バランサー機器へのポート 4443 に対する https: トラフィックを許可するルールが作成されていること。 ポート 80、443、および 4443 をリッスンするようにロード バランサー機器を構成する必要があります。

大事な

ハードウェア ロード バランサーの構成の詳細については、「 ポートの概要 - Lync Server 2013 のハードウェア ロード バランサーを使用した拡張統合エッジ」を参照してください。

ロード バランサー機器のアフィニティ要件の概要

クライアント/ユーザーの場所 外部 Web サービスの FQDN のアフィニティ要件 内部 Web サービスの FQDN のアフィニティ要件

Lync Web App (内部ユーザーと外部ユーザー)

モバイル デバイス (内部および外部ユーザー)

アフィニティなし

送信元アドレスのアフィニティ

Lync Web App (外部ユーザーのみ)

モバイル デバイス (内部および外部ユーザー)

アフィニティなし

送信元アドレスのアフィニティ

Lync Web App (内部ユーザーのみ)

モバイル デバイス (展開しない)

アフィニティなし

送信元アドレスのアフィニティ

ロード バランサー機器のポート監視

特定のサービスがハードウェアまたは通信障害によって使用できないような状況を確認する目的で、ロード バランサー機器に対してポート監視を定義します。 たとえば、フロントエンド サーバーまたはフロントエンド プールが失敗したためにフロントエンド サーバー サービス (RTCSRV) が停止した場合、HLB 監視は Web サービスでのトラフィックの受信も停止する必要があります。 以下を監視する目的で、HLB にポート監視を実装します。

フロントエンド サーバー ユーザー プール – HLB 内部インターフェイス

仮想 IP/ポート ノード ポート ノード コンピューター/モニター 保存プロファイル メモ

<pool>web-int_mco_443_vs

443

443

フロントエンド

5061

ソース

HTTPS

<pool>web-int_mco_80_vs

80

80

フロントエンド

5061

ソース

HTTP

フロントエンド サーバー ユーザー プール – HLB 外部インターフェイス

仮想 IP/ポート ノード ポート ノード コンピューター/モニター 保存プロファイル メモ

<プール>web_mco_443_vs

443

4443

フロントエンド

5061

なし

HTTPS

<プール>web_mco_80_vs

80

8080

フロントエンド

5061

なし

HTTP