Skype for Business の負荷分散の要件

  • [アーティクル]

概要：Skype for Business Serverを実装する前に、負荷分散に関する考慮事項を確認してください。

負荷分散により、プール内のサーバー間でトラフィックが分散されます。 フロントエンド プール、仲介サーバー プール、またはエッジ サーバー プールがある場合は、これらのプールの負荷分散を展開する必要があります。

Skype for Business Serverでは、クライアントからサーバーへのトラフィックに対して 2 種類の負荷分散ソリューションがサポートされています。ドメイン ネーム システム (DNS) 負荷分散とハードウェア負荷分散 (多くの場合、HLB と略記されます)。 DNS 負荷分散には、管理の簡素化、トラブルシューティングの効率化、ハードウェア ロード バランサーの潜在的な問題からSkype for Business Serverトラフィックの多くを分離する機能など、いくつかの利点があります。

デプロイ内の各プールに適した負荷分散ソリューションを自分で決定しますが、次の制限事項に注意してください。

  • 内部エッジ インターフェイスと外部エッジ インターフェイスでは、同じ種類の負荷分散を使用する必要があります。 1 つのインターフェイスで DNS 負荷分散を使用し、もう 1 つのインターフェイスでロード バランサー機器を使用することはできません。

  • 一部の種類のトラフィックでは、ロード バランサー機器が必要です。 たとえば、HTTP トラフィックでは、DNS 負荷分散ではなくロード バランサー機器が必要です。 クライアントとサーバー間の Web トラフィックでは、DNS 負荷分散は正常に機能しません。

プールで DNS 負荷分散を使用するように選択し、HTTP トラフィックなどのトラフィック用にロード バランサー機器も実装する必要がある場合、ロード バランサー機器の管理は非常に簡素化されます。 たとえば、ロード バランサー機器の構成は、他のすべてのプロトコルが DNS 負荷分散によって管理されるのに対して、HTTP および HTTPS のトラフィックを管理するのみであるため簡素になります。 詳細については、「DNS Load Balancing」を参照してください。

サーバー間トラフィックの場合、Skype for Business Serverはトポロジ対応の負荷分散を使用します。 サーバーは中央管理ストアの発行済みトポロジを読み取り、トポロジ内のサーバーの FQDN を取得し、トラフィックをサーバー間で自動的に分散します。 この種の負荷分散では、管理者が設定または管理を行う必要はありません。

DNS 負荷分散を使用していて、特定のコンピューターへのトラフィックを遮断する必要がある場合は、プールの FQDN から IP アドレス エントリを削除するだけでは十分ではありません。 コンピューターの DNS エントリも削除する必要があります。

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

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

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

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

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

重要

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

注意

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

注意

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

ハードウェア ロード バランサーがSkype for Business Serverに必要な機能をサポートしているかどうかを判断するには、「Skype for Businessのインフラストラクチャ」を参照してください。

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

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

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

  • 外部ポート範囲 50,000 ~ 59,999 の TCP ナグリングをオフにします。

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

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

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

  • ロード バランサー機器で、クライアントのソース アドレスを変更しないでください。

その他のハードウェア Load Balancer要件

Web サービスのSkype for Business Serverでは、Cookie ベースのアフィニティ要件が大幅に削減されます。 Skype for Business Serverを展開していて、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 サービスが受け取ることを想定している値であり、変更できません)

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

注意

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

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

注意

モバイル デバイスをデプロイする場合、ハードウェア ロード バランサーは TCP 接続内の各要求を個別に負荷分散できる必要があります。 最新の Apple iOS モバイル アプリには、トランスポート層セキュリティ (TLS) バージョン 1.2 が必要です。

注意

サード パーティ製ハードウェア ロード バランサーの詳細については、「Skype for Businessのインフラストラクチャ」を参照してください。

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

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

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

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

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

クライアント/ユーザーの場所 外部 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

DNS Load Balancing

Skype for Business Serverは、DNS 負荷分散を有効にします。これは、ネットワーク上の負荷分散の管理オーバーヘッドを大幅に削減できるソフトウェア ソリューションです。 DNS 負荷分散は、SIP トラフィックやメディア トラフィックなど、Skype for Business Server固有のネットワーク トラフィックのバランスを取ります。

DNS 負荷分散をデプロイすると、ハードウェア ロード バランサーに対するorganizationの管理オーバーヘッドが最小限に抑えられます。 さらに、SIP トラフィックのロード バランサーの構成ミスに関連する問題の複雑なトラブルシューティングも排除されます。 サーバーをオフラインにできるように、サーバー接続を禁止することもできます。 また、DNS 負荷分散により、ハードウェア ロード バランサーの問題が、基本的な呼び出しルーティングなどの SIP トラフィックの要素に影響を与えないようにします。

