高度なエッジ サーバーの DNS を計画する Skype のビジネス サーバー 2015
概要: Skype for Business Server 2015 の展開オプションに関するシナリオを確認します。単一サーバーを使用したいと考えている場合も、DNS または HLB と共にサーバー プールを使用することを優先する場合も、このトピックは役に立ちます。
Skype for Business Server 2015 に関連して DNS (ドメイン ネーム システム) の計画を立てる場合は、決定に影響を及ぼす可能性のある要因が多数存在します。組織のドメイン構造が既に確立されている場合は、どのように作業を進めるか確認するための考慮事項になる可能性があります。最初に、以下に示すトピックについて説明します。
Walkthrough of Skype for Business clients locating services
Split-brain DNS
Automatic configuration without split-brain DNS
DNS disaster recovery
DNS load balancing
Walkthrough of Skype for Business clients locating services
Skype for Business クライアントは、Skype for Business Server 2015 内のサービスを検索およびアクセスする方法に関して、Lync の以前のバージョンに似ています。ここではサーバー検索の詳細について説明します。
lyncdiscoverinternal.<domain>
これは、内部 Web サービスを対象とした自動検出サービスの A ホスト レコードです。
lyncdiscover.<domain>
これは、外部 Web サービスを対象とした自動検出サービスのホスト レコードです。
_sipinternaltls._tcp.<domain>
これは、内部 TLS 接続用の SRV レコードです。
_sip._tls.<domain>
これは、外部 TLS 接続用の SRV レコードです。
sipinternal.<domain>
This is an A host record for the フロントエンド プール or ディレクター, resolvable only on the internal network.
sip.<domain>
This is an A host record for the フロントエンド プール or ディレクター, resolvable only on the internal network.
sipexternal.<domain>
This is an A host record for the アクセス エッジ サービス, when the client is external.
常に自動検出サービスを使用することが望まれます。これはサービス検出に関して優先される方法であり、他の方法はフォールバックの方法です。
注意
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 レコードが一方のゾーン内または他方のゾーン内で一意になることが求められる結果につながります。重複が存在する場合は、これらのレコードに関連付けられる IP アドレスは一意になります。
この構成を採用すると、いくつかの課題が発生します。最も重要な課題は、スプリットブレイン DNS がモビリティで サポートされていない ことです。これは、LyncDiscover と LyncDiscoverInternal の各 DNS レコードが原因です (LyncDiscover は外部 DNS サーバー上で、また LyncDiscoverInternal は内部 DNS サーバー上で定義する必要があります)。
ここでは、内部ゾーンと外部ゾーンのそれぞれに対応する DNS レコードの一覧を示しますが、エッジ サーバーの環境要件に関するセクションで詳細な例を見つけることができます。
内部 DNS
(たとえば) contoso.com という信頼できる DNS ゾーンが含まれています。
以下は、内部 contoso.com の内容です。
フロントエンド プール、ディレクター プール、またはディレクター プールの名前と、組織のネットワーク内で Skype for Business Server 2015 を実行しているすべての内部サーバーに対応する DNS A と AAAA (IPv6 アドレスを使用している場合) レコード。
境界ネットワーク内にある各 Skype for Business Server 2015エッジ サーバーのエッジ内部インターフェイスに対応する DNS A および AAAA (IPv6 アドレスを使用している場合) レコード。
境界ネットワーク内の各リバース プロキシ サーバーの内部インターフェイスに対応する DNS A と AAAA (IPv6 アドレスを使用している場合) レコード (これらのレコードはリバース プロキシを管理する場合の オプション )。
内部 Skype for Business Server 2015 クライアントの自動構成用の DNS A および AAAA (IPv6 アドレスを使用している場合) レコードと SRV レコード (これらのレコードは オプション )。
Skype for Business Server 2015 Web サービスの自動検出用の DNS A および AAAA (IPv6 アドレスを使用している場合) レコードまたは CNAME レコード (これらのレコードは オプション )。
境界ネットワーク内にあるすべての Skype for Business Server 2015 の内部エッジ インターフェイスは、この内部 DNS ゾーンを使用してクエリを contoso.com に解決します。
社内ネットワークで Skype for Business Server 2015 を実行しているすべてのサーバーと、Skype for Business Server 2015 を実行しているすべてのクライアントは、クエリを contoso.com に解決するために内部 DNS サーバーを参照するか、各エッジ サーバー上にある Host ファイルを使用し、次ホップ サーバーに対応する A および AAAA (IPv6 アドレスを使用している場合) レコードを列挙します (特に、ディレクターまたはディレクター プールの VIP、フロントエンド プールの VIP、または Standard Edition サーバーの場合)。
外部 DNS
(たとえば) contoso.com という信頼できる DNS ゾーンが含まれています。
以下は、外部 contoso.com の内容です。
Skype for Business Server 2015 Web サービスの自動検出用の DNS A および AAAA (IPv6 アドレスを使用している場合) レコードまたは CNAME レコード。これらはモビリティで使用することを想定しています。
境界ネットワークの各 Skype for Business Server 2015エッジ サーバーまたはハードウェア負荷分散 (HLB) の VIP のエッジ外部インターフェイスに対応する DNS A および AAAA (IPv6 アドレスを使用している場合) レコードと SRV レコード。
境界ネットワーク内にあるリバース プロキシ サーバーの外部インターフェイス (またはリバース プロキシのプールを表す VIP) に対応する DNS A および AAAA (IPv6 アドレスを使用している場合) レコードと SRV レコード。
Skype for Business Server 2015 クライアント自動構成用の DNS A および AAAA (IPv6 アドレスを使用している場合) レコードと SRV レコード (これらのレコードは オプション )。
スプリットブレイン DNS なしの自動構成
スプリットブレイン DNS を使用しない場合は、ここで提示する回避策のいずれかを使用しない限り、Skype for Business を実行しているクライアントの内部自動構成は機能しません。なぜでしょうか。Skype for Business Server 2015 では、ユーザーの SIP に対応する URL が、自動構成の目的で指定したフロントエンド プールのドメインと一致することが必要とされるためです。この点は、Lync Server の以前のバージョンから変化していません。
たとえば、使用されている SIP ドメインが 2 つある場合、次の DNS SRV レコードが必要です。
_sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com
If a user signs in as bob@contoso.com, this record would work for automatic configuration, as the user's SIP domain matches the domain of the フロントエンド プール (contoso.com).
_sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com
If a user signs in as alice@fabrikam.com, this record would work for automatic configuration of the second domain, again because the SIP domain matches the フロントエンド プール for that domain.
ここまでの例を使用すると、次のレコードは機能しません。
_sipinternaltls._tcp.litwareinc.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com
tim@litwareinc.com としてサインインしたユーザーの場合は、自動構成は機能しません。このユーザーの SIP ドメイン (litwareinc.com) は、プール内のドメイン (fabrikam.com) と一致しないためです。
ここまでで、状況全般を把握しました。スプリットブレイン DNS なしで Skype for Business クライアントの自動構成が必要な場合は、以下のオプションを利用できます。
グループ ポリシー オブジェクト
グループ ポリシー オブジェクト (GPO) を使用して、適切なサーバーの値を設定できます。
注意
このオプションを使用しても自動構成は有効になりませんが、手動構成が自動化されます。この方法を使用した場合、自動構成に関連付ける SRV レコードは必要ありません。
内部ゾーンの一致
外部 DNS ゾーン (contoso.com など) と一致するゾーンを内部 DNS 内に作成してから、自動構成に使用する Skype for Business Server 2015 のプールに対応する DNS A (および IPv6 アドレスを使用している場合は AAAA) レコードを作成します。
たとえば、pool01.contoso.net に所属するユーザーが Skype for Business に bob@contoso.com としてサインインする場合、contoso.com という内部 DNS ゾーンを作成し、その中に pool01.contoso.com に対応する DNS A (および IPv6 アドレスを使用している場合は AAAA) レコードを作成します。
ピンポイントの内部ゾーン
内部 DNS 内にゾーン全体を作成することが適切なオプションではない場合は、自動構成で必要とされる複数の SRV レコードに対応するピンポイント (専用) ゾーンを作成し、dnscmd.exe を使用してそれらのゾーンを設定することができます。DNS ユーザー インターフェイスはピンポイント ゾーンの作成をサポートしていないため、Dnscmd.exe が必須です。
たとえば、SIP ドメインが contoso.com であり、pool01 というフロントエンド プールの中に 2 つのフロントエンド サーバーが存在している場合は、内部 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 を使用している場合は、単一のフロントエンド プール エントリのみが存在することになります。
また、フロントエンド プールの FQDN の値は、例に示した contoso.com と fabrikam.com の間で異なりますが、IP アドレスは同じ値にとどまります。どちらの SIP ドメインからサインインしたユーザーも、自動構成に関して同じフロントエンド プールを使用するためです。
DNS 障害復旧
Skype for Business Server 2015 の Web トラフィックを障害復旧 (DR) およびフェールオーバーのサイトにリダイレクトするように DNS を構成するには、GeoDNS をサポートする DNS プロバイダーを使用する必要があります。障害復旧をサポートする DNS レコードをセットアップできるので、フロントエンド プール全体がダウンした場合でも、Web サービスを使用する機能を引き続き利用できます。この障害復旧機能では、自動検出、会議、およびダイヤルインの簡易 URL をサポートします。
定義し、(AAAA IPv6 を使用する場合) は、GeoDNS プロバイダーで web サービスの内部および外部の解像度の記録その他の DNS ホストを構成します。 以下の詳細は、地理的に分散している、一対のプールを想定していて、ラウンド ロビン DNS 、または プロバイダー か でサポートされている GeoDNS を持っている Pool1 をプライマリとして使用するように構成されて Pool2 に、通信の発生時にフェイル オーバー損失または電源障害が発生。
この表の DNS レコードは、いずれも例です。
| GeoDNS レコード | プール レコード | CNAME レコード | DNS 設定 (オプションを 1 つ選択する) |
|---|---|---|---|
Meet-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
エイリアス Meet.contoso.com を Pool1InternalWebFQDN.contoso.com に指定 エイリアス Meet.contoso.com を Pool2InternalWebFQDN.contoso.com に指定 |
プール間のラウンド ロビン または プライマリを使用し、障害発生時はセカンダリに接続 |
Meet-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
エイリアス Meet.contoso.com を Pool1ExternalWebFQDN.contoso.com に指定 エイリアス Meet.contoso.com を Pool2ExternalWebFQDN.contoso.com に指定 |
プール間のラウンド ロビン または プライマリを使用し、障害発生時はセカンダリに接続 |
Dialin-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
エイリアス Dialin.contoso.com を Pool1InternalWebFQDN.contoso.com に指定 エイリアス Dialin.contoso.com を Pool2InternalWebFQDN.contoso.com に指定 |
プール間のラウンド ロビン または プライマリを使用し、障害発生時はセカンダリに接続 |
Dialin-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
エイリアス Dialin.contoso.com を Pool1ExternalWebFQDN.contoso.com に指定 エイリアス Dialin.contoso.com を Pool2ExternalWebFQDN.contoso.com に指定 |
プール間のラウンド ロビン または プライマリを使用し、障害発生時はセカンダリに接続 |
Lyncdiscoverint-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
エイリアス Lyncdiscoverinternal.contoso.com を Pool1InternalWebFQDN.contoso.com に指定 エイリアス Lyncdiscoverinternal.contoso.com を Pool2InternalWebFQDN.contoso.com に指定 |
プール間のラウンド ロビン または プライマリを使用し、障害発生時はセカンダリに接続 |
Lyncdiscover-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
エイリアス Lyncdiscover.contoso.com を Pool1ExternalWebFQDN.contoso.com に指定 エイリアス Lyncdiscover.contoso.com を Pool2ExternalWebFQDN.contoso.com に指定 |
プール間のラウンド ロビン または プライマリを使用し、障害発生時はセカンダリに接続 |
Scheduler-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
エイリアス Scheduler.contoso.com を Pool1InternalWebFQDN.contoso.com に指定 エイリアス Scheduler.contoso.com を Pool2InternalWebFQDN.contoso.com に指定 |
プール間のラウンド ロビン または プライマリを使用し、障害発生時はセカンダリに接続 |
Scheduler-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
エイリアス Scheduler.contoso.com を Pool1ExternalWebFQDN.contoso.com に指定 エイリアス Scheduler.contoso.com を Pool2ExternalWebFQDN.contoso.com に指定 |
プール間のラウンド ロビン または プライマリを使用し、障害発生時はセカンダリに接続 |
DNS 負荷分散
DNS 負荷分散は一般的に、アプリケーション レベルで実装されます。アプリケーション (Skype for Business を実行するクライアントなど) は、プールの FQDN に対応する DNS A および AAAA (IPv6 アドレスを使用している場合) レコード クエリから返される IP アドレスの 1 つに接続することで、プール内のサーバーへの接続を試みます。
たとえば、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 2015 を実行しているサーバーがないという通知をユーザーが受信します。
注意
DNS ベースの負荷分散は、一般的に、DNS を利用してプール内のサーバーの IP アドレスを別の順序で提供して負荷分散を行うことを指す DNS ラウンド ロビン (DNS RR) と異なります。一般的に、DNS RR は負荷分散が可能で、フェールオーバー機能を実現しません。たとえば、DNS A (または IPv6 のシナリオを使用している場合は AAAA) クエリで返された 1 つの IP アドレスに対する接続が失敗した場合、その接続は失敗します。したがって、DNS RR は DNS ベースの負荷分散より信頼性が劣りますが、上記の目的で、DNS 負荷分散と共に DNS RR を引き続き使用することができます。
DNS 負荷分散の用途:
サーバー間の SIP からエッジ サーバーへの負荷分散
会議自動アテンダント、応答グループ、コール パークなどの統合コミュニケーション アプリケーション サービス (UCAS) アプリケーションの負荷分散
UCAS アプリケーションへの新規接続の禁止(ドレインとも呼ばれます)
クライアントとエッジ サーバー間における、クライアントとサーバー間のすべてのトラフィックの負荷分散
DNS 負荷分散を使用できない用途:
- クライアントとサーバー間の Web トラフィックをフロントエンド サーバーまたはディレクターに負荷分散
複数の DNS レコードが、クエリによって返されるときに DNS SRV レコードをどのように選択するのに、もう少し詳細に、アクセス エッジ サービス常に優先度の低い数値のレコードを取得タイ ブレーカーが必要な場合とは、最大の数値の重量です。 これは、インターネット技術標準化委員会マニュアルと一致します。
そのため、たとえば最初の DNS SRV レコードの重み付けが 20 で、優先順位が 40、また 2 番目の DNS SRV レコードの重み付けが 10 で、優先順位が 50 の場合は、優先順位が 40 である最初のレコードが選択されます。常に優先順位が最初に考慮され、クライアントが最初にターゲットにするホストになります。同じ優先順位を持つターゲットが 2 つ存在する場合はどうなるでしょうか。
この場合は、重み付けが考慮されます。この状況では、重み付けが大きいほど、選択される確率が高くなります。サーバー選択を行わない場合は、DNS 管理者は重み付け 0 を使用する必要があります。0 より大きい重み付けを持つレコードが存在するとき、重み付け 0 のレコードが選択される可能性は非常に小さくなります。
同じ優先度と重み付けを持つ複数の DNS SRV レコードが返された場合は、どうなるでしょうか。この状況で、アクセス エッジ サービスは、DNS サーバーから最初に受け取った SRV レコードを選択します。