다음을 통해 공유

비즈니스용 Skype 서버 대한 고급 Edge 서버 배포 계획

  • 아티클

요약: 비즈니스용 Skype 서버 배포 옵션에 대한 시나리오를 검토합니다. 단일 서버를 사용하든 DNS 또는 HLB를 사용하는 서버 풀을 선호하든 이 항목이 도움이 됩니다.

비즈니스용 Skype 서버 대한 DNS(도메인 이름 시스템) 계획과 관련하여 많은 요소가 결정에 영향을 주게 될 수 있습니다. organization 도메인 구조가 이미 있는 경우 진행 방법을 검토해야 할 수 있습니다. 아래에서 topics 시작합니다.

서비스를 찾는 Skype for Business 클라이언트 연습

Skype for Business 클라이언트는 비즈니스용 Skype 서버 서비스를 찾고 액세스하는 방식에서 이전 버전의 Lync 클라이언트와 비슷합니다. 이 섹션에서는 서버 위치 프로세스를 자세히 설명합니다.

  1. lyncdiscoverinternal.<도메인>

    내부 웹 서비스의 자동 검색 서비스에 대한 호스트 레코드입니다.

  2. lyncdiscover.<도메인>

    외부 웹 서비스의 자동 검색 서비스에 대한 호스트 레코드입니다.

  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 수 없습니다.

이 작업을 수행하려는 경우 서비스의 수동 검색을 위해 모바일 디바이스를 설정할 수 있습니다. 원하는 경우 각 사용자는 다음과 같이 프로토콜 및 경로를 포함하여 전체 내부 및 외부 자동 검색 서비스 URI를 사용하여 모바일 디바이스 설정을 구성해야 합니다.

  • 외부 액세스의 경우: https://< ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root

  • 내부 액세스의 경우: https://< IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root

수동 검색이 아닌 자동 검색을 사용하는 것이 좋습니다. 그러나 몇 가지 문제 해결 또는 테스트를 수행하는 경우 수동 설정이 매우 유용할 수 있습니다.

분할 브레인 DNS

네임스페이스가 같은 두 개의 DNS 영역이 있는 DNS 구성입니다. 첫 번째 DNS 영역은 내부 요청을 처리하고 두 번째 DNS 영역은 외부 요청을 처리합니다.

회사에서 이 작업을 수행하는 이유는 무엇인가요? 내부 및 외부에서 동일한 네임스페이스를 사용해야 할 수도 있지만, 물론 이로 인해 많은 DNS SRV 및 A 레코드가 한 영역 또는 다른 영역에 고유하며 중복이 있는 경우 이러한 레코드와 연결된 IP 주소는 고유합니다.

이는 몇 가지 과제를 제시합니다. 가장 중요한 것은 분할 브레인 DNS가 Mobility에 지원되지 않는다는 것입니다. 이는 LyncDiscover 및 LyncDiscoverInternal DNS 레코드 때문입니다(LyncDiscover는 외부 DNS 서버에서 정의해야 하지만 LyncDiscoverInternal은 내부 DNS 서버에 정의되어야 합니다).

내부 및 외부 영역에 대한 DNS 레코드는 여기에 나열되지만 Edge Server 환경 요구 사항 섹션에서 자세한 예제를 찾을 수 있습니다.

내부 DNS

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

  • 이 내부 contoso.com 다음을 포함합니다.

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

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

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

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

    • DNS A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 또는 CNAME 레코드를 사용하여 비즈니스용 Skype 서버 Web Services(선택 사항)를 자동으로 검색합니다.

  • 경계 네트워크의 모든 비즈니스용 Skype 서버 내부 Edge 인터페이스는 이 내부 DNS 영역을 사용하여 contoso.com 쿼리를 확인합니다.

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

외부 DNS

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

  • 이 외부 contoso.com 다음을 포함합니다.

    • 비즈니스용 SKYPE 서버 웹 서비스의 자동 검색을 위해 DNS A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 또는 CNAME 레코드입니다. 이는 이동성과 함께 사용하기 위한 것입니다.

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

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

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

분할 브레인 DNS가 없는 자동 구성

분할 브레인 DNS를 사용하지 않는 경우 여기서 해결 방법 중 하나를 사용하지 않는 한 Skype for Business 실행하는 클라이언트의 내부 자동 구성이 작동하지 않습니다. 왜 안 돼요? 비즈니스용 Skype 서버 사용자의 SIP URI가 자동 구성에 지정된 프런트 엔드 풀의 도메인과 일치해야 하기 때문입니다. 이전 버전의 Lync Server에서는 변경되지 않았습니다.

따라서 두 개의 SIP 도메인을 사용하는 경우 다음 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 도메인이 해당 도메인의 프런트 엔드 풀과 일치하기 때문에 이 레코드는 두 번째 도메인의 자동 구성에 대해 작동합니다.

이 예제를 더 자세히 살펴보려면 이 작업이 작동하지 않습니다.

  • _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에서 외부 DNS 영역(예: contoso.com)과 일치하는 영역을 만든 다음, 자동 구성에 사용되는 비즈니스용 Skype 서버 풀에 해당하는 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이라는 프런트 엔드 풀이 있는 경우 내부 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 도메인이 있을 수 있습니다. 이 경우 내부 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이 두 번 표시되지만 두 개의 다른 IP 주소가 표시됩니다. DNS 부하 분산이 사용되었기 때문입니다. HLB를 사용하는 경우 단일 프런트 엔드 풀 항목만 있습니다.

참고

또한 프런트 엔드 풀 FQDN 값은 contoso.com 및 fabrikam.com 예제 간에 변경되지만 IP 주소는 동일하게 유지됩니다. 이는 SIP 도메인에서 로그인하는 사용자가 자동 구성에 동일한 프런트 엔드 풀을 사용하기 때문입니다.

DNS 재해 복구

비즈니스용 Skype 서버 웹 트래픽을 DR(재해 복구) 및 장애 조치(failover) 사이트로 리디렉션하도록 DNS를 구성하려면 GeoDNS를 지원하는 DNS 공급자를 사용해야 합니다. 재해 복구를 지원하도록 DNS 레코드를 설정하여 전체 프런트 엔드 풀이 중단되더라도 웹 서비스를 사용하는 기능이 계속되도록 할 수 있습니다. 이 DR 기능은 자동 검색, 모임 및 전화 접속 단순 URL을 지원합니다.

GeoDNS 공급자에서 웹 서비스의 내부 및 외부 확인을 위해 추가 DNS 호스트 A(IPv6을 사용하는 경우 AAAA) 레코드를 정의하고 구성합니다. 다음 세부 정보는 지리적으로 분산된 쌍을 이루는 풀을 가정 하고 공급자가 지원하는 GeoDNS에 라운드 로빈 DNS가 있거나 Pool1을 기본으로 사용하도록 구성되었으며 통신 손실 또는 정전이 있는 경우 Pool2로 장애 조치(fails over)됩니다.

이 테이블의 모든 DNS 레코드가 예제입니다.

GeoDNS 레코드 풀 레코드 CNAME 레코드 DNS 설정(옵션 하나 선택)
Meet-int.geolb.contoso.com
 Pool1InternalWebFQDN.contoso.com
Pool2InternalWebFQDN.contoso.com
 Meet.contoso.com to Meet-int.geolb.contoso.com

 풀 간 라운드 로빈
또는
주 데이터베이스 사용, 오류가 있는 경우 보조 데이터베이스에 연결
Meet-ext.geolb.contoso.com
 Pool1ExternalWebFQDN.contoso.com
Pool2ExternalWebFQDN.contoso.com
 Meet.contoso.com to Meet-ext.geolb.contoso.com

 풀 간 라운드 로빈
또는
주 데이터베이스 사용, 오류가 있는 경우 보조 데이터베이스에 연결
Dialin-int.geolb.contoso.com
 Pool1InternalWebFQDN.contoso.com
Pool2InternalWebFQDN.contoso.com
 Meet.contoso.com to Meet-int.geolb.contoso.com

 풀 간 라운드 로빈
또는
주 데이터베이스 사용, 오류가 있는 경우 보조 데이터베이스에 연결
Dialin-ext.geolb.contoso.com
 Pool1ExternalWebFQDN.contoso.com
Pool2ExternalWebFQDN.contoso.com
 Meet.contoso.com to Meet-ext.geolb.contoso.com

 풀 간 라운드 로빈
또는
주 데이터베이스 사용, 오류가 있는 경우 보조 데이터베이스에 연결
Lyncdiscoverint-int.geolb.contoso.com
 Pool1InternalWebFQDN.contoso.com
Pool2InternalWebFQDN.contoso.com
 Meet.contoso.com to Meet-int.geolb.contoso.com

 풀 간 라운드 로빈
또는
주 데이터베이스 사용, 오류가 있는 경우 보조 데이터베이스에 연결
Lyncdiscover-ext.geolb.contoso.com
 Pool1ExternalWebFQDN.contoso.com
Pool2ExternalWebFQDN.contoso.com
 Meet.contoso.com to Meet-ext.geolb.contoso.com

 풀 간 라운드 로빈
또는
주 데이터베이스 사용, 오류가 있는 경우 보조 데이터베이스에 연결
Scheduler-int.geolb.contoso.com
 Pool1InternalWebFQDN.contoso.com
Pool2InternalWebFQDN.contoso.com
 Meet.contoso.com to Meet-int.geolb.contoso.com

 풀 간 라운드 로빈
또는
주 데이터베이스 사용, 오류가 있는 경우 보조 데이터베이스에 연결
Scheduler-ext.geolb.contoso.com
 Pool1ExternalWebFQDN.contoso.com
Pool2ExternalWebFQDN.contoso.com
 Meet.contoso.com to Meet-ext.geolb.contoso.com

 풀 간 라운드 로빈
또는
주 데이터베이스 사용, 오류가 있는 경우 보조 데이터베이스에 연결

DNS 부하 분산

DNS 부하 분산은 일반적으로 애플리케이션 수준에서 구현됩니다. 애플리케이션(예: Skype for Business 실행하는 클라이언트)은 풀 FQDN에 대한 DNS A 및 AAAA(IPv6 주소 지정을 사용하는 경우) 레코드 쿼리에서 반환된 IP 주소 중 하나에 연결하여 풀의 서버에 연결하려고 합니다.

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

  • Skype for Business 쿼리 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 연결을 설정하려고 합니다. 실패하면 해당 목록에서 캐시된 다음 IP 주소를 시도합니다.

  • TCP 연결이 성공하면 클라이언트는 TLS를 협상하여 pool01.contoso.com 주 등록 기관에 연결합니다.

  • 클라이언트가 연결에 성공하지 않고 캐시된 모든 항목을 시도하는 경우 사용자는 현재 비즈니스용 Skype 서버 실행하는 서버를 사용할 수 없다는 알림을 받습니다.

참고

DNS 기반 부하 분산은 일반적으로 DNS를 사용하여 풀의 서버에 대해 다른 IP 주소 순서를 제공하여 부하 분산을 참조하는 DNS RR(DNS 라운드 로빈)와 다릅니다. 일반적으로 DNS RR은 부하 분산을 사용하도록 설정하지만 장애 조치(failover)를 사용하도록 설정할 수는 없습니다. 예를 들어 DNS A(또는 IPv6 시나리오의 AAAA)에서 반환된 하나의 IP 주소에 대한 연결이 실패하면 해당 연결이 실패합니다. 따라서 DNS 기반 부하 분산보다 DNS RR의 안정성이 떨어집니다. 필요한 경우 DNS 기반 부하 분산과 함께 DNS RR을 계속 사용할 수 있습니다.

DNS 부하 분산을 사용하여 다음을 수행합니다.

  • 서버 간 SIP를 에지 서버로 부하 분산합니다.

  • 회의 자동 전화 교환, 응답 그룹 및 통화 대기와 같은 UCAS(통합 통신 애플리케이션 서비스) 애플리케이션의 부하를 분산합니다.

  • UCAS 애플리케이션(드레이닝이라고도 함)에 대한 새 연결을 방지합니다.

  • 클라이언트와 Edge 서버 간에 모든 클라이언트-서버 트래픽 부하를 분산합니다.

다음을 위해 DNS 부하 분산을 사용할 수 없습니다.

  • 프런트 엔드 서버 또는 디렉터로의 클라이언트-서버 웹 트래픽.

쿼리에서 여러 DNS 레코드를 반환할 때 DNS SRV 레코드를 선택하는 방법에 대해 좀 더 자세히 알아보려면 Access Edge 서비스는 항상 가장 낮은 숫자 우선 순위로 레코드를 선택하고, 타이 브레이커가 필요한 경우 가장 높은 숫자 가중치를 선택합니다. 이는 인터넷 엔지니어링 태스크 포스 설명서와 일치합니다.

예를 들어 첫 번째 DNS SRV 레코드의 가중치가 20이고 우선 순위가 40이고 두 번째 DNS SRV 레코드의 가중치가 10이고 우선 순위가 50인 경우 첫 번째 레코드는 우선 순위가 40이므로 선택됩니다. 우선 순위는 항상 먼저 진행되며 클라이언트가 먼저 대상으로 지정하는 호스트입니다. 우선 순위가 같은 두 개의 대상이 있는 경우 어떻게 해야 할까요?

이 경우 가중치가 고려됩니다. 더 큰 가중치는 이 상황에서 선택될 확률이 높아야 합니다. DNS 관리자는 서버 선택이 없는 경우 가중치 0을 사용해야 합니다. 가중치가 0보다 큰 레코드가 있는 경우 가중치가 0인 레코드는 선택된 상태로 가져올 가능성이 적습니다.

따라서 반환된 것과 동일한 우선 순위 및 가중치를 가진 여러 DNS SRV 레코드가 있으면 어떻게 되나요? 이 경우 Access Edge 서비스는 DNS 서버에서 받은 SRV 레코드를 먼저 선택합니다.