次の図は、内部 DNS 負荷分散と外部 DNS 負荷分散の両方を含む例を示しています。

パブリック IPv4 アドレスを使用したエッジ ネットワーク ダイアグラム

DNS ネットワークダイアグラムの例。

DNS 負荷分散を使用する場合は、すべての種類のトラフィックにハードウェア ロード バランサーを使用した場合よりも低コストのハードウェア ロード バランサーを購入することもできます。 Skype for Business Serverとの相互運用性認定テストに合格したロード バランサーを使用する必要があります。 ロード バランサーの相互運用性テストの詳細については、「Lync Server 2010 Load Balancer パートナー」を参照してください。 そこに含まれるコンテンツは、Skype for Business Serverに適用されます。

DNS 負荷分散は、フロントエンド プール、エッジ サーバー プール、ディレクター プール、スタンドアロン仲介サーバー プールでサポートされています。

DNS 負荷分散は通常、アプリケーション レベルで実装されます。 アプリケーション (たとえば、Skype for Businessを実行しているクライアント) は、プールの完全修飾ドメイン名 (FQDN) のレコード クエリ (IPv6 アドレス指定が使用されている場合) と DNS A から返される IP アドレスのいずれかに接続することで、プール内のサーバーへの接続を試みます。

たとえば、pool01.contoso.com という名前のプールに 3 つのフロントエンド サーバーがある場合、次のことが発生します。

  • Skype for Business実行されているクライアントは、DNS に対して pool01.contoso.com のクエリを実行します。 クエリは 3 つの IP アドレスを返し、次のようにキャッシュします (必ずしもこの順序ではありません)。

    pool01.contoso.com 192.168.10.90

    pool01.contoso.com 192.168.10.91

    pool01.contoso.com 192.168.10.92

  • クライアントは、いずれかの IP アドレスへの伝送制御プロトコル (TCP) 接続の確立を試みます。 失敗した場合、クライアントはキャッシュ内の次の IP アドレスを試行します。

  • TCP 接続が成功した場合、クライアントは TLS のネゴシエーションを行い、pool01.contoso.com のプライマリ レジストラーに接続します。

  • クライアントが接続に成功せずにキャッシュされたすべてのエントリを試行すると、Skype for Business Serverを実行しているサーバーが現時点で使用できないという通知がユーザーに通知されます。

注意

DNS ベースの負荷分散は、DNS ラウンド ロビン (DNS RR) とは異なります。これは通常、DNS に依存してプール内のサーバーに対応する異なる IP アドレスの順序を提供することで負荷分散を指します。 通常、DNS RR では負荷分散のみが有効になりますが、フェールオーバーは有効になりません。 たとえば、DNS A と AAAA によって返される 1 つの IP アドレス (IPv6 アドレッシングを使用している場合) への接続が失敗した場合、接続は失敗します。 そのため、DNS ラウンド ロビン自体の信頼性は、DNS ベースの負荷分散よりも低くなります。 DNS ラウンド ロビンは、DNS 負荷分散と組み合わせて使用できます。

DNS 負荷分散は、次の目的で使用されます。

  • サーバー間 SIP をエッジ サーバーに負荷分散する

  • 会議自動応答、応答グループ、コール パークなどのユニファイド コミュニケーション アプリケーション サービス (UCAS) アプリケーションの負荷分散

  • UCAS アプリケーションへの新しい接続の防止 ("ドレイン" とも呼ばれます)

  • クライアントとエッジ サーバー間のすべてのクライアント間トラフィックの負荷分散

DNS 負荷分散は、次の場合に使用できません。

  • Director またはフロントエンド サーバーへのクライアントからサーバーへの Web トラフィック

DNS 負荷分散とフェデレーション トラフィック:

DNS SRV クエリによって複数の DNS レコードが返される場合、Access Edge サービスは常に、数値の優先順位が最も低く、数値の重みが最も高い DNS SRV レコードを選択します。 インターネット エンジニアリング タスク フォースのドキュメント「サービスの場所を指定するための DNS RR (DNS SRV)」 RFC 2782 では、DNS SRV RR では、 複数の DNS SRV レコードが定義されている場合、優先順位が最初に使用され、重みが指定されます。 たとえば、DNS SRV レコード A の重みは 20、優先順位は 40、DNS SRV レコード B の重みは 10、優先順位は 50 です。 優先順位 40 の DNS SRV レコード A が選択されます。 DNS SRV レコードの選択には、次の規則が適用されます。

  • 優先順位は最初に考慮されます。 クライアントは、DNS SRV レコードによって定義されたターゲット ホストに、到達できる最も低い番号の優先順位で接続を試みる必要があります。 同じ優先度のターゲットは、重みフィールドで定義された順序で試行する必要があります。

  • 重みフィールドは、同じ優先順位のエントリの相対的な重みを指定します。 重みが大きい場合は、選択される確率が比例的に高くなります。 DNS 管理者は、実行するサーバーの選択がない場合は、Weight 0 を使用する必要があります。 重みが 0 より大きいレコードがある場合、重み 0 のレコードは選択される可能性が非常に小さいはずです。

優先度と重みが等しい複数の DNS SRV レコードが返された場合、Access Edge サービスは、最初に DNS サーバーから受信した SRV レコードを選択します。

フロントエンド プールとディレクター プールでの DNS 負荷分散

フロントエンド プールとディレクター プールの SIP トラフィックに DNS 負荷分散を使用できます。 DNS 負荷分散がデプロイされた場合でも、これらのプールにはハードウェア ロード バランサーを使用する必要がありますが、クライアントからサーバーへの HTTPS トラフィックにのみ使用する必要があります。 ハードウェア ロード バランサーは、ポート 443 と 80 を介したクライアントからの HTTPS トラフィックに使用されます。

これらのプールにはハードウェア ロード バランサーが引き続き必要ですが、そのセットアップと管理は主に、ハードウェア ロード バランサーの管理者が慣れている HTTPS トラフィック用になります。

DNS 負荷分散と古いクライアントとサーバーのサポート

DNS 負荷分散では、Skype for Business Serverまたは Lync Server 2010 を実行しているサーバーと、Lync 2013 および Skype for Business クライアントに対してのみ自動フェールオーバーがサポートされます。 以前のバージョンのクライアントと Office Communications Server は引き続き DNS 負荷分散を実行しているプールに接続できますが、DNS 負荷分散によって参照されている最初のサーバーに接続できない場合、プール内の別のサーバーにフェールオーバーできません。

さらに、Exchange UM を使用している場合は、少なくとも Exchange 2010 SP1 を使用して、Skype for Business Server DNS 負荷分散のサポートを受ける必要があります。 以前のバージョンの Exchange を使用する場合、ユーザーには次の Exchange UM シナリオのフェールオーバー機能がありません。

  • 電話でエンタープライズ ボイスメールを再生する

  • Exchange UM 自動応答からの呼び出しの転送

その他のすべての Exchange UM シナリオは正常に動作します。

フロントエンド プールとディレクター プールに DNS 負荷分散をデプロイする

フロントエンド プールとディレクター プールに DNS 負荷分散をデプロイするには、FQDN と DNS レコードを使用していくつかの追加の手順を実行する必要があります。

  • DNS 負荷分散を使用するプールには、2 つの FQDN が必要です。DNS 負荷分散によって使用される通常のプール FQDN (pool01.contoso.com など) と、プール内のサーバーの物理 IP に解決され、プールの Web サービスの別の FQDN (web01.contoso.com など) がプールの仮想 IP アドレスに解決されます。

    トポロジ ビルダーで、プールの DNS 負荷分散を展開する場合は、プールの Web サービス用にこの追加の FQDN を作成するには、[内部 Web サービス プールの FQDN をオーバーライドする] チェック ボックスを選択し、[このプールの Web サービス URL の指定] ページに FQDN を入力する必要があります。

  • DNS 負荷分散で使用される FQDN をサポートするには、プールの FQDN (pool01.contoso.com など) をプール内のすべてのサーバーの IP アドレス (192.168.1.1、192.168.1.2 など) に解決するように DNS をプロビジョニングする必要があります。 現在デプロイされているサーバーの IP アドレスのみを含める必要があります。

    注意

    複数のフロントエンド プールまたはフロント エンド サーバーがある場合は、外部 Web サービスの FQDN が一意である必要があります。 たとえば、フロントエンド サーバーの外部 Web サービス FQDN を pool01.contoso.com として定義した場合、別のフロントエンド プールまたはフロント エンド サーバー に pool01.contoso.com を使用することはできません。 ディレクターも展開する場合、ディレクターまたはディレクター プールに対して定義されている外部 Web サービス FQDN は、他のディレクター プールまたはディレクター プール、およびフロント エンド プールまたはフロント エンド サーバーから一意である必要があります。 内部 Web サービスを自己定義 FQDN でオーバーライドする場合、各 FQDN は他のフロントエンド プール、ディレクター プール、またはディレクター プールから一意である必要があります。

エッジ サーバー プールでの DNS 負荷分散

エッジ サーバー プールに DNS 負荷分散をデプロイできます。 その場合は、いくつかの考慮事項に注意する必要があります。

エッジ サーバーで DNS 負荷分散を使用すると、次のシナリオではフェールオーバー機能が失われます。

  • Lync Server 2010 より前にリリースされたSkype for Business Serverのバージョンを実行している組織とのフェデレーション。

  • 現在、サポートされている唯一の XMPP パートナーである Google Talk などの XMPP ベースのプロバイダーとサーバーに加えて、パブリック インスタント メッセージング (IM) サービス AOL と Yahoo!のユーザーとのインスタント メッセージ交換。

これらのシナリオは、プール内のすべてのエッジ サーバーが稼働している限り機能しますが、1 つのエッジ サーバーが使用できない場合は、別のエッジ サーバーへのルーティングではなく、送信されるこれらのシナリオに対する要求は失敗します。

Exchange UM を使用している場合は、少なくとも Exchange 2013 を使用して、Edge での DNS 負荷分散Skype for Business Serverサポートを受ける必要があります。 以前のバージョンの Exchange を使用している場合、リモート ユーザーには、次の Exchange UM シナリオのフェールオーバー機能がありません。

  • 電話でエンタープライズ ボイスメールを再生する

  • Exchange UM 自動応答からの呼び出しの転送

その他のすべての Exchange UM シナリオは正常に動作します。

内部エッジ インターフェイスと外部エッジ インターフェイスでは、同じ種類の負荷分散を使用する必要があります。 1 つのエッジ インターフェイスで DNS ロード バランシングを使用し、もう 1 つのエッジ インターフェイスでロード バランサー機器を使用することはできません。

エッジ サーバー プールへの DNS 負荷分散のデプロイ

エッジ サーバー プールの外部インターフェイスに DNS 負荷分散を展開するには、次の DNS エントリが必要です。

  • Access Edge サービスには、プール内のサーバーごとに 1 つのエントリが必要です。 各エントリは、Access Edge サービスの FQDN (たとえば、sip.contoso.com) を、プール内のいずれかのエッジ サーバー上の Access Edge サービスの IP アドレスに解決する必要があります。

  • Web 会議エッジ サービスの場合は、プール内のサーバーごとに 1 つのエントリが必要です。 各エントリは、Web 会議エッジ サービスの FQDN (たとえば、webconf.contoso.com) を、プール内のいずれかのエッジ サーバー上の Web 会議エッジ サービスの IP アドレスに解決する必要があります。

  • Audio/Video Edge サービスには、プール内のサーバーごとに 1 つのエントリが必要です。 各エントリは、オーディオ/ビデオ エッジ サービスの FQDN (たとえば、av.contoso.com) を、プール内のいずれかのエッジ サーバー上の A/V Edge サービスの IP アドレスに解決する必要があります。

エッジ サーバー プールの内部インターフェイスに DNS 負荷分散を展開するには、エッジ サーバー プールの内部 FQDN をプール内の各サーバーの IP アドレスに解決する 1 つの DNS A レコードを追加する必要があります。

仲介サーバー プールでの DNS 負荷分散の使用

スタンドアロン仲介サーバー プールで DNS 負荷分散を使用できます。 すべての SIP トラフィックとメディア トラフィックは、DNS 負荷分散によってバランスが取れています。

仲介サーバー プールに DNS 負荷分散を展開するには、プールの FQDN (mediationpool1.contoso.com など) をプール内のすべてのサーバーの IP アドレス (192.168.1.1、192.168.1.2 など) に解決するために DNS をプロビジョニングする必要があります。

DNS 負荷分散を使用してサーバーへのトラフィックをブロックする

DNS 負荷分散を使用していて、特定のコンピューターへのトラフィックを遮断する必要がある場合は、プールの FQDN から IP アドレス エントリを削除するだけでは十分ではありません。 コンピューターの DNS エントリも削除する必要があります。

サーバー間トラフィックの場合、Skype for Business Serverはトポロジ対応の負荷分散を使用することに注意してください。 サーバーは中央管理ストアの発行済みトポロジを読み取り、トポロジ内のサーバーの FQDN を取得し、トラフィックをサーバー間で自動的に分散します。 サーバーがサーバー間トラフィックを受信できないようにするには、トポロジからサーバーを削除する必要があります。