Skype for Business Serverの Advanced Edge Server の展開を計画する

  • [アーティクル]

概要：Skype for Business Server展開オプションのシナリオを確認します。 単一サーバーを使用したいと考えている場合も、DNS または HLB と共にサーバー プールを使用することを優先する場合も、このトピックは役に立ちます。

Skype for Business Serverのドメイン ネーム システム (DNS) 計画に関しては、多くの要因が決定に影響する可能性があります。 組織のドメイン構造が既に確立されている場合は、どのように作業を進めるか確認するための考慮事項になる可能性があります。 最初に、以下に示すトピックについて説明します。

Walkthrough of Skype for Business clients locating services

Skype for Businessクライアントは、Skype for Business Serverでサービスを検索してアクセスする方法で、以前のバージョンの Lync クライアントと似ています。 ここではサーバー検索の詳細について説明します。

  1. lyncdiscoverinternal。<ドメイン>

    これは、内部 Web サービスを対象とした自動検出サービスの A ホスト レコードです。

  2. lyncdiscover。<ドメイン>

    これは、外部 Web サービスを対象とした自動検出サービスのホスト レコードです。

  3. _sipinternaltls._tcp。<ドメイン>

    これは、内部 TLS 接続の SRV レコードです。

  4. _sip._tls。<ドメイン>

    これは、外部 TLS 接続の SRV レコードです。

  5. sipinternal。<ドメイン>

    これはフロントエンド プールまたはディレクターのホスト レコードであり、内部ネットワークでのみ解決できます。

  6. Sip。<ドメイン>

    これはフロントエンド プールまたはディレクターのホスト レコードであり、内部ネットワークでのみ解決できます。

  7. sipexternal。<ドメイン>

    これは、クライアントが外部にある場合の Access Edge サービスの A ホスト レコードです。

常に自動検出サービスを使用することが望まれます。これはサービス検出に関して優先される方法であり、他の方法はフォールバックの方法です。

注意

SRV レコードを作成する場合は、DNS SRV レコードを作成するのと同じドメインにある DNS の A レコード (および、IPv6 アドレスを使用している場合は AAAA レコード) を指す必要があります。 たとえば、SRV レコードが contoso.com にある場合、A (および AAAA) レコードが fabrikam.com を指すことはできません。

希望する場合は、サービスの手動検出に依存するようにモバイル デバイスを設定することもできます。 この方法を採用しようとする場合は、各ユーザーが自らのモバイル デバイスで、次のようにプロトコルとパスを含め、内部と外部の完全な自動検出サービス URL を構成する必要があります。

  • 外部アクセスの場合: https://< ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root

  • 内部アクセスの場合: https://< IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root

手動検出ではなく、自動検出を使用することを強くお勧めします。 ただし、トラブルシューティングやテストを実行する場合は、手動設定が非常に役に立つこともあります。

スプリットブレイン DNS

これは、2 つの DNS ゾーンが同じ名前空間に存在する DNS 構成です。 一方の DNS ゾーンは内部要求のみ、他方の DNS ゾーンは外部要求のみを処理します。

会社がこれを行う理由 内部および外部で同じ名前空間を使用する必要がある場合がありますが、もちろん、多くの DNS SRV と A レコードが 1 つのゾーンまたは別のゾーンに固有であり、重複がある場合、これらのレコードに関連付けられている IP アドレスは一意になります。

この構成を採用すると、いくつかの課題が発生します。 最も重要なのは、スプリットブレイン DNS がモビリティ でサポートされていないこと です。 これは、LyncDiscover と LyncDiscoverInternal の各 DNS レコードが原因です (LyncDiscover は外部 DNS サーバー上で、また LyncDiscoverInternal は内部 DNS サーバー上で定義する必要があります)。

ここでは、内部ゾーンと外部ゾーンの DNS レコードの一覧を示しますが、詳細な例については、Edge Server の環境要件に関するセクションを参照してください。

