비즈니스용 Skype의 부하 분산 요구 사항

요약: 비즈니스용 Skype 서버 구현하기 전에 부하 분산 고려 사항을 검토합니다.

부하 분산은 풀의 서버 간에 트래픽을 분산합니다. 프런트 엔드 풀, 중재 서버 풀 또는 에지 서버 풀이 있는 경우 이러한 풀에 대한 부하 분산을 배포해야 합니다.

비즈니스용 Skype 서버 클라이언트-서버 트래픽에 대한 두 가지 유형의 부하 분산 솔루션인 DNS(Domain Name System) 부하 분산 및 하드웨어 부하 분산(HLB로 약어)을 지원합니다. DNS 부하 분산은 더 간단한 관리, 보다 효율적인 문제 해결, 잠재적인 하드웨어 부하 분산 장치 문제로부터 비즈니스용 Skype 서버 트래픽을 격리하는 기능 등 몇 가지 이점을 제공합니다.

배포의 각 풀에 적합한 부하 분산 솔루션을 직접 결정하지만 다음 제한 사항에 유의하세요.

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

  • 일부 유형의 트래픽에는 하드웨어 부하 분산 장치가 필요합니다. 예를 들어 HTTP 트래픽에는 DNS 부하 분산 대신 하드웨어 부하 분산 장치가 필요합니다. DNS 부하 분산은 클라이언트-서버 웹 트래픽에서 작동하지 않습니다.

풀에 DNS 부하 분산을 사용하도록 선택했지만 여전히 HTTP 트래픽과 같은 트래픽에 대한 하드웨어 부하 분산 장치를 구현해야 하는 경우 하드웨어 부하 분산 장치의 관리가 크게 간소화됩니다. 예를 들어 하드웨어 부하 분산 장치 구성은 HTTP 및 HTTPS 트래픽만 관리하는 반면 다른 모든 프로토콜은 DNS 부하 분산을 통해 관리되므로 더 간단합니다. 자세한 내용은 DNS 부하 분산을 참조하세요.

서버-서버 트래픽의 경우 비즈니스용 Skype 서버 토폴로지 인식 부하 분산을 사용합니다. 서버는 중앙 관리 저장소에서 게시된 토폴로지를 읽고 토폴로지에서 서버의 FQDN을 가져오고 서버 간에 트래픽을 자동으로 분산합니다. 관리자는 이러한 유형의 부하 분산을 설정하거나 관리할 필요가 없습니다.

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

하드웨어 부하 분산 장치 요구 사항

비즈니스용 Skype 서버 확장된 통합 Edge 토폴로지는 주로 비즈니스용 Skype 서버 또는 Lync Server를 사용하는 다른 조직과 페더레이션되는 새 배포에 대한 DNS 부하 분산에 최적화되어 있습니다. 다음 시나리오에 고가용성이 필요한 경우 다음을 위해 Edge Server 풀에서 하드웨어 부하 분산 장치를 사용해야 합니다.

  • Office Communications Server 2007 R2 또는 Office Communications Server 2007을 사용하여 조직과 페더레이션

  • EXCHANGE 2010 및 SP1 이전의 Exchange UM을 사용하는 원격 사용자에 대한 Exchange UM

  • 공용 메신저 사용자에 대한 연결

중요

한 인터페이스에서 DNS 부하 분산을 사용하고 다른 인터페이스에서 하드웨어 부하 분산을 사용하는 것은 지원되지 않습니다. 둘 다에 대해 인터페이스 또는 DNS 부하 분산 모두에 하드웨어 부하 분산을 사용해야 합니다.

참고

하드웨어 부하 분산 장치를 사용하는 경우 내부 네트워크와의 연결에 배포된 부하 분산 장치는 Access Edge 서비스 및 A/V Edge 서비스를 실행하는 서버에 대한 트래픽만 부하 분산하도록 구성되어야 합니다. 트래픽을 내부 웹 회의 Edge 서비스 또는 내부 XMPP 프록시 서비스에 부하를 분산할 수 없습니다.

참고

DSR(직접 서버 반환) NAT는 비즈니스용 Skype 서버 지원되지 않습니다.

하드웨어 부하 분산 장치가 비즈니스용 Skype 서버 필요한 기능을 지원하는지 여부를 확인하려면 Skype for Business 인프라를 참조하세요.

A/V Edge 서비스를 실행하는 Edge 서버에 대한 하드웨어 Load Balancer 요구 사항

다음은 A/V Edge 서비스를 실행하는 Edge 서버에 대한 하드웨어 부하 분산 장치 요구 사항입니다.

  • 내부 및 외부 포트 443 모두에 대한 TCP 잔소리를 끕니다. Nagling은 보다 효율적인 전송을 위해 여러 개의 작은 패킷을 하나의 더 큰 패킷으로 결합하는 프로세스입니다.

  • 외부 포트 범위 50,000 - 59,999에 대한 TCP 잔소리를 끕니다.

  • 내부 또는 외부 방화벽에서 NAT를 사용하지 마세요.

  • 에지 내부 인터페이스는 Edge Server 외부 인터페이스와 다른 네트워크에 있어야 하며 둘 간의 라우팅을 사용하지 않도록 설정해야 합니다.

  • A/V Edge 서비스를 실행하는 Edge Server의 외부 인터페이스는 공개적으로 라우팅 가능한 IP 주소를 사용해야 하며 에지 외부 IP 주소에는 NAT 또는 포트 변환이 없어야 합니다.

  • 부하 분산 장치는 클라이언트의 원본 주소를 변경하지 않아야 합니다.

기타 하드웨어 Load Balancer 요구 사항

웹 서비스의 비즈니스용 Skype 서버 쿠키 기반 선호도 요구 사항이 크게 줄어듭니다. 비즈니스용 Skype 서버 배포하고 Lync Server 2010 프런트 엔드 서버 또는 프런트 엔드 풀을 유지하지 않는 경우 쿠키 기반 지속성이 필요하지 않습니다. 그러나 Lync Server 2010 프런트 엔드 서버 또는 프런트 엔드 풀을 일시적으로 또는 영구적으로 유지하는 경우 Lync Server 2010에 배포 및 구성될 때 쿠키 기반 지속성을 계속 사용합니다.

참고

배포에 필요하지 않더라도 쿠키 기반 선호도를 사용하기로 결정한 경우 쿠키 기반 선호도에 부정적인 영향을 미치지 않습니다.

쿠키 기반 선호도를 사용하지 않는 배포의 경우:

  • 포트 4443에 대한 역방향 프록시 게시 규칙에서 호스트 헤더 전달 을 True로 설정합니다. 이렇게 하면 원래 URL이 전달됩니다.

쿠키 기반 선호도를 사용하는 배포의 경우:

  • 포트 4443에 대한 역방향 프록시 게시 규칙에서 호스트 헤더 전달 을 True로 설정합니다. 이렇게 하면 원래 URL이 전달됩니다.

  • 하드웨어 부하 분산 장치 쿠키를 httpOnly로 표시해서는 안 됩니다.

  • 하드웨어 부하 분산 장치 쿠키에 만료 시간이 없어야 합니다.

  • 하드웨어 부하 분산 장치 쿠키의 이름은 MS-WSMAN 이어야 합니다(웹 서비스에서 예상하는 값이며 변경할 수 없음).

  • 하드웨어 부하 분산 장치 쿠키는 동일한 TCP 연결에서 이전 HTTP 응답이 이미 쿠키를 얻었는지 여부에 관계없이 들어오는 HTTP 요청에 쿠키가 없는 모든 HTTP 응답에서 설정해야 합니다. 부하 분산 장치가 쿠키 삽입을 최적화하여 TCP 연결당 한 번만 발생하는 경우 해당 최적화를 사용하지 않아야 합니다.

참고

일반적인 하드웨어 부하 분산 장치 구성은 원본 주소 선호도와 20분 동안 사용합니다. TCP 세션 수명은 클라이언트 사용 및/또는 애플리케이션 상호 작용을 통해 세션 상태가 유지 관리되므로 Lync Server 및 Lync 2013 클라이언트에 적합합니다.

모바일 디바이스를 배포하는 경우 하드웨어 부하 분산 장치는 TCP 세션 내에서 개별 요청의 부하를 분산할 수 있어야 합니다(사실상 대상 IP 주소에 따라 개별 요청의 부하를 분산할 수 있어야 합니다).

주의

모바일 디바이스를 배포하는 경우 하드웨어 부하 분산 장치는 TCP 연결 내에서 각 요청의 부하를 개별적으로 분산할 수 있어야 합니다. 최신 Apple iOS 모바일 앱에는 TLS(전송 계층 보안) 버전 1.2가 필요합니다.

주의

타사 하드웨어 부하 분산 장치에 대한 자세한 내용은 Skype for Business 인프라를 참조하세요.

다음은 디렉터 및 프런트 엔드 풀 웹 서비스에 대한 하드웨어 부하 분산 장치 요구 사항입니다.

  • 내부 웹 서비스 VIP의 경우 하드웨어 부하 분산 장치에서 Source_addr 지속성(내부 포트 80, 443)을 설정합니다. 비즈니스용 Skype 서버 경우 Source_addr 지속성은 세션 상태를 유지하기 위해 단일 IP 주소에서 들어오는 여러 연결이 항상 하나의 서버로 전송됨을 의미합니다.

  • 1800초의 TCP 유휴 시간 제한을 사용합니다.

  • 역방향 프록시와 다음 홉 풀의 하드웨어 부하 분산 장치 사이의 방화벽에서 https: 포트 4443의 트래픽을 역방향 프록시에서 하드웨어 부하 분산 장치로 허용하는 규칙을 만듭니다. 80, 443 및 4443 포트에서 수신 대기하도록 하드웨어 부하 분산 장치를 구성해야 합니다.

하드웨어 Load Balancer 선호도 요구 사항 요약

클라이언트/사용자 위치 외부 웹 서비스 FQDN 선호도 요구 사항 내부 웹 서비스 FQDN 선호도 요구 사항
Lync 웹앱(내부 및 외부 사용자)
모바일 디바이스(내부 및 외부 사용자)
선호도 없음
원본 주소 선호도
Lync 웹앱(외부 사용자만 해당)
모바일 디바이스(내부 및 외부 사용자)
선호도 없음
원본 주소 선호도
Lync 웹앱(내부 사용자만 해당)
모바일 디바이스(배포되지 않음)
선호도 없음
원본 주소 선호도

하드웨어 부하 분산 장치에 대한 포트 모니터링

하드웨어 부하 분산 장치에서 포트 모니터링을 정의하여 하드웨어 또는 통신 오류로 인해 특정 서비스를 더 이상 사용할 수 없는 시기를 결정합니다. 예를 들어 프런트 엔드 서버 또는 프런트 엔드 풀이 실패하여 RTCSRV(프런트 엔드 서버 서비스)가 중지되는 경우 HLB 모니터링도 웹 서비스에서 트래픽 수신을 중지해야 합니다. HLB에서 포트 모니터링을 구현하여 다음을 모니터링합니다.

프런트 엔드 서버 사용자 풀 - HLB 내부 인터페이스

가상 IP/포트 노드 포트 Node Machine/Monitor 지속성 프로필 참고
<pool>web-int_mco_443_vs
443
443
프런트 엔드
5061
소스
HTTPS
<pool>web-int_mco_80_vs
80
80
프런트 엔드
5061
소스
HTTP(HTTP)

프런트 엔드 서버 사용자 풀 - HLB 외부 인터페이스

가상 IP/포트 노드 포트 Node Machine/Monitor 지속성 프로필 참고
<풀>web_mco_443_vs
443
4443
프런트 엔드
5061
없음
HTTPS
<풀>web_mco_80_vs
80
8080
프런트 엔드
5061
없음
HTTP(HTTP)

DNS 부하 분산

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

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

다음 다이어그램은 내부 및 외부 DNS 부하 분산을 모두 포함하는 예제를 보여줍니다.

공용 IPv4 주소를 사용하는 에지 네트워크 다이어그램

DNS 네트워크 다이어그램의 예입니다.

DNS 부하 분산을 사용하는 경우 모든 유형의 트래픽에 하드웨어 부하 분산 장치를 사용하는 경우보다 저렴한 하드웨어 부하 분산 장치를 구입할 수도 있습니다. 비즈니스용 Skype 서버와 상호 운용성 자격 테스트를 통과한 부하 분산 장치를 사용해야 합니다. 부하 분산 장치 상호 운용성 테스트에 대한 자세한 내용은 Lync Server 2010 Load Balancer 파트너를 참조하세요. 이 콘텐츠는 비즈니스용 Skype 서버에 적용됩니다.

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

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

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

  • 비즈니스용 Skype 쿼리 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 주소 중 하나에 대한 TCP(Transmission Control Protocol) 연결을 설정하려고 시도합니다. 실패하면 클라이언트는 캐시에서 다음 IP 주소를 시도합니다.

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

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

참고

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

DNS 부하 분산은 다음과 같은 용도로 사용됩니다.

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

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

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

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

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

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

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

DNS SRV 쿼리에서 여러 DNS 레코드를 반환하는 경우 Access Edge 서비스는 항상 숫자 우선 순위가 가장 낮고 숫자 가중치가 가장 높은 DNS SRV 레코드를 선택합니다. 인터넷 엔지니어링 태스크 포스 문서 "서비스 위치를 지정하기 위한 DNS RR(DNS SRV)" RFC 2782, DNS SRV RR은 정의된 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 레코드가 반환되면 Access Edge 서비스는 DNS 서버에서 먼저 받은 SRV 레코드를 선택합니다.

프런트 엔드 풀 및 디렉터 풀의 DNS 부하 분산

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

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

DNS 부하 분산 및 이전 클라이언트 및 서버 지원

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

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

  • 휴대폰에서 Enterprise 음성 메일 재생

  • Exchange UM 자동 전화 교환에서 통화 전송

다른 모든 Exchange UM 시나리오가 제대로 작동합니다.

프런트 엔드 풀 및 디렉터 풀에 DNS 부하 분산 배포

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

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

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

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

    주의

    둘 이상의 프런트 엔드 풀 또는 프런트 엔드 서버가 있는 경우 외부 웹 서비스 FQDN은 고유해야 합니다. 예를 들어 프런트 엔드 서버의 외부 웹 서비스 FQDN을 pool01.contoso.com 정의하는 경우 다른 프런트 엔드 풀 또는 프런트 엔드 서버에 pool01.contoso.com 사용할 수 없습니다. 디렉터를 배포하는 경우 디렉터 또는 디렉터 풀에 대해 정의된 외부 웹 서비스 FQDN은 다른 디렉터 또는 디렉터 풀과 프런트 엔드 풀 또는 프런트 엔드 서버에서 고유해야 합니다. 자체 정의 FQDN을 사용하여 내부 웹 서비스를 재정의하려는 경우 각 FQDN은 다른 프런트 엔드 풀, 디렉터 또는 디렉터 풀에서 고유해야 합니다.

에지 서버 풀의 DNS 부하 분산

에지 서버 풀에 DNS 부하 분산을 배포할 수 있습니다. 이렇게 하면 몇 가지 고려 사항을 알고 있어야 합니다.

Edge 서버에서 DNS 부하 분산을 사용하면 다음 시나리오에서 장애 조치(failover) 기능이 손실됩니다.

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

  • 메신저 대화(Im) 서비스 AOL 및 Yahoo!의 사용자와 인스턴트 메시지 교환은 현재 유일하게 지원되는 XMPP 파트너인 Google Talk와 같은 XMPP 기반 공급자 및 서버 외에 있습니다.

이러한 시나리오는 풀의 모든 Edge 서버가 가동되고 실행되는 한 작동하지만, 하나의 Edge Server를 사용할 수 없는 경우 다른 Edge Server로 라우팅하는 대신 해당 서버로 전송되는 이러한 시나리오에 대한 요청이 실패합니다.

Exchange UM을 사용하는 경우 최소 Exchange 2013을 사용하여 Edge에서 비즈니스용 SKYPE 서버 DNS 부하 분산에 대한 지원을 받아야 합니다. 이전 버전의 Exchange를 사용하는 경우 원격 사용자에게 다음 Exchange UM 시나리오에 대한 장애 조치(failover) 기능이 없습니다.

  • 휴대폰에서 Enterprise 음성 메일 재생

  • Exchange UM 자동 전화 교환에서 통화 전송

다른 모든 Exchange UM 시나리오가 제대로 작동합니다.

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

에지 서버 풀에 DNS 부하 분산 배포

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

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

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

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

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

중재 서버 풀에서 DNS 부하 분산 사용

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

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

DNS 부하 분산을 사용하여 서버에 대한 트래픽 차단

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

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