비즈니스용 Skype의 DNS 요구 사항

Skype for Business Server 2015
 

마지막으로 수정된 항목: 2016-12-20

비즈니스용 Skype 서버를 배포하려면 클라이언트 및 서버 검색을 사용하도록 설정하는 DNS(Domain Name System) 레코드를 만들어야 하며, 원하는 경우 자동 클라이언트 로그인도 지원해야 합니다(조직에서 지원하려는 경우).

비즈니스용 Skype 서버에서는 다음과 같은 방식으로 DNS가 사용됩니다.

  • 서버 간 통신을 위한 내부 서버 또는 풀을 검색합니다.

  • 클라이언트가 다양한 SIP 트랜잭션에 사용되는 프런트 엔드 풀 또는 Standard Edition 서버를 검색할 수 있도록 합니다.

  • 로그온하지 않은 UC(통합 통신) 장치가 장치 업데이트 웹 서비스를 실행하는 프런트 엔드 풀 또는 Standard Edition 서버를 검색하고 업데이트를 가져오고 로그를 보낼 수 있도록 합니다.

  • 외부 서버 및 클라이언트가 메신저 대화 또는 회의를 위해 에지 서버 또는 HTTP 역방향 프록시에 연결할 수 있도록 합니다.

  • 외부 UC 장치가 에지 서버 또는 HTTP 역방향 프록시를 통해 장치 업데이트 웹 서비스에 연결하고 업데이트를 가져올 수 있도록 합니다.

  • 사용자가 장치 설정에 URL을 수동으로 입력할 필요 없이 모바일 클라이언트가 웹 서비스 리소스를 자동으로 검색할 수 있도록 합니다.

다음 순서도를 사용하여 DNS(Domain Name System) 요구 사항을 확인할 수 있습니다.

important중요:
비즈니스용 Skype 서버에서는 IPv6 주소 지정을 사용할 수 있도록 지원합니다. IPv6 주소를 사용하려면 IPv6 DNS에 대한 지원을 제공하고 DNS 호스트 AAAA(“4자리 A”라고도 함) 레코드를 구성해야 합니다. IPv4와 IPv6를 모두 사용하는 배포에서는 IPv4를 위한 호스트 A 레코드와 IPv6를 위한 호스트 AAAA를 모두 구성하고 관리하는 것이 좋습니다. 배포를 완전히 IPv6로 전환했더라도 외부 사용자가 아직 IPv4를 사용하는 경우 IPv4 DNS 호스트 레코드가 여전히 필요할 수 있습니다.

DNS 요구 사항 확인 순서도

DNS 순서도 - 마이너스 분할
important중요:
기본적으로 도메인에 가입되지 않은 컴퓨터의 컴퓨터 이름은 FQDN(정규화된 도메인 이름)이 아닌 호스트 이름입니다. 토폴로지 작성기에서는 호스트 이름이 아닌 FQDN을 사용합니다. 따라서 도메인에 가입되지 않은 에지 서버로 배포할 컴퓨터의 이름에 DNS 접미사를 구성해야 합니다. 비즈니스용 Skype 서버를 실행하는 서버에 FQDN을 할당할 때는 표준 문자만 사용하고(A-Z, a-z, 0-9, 하이픈 등) 유니코드 문자나 밑줄을 사용하지 마세요. FQDN의 비표준 문자는 외부 DNS 및 공용 CA(인증서의 SN에 FQDN을 할당해야 하는 경우)에서 지원되지 않는 경우가 많습니다. 자세한 내용은 Lync Server 2013에 대한 DNS 호스트 레코드 구성을 참조하세요.

비즈니스용 Skype 및 Lync 2013에서는 클라이언트가 비즈니스용 Skype 서버에서 서비스를 찾아 액세스하는 방법이 비슷합니다. 다른 서비스 위치 프로세스를 사용하는 Lync Windows 스토어 앱의 경우는 예외입니다. 이 섹션에서는 클라이언트가 서비스를 찾는 방법과 관련한 두 가지 시나리오에 대해 자세히 설명하는데, 그중 첫 번째는 일련의 SRV 및 A 호스트 레코드를 사용하는 기존의 방법이고 두 번째는 자동 검색 서비스 레코드만 사용하는 것입니다. 모든 클라이언트에 대해 올바른 쿼리가 반환되거나 가능한 DNS 레코드 목록을 모두 확인하여 클라이언트로 최종 오류가 반환될 때까지 DNS 쿼리 프로세스는 계속됩니다.

Lync Windows 스토어 앱을 제외한 모든 클라이언트에 대해 DNS 조회 중에 SRV 레코드가 쿼리되어 다음 순서로 클라이언트에 반환됩니다.

  1. lyncdiscoverinternal.<domain>   내부 웹 서비스의 자동 검색 서비스용 A(호스트) 레코드입니다.

  2. lyncdiscover.<domain>   외부 웹 서비스의 자동 검색 서비스용 A(호스트) 레코드입니다.

  3. _sipinternaltls._tcp.<domain>   내부 TLS 연결용 SRV(서비스 로케이터) 레코드입니다.

  4. _sipinternal._tcp.<domain>   내부 TCP 연결용(TCP가 허용되는 경우에만 수행됨) SRV(서비스 로케이터) 레코드입니다.

  5. _sip._tls.<domain>   외부 TLS 연결용 SRV(서비스 로케이터) 레코드입니다.

  6. sipinternal.<domain>   프런트 엔드 풀 또는 디렉터용 A(호스트) 레코드로, 내부 네트워크에서만 확인할 수 있습니다.

  7. sip.<domain>   내부 네트워크의 프런트 엔드 풀 또는 디렉터용(클라이언트가 외부에 있는 경우에는 액세스 에지 서비스용) A(호스트) 레코드입니다.

  8. sipexternal.<domain>   클라이언트가 외부에 있는 경우 액세스 에지 서비스용 A(호스트) 레코드입니다.

Lync Windows 스토어 앱은 다음의 2개 레코드를 사용하므로 프로세스가 완전히 변경됩니다.

  1. lyncdiscoverinternal.<domain>   내부 웹 서비스의 자동 검색 서비스용 A(호스트) 레코드입니다.

  2. lyncdiscover.<domain>   외부 웹 서비스의 자동 검색 서비스용 A(호스트) 레코드입니다.

다른 레코드 유형이 대체 항목으로 사용되지는 않습니다.

이전 클라이언트와 최신 클라이언트에 사용되는 방법 간의 차이는 자동 검색 서비스가 모든 서비스를 찾는 기본 방법으로 사용된다는 점입니다.

연결이 성공하면 자동 검색 서비스에서 Mobility Service(IIS에서 서비스용으로 작성된 가상 디렉터리에서는 Mcx로 확인됨), Microsoft Lync Web App 및 Web Scheduler URL을 비롯하여 사용자 홈 풀의 모든 웹 서비스 URL을 반환합니다. 그러나 내부 Mobility Service URL과 외부 Mobility Service URL은 모두 외부 웹 서비스 FQDN에 연결됩니다. 따라서 모바일 장치는 네트워크 내부에 있든 외부에 있든 관계없이 항상 역방향 프록시를 통해 외부적으로 Mobility Service에 연결합니다.

자동 검색 서비스는 내부/UCWA, 외부/UCWA 및 UCWA에 대한 참조도 반환합니다. 이러한 항목은 UCWA(통합 통신 웹 API) 웹 구성 요소를 참조합니다. 현재는 UCWA 항목만 사용되어 웹 구성 요소의 URL에 대한 참조를 제공합니다. UCWA는 비즈니스용 Skype 클라이언트에서 사용하는 Mcx Mobility Service 대신 Lync 2010 Mobile 모바일 클라이언트에서 사용됩니다.

