Lync Server 2013 の簡易 URL の DNS 要件

単純な URL オプション 1

オプション 1 では、単純な URL ごとに新しいベース URL を作成します。

単純な URL オプション 1

オプション 1 を使用する場合は、次を定義する必要があります。

• Meet のシンプルな URL ごとに、URL をディレクターの IP アドレスに解決する DNS A レコードが必要です (デプロイされている場合)。 それ以外の場合は、フロントエンド プールのロード バランサーの IP アドレスに解決する必要があります。 プールを展開せず、Standard Edition サーバーの展開を使用している場合、DNS A レコードは組織内の 1 つの Standard Edition サーバーの IP アドレスに解決する必要があります。

  組織内に複数の SIP ドメインがあり、このオプションを使用する場合は、SIP ドメインごとに Meet Simple URL を作成する必要があり、Meet シンプル URL ごとに DNS A レコードが必要です。 たとえば、contoso.com と fabrikam.com の両方がある場合は、両方の https://meet.contoso.com DNS A レコードと https://meet.fabrikam.com.

  または、複数の SIP ドメインがあり、これらの単純な URL の DNS レコードと証明書の要件を最小限に抑える場合は、このトピックの後半で説明するようにオプション 3 を使用します。

• ダイヤルインの単純な URL の場合は、展開されている場合は、URL をディレクターの IP アドレスに解決する DNS A レコードが必要です。 それ以外の場合は、フロントエンド プールのロード バランサーの IP アドレスに解決する必要があります。 プールを展開せず、Standard Edition サーバーの展開を使用している場合、DNS A レコードは組織内の 1 つの Standard Edition サーバーの IP アドレスに解決する必要があります。

• 管理単純な URL は内部のみです。 展開されている場合は、ディレクターの IP アドレスに URL を解決する DNS A レコードが必要です。 それ以外の場合は、フロントエンド プールのロード バランサーの IP アドレスに解決する必要があります。 プールを展開せず、Standard Edition サーバーの展開を使用している場合、DNS A レコードは組織内の 1 つの Standard Edition サーバーの IP アドレスに解決する必要があります。

単純な URL オプション 2

オプション 2 では、Meet、Dial-in、管理 のシンプルな URL はすべて、lync.contoso.com などの共通のベース URL を持っています。 そのため、これらの単純な URL に対して必要な DNS A レコードは 1 つだけです。これにより、ディレクター プールまたはフロント エンド プールの IP アドレスに lync.contoso.com 解決されます。 プールを展開せず、Standard Edition サーバーの展開を使用している場合、DNS A レコードは組織内の 1 つの Standard Edition サーバーの IP アドレスに解決する必要があります。

組織内に複数の SIP ドメインがある場合でも、SIP ドメインごとに Meet シンプル URL を作成する必要があり、Meet 単純 URL ごとに DNS A レコードが必要であることに注意してください。 この例では、3 つの単純な URL がすべて lync.contoso.com に基づいていますが、別のベース URL を使用して追加の Meet simple URL for fabrikam.com が設定されています。 この例では、両方の DNS A レコード https://lync.contoso.com と https://lync.fabrikam.com. 単純な URL オプション 3 では、複数の SIP ドメインがある場合に名前付けと DNS A レコードを処理する別の方法を示します。

単純な URL オプション 2

単純な URL オプション 3

オプション 3 は、多くの SIP ドメインがあり、それらを個別の単純な URL にしたいが、これらの単純な URL の DNS レコードと証明書の要件を最小限に抑えたい場合に最も便利です。 この例では、ディレクター プールまたはフロント エンド プールの IP アドレスに lync.contoso.com を解決する DNS A レコードを 1 つだけ必要とします。

単純な URL オプション 3

単純な URL のディザスター リカバリー オプション

フロント エンド プールを含む複数のサイトがあり、DNS プロバイダーが GeoDNS をサポートしている場合は、ディザスター リカバリーをサポートするシンプル URL の DNS レコードを設定して、1 つのフロントエンド プール全体がダウンしてもシンプル URL 機能が続行されるようにすることができます。 このディザスター リカバリー機能は、Meet と Dial-In のシンプルな URL をサポートします。

これを構成するには、2 つの GeoDNS アドレスを作成します。 各アドレスには、ディザスター リカバリーのためにペアになっている 2 つのプールに解決される 2 つの DNS A または CNAME レコードがあります。 1 つの GeoDNS アドレスが内部アクセスに使用され、2 つのプールの内部 Web FQDN またはロード バランサー IP アドレスに解決されます。 もう 1 つの GeoDNS アドレスは外部アクセスに使用され、2 つのプールの外部 Web FQDN またはロード バランサー IP アドレスに解決されます。 プールの FQDN を使用した Meet 単純な URL の例を次に示します。

 Meet-int.geolb.contoso.com
      Pool1InternalWebFQDN.contoso.com
      Pool2InternalWebFQDN.contoso.com

Meet-ext.geolb.contoso.com
      Pool1ExternalWebFQDN.contoso.com
      Pool2ExternalWebFQDN.contoso.com

次に、Meet の単純な URL (meet.contoso.com など) を 2 つの GeoDNS アドレスに解決する CNAME レコードを作成します。

この方法を使用する場合は、ラウンド ロビン方式を使用して 2 つのプールに要求を分散するか、主に 1 つのプール (地理的に近いプールなど) に接続し、接続障害が発生した場合にのみもう一方のプールを使用するように各 GeoDNS アドレスを構成できます。

ダイヤルインの単純な URL に対して同じ構成を設定できます。 これを行うには、前の例のような追加のレコードを作成し、DNS レコードで置き換えますdialinmeet。 管理単純な URL については、このセクションで前述した 3 つのオプションのいずれかを使用します。

この構成を設定したら、監視アプリケーションを使用して HTTP 監視を設定し、エラーを監視する必要があります。 外部アクセスの場合は、2 つのプールの外部 Web FQDN またはロード バランサー IP アドレスへの HTTPS GET 自動検出要求が成功したことを監視します。 たとえば、次の要求には ACCEPT ヘッダーを含めず、 200 OK を返す必要があります。

    HTTPS GET Pool1ExternalWebFQDN.contoso.com/autodiscover/autodiscoverservice.svc/root
    HTTPS GET Pool2ExternalWebFQDN.contoso.com/autodiscover/autodiscoverservice.svc/root

内部アクセスの場合は、2 つのプールの内部 Web FQDN またはロード バランサーの IP アドレスでポート 5061 を監視する必要があります。 接続エラーが検出された場合、これらのプールの VIP はポート 80、443、および 444 を閉じる必要があります。