Skype for Business の負荷分散の要件Load balancing requirements for Skype for Business

概要: Skype for Business Server を実装する前に、負荷分散に関する考慮事項を確認してください。Summary: Review the load balancing considerations before implementing Skype for Business Server.

負荷分散は、プール内のサーバー間でトラフィックを分散します。Load balancing distributes traffic among the servers in a pool. フロントエンド プール、仲介サーバー プール、またはエッジ サーバー プールがある場合は、これらのプールの負荷分散を展開する必要があります。If you have Front End pools, Mediation Server pools, or Edge Server pools, you need to deploy load balancing for these pools.

Skype for Business Server は、クライアントからサーバーへのトラフィック用に 2 種類の負荷分散ソリューションをサポートしています。ドメイン ネーム システム (DNS) 負荷分散とハードウェア負荷分散 (HLB と省略される場合があります)。Skype for Business Server supports two types of load balancing solutions for client-to-server traffic: Domain Name System (DNS) load balancing and hardware load balancing (often abbreviated as HLB). DNS 負荷分散には、管理の簡易化、トラブルシューティングの効率化、Skype for Business Server トラフィックの多くをハードウェア ロード バランサーの潜在的な問題から切り離す機能など、いくつかの利点があります。DNS load balancing offers several advantages including simpler administration, more efficient troubleshooting, and the ability to isolate much of your Skype for Business Server traffic from any potential hardware load balancer problems.

展開内の各プールに適した負荷分散ソリューションを自分で決定しますが、次の制限に注意してください。Decide for yourself which load balancing solution is appropriate for each pool in your deployment, but keep in mind the following restrictions:

  • 内部エッジ インターフェイスと外部エッジ インターフェイスでは、同じ種類のロード バランシングを使用する必要があります。1 つのインターフェイスで DNS ロード バランシングを使用し、もう 1 つのインターフェイスでロード バランサー機器を使用することはできません。The internal Edge interface and external Edge interface must use the same type of load balancing. You cannot use DNS load balancing on one interface and hardware load balancing on the other.

  • 一部の種類のトラフィックでは、ハードウェア ロード バランサーが必要です。たとえば、HTTP トラフィックでは、DNS ロード バランシングではなくハードウェア ロード バランサーが必要です。クライアントとサーバー間の Web トラフィックでは、DNS ロード バランシングは正常に機能しません。Some types of traffic require a hardware load balancer. For example, HTTP traffic requires a hardware load balancer instead of DNS load balancing. DNS load balancing does not work with client-to-server web traffic.

プールで DNS ロード バランシングを使用するように選択し、HTTP トラフィックなどのトラフィック用にハードウェア ロード バランサーも実装する必要がある場合、ハードウェア ロード バランサーの管理は非常に簡素化されます。If you choose to use DNS load balancing for a pool but still need to implement hardware load balancers for traffic such as HTTP traffic, the administration of the hardware load balancers is greatly simplified. たとえば、ロード バランサーハードウェアの構成は HTTP トラフィックと HTTPS トラフィックのみを管理するのに対し、他のすべてのプロトコルは DNS 負荷分散によって管理されるので、構成が簡単です。For example, configuring the hardware load balancer will be simpler as it will only manage the HTTP and HTTPS traffic, while all other protocols will be managed by DNS load balancing. 詳細については、「DNS Load Balancing」を参照してください。For details, see DNS Load Balancing.

サーバー間トラフィックの場合、Skype for Business Server はトポロジ対応の負荷分散を使用します。For server-to-server traffic, Skype for Business Server uses topology-aware load balancing. サーバーは中央管理ストアの公開トポロジを読み取り、トポロジ内のサーバーの FQDN を取得し、トラフィックをサーバー間で自動的に分散します。Servers read the published topology in the Central Management store to obtain the FQDNs of servers in the topology, and automatically distribute the traffic among the servers. 管理者は、この種類の負荷分散を設定または管理する必要があります。Administrators do not need to set up or manage this type of load balancing.

DNS 負荷分散を使用し、特定のコンピューターへのトラフィックをブロックする必要がある場合は、プールの FQDN から IP アドレス エントリを削除するだけで十分ではありません。If you use DNS load balancing and you need to block traffic to a specific computer, it is not sufficient to just remove the IP address entries from the Pool FQDN. コンピューターの DNS エントリも削除する必要があります。You must remove the DNS entry for the computer as well.

ロード バランサーのハードウェア要件Hardware load balancer requirements

Skype for Business Server の拡張統合エッジ トポロジは、主に Skype for Business Server または Lync Server を使用する他の組織とフェデレーションする新しい展開向けに DNS 負荷分散用に最適化されています。The Skype for Business Server scaled consolidated Edge topology is optimized for DNS load balancing for new deployments federating primarily with other organizations using Skype for Business Server or Lync Server. 次のいずれかのシナリオで高可用性が必要な場合は、次の目的で、エッジ サーバー プールでハードウェア ロード バランサーを使用する必要があります。If high availability is required for any of the following scenarios, a hardware load balancer must be used on Edge Server pools for the following:

  • Communications Server 2007 R2 または Office Communications Server 2007 を使用Office組織とのフェデレーションFederation with organizations using Office Communications Server 2007 R2 or Office Communications Server 2007

  • Exchange 2010 SP1 より前の Exchange UM を使用するリモート ユーザーの Exchange UMExchange UM for remote users using Exchange UM prior to Exchange 2010 with SP1

  • パブリック IM ユーザーとの接続Connectivity to public IM users

重要

1 つのインターフェイスでハードウェア負荷分散を使用し、もう 1 つのインターフェイスで DNS 負荷分散を使用することはできません。両方のインターフェイスでハードウェア負荷分散を使用するか、両方で DNS 負荷分散を使用する必要があります。Using DNS load balancing on one interface and hardware load balancing on the other is not supported. You must use hardware load balancing for both interfaces or DNS load balancing for both.

注意

ロード バランザー機器を使用している場合は、内部ネットワークとの接続用に展開されているロード バランザーを構成して、アクセス エッジ サービスおよび音声ビデオ サービスを実行しているサーバーへのトラフィックのみを負荷分散する必要があります。内部の Web 会議エッジ サービスまたは内部 XMPP プロキシ サービスへのトラフィックを負荷分散することはできません。If you are using a hardware load balancer, the load balancer deployed for connections with the internal network must be configured to load balance only the traffic to servers running the Access Edge service and the A/V Edge service. It cannot load balance the traffic to the internal Web Conferencing Edge service or the internal XMPP Proxy service.

注意

直接サーバー リターン (DSR) NAT は、Skype for Business Server ではサポートされていません。The direct server return (DSR) NAT is not supported with Skype for Business Server.

ハードウェア ロード バランサーが Skype for Business Server に必要な機能をサポートするかどうかを確認するには、「Skype for Business のインフラストラクチャ」 を参照してくださいTo determine whether your hardware load balancer supports the necessary features required by Skype for Business Server, see Infrastructure for Skype for Business.

音声ビデオ エッジ サービスを実行するエッジ サーバーに対するロード バランサー機器の要件Hardware Load Balancer Requirements for Edge Servers Running the A/V Edge Service

A/V エッジ サービスを実行するエッジ サーバーのハードウェア ロード バランサー要件は次のとおりです。Following are the hardware load balancer requirements for Edge Servers running the A/V Edge service:

  • 内部と外部の両方のポート 443 に対して TCP のネーグル処理がオフになっていること。ネーグル処理はいくつかの小さなパケットを 1 つの大きなパケットにまとめて転送効率を向上させるプロセスです。Turn off TCP nagling for both internal and external ports 443. Nagling is the process of combining several small packets into a single, larger packet for more efficient transmission.

  • 外部ポート範囲 50,000 ~ 59,999 の TCP の入れ子をオフにします。Turn off TCP nagling for external port range 50,000 - 59,999.

  • 内部または外部のファイアウォールで NAT が使用されていないこと。Do not use NAT on the internal or external firewall.

  • エッジの内部インターフェイスがエッジ サーバーの外部インターフェイスとは別のネットワークに存在し、それらの間のルーティングが無効になっていること。The edge internal interface must be on a different network than the Edge Server external interface and routing between them must be disabled.

  • A/V エッジ サービスを実行するエッジ サーバーの外部インターフェイスは、パブリックにログアウト可能な IP アドレスを使用し、エッジ外部 IP アドレスに NAT またはポート変換を使用する必要はありません。The external interface of the Edge Server running the A/V Edge Service must use publicly routable IP addresses and no NAT or port translation on any of the edge external IP addresses.

  • ロード バランサーは、クライアントのソース アドレスを変更する必要があります。The load balancer must not change the source address of the client.

その他のハードウェア ロード バランサーの要件Other Hardware Load Balancer requirements

Skype for Business Server for Web サービスでは、Cookie ベースのアフィニティ要件が大幅に削減されます。Cookie-based affinity requirements are greatly reduced in Skype for Business Server for Web services. Skype for Business Server を展開し、Lync Server 2010 フロントエンド サーバーまたはフロントエンド プールを保持しない場合は、Cookie ベースの永続性は必要ではありません。If you are deploying Skype for Business Server and will not retain any Lync Server 2010 Front End Servers or Front End pools, you do not need cookie-based persistence. ただし、Lync Server 2010 フロントエンド サーバーまたはフロントエンド プールを一時的または永続的に保持する場合は、Lync Server 2010 用に展開および構成された Cookie ベースの永続性を引き続き使用します。However, if you will temporarily or permanently retain any Lync Server 2010 Front End Servers or Front End pools, you still use cookie-based persistence as it is deployed and configured for Lync Server 2010.

注意

展開では不要だが、Cookie ベースのアフィニティを使用する場合でも、悪影響はありません。If you decide to use cookie-based affinity even though your deployment does not require it, there is no negative impact to doing so.

Cookie ベースのアフィニティを 使用しない 展開の場合For deployments that will not use cookie-based affinity:

  • リバース プロキシのポート 4443 に対する公開ルールで、[ホスト ヘッダーを転送する] が True に設定します。これにより、元の URL が確実に転送されます。On the reverse proxy publishing rule for port 4443, set Forward host header to True. This will ensure that the original URL is forwarded.

Cookie ベースのアフィニティを 使用する 展開の場合For deployments that will use cookie-based affinity:

  • リバース プロキシのポート 4443 に対する公開ルールで、[ホスト ヘッダーを転送する] が True に設定します。これにより、元の URL が確実に転送されます。On the reverse proxy publishing rule for port 4443, set Forward host header to True. This will ensure that the original URL is forwarded.

  • ロード バランサー機器 Cookie が httpOnly とマークされていないことHardware load balancer cookie MUST NOT be marked httpOnly

  • ロード バランサー機器 Cookie に有効期限がないことHardware load balancer cookie MUST NOT have an expiration time

  • ロード バランサー機器 Cookie の名前が MS-WSMAN であること (これは Web サービスが受け取ることを想定している値であり、変更できません)Hardware load balancer cookie MUST be named MS-WSMAN (This is the value that the Web services expect, and cannot be changed)

  • ロード バランサー機器着信 HTTP 要求に Cookie が含まれていなかったすべての HTTP 応答に Cookie が設定されていること。同じ TCP 接続での以前の HTTP 応答で Cookie がすでに取得されているかどうかは関係ありません。ロード バランサーによって、Cookie の挿入が TCP 接続ごとに 1 回のみ行われるように最適化されている場合は、その最適化を使用しないでください。Hardware load balancer cookie MUST be set in every HTTP response for which the incoming HTTP request did not have a cookie, regardless of whether a previous HTTP response on that same TCP connection had already obtained a cookie. If the load balancer optimizes cookie insert to only occur once per TCP connection, that optimization MUST NOT be used

注意

一般的なハードウェア ロード バランサー構成では、送信元アドレス アフィニティと 20 分の TCP セッションの有効期間を使用します。これは、クライアントの使用状況やアプリケーションのやり取りによってセッション状態が維持されるので、Lync Server および Lync 2013 クライアントで問題ありません。Typical hardware load balancer configurations use source-address affinity and a 20 min. TCP session lifetime, which is fine for Lync Server and Lync 2013 clients because session state is maintained through client usage and/or and application interaction.

モバイル デバイスを展開する場合、ロード バランサー機器で、TCP セッション内の個々の要求を負荷分散できるようにする必要があります (実際には、ターゲット IP アドレスに基づいて個々の要求を負荷分散できる必要があります)。If you are deploying mobile devices, your hardware load balancer must be able to load balance individual request within a TCP session (in effect, you must be able to load balance an individual request based on the target IP address).

注意事項

モバイル デバイスを展開する場合は、ハードウェア ロード バランサーが TCP 接続内の各要求を個別に負荷分散できる必要があります。If you are deploying mobile devices, your hardware load balancer must be able to individually load balance each request within a TCP connection. 最新の Apple iOS モバイル アプリには、トランスポート層セキュリティ (TLS) バージョン 1.2 が必要です。The latest Apple iOS mobile apps require Transport Layer Security (TLS) version 1.2.

注意事項

サード パーティ製ハードウェア ロード バランサーの詳細については 、「Skype for Business のインフラストラクチャ」を参照してくださいFor details on third party hardware load balancers, see Infrastructure for Skype for Business.

ディレクターおよびフロントエンド プールの Web サービスに対するロード バランサー機器の要件は次のとおりです。Following are the hardware load balancer requirements for Director and Front End pool Web Services:

  • 内部 Web サービスの VIP で、ロード バランサー機器の送信元アドレスの永続性 (内部ポート 80、443) が設定されていること。For internal Web Services VIPs, set Source_addr persistence (internal port 80, 443) on the hardware load balancer. Skype for Business Server の場合、Source_addrは、1 つの IP アドレスから複数の接続が常に 1 つのサーバーに送信され、セッション状態が維持されます。For Skype for Business Server, Source_addr persistence means that multiple connections coming from a single IP address are always sent to one server to maintain session state.

  • TCP アイドル タイムアウトが 1,800 秒に設定されていることUse TCP idle timeout of 1800 seconds.

  • リバース プロキシと次ホップ プールのハードウェア ロード バランサーの間のファイアウォールで、リバース プロキシからハードウェア ロード バランサーへの https: トラフィックをポート 4443 で許可するルールを作成します。On the firewall between the reverse proxy and the next hop pool's hardware load balancer, create a rule to allow https: traffic on port 4443, from the reverse proxy to the hardware load balancer. ポート 80、443、および 4443 をリッスンするようにロード バランサー機器を構成する必要があります。The hardware load balancer must be configured to listen on ports 80, 443, and 4443.

ロード バランサー機器のアフィニティ要件の概要Summary of Hardware Load Balancer Affinity Requirements

クライアント/ユーザーの場所Client/user location 外部 Web サービスの FQDN のアフィニティ要件External web services FQDN affinity requirements 内部 Web サービスの FQDN のアフィニティ要件Internal web services FQDN affinity requirements
Lync Web App (内部ユーザーと外部ユーザー)Lync Web App (internal and external users)
モバイル デバイス (内部および外部ユーザー)Mobile device (internal and external users)
アフィニティなしNo affinity
送信元アドレスのアフィニティSource address affinity
Lync Web App (外部ユーザーのみ)Lync Web App (external users only)
モバイル デバイス (内部および外部ユーザー)Mobile device (internal and external users)
アフィニティなしNo affinity
送信元アドレスのアフィニティSource address affinity
Lync Web App (内部ユーザーのみ)Lync Web App (internal users only)
モバイル デバイス (展開しない)Mobile device (not deployed)
アフィニティなしNo affinity
送信元アドレスのアフィニティSource address affinity

ロード バランサー機器のポート監視Port Monitoring for Hardware Load Balancers

特定のサービスがハードウェアまたは通信障害によって使用できないような状況を確認する目的で、ロード バランサー機器に対してポート監視を定義します。You define port monitoring on the hardware load balancers to determine when specific services are no longer available due to hardware or communications failure. たとえば、フロントエンド サーバーまたはフロント エンド プールに障害が発生してフロントエンド サーバー サービス (RTCSRV) が停止した場合、HLB 監視は Web サービス上のトラフィックの受信も停止する必要があります。For example, if the Front End Server service (RTCSRV) stops because the Front End Server or Front End pool fails, the HLB monitoring should also stop receiving traffic on the Web Services. 以下を監視する目的で、HLB にポート監視を実装します。You implement port monitoring on the HLB to monitor the following:

フロントエンド サーバーのユーザー プール - HLB 内部インターフェイスFront End Server User Pool - HLB Internal Interface

仮想 IP/ポートVirtual IP/Port ノード ポートNode Port ノード コンピューター/モニターNode Machine/Monitor 保存プロファイルPersistence Profile Notes
<pool>web-int_mco_443_vs<pool>web-int_mco_443_vs
443443
443443
フロントエンドFront End
50615061
ソースSource
HTTPSHTTPS
<pool>web-int_mco_80_vs<pool>web-int_mco_80_vs
8080
8080
フロントエンドFront End
50615061
ソースSource
HTTPHTTP

フロントエンド サーバーのユーザー プール - HLB 外部インターフェイスFront End Server User Pool - HLB External Interface

仮想 IP/ポートVirtual IP/Port ノード ポートNode Port ノード コンピューター/モニターNode Machine/Monitor 保存プロファイルPersistence Profile Notes
<pool>web_mco_443_vs<pool>web_mco_443_vs
443443
44434443
フロントエンドFront End
50615061
なしNone
HTTPSHTTPS
<pool>web_mco_80_vs<pool>web_mco_80_vs
8080
80808080
フロントエンドFront End
50615061
なしNone
HTTPHTTP

DNS 負荷分散DNS Load Balancing

Skype for Business Server を使用すると、DNS 負荷分散が可能になります。これは、ネットワーク上の負荷分散の管理オーバーヘッドを大幅に削減できるソフトウェア ソリューションです。Skype for Business Server enables DNS load balancing, a software solution that can greatly reduce the administration overhead for load balancing on your network. DNS 負荷分散は、SIP トラフィックやメディア トラフィックなど、Skype for Business Server に固有のネットワーク トラフィックを分散します。DNS load balancing balances the network traffic that is unique to Skype for Business Server, such as SIP traffic and media traffic.

DNS 負荷分散を展開すると、ハードウェア ロード バランサーに対する組織の管理オーバーヘッドが最小限に抑えることができます。If you deploy DNS load balancing, your organization's administration overhead for hardware load balancers will be minimized. さらに、SIP トラフィックの負荷分散装置の構成ミスに関する問題に対応するために、複雑なトラブルシューティングを行う必要がなくなります。Additionally, complex troubleshooting of problems related to misconfiguration of load balancers for SIP traffic will be eliminated. サーバーをオフラインにできるようにサーバー接続を禁止することもできます。You can also prevent server connections so that you can take servers offline. また、DNS 負荷分散を使用して、ハードウェア ロード バランサーの問題が基本的な通話のルーティングなどの SIP トラフィックの要素に影響しないようにすることもできます。DNS load balancing also ensures that hardware load balancer problems do not affect elements of SIP traffic such as basic call routing.

次の図は、内部と外部の両方の DNS 負荷分散を含む例を示しています。The following diagram shows an example that includes both internal and external DNS load balancing:

パブリック IPv4 アドレスを使用したエッジ ネットワーク図Edge network diagram using Public IPv4 addresses

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

また、DNS 負荷分散を使用すると、すべての種類のトラフィックに対応するハードウェア ロード バランサーを使用していた場合よりもハードウェア ロード バランサーを低価格で購入できます。If you use DNS load balancing, you may also be able to purchase lower-cost hardware load balancers than if you used the hardware load balancers for all types of traffic. Skype for Business Server との相互運用性の認定テストに合格したロード バランサーを使用する必要があります。You should use load balancers that have passed interoperability qualification testing with Skype for Business Server. ロード バランサー相互運用性テストの詳細については 、「Lync Server 2010 Load Balancer Partners」を参照してくださいFor details about load balancer interoperability testing, see Lync Server 2010 Load Balancer Partners. Skype for Business Server に適用されるコンテンツ。The content there applies to Skype for Business Server.

DNS 負荷分散は、フロント エンド プール、エッジ サーバー プール、ディレクター プール、およびスタンドアロンの仲介サーバー プールでサポートされます。DNS load balancing is supported for Front End pools, Edge Server pools, Director pools, and stand-alone Mediation Server pools.

DNS 負荷分散は、通常、アプリケーション レベルで実装されます。DNS load balancing is typically implemented at the application level. アプリケーション (Skype for Business を実行しているクライアントなど) は、プールの完全修飾ドメイン名 (FQDN) に対する DNS A および AAAA (IPv6 アドレスが使用されている場合) レコード クエリから返された IP アドレスの 1 つに接続して、プール内のサーバーへの接続を試行します。The application (for example, a client running Skype for Business), tries to connect to a server in a pool by connecting to one of the IP addresses returned from the DNS A and AAAA (if IPv6 addressing is used) record query for the pool fully qualified domain name (FQDN).

たとえば、pool01.contoso.com という名前のプールに 3 つのフロントエンド サーバーがある場合、次のことが発生します。For example, if there are three front end servers in a pool named pool01.contoso.com, the following will happen:

  • Skype for Business を実行しているクライアントは、DNS にクエリをpool01.contoso.com。Clients running Skype for Business query DNS for pool01.contoso.com. クエリは 3 つの IP アドレスを返し、次のようにキャッシュします (必ずしもこの順序ではありません)。The query returns three IP addresses and caches them as follows (not necessarily in this order):

    pool01.contoso.com 192.168.10.90pool01.contoso.com 192.168.10.90

    pool01.contoso.com 192.168.10.91pool01.contoso.com 192.168.10.91

    pool01.contoso.com 192.168.10.92pool01.contoso.com 192.168.10.92

  • クライアントは、IP アドレスの 1 つへの伝送制御プロトコル (TCP) 接続を確立します。The client attempts to establish a Transmission Control Protocol (TCP) connection to one of the IP addresses. これが失敗した場合、クライアントはキャッシュ内の次の IP アドレスを試行します。If that fails, the client tries the next IP address in the cache.

  • TCP 接続が成功すると、クライアントは TLS をネゴシエートして、サーバー上のプライマリ レジストラー pool01.contoso.com。If the TCP connection succeeds, the client negotiates TLS to connect to the primary registrar on pool01.contoso.com.

  • クライアントが接続に成功せずにすべてのキャッシュされたエントリを試行すると、Skype for Business Server を実行しているサーバーが現時点で使用できないという通知がユーザーに表示されます。If the client tries all cached entries without a successful connection, the user is notified that no servers running Skype for Business Server are available at the moment.

注意

DNS ベースの負荷分散は、DNS ラウンド ロビン (DNS RR) とは異なります。DNS ラウンド ロビン (DNS RR) は、通常、DNS に依存してプール内のサーバーに対応する異なる順序の IP アドレスを提供することで負荷分散を指します。DNS-based load balancing is different from DNS round robin (DNS RR) which typically refers to load balancing by relying on DNS to provide a different order of IP addresses corresponding to the servers in a pool. 通常、DNS RR は負荷分散のみを有効にしますが、フェールオーバーは有効にしません。Typically DNS RR only enables load distribution, but does not enable failover. たとえば、DNS A および AAAA (IPv6 アドレス指定を使用している場合) クエリによって返される 1 つの IP アドレスへの接続が失敗した場合、接続は失敗します。For example, if the connection to the one IP address returned by the DNS A and AAAA (if you are using IPv6 addressing) query fails, the connection fails. したがって、DNS ラウンド ロビン自体は DNS ベースの負荷分散よりも信頼性が低い。Therefore, DNS round robin by itself is less reliable than DNS-based load balancing. DNS ラウンド ロビンは、DNS 負荷分散と組み合わせて使用できます。You can use DNS round robin in conjunction with DNS load balancing.

DNS 負荷分散は、次の場合に使用されます。DNS load balancing is used for the following:

  • エッジ サーバーへのサーバー間 SIP の負荷分散Load balancing server-to-server SIP to the Edge Servers

  • 電話会議、応答グループ、コール パークなどのユニファイド コミュニケーション アプリケーション サービス (UCAS) アプリケーション自動応答負荷分散Load balancing Unified Communications Application Services (UCAS) applications such as Conferencing Auto Attendant, Response Group, and Call Park

  • UCAS アプリケーションへの新しい接続の防止 ("ドレイン" とも呼ばれる)Preventing new connections to UCAS applications (also known as "draining")

  • クライアントとエッジ サーバー間のすべてのクライアント間トラフィックの負荷分散Load balancing all client-to-server traffic between clients and Edge Servers

DNS 負荷分散は、次の場合には使用できません。DNS load balancing cannot be used for the following:

  • ディレクターまたはフロントエンド サーバーへのクライアントからサーバーへの Web トラフィックClient-to-server web traffic to Director or Front End Servers

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

DNS SRV クエリによって複数の DNS レコードが返される場合、アクセス エッジ サービスは常に、数値の優先順位が最も低く数値ウェイトが最も高い DNS SRV レコードを選択します。If multiple DNS records are returned by a DNS SRV query, the Access Edge service always picks the DNS SRV record with the lowest numeric priority and highest numeric weight. Internet Engineering Task Force ドキュメント「A DNS RR for specifying the location of services (DNS SRV)」RFC 2782、DNS SRV RR では、定義されている DNS SRV レコードが複数ある場合、優先順位が最初に使用され、重み付けされます。The Internet Engineering Task Force document "A DNS RR for specifying the location of services (DNS SRV)" RFC 2782, DNS SRV RR specifies that if there are multiple DNS SRV records defined, priority is first used, then weight. たとえば、DNS SRV レコード A の重み付けは 20、優先度は 40、DNS SRV レコード B の重みは 10、優先度は 50 です。For example DNS SRV record A has a weight of 20 and a priority of 40 and DNS SRV record B has a weight of 10 and priority of 50. 優先度 40 の DNS SRV レコード A が選択されます。DNS SRV record A with priority 40 will be selected. DNS SRV レコードの選択には、次のルールが適用されます。The following rules apply to DNS SRV record selection:

  • 優先度が最初に考慮されます。Priority is considered first. クライアントは、DNS SRV レコードによって定義されたターゲット ホストに、到達可能な番号付き優先順位が最も低いホストに接続を試みる必要があります。A client MUST attempt to contact the target host defined by the DNS SRV record with the lowest numbered priority it can reach. 優先度が同じターゲットは、重みフィールドで定義された順序で試される必要があります。Targets with the same priority SHOULD be tried in an order defined by the weight field.

  • 重みフィールドは、同じ優先度を持つエントリの相対的な重みを指定します。The weight field specifies a relative weight for entries with the same priority. 重みを大きくすると、選択される確率が比例して高くなります。Larger weights SHOULD be given a proportionately higher probability of being selected. DNS 管理者は、実行するサーバーが選択されていない場合は、重み 0 を使用する必要があります。DNS administrators SHOULD use Weight 0 when there isn't any server selection to do. 重み付けが 0 より大きいレコードがある場合、重み付け 0 のレコードが選択される可能性は非常に小さい必要があります。In the presence of records containing weights greater than 0, records with weight 0 should have a very small chance of being selected.

同じ優先度と重みを持つ複数の DNS SRV レコードが返された場合、アクセス エッジ サービスは DNS サーバーから最初に受信した SRV レコードを選択します。If multiple DNS SRV records with equal priority and weight are returned, the Access Edge service will select the SRV record that was received first from the DNS server.

フロント エンド プールとディレクター プールの DNS 負荷分散DNS Load Balancing on Front End Pools and Director Pools

フロント エンド プールとディレクター プールの SIP トラフィックに DNS 負荷分散を使用できます。 DNS 負荷分散を展開している場合でも、クライアントとサーバー間の HTTPS トラフィックに対してのみ、これらのプールに引き続きハードウェア ロード バランサーを使用する必要があります。 ハードウェア ロード バランサーは、ポート 443 とポート 80 経由のクライアントからの HTTPS トラフィックに対して使用します。You can use DNS load balancing for the SIP traffic on Front End pools and Director pools. With DNS load balancing deployed, you still need to also use hardware load balancers for these pools, but only for client-to-server HTTPS traffic. The hardware load balancer is used for HTTPS traffic from clients over ports 443 and 80.

これらのプール用のハードウェア ロード バランサーは引き続き必要ですが、そのセットアップと管理は主に HTTP トラフィックに対するものであり、ハードウェア ロード バランサーの管理者にはなじみのあるものです。Although you still need hardware load balancers for these pools, their setup and administration will be primarily for HTTPS traffic, which the administrators of hardware load balancers are accustomed to.

DNS 負荷分散およびサポートされる以前のクライアントとサーバーDNS Load Balancing and Supporting Older Clients and Servers

DNS 負荷分散は、Skype for Business Server または Lync Server 2010 を実行しているサーバー、および Lync 2013 および Skype for Business クライアントに対する自動フェールオーバーのみをサポートします。DNS load balancing supports automatic failover only for servers running Skype for Business Server or Lync Server 2010, and for Lync 2013 and Skype for Business clients. 以前のバージョンのクライアントと Office Communications Server は DNS 負荷分散を実行しているプールに接続できますが、DNS 負荷分散が参照する最初のサーバーに接続できない場合は、プール内の別のサーバーにフェールオーバーできません。Earlier versions of clients and Office Communications Server can still connect to pools running DNS load balancing, but if they cannot make a connection to the first server that DNS load balancing refers them to, they are unable to fail over to another server in the pool.

また、Exchange UM を使用している場合は、最低でも Exchange 2010 SP1 を使用して Skype for Business Server DNS 負荷分散のサポートを受け取る必要があります。Additionally, if you are using Exchange UM, you must use a minimum of Exchange 2010 SP1 to get support for Skype for Business Server DNS load balancing. 以前のバージョンの Exchange を使用している場合、ユーザーは次の Exchange UM シナリオに対するフェールオーバー機能を使用しません。If you use an earlier version of Exchange, your users will not have failover capabilities for these Exchange UM scenarios:

  • 電話でのエンタープライズ ボイスメールの再生Playing their Enterprise voicemail on their phone

  • Exchange UM 自動応答から通話を転送するTransferring calls from an Exchange UM Auto Attendant

他のすべての Exchange UM シナリオでは効果があります。All other Exchange UM scenarios will work properly.

フロント エンド プールとディレクター プールへの DNS 負荷分散の展開Deploying DNS Load Balancing on Front End Pools and Director Pools

フロント エンド プールとディレクター プールに DNS 負荷分散を展開するには、FQDN と DNS レコードでいくつか追加の手順を実行する必要があります。Deploying DNS load balancing on Front End pools and Director pools requires you to perform a couple of extra steps with FQDNs and DNS records.

  • DNS 負荷分散を使用するプールには、DNS 負荷分散で使用される通常のプール FQDN (pool01.contoso.com など) と、プール内のサーバーの物理 IP に解決される 2 つの FQDN と、プールの仮想 IP アドレスに解決されるプールの Web サービス用の別の FQDN (web01.contoso.com など) が必要です。A pool that uses DNS load balancing must have two FQDNs: the regular pool FQDN that is used by DNS load balancing (such as pool01.contoso.com), and resolves to the physical IPs of the servers in the pool, and another FQDN for the pool's Web services (such as web01.contoso.com), which resolves to virtual IP address of the pool.

    トポロジ ビルダーでプールの DNS 負荷分散を展開する場合は、プールの Web サービスにこの追加の FQDN を作成するには、[内部 Web サービス プール の FQDN を上書きする] チェック ボックスをオンにして、FQDN を [このプールの Web サービス URL の指定] ページに入力する必要があります。In Topology Builder, if you want to deploy DNS load balancing for a pool, to create this extra FQDN for the pool's Web services you must select the Override internal Web Services pool FQDN check box and type the FQDN, in the Specify the Web Services URLs for this Pool page.

  • DNS 負荷分散で使用される FQDN をサポートするには、プールの FQDN (pool01.contoso.com など) をプール内のすべてのサーバーの IP アドレス (192.168.1.1、192.168.1.2 など) に解決するように DNS をプロビジョニングする必要があります。現在展開されているサーバーの IP アドレスのみ含めるようにしてください。To support the FQDN used by DNS load balancing, you must provision DNS to resolve the pool FQDN (such as pool01.contoso.com) to the IP addresses of all the servers in the pool (for example, 192.168.1.1, 192.168.1.2, and so on). You should include only the IP addresses of servers that are currently deployed.

    注意事項

    複数のフロントエンド プールまたはフロントエンド サーバーがある場合、外部 Web サービスの FQDN は一意である必要があります。If you have more than one Front End pool or Front End Server the external Web services FQDN must be unique. たとえば、フロントエンド サーバーの外部 Web サービス FQDN を pool01.contoso.com として定義する場合、別のフロントエンド プールまたはフロントエンド サーバーに pool01.contoso.com を使用することはできません。For example, if you define the external Web services FQDN of a Front End Server as pool01.contoso.com, you cannot use pool01.contoso.com for another Front End pool or Front End Server. ディレクターも展開する場合、ディレクターまたはディレクター プールに対して定義された外部 Web サービスの FQDN は、他のディレクターまたはディレクター プール、およびフロントエンド プールまたはフロントエンド サーバーから一意である必要があります。If you are also deploying Directors, the external Web services FQDN defined for any Director or Director pool must be unique from any other Director or Director pool as well as any Front End pool or Front End Server. 内部 Web サービスを自己定義の FQDN で上書きする場合、各 FQDN は他のフロントエンド プール、ディレクター、またはディレクター プールから一意である必要があります。If decide to override the Internal web services with a self-defined FQDN, each FQDN must be unique from any other Front End pool, Director or a Director pool.

エッジ サーバー プールの DNS 負荷分散DNS Load Balancing on Edge Server Pools

エッジ サーバー プールに DNS 負荷分散を展開できます。 その場合、いくつかの考慮事項に注意する必要があります。You can deploy DNS load balancing on Edge Server pools. If you do, you must be aware of some considerations.

エッジ サーバーで DNS 負荷分散を使用する場合、次のシナリオではフェールオーバー機能を利用できません。Using DNS load balancing on your Edge Servers causes a loss of failover ability in the following scenarios:

  • Lync Server 2010 より前にリリースされたバージョンの Skype for Business Server を実行している組織とのフェデレーション。Federation with organizations that are running versions of Skype for Business Server released prior to Lync Server 2010.

  • 現在サポートされている唯一の XMPP パートナーである Google Talk などの XMPP ベースのプロバイダーおよびサーバーに加えて、パブリック インスタント メッセージング (IM) サービス AOL および Yahoo! のユーザーとのインスタント メッセージ交換。Instant message exchange with users of public instant messaging (IM) services AOL and Yahoo!, in addition to XMPP-based providers and servers, such as Google Talk, currently the only supported XMPP partner.

これらのシナリオは、プール内のすべてのエッジ サーバーが実行されている限り有効ですが、いずれかのエッジ サーバーが利用できなくなると、これらのシナリオでそのエッジ サーバーに送信されるすべての要求は、別のエッジ サーバーにルーティングされずに失敗します。These scenarios will work as long as all Edge Servers in the pool are up and running, but if one Edge Server is unavailable, any requests for these scenarios that are sent to it will fail, instead of routing to another Edge Server.

Exchange UM を使用している場合は、最低でも Exchange 2013 を使用して、エッジでの Skype for Business Server DNS 負荷分散のサポートを受け取る必要があります。If you are using Exchange UM, you must use a minimum of Exchange 2013 to get support for Skype for Business Server DNS load balancing on Edge. 以前のバージョンの Exchange を使用している場合、リモート ユーザーは次の Exchange UM シナリオに対するフェールオーバー機能を使用しません。If you use an earlier version of Exchange, your remote users will not have failover capabilities for these Exchange UM scenarios:

  • 電話でのエンタープライズ ボイスメールの再生Playing their Enterprise voicemail on their phone

  • Exchange UM 自動応答から通話を転送するTransferring calls from an Exchange UM Auto Attendant

他のすべての Exchange UM シナリオでは効果があります。All other Exchange UM scenarios will work properly.

内部エッジ インターフェイスと外部エッジ インターフェイスでは、同じ種類のロード バランシングを使用する必要があります。1 つのエッジ インターフェイスで DNS ロード バランシングを使用し、もう 1 つのエッジ インターフェイスでロード バランサー機器を使用することはできません。The internal Edge interface and external Edge interface must use the same type of load balancing. You cannot use DNS load balancing on one Edge interface and hardware load balancing on the other Edge interface.

エッジ サーバー プールへの DNS 負荷分散の展開Deploying DNS Load Balancing on Edge Server Pools

エッジ サーバー プールの外部インターフェイスに DNS 負荷分散を展開するには、次の DNS エントリが必要です。To deploy DNS load balancing on the external interface of your Edge Server pool, you need the following DNS entries:

  • アクセス エッジ サービスでは、プール内のサーバーごとに 1 つのエントリが必要です。For the Access Edge service, you need one entry for each server in the pool. 各エントリは、アクセス エッジ サービスの FQDN (sip.contoso.com など) をプール内のいずれかのエッジ サーバー上のアクセス エッジ サービスの IP アドレスに解決する必要があります。Each entry must resolve the FQDN of the Access Edge service (for example, sip.contoso.com) to the IP address of the Access Edge service on one of the Edge Servers in the pool.

  • Web 会議エッジ サービスでは、プール内のサーバーごとに 1 つのエントリが必要です。For the Web Conferencing Edge service, you need one entry for each server in the pool. 各エントリは、Web 会議エッジ サービス (webconf.contoso.com など) の FQDN を、プール内のいずれかのエッジ サーバー上の Web 会議エッジ サービスの IP アドレスに解決する必要があります。Each entry must resolve the FQDN of the Web Conferencing Edge service (for example, webconf.contoso.com) to the IP address of the Web Conferencing Edge service on one of the Edge Servers in the pool.

  • 音声ビデオ エッジ サービスでは、プール内のサーバーごとに 1 つのエントリが必要です。For the Audio/Video Edge service, you need one entry for each server in the pool. 各エントリは、音声ビデオ エッジ サービス (av.contoso.com など) の FQDN を、プール内のいずれかのエッジ サーバー上の音声ビデオ エッジ サービスの IP アドレスに解決する必要があります。Each entry must resolve the FQDN of the Audio/Video Edge service (for example, av.contoso.com) to the IP address of the A/V Edge service on one of the Edge Servers in the pool.

エッジ サーバー プールの内部インターフェイスに DNS ロード バランシングを展開するには、エッジ サーバー プールの内部 FQDN をプール内の各サーバーの IP アドレスに解決する 1 つの DNS A レコードを追加する必要があります。To deploy DNS load balancing on the internal interface of your Edge Server pool, you must add one DNS A record, which resolves the internal FQDN of the Edge Server pool to the IP address of each server in the pool.

仲介サーバー プールでの DNS 負荷分散の使用Using DNS Load Balancing on Mediation Server Pools

スタンドアロンの仲介サーバー プールで、DNS 負荷分散を使用できます。すべての SIP トラフィックとメディア トラフィックは DNS 負荷分散によって調整されます。You can use DNS load balancing on stand-alone Mediation Server pools. All SIP and media traffic is balanced by DNS load balancing.

仲介サーバー プールに DNS 負荷分散を展開するには、プールの FQDN (mediationpool1.contoso.com など) をプール内のすべてのサーバーの IP アドレス (192.168.1.1、192.168.1.2 など) に解決するように DNS をプロビジョニングする必要があります。To deploy DNS load balancing on a Mediation Server pool, you must provision DNS to resolve the pool FQDN (for example, mediationpool1.contoso.com) to the IP addresses of all the servers in the pool (for example, 192.168.1.1, 192.168.1.2, and so on).

DNS 負荷分散を使用したサーバーへのトラフィックのブロックBlocking Traffic to a Server With DNS Load Balancing

DNS 負荷分散を使用し、特定のコンピューターへのトラフィックをブロックする必要がある場合は、プールの FQDN から IP アドレス エントリを削除するだけで十分ではありません。If you use DNS load balancing and you need to block traffic to a specific computer, it is not sufficient to just remove the IP address entries from the Pool FQDN. コンピューターの DNS エントリも削除する必要があります。You must remove the DNS entry for the computer as well.

サーバー間トラフィックの場合、Skype for Business Server はトポロジ対応の負荷分散を使用します。Note that for server-to-server traffic, Skype for Business Server uses topology-aware load balancing. サーバーは中央管理ストアの公開トポロジを読み取り、トポロジ内のサーバーの FQDN を取得し、トラフィックをサーバー間で自動的に分散します。Servers read the published topology in the Central Management store to obtain the FQDNs of servers in the topology, and automatically distribute the traffic among the servers. サーバーがサーバー間トラフィックを受信するのをブロックするには、トポロジからサーバーを削除する必要があります。To block a server from receiving server-to-server traffic, you must remove the server from the topology.