note참고:
SRV 레코드를 만들 때 이러한 레코드는 DNS SRV가 만들어진 곳과 같은 도메인에 있는 DNS A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 레코드를 가리켜야 합니다. 예를 들어 SRV 레코드가 contoso.com에 있는 경우 이 레코드가 가리키는 A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 레코드는 fabrikam.com에 있을 수 없습니다.
tip팁:
기본 구성은 모든 모바일 클라이언트 트래픽이 외부 사이트를 통과하도록 지정하는 것입니다. 요구 사항에 보다 적합한 경우에는 내부 URL만 반환되도록 설정을 수정할 수 있습니다. 이 구성의 경우 사용자는 회사 네트워크 내에 있을 때만 모바일 장치에서 Lync 모바일 응용 프로그램을 사용할 수 있습니다. 이 구성을 정의하려면 Set-CsMcxConfiguration cmdlet을 사용합니다.
note참고:
모바일 응용 프로그램은 주소록 서비스 등의 다른 비즈니스용 Skype 서버 서비스에도 연결할 수 있지만, 내부 모바일 응용 프로그램 웹 요청은 Mobility Service에 대해서만 외부 웹 FQDN으로 이동합니다. 주소록 요청 등의 다른 서비스 요청에는 이 구성이 필요하지 않습니다.

모바일 장치는 서비스를 수동으로 검색할 수 있습니다. 이 경우 각 사용자는 프로토콜과 경로를 포함하여 전체 내부/외부 자동 검색 서비스 URI로 모바일 장치 설정을 다음과 같이 구성해야 합니다.

  • https://<ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/외부 액세스 루트

  • https://<IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/내부 액세스 루트

가능한 경우에는 수동 검색보다 자동 검색을 사용하는 것이 좋습니다. 그러나 모바일 장치 연결 문제를 해결하려는 경우에는 수동 설정을 사용하는 것이 유용합니다.

분할 DNS(split-brain DNS)는 여러 가지 이름(예: split DNS 또는 split-horizon DNS)으로 알려져 있는데, 간단히 말해 네임스페이스가 동일한 두 DNS 영역이 있는 DNS 구성을 나타냅니다. 분할 DNS의 한 DNS 영역은 내부 전용 요청을 처리하고 다른 DNS 영역은 외부 전용 요청을 처리합니다. 그러나 내부 DNS에 포함된 많은 DNS SRV 및 A 레코드가 외부 DNS에는 포함되지 않으며, 그 반대의 경우도 마찬가지입니다. 또한 같은 DNS 레코드가 내부 DNS와 외부 DNS(예: www.contoso.com)에 존재하는 경우 DNS 쿼리가 실행된 위치(내부 또는 외부)에 따라 반환되는 IP 주소가 다릅니다.

important중요:
모바일 기능(구체적으로는 LyncDiscover 및 LyncDiscoverInternal DNS 레코드)에 대해서는 현재 분할 DNS가 지원되지 않습니다. LyncDiscover는 외부 DNS 서버에 대해 정의해야 하며 LyncDiscoverInternal은 내부 DNS 서버에 대해 정의해야 합니다.

이 항목에서는 분할 DNS라는 용어를 사용하겠습니다.

분할 DNS를 구성하는 경우 다음 내부 및 외부 영역에 각 영역에서 필요한 DNS 레코드 유형에 대한 요약이 포함됩니다. 자세한 내용은 Lync Server 2013의 외부 사용자 액세스에 대한 시나리오를 참조하세요.

내부 DNS:

  • 신뢰할 수 있는 contoso.com이라는 DNS 영역을 포함합니다.

  • 내부 contoso.com 영역에는 다음이 포함됩니다.

    • 내부 비즈니스용 Skype 서버 클라이언트 자동 구성을 위한 DNS A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 및 SRV 레코드(선택 사항)

    • 비즈니스용 Skype 서버 웹 서비스 자동 검색을 위한 DNS A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 및 CNAME 레코드(선택 사항)

    • 프런트 엔드 풀 이름, 디렉터 또는 디렉터 풀 이름, 회사 네트워크에서 비즈니스용 Skype 서버를 실행하는 모든 내부 서버에 대한 DNS A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 레코드

    • 경계 네트워크에 있는 각 비즈니스용 Skype 서버, 에지 서버의 에지 내부 인터페이스에 대한 DNS A 및 AAAA(IPv6 주소 지정을 사용하는 경우)

    • 경계 네트워크에 있는 각 역방향 프록시 서버의 내부 인터페이스에 대한 DNS A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 레코드(역방향 프록시 관리를 위한 선택 사항)

    • 경계 네트워크의 모든 비즈니스용 Skype 서버 에지 서버 내부 에지 인터페이스는 contoso.com에 대한 쿼리를 확인하기 위해 내부 DSN 영역을 사용합니다.

    • 회사 네트워크에서 비즈니스용 Skype 서버를 실행하는 모든 서버와 비즈니스용 Skype를 실행하는 모든 클라이언트는 contoso.com에 대한 쿼리를 확인하기 위해 내부 DSN 서버를 가리키거나 각 에지 서버에 있는 HOSTS 파일을 사용하고 다음 홉 서버, 특히 디렉터 또는 디렉터 VIP, 프런트 엔드 풀 VIP 또는 Standard Edition Server에 대한 A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 레코드를 나열합니다.

외부 DNS:

  • 신뢰할 수 있는 contoso.com이라는 DNS 영역을 포함합니다.

  • 외부 contoso.com 영역에는 다음이 포함됩니다.

    • 비즈니스용 Skype 서버 클라이언트 자동 구성을 위한 DNS A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 및 SRV 레코드(선택 사항)

    • 모바일 기능과 함께 사용할 비즈니스용 Skype 서버 웹 서비스의 자동 검색을 위한 DNS A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 및 CNAME 레코드

    • 경계 네트워크에 있는 각 비즈니스용 Skype 서버, 에지 서버 또는 하드웨어 부하 분산 장치 VIP(가상 IP)의 에지 외부 인터페이스에 대한 DNS A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 및 SRV 레코드

    • 경계 네트워크에 있는 역방향 프록시 서버 또는 역방향 프록시 서버 풀 VIP의 외부 인터페이스에 대한 DNS A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 레코드

분할 DNS를 사용하면 내부적으로 로그인한 비즈니스용 Skype 서버 사용자가 내부 DNS 영역에 사용 중인 각 SIP 도메인의 _sipinternaltls._tcp SRV 레코드가 포함된 경우 자동 구성을 사용할 수 있습니다. 그러나 분할 DNS를 사용하지 않는 경우에는 이 섹션의 뒷부분에 설명된 해결 방법 중 하나를 구현하지 않는 한 비즈니스용 Skype를 실행하는 클라이언트의 내부 자동 구성이 작동하지 않습니다. 비즈니스용 Skype 서버에서는 사용자의 SIP URI가 자동 구성용으로 지정된 프런트 엔드 풀의 도메인과 일치해야 하기 때문입니다. 이는 이전 버전의 Communicator에서도 마찬가지였습니다.

예를 들어 두 개의 SIP 도메인을 사용 중인 경우 다음 DNS 서비스(SRV) 레코드가 필요합니다.

  • 사용자가 bob@contoso.com으로 로그인한 경우 사용자의 SIP 도메인(contoso.com)이 자동 구성 프런트 엔드 풀의 도메인과 일치하므로 자동 구성에 대해 다음 SRV 레코드가 작동합니다.

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

  • 사용자가 alice@fabrikam.com으로 로그인한 경우 두 번째 SIP 도메인의 자동 구성에 대해 다음 DNS SRV 레코드가 작동합니다.

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

반면, 사용자가 tim@litwareinc.com으로 로그인한 경우에는 클라이언트의 SIP 주소(litwareinc.com)가 풀이 있는 도메인(fabrikam.com)과 일치하지 않으므로 자동 구성에 대해 다음 DNS SRV 레코드가 작동하지 않습니다.

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