内部 DNS

  • (たとえば) contoso.com という信頼できる DNS ゾーンが含まれています。

  • 以下は、内部 contoso.com の内容です。

    • フロントエンド プール、ディレクター プールまたはディレクター プール名、およびorganizationのネットワークでSkype for Business Server実行されているすべての内部サーバーの DNS A と AAAA (IPv6 アドレス指定を使用している場合) レコード。

    • 境界ネットワーク内の各エッジ サーバーのエッジ内部インターフェイスの DNS A と AAAA (IPv6 アドレス指定を使用している場合) レコードSkype for Business Server。

    • 境界ネットワーク内の各リバース プロキシ サーバーの内部インターフェイスの DNS A と AAAA (IPv6 アドレス指定を使用している場合) レコード (リバース プロキシの管理には 省略可能 )。

    • DNS A と AAAA (IPv6 アドレッシングを使用している場合) と SRV レコードは、内部Skype for Business Serverクライアントの自動構成 (省略可能) です。

    • DNS A と AAAA (IPv6 アドレス指定を使用している場合) または CNAME レコードを使用して、Skype for Business Server Web サービスの自動検出 (省略可能) します。

  • 境界ネットワーク内のすべてのSkype for Business Server内部エッジ インターフェイスは、この内部 DNS ゾーンを使用して、クエリを contoso.com に解決します。

  • Skype for Business Serverを実行しているすべてのサーバーと、企業ネットワークでSkype for Business Serverを実行しているクライアントは、クエリを contoso.com に解決するために内部 DNS サーバーをポイントするか、各エッジ サーバーのホスト ファイルを使用して、次ホップ サーバー (特にディレクターまたはディレクター プール用) の A レコードと AAAA レコードを一覧表示します (IPv6 アドレス指定を使用している場合)。VIP、フロントエンド プール VIP、または Standard Edition サーバー)。

外部 DNS

  • (たとえば) contoso.com という信頼できる DNS ゾーンが含まれています。

  • 以下は、外部 contoso.com の内容です。

    • DNS A と AAAA (IPv6 アドレス指定を使用している場合)、または CNAME レコード (Skype for Business Server Web サービスの自動検出用)。 これはモビリティで使用するために使用されます。

    • 境界ネットワーク内の各 Skype for Business Server エッジ サーバーまたはハードウェア負荷分散 (HLB) VIP のエッジ外部インターフェイスの DNS A と AAAA (IPv6 アドレス指定を使用している場合) と SRV レコード。

    • 境界ネットワークのリバース プロキシ サーバーの外部インターフェイスまたは (リバース プロキシ サーバーのプールの VIP) の DNS A と AAAA (IPv6 アドレス指定を使用している場合) と SRV レコード。

    • DNS A と AAAA (IPv6 アドレス指定を使用している場合) と、Skype for Business Server クライアントの自動構成 (省略可能) の SRV レコード。

スプリットブレイン DNS なしの自動構成

スプリットブレイン DNS を使用しない場合、ここで用意されている回避策のいずれかを使用しない限り、Skype for Businessを実行しているクライアントの内部自動構成は機能しません。 なぜでしょうか。 Skype for Business Serverでは、ユーザーの SIP URI が、自動構成用に指定されたフロントエンド プールのドメインと一致する必要があるためです。 これは以前のバージョンの Lync Server から変更されていません。

たとえば、使用されている SIP ドメインが 2 つある場合、次の DNS SRV レコードが必要です。

  • _sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com

    としてサインイン bob@contoso.comすると、ユーザーの SIP ドメインがフロントエンド プール (contoso.com) のドメインと一致する場合、このレコードは自動構成で機能します。

  • _sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

    ユーザーが として alice@fabrikam.comサインインすると、SIP ドメインがそのドメインのフロントエンド プールと一致するため、このレコードは 2 番目のドメインの自動構成で機能します。

ここまでの例を使用すると、次のレコードは機能しません。

  • _sipinternaltls._tcp.litwareinc.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

    SIP ドメイン (litwareinc.com) がプール内のドメイン (fabrikam.com) と一致しないため、ユーザーが として tim@litwareinc.com サインインしても自動構成では機能しません。

これで、スプリットブレイン DNS を使用しないSkype for Business クライアントの自動要件が必要な場合は、次のオプションがあります。

  • グループ ポリシー オブジェクト

    グループ ポリシー オブジェクト (GPO) を使用して、適切なサーバーの値を設定できます。

    注意

    このオプションを使用しても自動構成は有効になりませんが、手動構成が自動化されます。 この方法を使用した場合、自動構成に関連付ける SRV レコードは必要ありません。

  • 内部ゾーンの一致

    外部 DNS ゾーン (contoso.com など) に一致するゾーンを内部 DNS に作成し、自動構成に使用されるSkype for Business Server プールに対応する DNS A (および IPv6 アドレス指定を使用している場合は AAAA) レコードを作成する必要があります。

    たとえば、ユーザーが pool01.contoso.net に所属していても、 としてbob@contoso.comSkype for Businessにサインインしている場合は、contoso.com という内部 DNS ゾーンを作成し、その中に pool01.contoso.com の DNS A (IPv6 アドレス指定が使用されている場合は AAAA) レコードを作成する必要があります。

  • ピンポイントの内部ゾーン

    内部 DNS 内にゾーン全体を作成することが適切なオプションではない場合は、自動構成で必要とされる複数の SRV レコードに対応するピンポイント (専用) ゾーンを作成し、dnscmd.exe を使用してそれらのゾーンを設定することができます。 DNS ユーザー インターフェイスはピンポイント ゾーンの作成をサポートしていないため、Dnscmd.exe が必須です。

    たとえば、SIP ドメインが contoso.com で、2 つのフロントエンド サーバーを含む pool01 というフロントエンド プールがある場合、内部 DNS には次のピンポイント ゾーンと A レコードが必要です。

    dnscmd . /zoneadd _sipinternaltls._tcp.contoso.com. /dsprimary
dnscmd . /recordadd _sipinternaltls._tcp.contoso.com. @ SRV 0 0 5061 pool01.contoso.com.
dnscmd . /zoneadd pool01.contoso.com. /dsprimary
dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.90
dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.91 
dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>

    環境内で 2 番目の SIP ドメインを用意することもできます。 この場合は、内部 DNS 内で以下のピンポイント ゾーンと A レコードが必要になります。

    dnscmd . /zoneadd _sipinternaltls._tcp.fabrikam.com. /dsprimary
dnscmd . /recordadd _sipinternaltls._tcp.fabrikam.com. @ SRV 0 0 5061 pool01.fabrikam.com.
dnscmd . /zoneadd pool01.fabrikam.com. /dsprimary
dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.90
dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.91
dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>

注意

フロントエンド プールの FQDN が 2 回表示されますが、2 つの異なる IP アドレスが表示されます。 DNS 負荷分散を使用しているためです。 HLB を使用する場合、フロントエンド プール エントリは 1 つだけです。

注意

また、フロントエンド プールの FQDN 値は、contoso.com と fabrikam.com の例の間で変化しますが、IP アドレスは変わりません。 これは、いずれかの SIP ドメインからサインインしているユーザーが、自動構成に同じフロントエンド プールを使用するためです。

DNS 障害復旧

web トラフィックSkype for Business Serverディザスター リカバリー (DR) サイトとフェールオーバー サイトにリダイレクトするように DNS を構成するには、GeoDNS をサポートする DNS プロバイダーを使用する必要があります。 ディザスター リカバリーをサポートするように DNS レコードを設定すると、フロントエンド プール全体がダウンしても Web サービスを使用する機能が続行されます。 この障害復旧機能では、自動検出、会議、およびダイヤルインの簡易 URL をサポートします。

You define and configure additional DNS host A (AAAA if using IPv6) records for internal and external resolution of web services at your GeoDNS provider. 次の詳細では、ペアプールが地理的に分散しており 、プロバイダーで サポートされている GeoDNS にラウンド ロ ビン DNS があるか 、Pool1 をプライマリとして使用するように構成されており、通信の損失や電源障害がある場合は Pool2 にフェールオーバーすることを前提としています。

この表の DNS レコードは、いずれも例です。

GeoDNS レコード プール レコード CNAME レコード DNS 設定 (オプションを 1 つ選択する)
Meet-int.geolb.contoso.com
 Pool1InternalWebFQDN.contoso.com
Pool2InternalWebFQDN.contoso.com
 Meet-int.geolb.contoso.com への Meet.contoso.com

 プール間のラウンド ロビン
または
プライマリを使用し、障害発生時はセカンダリに接続
Meet-ext.geolb.contoso.com
 Pool1ExternalWebFQDN.contoso.com
Pool2ExternalWebFQDN.contoso.com
 Meet-ext.geolb.contoso.com への Meet.contoso.com

 プール間のラウンド ロビン
または
プライマリを使用し、障害発生時はセカンダリに接続
Dialin-int.geolb.contoso.com
 Pool1InternalWebFQDN.contoso.com
Pool2InternalWebFQDN.contoso.com
 Meet-int.geolb.contoso.com への Meet.contoso.com

 プール間のラウンド ロビン
または
プライマリを使用し、障害発生時はセカンダリに接続
Dialin-ext.geolb.contoso.com
 Pool1ExternalWebFQDN.contoso.com
Pool2ExternalWebFQDN.contoso.com
 Meet-ext.geolb.contoso.com への Meet.contoso.com

 プール間のラウンド ロビン
または
プライマリを使用し、障害発生時はセカンダリに接続
Lyncdiscoverint-int.geolb.contoso.com
 Pool1InternalWebFQDN.contoso.com
Pool2InternalWebFQDN.contoso.com
 Meet-int.geolb.contoso.com への Meet.contoso.com

 プール間のラウンド ロビン
または
プライマリを使用し、障害発生時はセカンダリに接続
Lyncdiscover-ext.geolb.contoso.com
 Pool1ExternalWebFQDN.contoso.com
Pool2ExternalWebFQDN.contoso.com
 Meet-ext.geolb.contoso.com への Meet.contoso.com

 プール間のラウンド ロビン
または
プライマリを使用し、障害発生時はセカンダリに接続
Scheduler-int.geolb.contoso.com
 Pool1InternalWebFQDN.contoso.com
Pool2InternalWebFQDN.contoso.com
 Meet-int.geolb.contoso.com への Meet.contoso.com

 プール間のラウンド ロビン
または
プライマリを使用し、障害発生時はセカンダリに接続
Scheduler-ext.geolb.contoso.com
 Pool1ExternalWebFQDN.contoso.com
Pool2ExternalWebFQDN.contoso.com
 Meet-ext.geolb.contoso.com への Meet.contoso.com

 プール間のラウンド ロビン
または
プライマリを使用し、障害発生時はセカンダリに接続

DNS 負荷分散

DNS 負荷分散は一般的に、アプリケーション レベルで実装されます。 アプリケーション (たとえば、Skype for Businessを実行しているクライアント) は、プール FQDN の DNS A および AAAA (IPv6 アドレス指定が使用されている場合) レコード クエリから返されるいずれかの 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 アドレスの 1 つに対して TCP 接続を確立しようとします。 失敗した場合は、その一覧からキャッシュされた次の IP アドレスが試されます。

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

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

注意

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

DNS 負荷分散の用途:

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

  • 会議自動アテンダント、応答グループ、コール パークなどの統合コミュニケーション アプリケーション サービス (UCAS) アプリケーションの負荷分散

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

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

DNS 負荷分散を使用できない用途:

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

クエリによって複数の DNS レコードが返されたときに DNS SRV レコードがどのように選択されるかについてもう少し詳しく説明するために、Access Edge サービスは常に最も低い数値の優先順位でレコードを選択し、タイ ブレーカーが必要な場合は最も高い数値の重みを取得します。 これは、 インターネット エンジニアリング タスク フォースのドキュメントと一致します。

そのため、たとえば最初の DNS SRV レコードの重み付けが 20 で、優先順位が 40、また 2 番目の DNS SRV レコードの重み付けが 10 で、優先順位が 50 の場合は、優先順位が 40 である最初のレコードが選択されます。 常に優先順位が最初に考慮され、クライアントが最初にターゲットにするホストになります。 同じ優先順位を持つターゲットが 2 つ存在する場合はどうなるでしょうか。

この場合は、重み付けが考慮されます。 この状況では、重み付けが大きいほど、選択される確率が高くなります。 サーバー選択を行わない場合は、DNS 管理者は重み付け 0 を使用する必要があります。 重みが 0 より大きいレコードが存在する場合、重み 0 のレコードでは、持ち込みが選択される可能性が小さくなります。

同じ優先度と重み付けを持つ複数の DNS SRV レコードが返された場合は、どうなるでしょうか。 このような場合、Access Edge サービスは、最初に DNS サーバーから取得した SRV レコードを選択します。