비즈니스용 Skype를 실행하는 클라이언트에 자동 구성이 필요한 경우 다음 옵션 중 하나를 선택합니다.

  • 그룹 정책 개체   GPO(그룹 정책 개체)를 사용하여 올바른 서버 값을 채웁니다.

    note참고:
    이 옵션은 자동 구성을 사용하지 않도록 설정하지만 수동 구성 프로세스를 자동화하므로 이 접근 방법을 사용할 경우 자동 구성과 연결된 SRV 레코드가 필요하지 않습니다.
  • 일치하는 내부 영역   내부 DNS에 외부 DNS 영역(예: contoso.com)과 일치하는 영역을 만들고 자동 구성에 사용되는 비즈니스용 Skype 서버 풀에 해당하는 DNS A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 레코드를 만듭니다. 예를 들어 사용자가 pool01.contoso.net에 속해 있지만 비즈니스용 Skype에 bob@contoso로 로그인한 경우 contoso.com이라는 내부 DNS 영역을 만들고 그 안에 pool01.contoso.com에 대한 DNS A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 레코드를 만듭니다.

  • 핀 포인트 내부 영역   내부 DNS에 전체 영역을 만드는 것이 옵션이 아닌 경우 자동 구성에 필요한 SRV 레코드에 해당하는 핀 포인트(즉, 전용) 영역을 만들고 dnscmd.exe를 사용하여 이러한 영역을 채울 수 있습니다. Dnscmd.exe는 DNS 사용자 인터페이스가 핀 포인트 영역 만들기를 지원하지 않기 때문에 필요합니다. 예를 들어 SIP 도메인이 contoso.com이고 두 개의 프런트 엔드 서버가 포함된 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>
    

    환경에 두 번째 SIP 도메인(예: fabrikam.com)이 있는 경우 내부 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>
    
note참고:
프런트 엔드 풀 FQDN이 두 번 나타나지만 서로 다른 IP 주소를 사용합니다. 이는 DNS 부하 분산이 사용되지만 하드웨어 부하 분산이 사용되는 경우 프런트 엔드 풀 항목이 하나만 있기 때문입니다. 또한 프런트 엔드 풀 FQDN 값은 contoso.com 예와 fabrikam.com 예 간에 변경되지만 IP 주소는 동일하게 유지됩니다. 이는 SIP 도메인에서 로그인한 사용자가 자동 구성에 동일한 프런트 엔드 풀을 사용하기 때문입니다.

자세한 내용은 DMTF 블로그 문서, "Communicator 자동 구성 및 분할 DNS"(http://go.microsoft.com/fwlink/p/?linkId=200707)를 참조하세요. 이 문서에는 Office Communicator가 언급되어 있긴 하지만 세부 정보는 비즈니스용 Skype 서버에도 동일하게 적용됩니다.

note참고:
각 블로그의 콘텐츠와 해당 URL은 공지 없이 변경될 수 있습니다.

DNS에서 비즈니스용 Skype 서버 웹 트래픽을 재해 복구 및 장애 조치(failover) 사이트로 리디렉션하도록 구성하려면 GeoDNS를 지원하는 DNS 공급자를 사용하여 가능하면 지리적으로 가까운 서버를 확인하거나 필요한 경우 원거리 서버를 확인하도록 해야 합니다. 전체 프런트 엔드 풀 하나가 다운되는 경우에도 웹 서비스를 사용하는 기능이 계속 작동하도록 웹에 대한 DNS 레코드가 재해 복구를 지원하게 설정할 수 있습니다. 이 재해 복구 기능은 자동 검색(Lyncdiscover URL), 모임 및 전화 접속 단순 URL을 지원합니다.

GeoDNS 공급자에서 웹 서비스를 내부적 및 외부적으로 확인하도록 추가 DNS 호스트(A 및 AAAA(IPv6를 사용하는 경우)) 레코드를 정의하고 구성해야 합니다. 다음 표의 내용은 지리적으로 분산된 한 쌍의 풀과 공급자가 지원하는 GeoDNS를 사용하며, 라운드 로빈 DNS를 사용하거나 Pool1을 주 풀로 사용하고 통신이 끊기거나 하드웨어 오류가 발생할 경우 Pool2로 장애 조치하도록 구성하는 것으로 가정합니다.

 

GeoDNS 레코드(예) 풀 레코드(예) CNAME 레코드(예) DNS 설정(한 가지 옵션 선택)

Meet-int.geolb.contoso.com

Pool1InternalWebFQDN.contoso.com

Pool2InternalWebFQDN.contoso.com

Pool1InternalWebFQDN.contoso.com에 대한 Meet.contoso.com 별칭

Pool2InternalWebFQDN.contoso.com에 대한 Meet.contoso.com 별칭

풀 간의 라운드 로빈

주 풀을 사용하고 장애 발생 시 보조 풀에 연결

Meet-ext.geolb.contoso.com

Pool1ExternalWebFQDN.contoso.com

Pool2ExternalWebFQDN.contoso.com

Pool1ExternalWebFQDN.contoso.com에 대한 Meet.contoso.com 별칭

Pool2ExternalWebFQDN.contoso.com에 대한 Meet.contoso.com 별칭

풀 간의 라운드 로빈

주 풀을 사용하고 장애 발생 시 보조 풀에 연결

Dialin-int.geolb.contoso.com

Pool1InternalWebFQDN.contoso.com

Pool2InternalWebFQDN.contoso.com

Pool1InternalWebFQDN.contoso.com에 대한 Dialin.contoso.com 별칭

Pool2InternalWebFQDN.contoso.com에 대한 Dialin.contoso.com 별칭

풀 간의 라운드 로빈

주 풀을 사용하고 장애 발생 시 보조 풀에 연결

Dialin-ext.geolb.contoso.com

Pool1ExternalWebFQDN.contoso.com

Pool2ExternalWebFQDN.contoso.com

Pool1ExternalWebFQDN.contoso.com에 대한 Dialin.contoso.com 별칭

Pool2ExternalWebFQDN.contoso.com에 대한 Dialin.contoso.com 별칭

풀 간의 라운드 로빈

주 풀을 사용하고 장애 발생 시 보조 풀에 연결

Lyncdiscoverint-int.geolb.contoso.com

Pool1InternalWebFQDN.contoso.com

Pool2InternalWebFQDN.contoso.com

Pool1InternalWebFQDN.contoso.com에 대한 Lyncdiscoverinternal.contoso.com 별칭

Pool2InternalWebFQDN.contoso.com에 대한 Lyncdiscoverinternal.contoso.com 별칭

풀 간의 라운드 로빈

주 풀을 사용하고 장애 발생 시 보조 풀에 연결

Lyncdiscover-ext.geolb.contoso.com

Pool1ExternalWebFQDN.contoso.com

Pool2ExternalWebFQDN.contoso.com

Pool1ExternalWebFQDN.contoso.com에 대한 Lyncdiscover.contoso.com 별칭

Pool2ExternalWebFQDN.contoso.com에 대한 Lyncdiscover.contoso.com 별칭

풀 간의 라운드 로빈

주 풀을 사용하고 장애 발생 시 보조 풀에 연결

Scheduler-int.geolb.contoso.com

Pool1InternalWebFQDN.contoso.com

Pool2InternalWebFQDN.contoso.com

Pool1InternalWebFQDN.contoso.com에 대한 Scheduler.contoso.com 별칭

Pool2InternalWebFQDN.contoso.com에 대한 Scheduler.contoso.com 별칭

풀 간의 라운드 로빈

주 풀을 사용하고 장애 발생 시 보조 풀에 연결

Scheduler-ext.geolb.contoso.com

Pool1ExternalWebFQDN.contoso.com

Pool2ExternalWebFQDN.contoso.com

Pool1ExternalWebFQDN.contoso.com에 대한 Scheduler.contoso.com 별칭

Pool2ExternalWebFQDN.contoso.com에 대한 Scheduler.contoso.com 별칭

풀 간의 라운드 로빈

주 풀을 사용하고 장애 발생 시 보조 풀에 연결

DNS 부하 분산은 일반적으로 응용 프로그램 수준에서 구현됩니다. 응용 프로그램(예: 비즈니스용 Skype를 실행하는 클라이언트)에서는 풀 FQDN(정규화된 도메인 이름)에 대한 DNS A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 레코드 쿼리에서 반환되는 IP 주소 중 하나에 연결하여 풀의 서버에 연결합니다.

예를 들어 pool01.contoso.com이라는 풀에 세 개의 프런트 엔드 서버가 있는 경우 다음과 같은 상황이 발생합니다.

  • 비즈니스용 Skype를 실행하는 클라이언트는 DNS에서 pool01.contoso.com을 쿼리하며, 이 쿼리는 세 개의 IP 주소를 반환하여 다음과 같이 캐시합니다(순서에 관계없음).

    pool01.contoso.com      192.168.10.90

    pool01.contoso.com      192.168.10.91

    pool01.contoso.com      192.168.10.92

  • 그러면 클라이언트에서 IP 주소 중 하나에 대한 TCP(Transmission Control Protocol) 연결을 설정합니다. 연결에 실패하면 캐시의 다음 IP 주소에 연결합니다.

  • TCP 연결에 성공하면 클라이언트에서 TLS와 협상하여 pool01.contoso.com의 기본 등록자에 연결합니다.

  • 캐시의 항목 연결에 모두 성공하지 못한 경우 사용자에게 지금은 비즈니스용 Skype 서버 실행 서버를 사용할 수 없다는 알림이 제공됩니다.

note참고:
DNS 기반 부하 분산은 DNS RR(DNS 라운드 로빈)과 다릅니다. DNS RR은 일반적으로 DNS를 기반으로 풀의 서버에 해당하는 다른 순서의 IP 주소를 제공하는 부하 분산을 참조합니다. 또한 DNS RR은 일반적으로 부하 분산만 지원하고 장애 조치는 지원하지 않습니다. 예를 들어 DNS A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 쿼리에서 반환된 IP 주소 중 하나에 대한 연결에 실패하면 연결되지 않습니다. 따라서 DNS 라운드 로빈 자체는 DNS 기반 부하 분산보다 안정적이지 않습니다. DNS 라운드 로빈을 DNS 부하 분산과 함께 사용할 수 있습니다.

DNS 부하 분산은 다음에 사용됩니다.

  • 서버 간 SIP를 에지 서버에 부하 분산

  • 회의 자동 길잡이, 응답 그룹 및 통화 대기와 같은 UCAS(Unified Communications Application Services) 응용 프로그램 부하 분산

  • UCAS 응용 프로그램에 대한 새 연결 방지("드레이닝"이라고도 함)

  • 클라이언트와 에지 서버 간의 모든 클라이언트-서버 트래픽 부하 분산

DNS 부하 분산은 다음에 사용할 수 없습니다.

  • 디렉터 또는 프런트 엔드 서버에 대한 클라이언트-서버 웹 트래픽

DNS 부하 분산 및 페더레이션 트래픽

DNS SRV 쿼리에서 여러 개의 DNS 레코드가 반환되는 경우 액세스 에지 서비스는 항상 숫자 우선 순위는 가장 낮고 가중치는 가장 큰 DNS SRV 레코드를 선택합니다. Internet Engineering Task Force 문서 "서비스 위치 지정을 위한 DNS RR(DNS SRV)"(http://www.ietf.org/rfc/rfc2782.txt)에서는 DNS SRV 레코드가 여러 개 정의된 경우 우선 순위가 먼저 사용된 다음 가중치가 사용된다고 지정되어 있습니다. 예를 들어 DNS SRV 레코드 A의 가중치가 20, 우선 순위가 40이고 DNS SRV 레코드 B의 가중치는 10, 우선 순위는 50이라고 가정해 보겠습니다. 이 경우 우선 순위가 40인 DNS SRV 레코드 A가 선택됩니다. DNS SRV 레코드 선택 시에는 다음 규칙이 적용됩니다.

  • 우선 순위를 먼저 고려합니다. 클라이언트는 연결 가능한 가장 낮은 숫자 우선 순위의 DNS SRV 레코드로 정의된 대상 호스트에 연결을 시도해야 합니다. 대상의 우선 순위가 같은 경우에는 가중치 필드로 정의된 순서로 연결을 시도해야 합니다.

  • 가중치 필드는 우선 순위가 같은 항목의 상대 가중치를 지정합니다. 가중치가 클수록 그에 비례하여 선택될 가능성도 커집니다. DNS 관리자는 서버를 선택하지 않는 경우 가중치로 0을 사용해야 합니다. 가중치가 0보다 큰 레코드가 있으면 가중치가 0인 레코드가 선택될 확률은 매우 낮습니다.

우선 순위와 가중치가 동일한 여러 DNS SRV 레코드가 반환되는 경우 액세스 에지 서비스는 DNS 서버에서 가장 먼저 반환된 SRV 레코드를 선택합니다.

이 섹션에서는 프런트 엔드 풀을 배포하는 데 필요한 DNS(도메인 이름 시스템) 레코드에 대해 설명합니다.

다음 표에는 비즈니스용 Skype 서버 프런트 엔드 풀을 배포하는 데 필요한 DNS 요구 사항이 지정되어 있습니다.

프런트 엔드 풀에 대한 DNS 요구 사항

배포 시나리오 DNS 요구 사항

여러 프런트 엔드 서버 및 하나의 하드웨어 분산 장치가 포함된 프런트 엔드 풀(DNS 부하 분산이 해당 풀에 배포되었는지 여부는 상관없음)

DNS 부하 분산과 하드웨어 부하 분산 장치를 모두 사용할 때는 호스트 A 레코드를 만들어야 합니다. DNS 부하 분산용으로 프런트 엔드 풀의 FQDN(정규화된 도메인 이름)을 확인하는 각 프런트 엔드 서버를 위한 내부 A 레코드를 만듭니다. 그리고 부하 분산 장치의 VIP(가상 IP) 주소에 대해 내부 웹 서비스용 내부 호스트 A 레코드를 만듭니다. 토폴로지 작성기에 정의된 내부 웹 서비스 이름을 사용해야 합니다.

예를 들어 DNS 부하 분산과 하드웨어 부하 분산을 모두 사용하는 경우 풀의 각 프런트 엔드 서버에 대해 DNS 부하 분산용 A 레코드가 있고 하드웨어 부하 분산 장치의 가상 IP를 가리키는 내부 웹 서비스용 A 레코드가 있습니다.

  • DNS 부하 분산:   Pool01.contoso.net   풀의 IP 주소   10.10.10.5

    warning주의:
    각 프런트 엔드 서버에는 고유 A 레코드도 있습니다.
    1. FE01.contoso.net    10.10.10.1

    2. FE02.contoso.net    10.10.10.2

    3. FE03.contoso.net    10.10.10.3

    4. FE04.contoso.net    10.10.10.4

  • 하드웨어 부하 분산:   WebInternal.contoso.net   HLB VIP의 IP 주소   192.168.10.5

HTTP/HTTPS 트래픽을 제외한 모든 트래픽은 Pool01.contoso.net.record를 사용합니다. HTTP/HTTPS 트래픽은 정의된 내부 웹 서비스 주소인 192.168.10.5를 사용합니다.

DNS 부하 분산이 배포된 프런트 엔드 풀

풀의 FQDN을 풀에 있는 각 서버의 IP 주소로 확인하는 내부 A 레코드 집합. 풀에는 서버당 하나의 A 레코드가 포함될 수 있습니다. 자세한 내용은 계획 설명서에서 Lync Server 2013의 DNS 부하 분산을 참조하세요.

   

단일 프런트 엔드 서버와 전용 백 엔드 데이터베이스를 포함하지만 부하 분산 장치는 포함하지 않는 프런트 엔드 풀

프런트 엔드 풀의 FQDN을 단일 Enterprise Edition 프런트 엔드 서버의 IP 주소로 확인하는 내부 A 레코드

자동 클라이언트 로그인

지원되는 각 SIP 도메인에 대해 로그인을 위한 클라이언트 요청을 인증하고 리디렉션하는 프런트 엔드 풀의 FQDN에 매핑되는 _sipinternaltls._tcp.<도메인>(포트 5061)에 대한 SRV 레코드. 자세한 내용은 Lync Server 2013의 자동 클라이언트 로그인에 대한 DNS 요구 사항을 참조하세요.

UC(통합 통신) 장치를 통한 장치 업데이트 웹 서비스 검색

장치 업데이트 웹 서비스를 호스트하는 프런트 엔드 풀의 IP 주소를 확인하는 ucupdates-r2.<SIP 도메인> 이름의 내부 A 레코드. UC 장치가 설정되었지만 사용자가 장치에 로그인하지 않은 상황에서 A 레코드를 사용하면 장치가 장치 업데이트 웹 서비스를 호스트하는 프런트 엔드 풀을 검색하고 업데이트를 가져올 수 있습니다. 그렇지 않으면 장치는 사용자가 처음 로그인할 때 인밴드 구축을 통해 이 정보를 가져옵니다.

important중요:
Lync Server 2010에 기존 장치 업데이트 웹 서비스가 배포되어 있는 경우 이름이 ucupdates.<SIP domain>인 내부 A 레코드가 이미 만들어져 있습니다. Microsoft Office Communications Server 2007 R2의 경우 이름이 ucupdates-r2.<SIP domain>인 DNS A 레코드를 추가로 만들어야 합니다.

HTTP 트래픽을 지원하는 역방향 프록시

외부 웹 팜 FQDN을 역방향 프록시의 외부 IP 주소로 확인하는 외부 A 레코드. 클라이언트와 UC 장치는 이 레코드를 사용하여 역방향 프록시에 연결합니다. 자세한 내용은 계획 설명서에서 Lync Server 2013에 대한 DNS 요구 사항 확인을 참조하세요.

다음 표에서는 내부 웹 팜 FQDN에 필요한 DNS 레코드의 예를 보여 줍니다.

내부 웹 팜 FQDN에 필요한 DNS 레코드의 예

내부 웹 팜 FQDN 풀 FQDN DNS A 레코드

webcon.contoso.com

ee-pool.contoso.com

프런트 엔드 서버가 사용하는 부하 분산 장치의 VIP 주소로 확인되는 ee-pool.contoso.com에 대한 DNS A 레코드

프런트 엔드 서버가 사용하는 부하 분산 장치의 VIP 주소로 확인되는 webcon.contoso.com에 대한 DNS A 레코드

ee-pool.contoso.com

ee-pool.contoso.com

프런트 엔드 풀에서 Enterprise Edition 프런트 엔드 서버가 사용하는 부하 분산 장치의 VIP(가상 IP) 주소로 확인되는 ee-pool.contoso.com에 대한 DNS A 레코드

이 풀에서 DNS 부하 분산을 사용하는 경우에는 프런트 엔드 풀과 내부 웹 팜의 FQDN이 동일할 수 없습니다.

이 섹션에서는 Standard Edition 서버를 배포하는 데 필요한 DNS(Domain Name System) 레코드에 대해 설명합니다.

다음 표에서는 비즈니스용 Skype 서버 Standard Edition 서버 배포에 대한 DNS 요구 사항을 지정합니다.

Standard Edition 서버에 대한 DNS 요구 사항

배포 시나리오 DNS 요구 사항

Standard Edition 서버

서버의 FQDN(정규화된 도메인 이름)을 IP 주소로 확인하는 내부 A 레코드

자동 클라이언트 로그인

지원되는 각 SIP 도메인에 대해 클라이언트의 로그인 요청을 인증 및 리디렉션하는 Standard Edition 서버의 FQDN에 매핑되는 _sipinternaltls._tcp.<domain>(포트 5061)에 대한 SRV 레코드. 자세한 내용은 Lync Server 2013의 자동 클라이언트 로그인에 대한 DNS 요구 사항을 참조하세요.

UC(통합 통신) 장치를 통한 장치 업데이트 웹 서비스 검색

장치 업데이트 웹 서비스를 호스팅하는 Standard Edition 서버의 IP 주소로 확인되는 ucupdates-r2.<SIP domain> 이름의 내부 A 레코드. UC 장치가 설정되었지만 사용자가 장치에 로그인하지 않은 상황에서 A 레코드를 사용하면 장치가 장치 업데이트 웹 서비스를 호스팅하는 서버를 검색하고 업데이트를 가져올 수 있습니다. 그렇지 않은 경우 장치는 사용자가 처음 로그인할 때 인밴드 프로비전을 통해 이 정보를 가져옵니다.

HTTP 트래픽을 지원하는 역방향 프록시

외부 웹 팜 FQDN을 역방향 프록시의 외부 IP 주소로 확인하는 외부 A 레코드. 클라이언트와 UC 장치는 이 레코드를 사용하여 역방향 프록시에 연결합니다. 자세한 내용은 계획 설명서에서 Lync Server 2013에 대한 DNS 요구 사항 확인을 참조하세요.

비즈니스용 Skype 서버에서는 단순 URL이 지원되며, 따라서 사용자가 모임에 쉽게 참가하고 관리자가 비즈니스용 Skype 서버 관리 도구를 보다 쉽게 이용할 수 있습니다. 단순 URL 도메인은 SIP 도메인과 일치하지 않습니다. 단순 URL에 대한 자세한 내용은 Lync Server 2013의 단순 URL 계획을 참조하세요.

비즈니스용 Skype 서버에서는 모임, 전화 접속 및 관리의 세 가지 단순 URL을 지원합니다. 모임 및 전화 접속에 대한 단순 URL은 필수 설정이고, 관리 단순 URL은 선택 사항입니다. 단순 URL을 지원하는 데 필요한 DNS(Domain Name System) 레코드는 이러한 단순 URL을 정의한 방법 및 단순 URL에 대해 재해 복구를 지원할지 여부에 따라 다릅니다.

옵션 1에서는 각 단순 URL에 대한 새로운 기본 URL을 만듭니다.

note참고:
사용자가 단순 URL 모임 링크를 클릭하면 DNS A 레코드에서 확인하는 서버에서 시작할 올바른 클라이언트 소프트웨어를 결정합니다. 클라이언트 소프트웨어는 시작되는 즉시 전화 회의가 호스트되는 풀과 자동으로 통신합니다. 따라서 사용자가 단순 URL DNS A 레코드에서 확인한 서버 또는 풀에 관계없이 모임 콘텐츠에 적절한 서버로 이동합니다.

단순 URL 옵션 1

단순 URL

모임

https://meet.contoso.com, https://meet.fabrikam.com 등(조직의 각 SIP 도메인당 하나)

전화 접속

https://dialin.contoso.com

관리

https://admin.contoso.com

옵션 1을 사용하는 경우 다음을 정의해야 합니다.

  • 디렉터를 배포한 경우 각 모임 단순 URL에 대해 URL을 디렉터의 IP 주소로 확인하는 DNS A 레코드가 있어야 합니다. 그렇지 않으면 DNS A 레코드에서 프런트 엔드 풀 부하 분산 장치의 IP 주소를 확인해야 합니다. 풀을 배포하지 않고 Standard Edition 서버 배포를 사용하는 경우 DNS A 레코드는 조직에 있는 Standard Edition 서버 하나의 IP 주소를 확인해야 합니다.

    조직에 둘 이상의 SIP 도메인이 있는 경우 이 옵션을 사용하려면 각 SIP 도메인에 대해 모임 단순 URL을 만들어야 하며 각 모임 단순 URL에 대한 DNS A 레코드가 있어야 합니다. 예를 들어 contoso.com과 fabrikam.com을 둘 다 사용하는 경우 https://meet.contoso.com과 https://meet.fabrikam.com에 대한 DNS A 레코드를 만듭니다.

    또는 여러 SIP 도메인이 있는 경우 이러한 단순 URL에 필요한 DNS 레코드 및 인증서를 최소화하려면 옵션 3(이 항목의 뒷부분에 나오는 설명 참조)을 사용합니다.

  • 디렉터를 배포한 경우 각 전화 접속 단순 URL에 대해 URL을 디렉터의 IP 주소로 확인하는 DNS A 레코드가 있어야 합니다. 그렇지 않으면 DNS A 레코드에서 프런트 엔드 풀 부하 분산 장치의 IP 주소를 확인해야 합니다. 풀을 배포하지 않고 Standard Edition 서버 배포를 사용하는 경우 DNS A 레코드는 조직에 있는 Standard Edition 서버 하나의 IP 주소를 확인해야 합니다.

  • 관리 단순 URL은 내부 전용입니다. 이 URL에는 디렉터를 배포한 경우 URL을 디렉터의 IP 주소로 확인하는 DNS A 레코드가 있어야 합니다. 그렇지 않으면 DNS A 레코드에서 프런트 엔드 풀 부하 분산 장치의 IP 주소를 확인해야 합니다. 풀을 배포하지 않고 Standard Edition 서버 배포를 사용하는 경우 DNS A 레코드는 조직에 있는 Standard Edition 서버 하나의 IP 주소를 확인해야 합니다.

옵션 2를 사용하는 경우에는 모임, 전화 접속 및 관리 단순 URL 모두 공통 기본 URL(예: lync.contoso.com)을 사용합니다. 따라서 이러한 단순 URL에 대해 lync.contoso.com을 디렉터 풀 또는 프런트 엔드 풀의 IP 주소로 확인하는 DNS A 레코드가 하나만 있으면 됩니다. 풀을 배포하지 않고 Standard Edition 서버 배포를 사용하는 경우 DNS A 레코드는 조직에 있는 Standard Edition 서버 하나의 IP 주소를 확인해야 합니다.

조직에 둘 이상의 SIP 도메인이 있는 경우 여전히 각 SIP 도메인에 대해 모임 단순 URL을 만들어야 하며 각 모임 단순 URL에 대한 DNS A 레코드가 있어야 합니다. 이 예에서는 세 가지 단순 URL이 모두 lync.contoso.com을 기반으로 하지만 fabrikam.com에 대한 추가 모임 단순 URL이 다른 기본 URL로 설정됩니다. 이 예에서는 https://lync.contoso.com과 https://lync.fabrikam.com에 대한 DNS A 레코드를 만들어야 합니다. 단순 URL 옵션 3에서는 여러 SIP 도메인이 있는 이름 지정 및 DNS A 레코드를 처리하는 다른 방법을 보여 줍니다.

단순 URL 옵션 2

단순 URL

모임

https://lync.contoso.com/Meet, https://lync.fabrikam.com/Meet 등(조직의 각 SIP 도메인당 하나)

전화 접속

https://lync.contoso.com/Dialin

관리

https://lync.contoso.com/Admin

옵션 3은 많은 SIP 도메인이 있고 이러한 단순 URL에 필요한 DNS 레코드 및 인증서 요구 사항을 최소화하려는 경우에 가장 유용합니다. 이 예에서는 lync.contoso.com을 디렉터 풀 또는 프런트 엔드 풀의 IP 주소로 확인하는 DNS A 레코드가 하나만 있으면 됩니다.

단순 URL 옵션 3

단순 URL

모임

https://lync.contoso.com/contosoSIPdomain/Meet

https://lync.contoso.com/fabrikamSIPdomain/Meet

전화 접속

https://lync.contoso.com/contosoSIPdomain/Dialin

관리

https://lync.contoso.com/contosoSIPdomain/Admin

여러 사이트에 프런트 엔드 풀이 포함되어 있으며 DNS 공급자가 GeoDNS를 지원하는 경우에는 재해 복구를 지원하도록 단순 URL에 대해 DNS 레코드를 설정하여 전체 프런트 엔드 풀 하나가 다운되어도 단순 URL 기능이 계속 작동하도록 할 수 있습니다. 이 재해 복구 기능은 모임 및 전화 접속 단순 URL을 지원합니다.

이와 같이 구성하려면 GeoDNS 주소 두 개를 만듭니다. 각 주소에는 재해 복구용으로 쌍으로 지정된 두 개의 풀로 확인되는 DNS A 또는 CNAME 레코드 두 개가 포함됩니다. GeoDNS 주소 중 하나는 내부 액세스용으로 사용되며, 두 풀에 대한 내부 웹 FQDN 또는 부하 분산 장치 IP 주소로 확인됩니다. 나머지 GeoDNS 주소는 외부 액세스용으로 사용되며, 두 풀의 외부 웹 FQDN 또는 부하 분산 장치 IP 주소로 확인됩니다. 아래에는 풀의 FQDN을 사용하는 모임 단순 URL의 예가 나와 있습니다.

Meet-int.geolb.contoso.com
     Pool1InternalWebFQDN.contoso.com
     Pool2InternalWebFQDN.contoso.com
Meet-ext.geolb.contoso.com
     Pool1ExternalWebFQDN.contoso.com
     Pool2ExternalWebFQDN.contoso.com

그런 후에 meet.contoso.com과 같은 모임 단순 URL을 두 개의 GeoDNS 주소로 확인하는 CNAME 레코드를 만듭니다.

note참고:
네트워크에서 헤어핀(조직 내부에서 생성되는 트래픽을 비롯하여 모든 단순 URL 트래픽을 외부 링크를 통해 라우팅)을 사용하는 경우에는 외부 GeoDNS 주소만 구성하고 모임 단순 URL을 해당 외부 주소로만 확인할 수 있습니다.

이 방법을 사용하는 경우 각 GeoDNS 주소가 라운드 로빈 방법을 사용하여 요청을 두 풀로 분산시키거나, 기본적으로 한 풀(예: 지리적으로 더 가까이 있는 풀)에 연결하고 다른 풀은 연결 오류 시에만 사용하도록 구성할 수 있습니다.

전화 접속 단순 URL에 대해 같은 구성을 설정할 수 있습니다. 이렇게 하려면 위의 예제와 같은 추가 레코드를 만들되 DNS 레코드에서 dialinmeet 대신 사용합니다. 관리 단순 URL의 경우 이 섹션 앞부분에 나와 있는 세 가지 옵션 중 하나를 사용합니다.

이 구성을 설정한 후에는 모니터링 응용 프로그램을 사용하여 오류를 감시할 HTTP 모니터링을 설정해야 합니다. 외부 액세스의 경우 두 풀에 대한 외부 웹 FQDN 또는 부하 분산 장치 IP 주소로의 HTTPS GET lyncdiscover.<sipdomain> 요청이 정상적으로 수행되는지 확인합니다. 예를 들어 다음 요청은 ACCEPT 헤더를 포함하면 안 되며 200 OK를 반환해야 합니다.

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

내부 액세스의 경우에는 두 풀에 대해 내부 웹 FQDN 또는 부하 분산 장치 IP 주소에서 포트 5061을 모니터링해야 합니다. 연결 오류가 감지되면 이러한 풀의 VIP가 포트 80, 443, 4443을 닫아야 합니다.

이 섹션에서는 자동 클라이언트 로그인에 필요한 DNS(Domain Name System) 레코드에 대해 설명합니다. Standard Edition 서버 또는 프런트 엔드 풀을 배포할 때는 클라이언트가 자동 검색을 사용하여 적절한 Standard Edition 서버 또는 프런트 엔드 풀에 로그인하도록 구성할 수 있습니다. 클라이언트에서 비즈니스용 Skype 서버에 수동으로 연결하는 것은 권장되지 않습니다.

자동 클라이언트 로그인을 지원하려면 다음을 수행해야 합니다.

  • 클라이언트 로그인 요청을 분산시키고 인증하는 단일 서버 또는 풀을 지정합니다. 사용자를 호스팅하는 조직 내의 기존 서버나 풀일 수도 있고, 이 목적을 위해 어떤 사용자도 호스팅하고 있지 않은 전용 서버나 풀을 지정할 수도 있습니다. 고가용성을 위해서는 이 기능에 프런트 엔드 풀을 지정하는 것이 좋습니다.

  • 이 서버 또는 풀에 대한 자동 클라이언트 로그인을 지원하는 내부 DNS SRV 레코드를 만듭니다.

    note참고:
    다음의 레코드 요구 사항에서 SIP 도메인은 사용자에게 할당된 SIP URI의 호스트 부분을 나타냅니다. 예를 들어 SIP URI의 형식이 *@contoso.com인 경우에는 contoso.com이 SIP 도메인입니다. SIP 도메인은 대개 내부 Active Directory 도메인과 다릅니다. 조직에서 여러 SIP 도메인을 지원할 수도 있습니다.

클라이언트에 대해 자동 구성을 사용하려면 비즈니스용 Skype 클라이언트의 로그인 요청을 분산시키는 프런트 엔드 풀 또는 Standard Edition 서버의 FQDN(정규화된 도메인 이름)에 다음 레코드 중 하나를 매핑하는 내부 DNS SRV 레코드를 만들어야 합니다.

  • _sipinternaltls._tcp.<domain> - 내부 TLS 연결용

로그인 요청을 분산할 프런트 엔드 풀 또는 Standard Edition 서버에 대해 도메인당 하나의 SRV 레코드만 만들면 됩니다.

다음 표에서는 contoso.com 및 retail.contoso.com이라는 SIP 도메인을 지원하는 Contoso라는 가상 회사에 필요한 일부 예제 레코드를 보여 줍니다.

SIP 도메인이 여러 개인 자동 클라이언트 로그인에 필요한 DNS 레코드의 예

로그인 요청을 분산하는 데 사용되는 프런트 엔드 풀의 FQDN SIP 도메인 DNS SRV 레코드

pool01.contoso.com

contoso.com

pool01.contoso.com에 매핑되는 _sipinternaltls._tcp.contoso.com 도메인(포트 5061)에 대한 SRV 레코드

pool01.contoso.com

retail.contoso.com

pool01.contoso.com에 매핑되는 _sipinternaltls._tcp.retail.contoso.com 도메인(포트 5061)에 대한 SRV 레코드

note참고:
기본적으로 DNS 레코드에 대한 쿼리는 SRV 레코드 및 사용자 이름에 있는 도메인 간의 엄격한 도메인 이름 일치를 따릅니다. 접미사 일치를 대신 사용하도록 클라이언트 DNS 쿼리를 설정하려면 DisableStrictDNSNaming 그룹 정책을 구성하면 됩니다. 자세한 내용은 계획 설명서에서 Lync Server 2013에서 클라이언트 및 장치 계획을 참조하세요.

이 예에서는 앞의 표에 있는 것과 같은 예제 이름을 사용합니다. Contoso 조직은 contoso.com 및 retail.contoso.com이라는 SIP 도메인을 지원하고 이 조직의 모든 사용자는 다음 중 한 형태의 SIP URI를 갖게 됩니다.

  • <user>@retail.contoso.com

  • <user>@contoso.com

비즈니스용 Skype 서버 모바일 기능을 배포할 때는 Microsoft 비즈니스용 Skype 서버 자동 검색 서비스에서 제공되는 새로운 URL을 사용할 수도 있고 기존 웹 서비스 URL을 사용할 수도 있습니다. 기존 URL을 사용하는 경우 사용자는 모바일 장치 설정에 URL을 수동으로 입력해야 합니다. 이 옵션은 보통 문제 해결용으로 사용됩니다. 새 URL을 사용하는 경우에는 모바일 클라이언트가 비즈니스용 Skype 서버 리소스를 자동으로 검색할 수 있습니다. 자동 검색을 지원하는 경우에는 새 DNS(Domain Name System) 레코드를 추가해야 합니다. 이 섹션에서는 자동 검색에 필요한 DNS 레코드에 대해 설명합니다.

자동 검색을 지원하려면 각 SIP 도메인에 대해 다음 DNS 레코드를 만들어야 합니다.

  • 조직 네트워크 내에서 연결하는 모바일 사용자를 지원하기 위한 내부 DNS 레코드

  • 인터넷에서 연결하는 모바일 사용자를 지원하기 위한 외부(공용) DNS 레코드

내부 자동 검색 URL의 주소는 네트워크 외부에서 확인할 수 없어야 하며, 외부 자동 검색 URL의 주소는 네트워크 내에서 확인할 수 없어야 합니다. 그러나 외부 URL에 대해 이 요구 사항을 충족할 수 없는 경우에도 모바일 클라이언트의 기능에 영향이 있어서는 안 됩니다.

DNS 레코드는 CNAME 레코드 또는 A(호스트) 레코드일 수 있습니다.

내부 DNS 레코드

다음 내부 DNS 레코드 중 하나를 만들어야 합니다.

 

레코드 유형 호스트 이름 또는 SRV 정의 확인 대상

CNAME

lyncdiscoverinternal.<sipdomain>

디렉터 풀의 내부 웹 서비스 FQDN(정규화된 도메인 이름)(있는 경우) 또는 프런트 엔드 풀(디렉터가 없는 경우)

A(호스트)

lyncdiscoverinternal.<sipdomain>

디렉터 풀의 내부 웹 서비스 IP 주소(부하 분산 장치를 사용하는 경우 VIP(가상 IP) 주소)(있는 경우) 또는 프런트 엔드 풀(디렉터가 없는 경우)

외부 DNS 레코드

다음 외부 DNS 레코드 중 하나를 만들어야 합니다.

 

레코드 유형 호스트 이름 확인 대상

CNAME

lyncdiscover. <sipdomain>

디렉터 풀의 외부 웹 서비스 FQDN(있는 경우) 또는 프런트 엔드 풀(디렉터가 없는 경우)

A(호스트)

lyncdiscover. <sipdomain>

역방향 프록시의 외부(공용) IP 주소(부하 분산 장치를 사용하는 경우 VIP 주소)

SRV

_sipfederationtls._tcp. <sipdomain>

액세스 에지 서비스의 호스트(A 또는 AAAA) 레코드로 확인됩니다.

푸시 알림 서비스 및 Apple 푸시 알림 서비스를 지원하려면 Microsoft Lync Mobile 클라이언트가 있는 SIP 도메인마다 SRV 레코드를 하나씩 만듭니다.

important중요:
이 요구 사항은 Apple 또는 Microsoft 기반 모바일 장치의 Microsoft Lync Mobile 클라이언트에만 적용됩니다. Andriod 및 Nokia Symbian 장치에서는 푸시 알림을 사용하지 않습니다.
note참고:
자동 검색 트래픽은 역방향 프록시를 통과합니다. SRV 레코드는 액세스 에지 서비스를 통해 확인되는 레코드를 가리킵니다.

비즈니스용 Skype 서버에서는 네트워크의 부하 분산에 대한 관리 오버헤드를 크게 줄일 수 있는 소프트웨어 솔루션인 DNS 부하 분산이 지원됩니다. DNS 부하 분산은 SIP 트래픽 및 미디어 트래픽과 같이 비즈니스용 Skype 서버의 고유한 네트워크 트래픽 부하를 분산합니다.

DNS 부하 분산을 배포하면 하드웨어 부하 분산 장치에 대한 조직의 관리 오버헤드가 최소화됩니다. 또한 SIP 트래픽에 대한 부하 분산 장치의 잘못된 구성과 관련된 복잡한 문제를 해결할 필요가 없게 됩니다. 또한 서버를 오프라인으로 설정할 수 있도록 서버 연결을 방지할 수도 있습니다. 또한 DNS 부하 분산은 하드웨어 부하 분산 장치 문제가 기본 통화 라우팅과 같은 SIP 트래픽 요소에 영향을 주지 않도록 합니다.

DNS 부하 분산을 사용하는 경우에는 모든 트래픽 유형에 대해 하드웨어 부하 분산 장치를 사용하는 경우에 비해 저렴한 가격에 하드웨어 부하 분산 장치를 구입할 수도 있습니다. 이 경우 비즈니스용 Skype 서버의 상호 운용성 검증 테스트를 통과한 부하 분산 장치를 사용해야 합니다. 부하 분산 장치의 상호 운용성 테스트에 대한 자세한 내용은 "Lync Server 2010 부하 분산 장치 파트너"(http://go.microsoft.com/fwlink/p/?linkId=202452)를 참조하세요. 해당 내용은 비즈니스용 Skype 서버에 적용됩니다.

DNS 부하 분산은 프런트 엔드 풀, 에지 서버 풀, 디렉터 풀 및 독립 실행형 중재 서버 풀에서 지원됩니다.

프런트 엔드 풀과 디렉터 풀의 SIP 트래픽에 DNS 부하 분산을 사용할 수 있습니다. DNS 부하 분산을 배포한 경우에는 이러한 풀에 클라이언트-서버 HTTPS 트래픽 전용 하드웨어 부하 분산 장치를 사용해야 합니다. 하드웨어 부하 분산 장치는 포트 443 및 80을 통해 클라이언트에서 전송되는 HTTPS 트래픽에 사용됩니다.

이러한 풀에 여전히 하드웨어 부하 분산 장치가 필요하지만 설치 및 관리는 주로 HTTP 트래픽에 대한 것이며, 이는 하드웨어 부하 분산 장치 관리자에게 익숙한 일입니다.

DNS 부하 분산은 비즈니스용 Skype 서버 또는 Lync Server 2010 실행 서버 및 Lync 2013 및 비즈니스용 Skype 클라이언트에 대해서만 자동 장애 조치(failover)를 지원합니다. 이전 버전의 클라이언트 및 Office Communications Server에서도 DNS 부하 분산을 실행하는 풀에 연결할 수 있지만 DNS 부하 분산에서 참조하는 첫 번째 서버에 연결할 수 없는 경우 풀의 다른 서버로 장애 조치될 수 없습니다.

또한 Exchange UM을 사용하는 경우 비즈니스용 Skype 서버 DNS 부하 분산에 대한 지원을 얻으려면 최소한 Exchange 2010 SP1을 사용해야 합니다. 이전 버전의 Exchange를 사용할 경우에는 사용자에게 이러한 Exchange UM 시나리오에 대한 장애 조치(Failover) 기능이 없습니다.

  • 전화기에서 Enterprise 음성 메일 재생

  • Exchange UM 자동 전화 교환의 통화 전송

다른 모든 Exchange UM 시나리오는 제대로 적용됩니다.

프런트 엔드 풀과 디렉터 풀에 DNS 부하 분산을 배포하려면 FQDN 및 DNS 레코드와 관련된 몇 가지 추가 단계를 수행해야 합니다.

  • DNS 부하 분산을 사용하는 풀에는 두 개의 FQDN이 있어야 합니다. 하나는 DNS 부하 분산에 사용되고 풀에 있는 서버의 실제 IP를 확인하는 일반적인 풀 FQDN(예: pool01.contoso.com)이고, 또 하나는 풀의 가상 IP 주소를 확인하는 풀의 웹 서비스에 대한 FQDN(예: web01.contoso.com)입니다.

    풀에 대한 DNS 부하 분산을 배포하려는 경우 풀의 웹 서비스에 대한 이 추가 FQDN을 만들려면 토폴로지 작성기의 이 풀에 대한 웹 서비스 URL 지정 페이지에서 내부 웹 서비스 풀 FQDN 다시 정의 확인란을 선택하고 FQDN을 입력합니다.

  • DNS 부하 분산에 사용되는 FQDN을 지원하려면 풀 FQDN(예: pool01.contoso.com)을 풀에 있는 모든 서버의 IP 주소(예: 192.168.1.1, 192.168.1.2 등)로 확인하는 DNS를 프로비전해야 합니다. 이때 현재 배포된 서버의 IP 주소만 포함해야 합니다.

    warning주의:
    프런트 엔드 풀 또는 프런트 엔드 서버가 2개 이상 있으면 외부 웹 서비스 FQDN이 고유해야 합니다. 예를 들어 프런트 엔드 서버의 외부 웹 서비스 FQDN을 pool01.contoso.com으로 정의할 경우 또 다른 프런트 엔드 풀 또는 프런트 엔드 서버에 대해 pool01.contoso.com을 다시 사용할 수 없습니다. 또한 디렉터를 배포하는 경우 디렉터 또는 디렉터 풀에 대해 정의된 외부 웹 서비스 FQDN은 디렉터 또는 디렉터 풀뿐만 아니라 다른 모든 프런트 엔드 풀 또는 프런트 엔드 서버와도 고유해야 합니다. 내부 웹 서비스를 자동 정의된 FQDN으로 다시 정의하려는 경우 각 FQDN은 다른 프런트 엔드 풀, 디렉터 또는 디렉터 풀과 고유해야 합니다.

에지 서버 풀에 DNS 부하 분산을 배포할 수 있습니다. 이 경우 몇 가지 사항을 고려해야 합니다.

에지 서버에서 DNS 부하 분산을 사용하면 다음과 같은 시나리오에서 장애 조치 기능이 손실됩니다.

  • 비즈니스용 Skype 서버 이전에 릴리스된 Lync Server 2010 버전을 실행하는 조직과의 페더레이션

  • 공용 메신저 서비스(예: AOL 및 Yahoo!) 사용자 및 XMPP 기반 공급자/서버(예: 현재 지원되는 유일한 XMPP 파트너인 Google Talk) 사용자와의 메신저 대화 교환

이러한 시나리오는 풀의 모든 에지 서버가 작동되고 실행 중인 한 적용되지만 하나의 에지 서버를 사용할 수 없는 경우 이 서버로 전송되는 요청은 다른 에지 서버로 라우팅되지 않고 실패합니다.

Exchange UM을 사용하는 경우 에지의 비즈니스용 Skype 서버 DNS 부하 분산에 대한 지원을 받으려면 최소한 Exchange 2013을 사용해야 합니다. 이전 버전의 Exchange를 사용할 경우에는 원격 사용자에게 이러한 Exchange UM 시나리오에 대한 장애 조치(Failover) 기능이 없습니다.

  • 전화기에서 Enterprise 음성 메일 재생

  • Exchange UM 자동 전화 교환의 통화 전송

다른 모든 Exchange UM 시나리오는 제대로 적용됩니다.

내부 에지 인터페이스와 외부 에지 인터페이스는 같은 유형의 부하 분산을 사용해야 합니다. 즉, 한 에지 인터페이스에서는 DNS 부하 분산을 사용하고 다른 에지 인터페이스에서는 하드웨어 부하 분산을 사용할 수는 없습니다.

에지 서버 풀의 외부 인터페이스에 DNS 부하 분산을 배포하려면 다음 DNS 항목이 필요합니다.

  • 액세스 에지 서비스의 경우 풀의 각 서버에 대해 하나의 항목이 필요합니다. 각 항목은 액세스 에지 서비스의 FQDN(예: sip.contoso.com)을 풀의 에지 서버 중 하나에 있는 액세스 에지 서비스의 IP 주소로 확인해야 합니다.

  • 웹 회의 에지 서비스의 경우 풀의 각 서버에 대해 하나의 항목이 필요합니다. 각 항목은 웹 회의 에지 서비스의 FQDN(예: webconf.contoso.com)을 풀의 에지 서버 중 하나에 있는 웹 회의 에지 서비스의 IP 주소로 확인해야 합니다.

  • 오디오/비디오 에지 서비스의 경우 풀의 각 서버에 대해 하나의 항목이 필요합니다. 각 항목은 오디오/비디오 에지 서비스의 FQDN(예: av.contoso.com)을 풀의 에지 서버 중 하나에 있는 A/V 에지 서비스의 IP 주소로 확인해야 합니다.

에지 서버 풀의 내부 인터페이스에 DNS 부하 분산을 배포하려면 에지 서버 풀의 내부 FQDN을 풀에 있는 각 서버의 IP 주소로 확인하는 DNS A 레코드를 추가해야 합니다.

독립 실행형 중재 서버 풀에서 DNS 부하 분산을 사용할 수 있습니다. 모든 SIP 및 미디어 트래픽은 DNS 부하 분산에 의해 균형이 조정됩니다.

중재 서버 풀에 DNS 부하 분산을 배포하려면 풀 FQDN(예: mediationpool1.contoso.com)을 풀에 있는 모든 서버의 IP 주소(예: 192.168.1.1, 192.168.1.2 등)로 확인하는 DNS를 프로비전해야 합니다.

DNS 부하 분산을 사용하고 특정 컴퓨터에 대한 트래픽을 차단해야 하는 경우 풀 FQDN에서 IP 주소 항목만 제거하는 것으로는 충분하지 않습니다. 컴퓨터에 대한 DNS 항목도 함께 제거해야 합니다.

서버 간 트래픽에 대해 비즈니스용 Skype 서버는 토폴로지 인식 부하 분산을 사용합니다. 서버는 중앙 관리 저장소에서 게시된 토폴로지를 읽고 토폴로지의 서버 FQDN을 가져오고 트래픽을 서버 간에 자동으로 분산합니다. 서버가 서버 간 트래픽을 수신하지 못하도록 차단하려면 토폴로지에서 서버를 제거해야 합니다.

이 섹션에서는 영구 채팅 서버를 배포하는 데 필요한 DNS(Domain Name System) 레코드에 대해 설명합니다.

다음 표에서는 영구 채팅 서버 배포에 대한 DNS 요구 사항을 지정합니다.

영구 채팅 서버에 대한 DNS 요구 사항

배포 시나리오 DNS 요구 사항

영구 채팅 서버 한 개

서버의 FQDN(정규화된 도메인 이름)을 IP 주소로 확인하는 내부 A 레코드

영구 채팅 풀

서버의 FQDN(정규화된 도메인 이름)을 IP 주소로 확인하는 내부 A 레코드

PersistentChatServer01.contoso.com     10.10.10.1

PersistentChatServer02.contoso.com     10.10.10.2

서버의 FQDN(정규화된 도메인 이름)을 IP 주소로 확인하는 내부 A 레코드

PersistentChatPool.contoso.com    10.10.10.1

PersistentChatPool.contoso.com    10.10.10.2

 
표시: