다음을 통해 공유

Exchange 2010의 부하 분산 이해

  • 아티클

 

적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3

마지막으로 수정된 항목: 2016-11-28

부하 분산은 어떤 서버가 트래픽을 수신할지 관리하기 위한 방법입니다. 부하 분산은 장애 조치 중복을 제공하여 컴퓨터 오류가 발생한 경우 사용자가 Exchange 서비스를 계속 받을 수 있도록 합니다. 또한 이를 사용하면 배포를 통해 클라이언트에 대한 단일 호스트 이름을 제공하면서 하나의 서버가 처리할 수 있는 것보다 많은 트래픽을 처리할 수 있습니다.

Microsoft Exchange Server 2010은 부하 분산뿐 아니라 전환 또는 장애 조치 중복을 위한 여러 가지 솔루션을 제공합니다. 이 솔루션에는 다음이 포함됩니다.

  • 고가용성 및 사이트 복구   각기 다른 지리적 위치에 두 개의 Active Directory 사이트를 배포하고, 이 두 사이트 간에 사서함 데이터가 동기화되도록 유지하며, 사이트 중 하나에 문제가 있을 대 다른 사이트에서 전체 부하를 수행하도록 할 수 있습니다. Exchange 2010에서는 DAG(데이터베이스 가용성 그룹)를 사용하여 동기화된 다른 서버에 여러 개의 사서함 복사본을 유지합니다.

  • 온라인 사서함 이동 온라인 사서함 이동에서는 최종 사용자가 이동 중에도 전자 메일 계정에 액세스할 수 있습니다. 최종 동기화가 수행되는 프로세스 마지막 부분의 잠깐 동안만 사용자 계정이 잠깁니다. 온라인 사서함 이동은 Exchange 2010 데이터베이스 사이와 Exchange Server 2007 SP3(서비스 팩 3) 버전 또는 Exchange 2007 이상과 Exchange 2010 데이터베이스 사이에 지원됩니다. 포리스트 간이나 같은 포리스트에서 온라인 사서함 이동을 수행할 수 있습니다.

  • 섀도 중복성   섀도 중복성은 메시지가 전송되는 동안 메시지의 가용성과 복구 기능을 보호합니다. 섀도 중복성을 사용하면 전송 서버가 해당 메시지에 대한 다음 홉이 모두 완료되었다는 것을 확인할 때까지 전송 데이터베이스에서의 메시지 삭제가 지연됩니다. 배달 성공이 보고되기 전에 다음 홉이 실패하는 경우 배달을 위해 메시지가 완료되지 않은 홉으로 다시 제출됩니다.

목차

부하 분산의 개요

Exchange 2010 트래픽 부하 이해

부하 분산 옵션 이해

부하 분산 권장 사항

선호도 옵션

부하 분산의 개요

부하 분산에는 두 가지 주요 목적이 있습니다. Active Directory 사이트 중의 하나에서 발생하는 단일 클라이언트 액세스 서버 장애가 미치는 영향이 줄어듭니다. 또한 부하 분산을 통해 클라이언트 액세스 서버 및 허브 전송 컴퓨터의 부하가 균등하게 분산됩니다.

Exchange 2010 부하 분산의 구조적 변화

Exchange 2010의 여러 가지 변경 사항으로 인해 조직에 대한 부하 분산의 중요성이 높아집니다. 클라이언트 액세스 서버 역할에 대한 Exchange RPC 클라이언트 액세스 서비스 및 Exchange 주소록 서비스는 액세스를 위한 연결 끝점을 Outlook 및 기타 MAPI 클라이언트에서 사서함 서버 역할 대신 클라이언트 액세스 서버 역할로 이동하여 사서함 장애 조치 동안의 사용자 환경을 개선합니다. Exchange의 이전 버전에서는 사용자의 사서함을 호스트하는 사서함 서버에 직접 연결된 Outlook 및 디렉터리 연결이 사서함 서버 역할을 통해 프록시 처리되거나 특정 Active Directory 글로벌 카탈로그 서버로 직접 참조되었습니다. 이제 이러한 연결이 클라이언트 액세스 서버 역할에 의해 처리되므로 외부 및 내부 Outlook 연결 모두의 부하를 배포 내의 클라이언트 액세스 서버 배열 전체에 걸쳐 분산하여 내결함성을 달성해야 합니다.

각 Active Directory 사이트와 각 Exchange 버전에 대해 부하가 분산된 클라이언트 액세스 서버 배열을 사용하는 것이 좋습니다. 여러 Active Directory 사이트에 대해 부하가 분산된 하나의 클라이언트 액세스 서버 배열을 공유하거나 동일한 배열 내에서 다양한 Exchange 버전 또는 Exchange의 서비스 팩 버전을 혼합할 수는 없습니다.

기존 조직 내에 Exchange 2010을 설치하고 이전 버전의 Exchange와 동시 사용하도록 레거시 네임스페이스를 구성하면, 클라이언트가 Exchange 2010 클라이언트 액세스 서버 또는 서버 배열에 자동으로 연결됩니다. Exchange 2010 클라이언트 액세스 서버 또는 클라이언트 액세스 서버 배열은 이전 Exchange 버전에 있는 사서함에 대한 클라이언트 요청을 Exchange 2003 프런트 엔드 서버 또는 사서함 버전과 일치하는 Exchange 2007 클라이언트 액세스 서버로 프록시 처리하거나 리디렉션합니다. 자세한 내용은 Exchange 2010으로 업그레이드 이해를 참조하십시오.

참고

QFE(Quick Fix Engineering)와 업데이트 롤업을 배열의 모든 부분이나 일부분에 적용하는 경우 이 두 가지를 혼합할 수 있습니다. 배열 내에 있는 모든 컴퓨터에 QFE와 업데이트 롤업을 적용하는 것이 좋습니다.

부하 분산 구성은 클라이언트가 연결할 때 사용하는 호스트 이름과 사용자가 사용하는 SSL(Secure Sockets Layer) 인증서에 직접적인 영향을 미칩니다. Exchange 2010 인증서에 대한 자세한 내용은 디지털 인증서 및 SSL 이해를 참조하십시오.

클라이언트 액세스 서버 배열 구성

Active Directory 사이트당 하나의 클라이언트 액세스 서버 배열을 구성할 수 있습니다. 클라이언트 액세스 서버 배열이 구성되자마자 클라이언트 액세스 서버 배열을 특정 클라이언트 액세스 서버가 아닌 MAPI 끝점으로 사용하도록 사서함 데이터베이스를 구성할 수 있습니다.

클라이언트 액세스 서버 배열과 특정 Active Directory 사이트에 대해 클라이언트 액세스 서버 배열을 사용하도록 사서함 데이터베이스를 구성하는 방법에 대한 자세한 내용은 RPC 클라이언트 액세스 이해를 참조하십시오.

Exchange 2010 트래픽 부하 이해

부하 분산을 구성하려면 Exchange 2010 클라이언트 액세스 서버에 배치된 부하에 대해 잘 알고 있어야 합니다. Exchange 2010 클라이언트 액세스 서버는 다음과 같은 세 가지 유형의 트래픽을 수신합니다.

  • 외부 클라이언트로부터의 트래픽

  • 내부 클라이언트로부터의 트래픽

  • 다른 클라이언트 액세스 서버로부터의 프록시 트래픽

다른 클라이언트 액세스 서버로부터의 프록시 트래픽은 외부 또는 내부 클라이언트가 원래 하나의 클라이언트 액세스 서버로 보냈지만 다른 클라이언트 액세스 서버로 프록시 처리된 트래픽입니다. 이것은 여러 가지 이유로 발생할 수 있지만 일반적으로 원래 클라이언트가 대상 클라이언트 액세스 서버에 직접 연결할 수 없기 때문에 발생합니다. 사용자가 인터넷에서 사서함에 액세스하려고 시도하는 경우 이런 현상이 발생할 수 있지만, 사서함은 인터넷과 연결되지 않은 Active Directory 사이트에 위치해 있습니다. 프록시 처리에 대한 자세한 내용은 프록시 및 리디렉션 이해를 참조하십시오.

클라이언트 액세스 서버에서 수신하는 각 트래픽 유형에는 프로토콜 목록의 요청이 포함되며 이러한 각 유형은 특성이 다른 클라이언트 장치와 컴퓨터에서 가져온 것입니다. 이러한 차이는 사용할 수 있는 부하 분산 전략에 영향을 미칩니다.

맨 위로 이동

부하 분산 옵션 이해

다양한 부하 분산 솔루션 간에는 여러 가지 주요한 기술적 차이가 있습니다.

  • 성능   솔루션에서 초당 몇 개의 요청 수를 처리할 수 있습니까?

  • 관리 효율성   부하 분산 솔루션을 구성하고 배포하는 것이 얼마나 간단합니까?

  • 장애 조치 자동화 및 검색 부하 분산 장치가 클라이언트 액세스 서버 또는 서비스 작업 실패를 얼마나 스마트하게 검색합니까?

  • 선호도 어떤 유형의 클라이언트와 클라이언트 액세스 서버 간 선호도가 부하 분산 솔루션을 지원합니까?

선호도 이해

부하 분산 솔루션이 클라이언트와 클라이언트 액세스 서버 간 선호도를 제공하는 것은 특정 클라이언트와 특정 클라이언트 액세스 서버 간에 오랫동안 지속되는 연관 관계가 있다는 것을 의미합니다. 클라이언트는 랩톱에서 실행되는 Outlook, 모바일 장치에서 실행되는 Microsoft Exchange ActiveSync, Microsoft Office Outlook Web App, Exchange 웹 서비스 또는 또 다른 클라이언트 응용 프로그램일 수 있습니다.

오랫동안 지속되는 이러한 연관 관계 또는 선호도는 클라이언트에서 보낸 모든 요청이 동일한 클라이언트 액세스 서버로 전송되도록 해 줍니다. 어떤 Exchange 2010 프로토콜에는 선호도가 반드시 필요하며 어떤 Exchange 프로토콜에서는 그렇지 않습니다.

Windows 네트워크 부하 분산

WNLB(Windows 네트워크 부하 분산)는 Exchange 서버에 대해 사용되는 가장 일반적인 소프트웨어 부하 분산 장치입니다. Microsoft Exchange를 통한 WNLB 배포와 관련된 몇 가지 제한 사항이 있습니다.

  • WNLB는 Windows 장애 조치 클러스터링과 호환되지 않기 때문에 사서함 DAG를 사용 중인 Exchange 서버에서는 WNLB를 사용할 수 없습니다. Exchange 2010 DAG를 사용 중이며 WNLB를 사용하려는 경우 클라이언트 액세스 서버 역할과 사서함 서버 역할을 서로 다른 서버에서 실행해야 합니다.

  • 성능 문제로 인해 WNLB로 부하가 분산되는 배열에 8대가 넘는 클라이언트 액세스 서버를 배치하지 않는 것이 좋습니다.

  • WNLB는 서비스 중지를 검색하지 않습니다. WNLB는 IP 주소에 의한 서버 중지만 검색합니다. 즉, Outlook Web App과 같은 특정 웹 서비스에 장애가 발생하지만 서버가 계속 작동하면, WNLB는 장애를 검색하지 못하고 해당 클라이언트 액세스 서버로 요청을 계속 라우팅하게 됩니다. 부하 분산 풀에서 중지된 클라이언트 액세스 서버를 제거하려면 수동으로 작업해야 합니다.

  • WNLB 구성으로 포트 초과가 발생하여 네트워크가 과부하될 수 있습니다.

  • WNLB는 원본 IP 주소를 사용하여 클라이언트 선호도만 수행하므로 원본 IP 풀이 작을 때는 효과적인 솔루션이 아닙니다. 원본 IP 풀이 원격 네트워크 서브넷에서 가져온 것이거나 조직에서 네트워크 주소 변환을 사용 중인 경우 이러한 상황이 발생합니다.

부하 분산 권장 사항

여러 가지 부하 분산 옵션을 사용할 수 있습니다. 사용하는 옵션은 네트워크의 크기와 구성에 따라 다릅니다.

원본 IP 선호도를 통한 Windows 네트워크 부하 분산

첫 번째 부하 분산 옵션은 원본 IP 선호도를 통한 WNLB입니다. Active Directory 사이트당 두 개 이상(여덟 개 미만)의 클라이언트 액세스 서버가 있는 경우 이 솔루션이 적합합니다. 이 솔루션은 Windows에서 기본 제공되며 추가 컴퓨터가 필요하지 않습니다.

다음 두 가지 시나리오에서는 WNLB를 사용하지 않으려고 할 것입니다.

  • 조직에 WNLB 가상 IP 주소를 통해서가 아니라 클라이언트 액세스 서버와 직접 통신하는 역방향 프록시 서버가 있습니다. 역방향 프록시 서버는 클라이언트 액세스 서버 배열에서 클라이언트 IP 주소를 숨깁니다. 따라서 원본 IP 선호도가 예상대로 작동하지 않습니다. 하지만 계속 WNLB를 사용하여 내부 트래픽의 부하를 분산할 수는 있습니다.

  • 조직에 매우 작은 IP 주소 집합을 통해 클라이언트 액세스 서버에 액세스하는 여러 클라이언트가 있습니다. WNLB에서는 전체 클래스 C 서브넷을 하나의 클라이언트 액세스 서버와 밀접하게 연결할 가능성이 높습니다.

하드웨어 부하 분산

단일 Active Directory 사이트에 여덟 대가 넘는 클라이언트 액세스 서버가 있는 경우, 조직에는 더욱 강력한 부하 분산 솔루션이 필요합니다. 강력한 소프트웨어 부하 분산 솔루션을 사용할 수는 있지만 가장 많은 용량을 제공하는 것은 하드웨어 부하 분산 솔루션입니다. Exchange 2010 서버 부하 분산 솔루션에 대한 자세한 내용은 Microsoft 통합 통신 하드웨어 부하 분산 장치 배포를 참조하십시오.

하드웨어 부하 분산 장치는 매우 높은 트래픽 처리량을 지원하며 다양한 방법으로 부하를 분산하도록 구성될 수 있습니다. 대부분의 하드웨어 부하 분산 장치 공급업체에는 자사 제품이 Exchange 2010에서 어떻게 작동하는지에 대한 자세한 설명서가 있습니다. 하드웨어 부하 분산 장치를 구성하는 가장 간단한 방법은 부하 분산 장치가 적용할 선호도 방법의 대체 목록을 만드는 것입니다. 예를 들어 부하 분산 장치는 먼저 쿠키 기반 선호도를 시도한 다음, SSL 세션 ID와 원본 IP 선호도를 차례로 시도합니다.

역방향 프록시 솔루션

Microsoft Forefront TMG(Threat Management Gateway) 또는 Forefront UAG(Unified Access Gateway)와 같은 인터넷에 게시하는 서버에 대한 부하 분산을 수행할 수 있는 역방향 프록시 솔루션이 있는 경우, 이를 사용하는 것이 좋습니다.

트래픽이 역방향 프록시 서버를 통해 클라이언트 액세스 서버에 도달하면 클라이언트의 원래 IP 주소가 역방향 프록시 서버의 IP 주소로 바뀝니다. 이로 인해 원본 IP 선호도가 중단됩니다. 프록시 처리 중인 서브넷에 대한 기본 게이트웨이가 되도록 역방향 프록시 서버를 구성하는 것을 포함하여 이 문제를 해결하는 여러 가지 방법이 있습니다.

하지만 최신 역방향 프록시 서버는 인터넷에 게시하는 서비스에 대한 부하 분산을 수행할 수 있습니다. 이러한 역방향 프록시 서버는 이를 지원하는 Exchange 서비스에 대해 부하 분산 장치에서 만들어진 쿠키 부하 분산을 지원합니다. 이 솔루션은 원본 IP 부하 분산보다 더 안정적입니다. 이 솔루션이 작동되려면 역방향 프록시 서버가 HTTP 데이터 스트림을 읽고 수정할 수 있어야 합니다. 즉, SSL을 사용 중인 경우에는 역방향 프록시 서버가 트래픽의 암호를 해독하여 내용을 읽고 스트림 내에서 쿠키를 만들어야 합니다. 클라이언트가 클라이언트 액세스 서버에 연결되어 있는 클라이언트 인증서 인증을 사용 중인 경우와 같은 일부 상황에서는 이러한 암호 해독을 수행할 수 없습니다.

맨 위로 이동

선호도 옵션

다른 부하 분산 솔루션은 클라이언트를 특정 클라이언트 액세스 서버와 연결하기 위한 다른 방법을 제공합니다. 하드웨어와 소프트웨어를 모두 포함한 다양한 부하 분산 제품에서는 여러 가지 일반적인 유형의 선호도를 사용할 수 있습니다. 다음 예에서 설명된 것처럼 모든 부하 분산 옵션에서 모든 유형의 선호도가 지원되는 것은 아닙니다.

  • WNLB는 원본 IP 선호도만 지원하거나 어떤 선호도도 지원하지 않습니다.

  • 서로 다른 서버 배열에 있는 소프트웨어 부하 분산 장치에서는 나머지 프로토콜에 대한 부하 분산 장치에서 만들어진 쿠키와 원본 IP 선호도를 지원하는 프로토콜에 대해 해당 쿠키를 사용할 수 있습니다.

  • SSL 오프로딩을 사용하는 하드웨어 부하 분산 장치를 통해 더 복잡한 동작을 구성할 수 있습니다. 예를 들어 부하 분산 장치에서 만들어진 쿠키, SSL 세션 ID 및 원본 IP와 해당 쿠키를 지원하는 프로토콜에 적용될 기존 쿠키 집합을 구성할 수 있습니다.

다른 부하 분산 솔루션에서 지원되는 옵션뿐 아니라 특정 Exchange 프로토콜 및 서비스에 대해서만 적용되는 이러한 몇 가지 단계를 구성할 수 있습니다. 각 프로토콜이 다르게 작동하므로 이를 통해 성능 최적화에 도움을 얻을 수 있습니다.

기존 쿠키 또는 HTTP 헤더

기존 쿠키 또는 HTTP 헤더를 사용하는 것은 가장 안정적으로 클라이언트를 식별하고 이를 특정 클라이언트 액세스 서버와 연관할 수 있는 방법입니다. 이러한 쿠키와 헤더는 통신 프로토콜의 일부로서 클라이언트나 서버에서 만들어집니다. 또한 이 옵션에서는 부하 분산 장치가 트래픽을 수정할 필요가 없으므로 성능에 도움이 됩니다.

이 선호도 옵션을 사용하는 경우 다음 사항을 고려해야 합니다.

  • 부하 분산 장치가 이 유형의 선호도를 지원해야 합니다. 현재 하드웨어 부하 분산 장치만 이 선호도를 지원합니다.

  • 이 선호도는 HTTP에서 트래픽을 전달하는 프로토콜에 대해서만 작동합니다.

  • 클라이언트 세션 동안 일정하게 유지되며 프로토콜에서 각 특정 클라이언트 또는 작은 클라이언트 집합에 대해 고유한 기존 쿠키 또는 헤더가 있어야 합니다.

  • 부하 분산 장치 솔루션이 HTTP 데이터 스트림을 읽고 해석할 수 있어야 합니다. 즉, SSL을 사용 중인 경우에는 부하 분산 장치가 트래픽의 암호를 해독하여 내용을 읽어야 합니다. 경우에 따라 이로 인해 부하 분산 장치의 부하가 증가하기도 합니다. 또한 클라이언트가 클라이언트 액세스 서버에 연결된 SSL 세션에서 클라이언트 인증서 인증을 사용하는 경우와 같은 일부 상황에서는 이러한 암호 해독을 수행할 수 없습니다.

Exchange 2010 프로토콜에서 사용할 수 있는 부하 분산에 적합한 기존 쿠키와 HTTP 헤더는 다음과 같습니다.

  • HTTP 기본 인증 권한 부여 헤더   이 헤더는 HTTP 기본 인증이 사용될 때 작동됩니다. 기본 인증은 Exchange ActiveSync에 대해 가장 일반적으로 사용되는 기본 유형의 인증입니다. 다른 프로토콜 및 인증 방법에서는 이 헤더가 일반적으로 사용되지 않습니다. 기본 인증 헤더는 기본 인증을 사용하고 특정 사용자로부터 동일한 클라이언트 액세스 서버로의 모든 트래픽을 보냅니다. Outlook 트래픽이 HTTP를 통해 완전히 전송되고 클라이언트가 역방향 프록시 서버 뒤에 있을 때도 이 헤더가 사용됩니다.

  • HTTP OWA UserContext 쿠키   이 쿠키는 이를 사용하는 유일한 클라이언트인 Outlook Web App에 대해 작동합니다. 기본 구성인 Outlook Web App에서 FBA(폼 기반 인증)를 사용하는 경우, UserContext 쿠키가 만들어지기 전 Outlook Web App 세션이 시작될 때 작은 요청 집합이 만들어집니다. 이러한 요청에서 클라이언트를 동일한 클라이언트 액세스 서버에 연결하기 위한 선호도를 사용하도록 하려면(폼 기반 인증이 작동하는 데 필요), UserContext 쿠키를 사용할 때 대체 선호도 옵션이 있어야 합니다. 부하 분산 장치에서 사용할 UserContext 쿠키를 가져오려면 초기 요청에 대한 선호도를 제공하기 위한 대체 수단으로서 SSL 세션 ID 또는 원본 IP 선호도를 사용하는 것이 좋습니다.

    참고

    특정 사서함에 액세스하기 위해 명시적 로그온을 사용하는 Outlook Web App 요청으로 인해 서로 다른 이름과 ID를 가진 UserContext 쿠키를 사용하게 됩니다. 쿠키는 UserContext로 시작되지만, 개별 사서함을 식별하는 문자열이 추가됩니다. 부하 분산 장치에서는 UserContext로 시작하는 쿠키를 먼저 찾아야 하기 때문에 이렇게 되면 UserContext를 통한 부하 분산이 복잡해 집니다. 이에 따라 성능이 저하될 수 있습니다.

  • HTTP Exchange 제어판 msExchEcpCanary 쿠키   이 쿠키는 Exchange 제어판에 대해서만 작동합니다.

  • HTTP Outlook 2010 OutlookSession 쿠키   하드웨어 부하 분산 장치는 OutlookSession 쿠키 및 다른 일반적인 쿠키를 지원합니다. 다음 표에는 Outlook RPC/HTTP에 필요한 OutlookSession 클라이언트 쿠키 지원 요구 사항이 정리되어 있습니다.

    Windows XP

    Windows Vista

    Windows 7

    Outlook 2003

    지원되지 않음

    지원되지 않음

    지원되지 않음

    Outlook 2007

    지원되지 않음

    지원되지 않음

    지원되지 않음

    Outlook 2007 호스팅 팩(KB2544404)

    지원되지 않음

    지원됨

    지원됨

    Outlook 2010

    지원되지 않음

    지원됨

    지원됨

    참고

    Windows XP에서 실행되는 Microsoft Outlook은 부하 분산을 위한 OutlookSession 쿠키를 지원하지 않습니다. 이 시나리오에서는 IP 부하 분산을 사용하는 것이 좋습니다.

  • HTTP Remote PowerShell MS-WSMAN 쿠키   이 방법은 Remote PowerShell에 대해서만 사용 가능합니다.

맨 위로 이동

부하 분산 장치에서 만들어진 쿠키

클라이언트 세션을 클라이언트 액세스 서버와 연관하는 두 번째로 안정적인 방법은 부하 분산 장치에서 만들어진 쿠키를 사용하는 방법입니다. 부하 분산 장치는 HTTP 쿠키를 클라이언트/서버 프로토콜 대화에 추가한 다음, 해당 쿠키를 사용하여 어떤 클라이언트 액세스 서버가 들어오는 요청을 처리해야 할지 결정합니다. 이 방법을 지원하는 Exchange 2010 응용 프로그램은 Outlook Web App, Exchange 제어판 및 Remote PowerShell입니다. 이러한 유형의 쿠키에는 몇 가지 제한이 있습니다.

  • 부하 분산 장치에서 이 유형의 선호도를 지원해야 합니다. 현재 별개의 서버 계층에서 실행되는 하드웨어 부하 분산 장치 및 소프트웨어 부하 분산 장치만 이 선호도를 지원합니다.

  • 이 방법은 HTTP에서 트래픽을 전달하는 프로토콜에 대해서만 작동합니다. RPC 클라이언트 액세스 서비스, Exchange 주소록 서비스, POP3 또는 IMAP4에는 이 방법을 사용할 수 없습니다.

  • 부하 분산 장치 솔루션이 HTTP 데이터 스트림을 읽고 해석할 수 있어야 합니다. 즉, SSL을 사용 중인 경우에는 부하 분산 장치가 트래픽의 암호를 해독하여 내용을 읽어야 합니다. 경우에 따라 이로 인해 부하 분산 장치의 부하가 증가하기도 합니다. 클라이언트 액세스 서버에서 클라이언트 인증서 인증을 사용할 때와 같이 부하 분산 장치가 HTTP 데이터 스트림을 해석할 수 없는 경우도 있습니다.

  • 클라이언트는 서버에서 임의의 쿠키를 수신할 수 있어야 하며, 그런 다음 클라이언트에서 서버로 전송되는 향후의 모든 요청에 해당 쿠키가 포함되어야 합니다. Exchange ActiveSync 클라이언트, Outlook Anywhere 클라이언트 및 Exchange Microsoft Communications Server 2007 장치와 같은 일부 Office 웹 서비스 클라이언트는 이를 지원하지 않습니다.

SSL 세션 ID

SSL 세션 ID를 바탕으로 한 부하 분산은 원본 IP 선호도보다 자세한 정보를 제공하며 이를 통해 서로 다른 클라이언트가 같은 IP 주소에서 수신되더라도 해당 클라이언트로부터의 트래픽을 분할할 수 있습니다. SSL 세션 ID 부하 분산에는 또한 SSL 트래픽의 암호를 해독하지 않고 부하를 분산할 수 있는 이점이 있습니다. 클라이언트 인증서 인증을 사용하는 경우와 클라이언트 액세스 서버에서 SSL 연결을 종료하는 경우 이것이 필요합니다.

다음 두 가지 상황에서는 SSL 세션 ID 선호도가 권장되지 않습니다.

  • Internet Explorer 8과 같은 일부 클라이언트에서는 클라이언트 컴퓨터에서 실행되는 각 브라우저 프로세스에 대해 SSL 세션을 다시 만듭니다. 이렇게 하면 각 Outlook Web App 창에 대한 새 SSL 세션이 만들어집니다. 이를 통해 Outlook Web App에 대한 클라이언트 선호도가 중단되므로 이런 방법을 사용한 부하 분산 배포는 Exchange 2010에서 지원되지 않습니다. Apple iPhone과 같은 일부 모바일 장치에서도 Exchange와의 Exchange ActiveSync 통신의 일부에 대한 새 SSL 세션을 만듭니다.

    참고

    클라이언트 인증서 인증을 사용하는 경우, 브라우저는 특정 호스트 이름으로의 모든 트래픽에 대해 같은 SSL 세션을 사용합니다. 클라이언트 인증서 인증을 사용하는 한, SSL 세션 ID는 Outlook Web App 및 Exchange 제어판에 대한 유효한 선호도 옵션입니다.

  • Outlook Anywhere의 경우, 클라이언트 액세스 서버는 Windows RPC 프록시 구성 요소를 사용하여 RPC_DATA_IN 및 RPC_DATA_OUT 연결을 쌍으로 구성합니다. 이는 성능에 좋지 않은 영향을 줄 수 있습니다.

원본 IP

클라이언트와 클라이언트 액세스 서버 간의 선호도를 제공하는 가장 일반적인 방법은 원본 IP 선호도를 사용하는 것입니다. 부하 분산 장치는 클라이언트 IP 주소를 검사하고 특정 원본 IP에서 특정 클라이언트 액세스 서버로 모든 트래픽을 보냅니다. 이것이 WNLB에서 지원하는 유일한 선호도 유형입니다. 원본 IP 선호도를 사용하는 경우 고려해야 할 두 가지 중요한 사항이 있습니다.

  • 클라이언트에서 IP 주소를 변경하면 선호도가 중단됩니다. 랩톱이 유선 LAN에서 Wi-Fi로 이동되거나 다른 Wi-Fi 네트워크 간에 로밍되면 이러한 문제가 발생할 수 있습니다. 클라이언트에서 IP 주소를 변경하면 사용자에게 영향을 미칩니다. 예를 들어 Outlook Web App을 사용 중인 경우 사용자는 컴퓨터에서 새 IP 주소를 가져올 때마다 인증을 수행해야 합니다.

  • 여러 클라이언트가 같은 IP 주소에서 부하 분산 솔루션에 액세스하는 경우, 부하가 균등하지 않게 분산됩니다. 이런 현상이 미치는 영향은 얼마나 많은 클라이언트가 특정 IP 주소 뒤에 숨겨져 있는지에 따라 결정됩니다. 예를 들어 4대의 클라이언트 액세스 서버가 있으며 클라이언트 중 50%가 같은 IP 주소에서 부하 분산 장치에 액세스하는 경우, 트래픽 중 최소한 50%는 하나의 클라이언트 액세스 서버로 이동하며 다른 세 대의 클라이언트 액세스 서버에서 나머지 트래픽을 처리합니다. 대부분의 클라이언트가 단일 IP 주소를 통해 Exchange 조직에 액세스하는 데는 두 가지 주요 이유가 있습니다.

    • NAT(네트워크 주소 변환기) 또는 Microsoft Forefront TMG(Threat Management Gateway)와 같은 발신 프록시 서버. 클라이언트와 클라이언트 액세스 서버 간에 NAT 또는 발신 프록시 서버가 있는 경우, 원래 클라이언트 IP 주소는 NAT 또는 발신 프록시 서버 IP 주소에 의해 숨겨집니다.

    • 클라이언트 액세스 서버에서 클라이언트 액세스 서버 프록시로의 트래픽. 일부 시나리오의 경우 하나의 클라이언트 액세스 서버가 다른 클라이언트 액세스 서버로 트래픽을 프록시 처리합니다. 일반적으로 클라이언트가 사서함과 동일한 Active Directory 사이트 내부의 클라이언트 액세스 서버에 액세스해야 하기 때문에 Active Directory 사이트 간에 이러한 상황이 발생합니다. 프록시 처리에 대한 자세한 내용은 프록시 및 리디렉션 이해를 참조하십시오.

선호도 없음

마지막 선호도 유형은 선호도 없음입니다. 선호도를 사용하지 않는 경우, 클라이언트로부터의 각 요청은 임의의 클라이언트 액세스 서버에 할당됩니다. 선호도가 필요한 프로토콜 또는 선호도로 인해 성능상의 이점이 생기는 프로토콜에는 이 옵션을 사용하지 않는 것이 좋습니다.

SSL 오프로딩이 구성되어 있는 경우 선호도가 필요하지 않은 프로토콜에 대해서는 선호도를 사용하지 않는 것이 좋습니다.

맨 위로 이동

부하 분산 옵션 요약

다음 표는 사용 가능한 부하 분산 옵션을 요약한 것입니다.

해결 방법 클라이언트와 클라이언트 액세스 서버 간의 선호도 장애 조치 방법 용량 비용

하드웨어 부하 분산 장치

프로토콜 및 클라이언트에 따라, 다음 방법 간에 대체 방안으로 변경됩니다.

기존 쿠키

부하 분산 장치에서 만들어진 쿠키

SSL ID

원본 IP

클라이언트 가동 중지 시간이 최소화한 자동 장애 조치(failover). 하드웨어 부하 분산 장치는 특정 프로토콜에 대한 장애 조치를 제공할 수도 있습니다.

++++

$$$

별개의 서버 계층에 있는 소프트웨어 부하 분산 장치

참고: TMG와 UAG는 외부 트래픽에 대해 유일하게 작동하는 솔루션입니다.

프로토콜과 클라이언트에 따라 부하 분산 장치에서 만들어진 쿠키나 원본 IP 중 하나

클라이언트 가동 중지 시간을 최소화한 자동 장애 조치(failover).

++

$$

클라이언트 액세스 서버와 동일한 서버 계층에 있는 소프트웨어 부하 분산 장치(WNLB)

원본 IP

클라이언트 가동 중지 시간을 최소화한 자동 장애 조치(failover).

+

$

DNS 라운드 로빈

각 클라이언트가 임의의 클라이언트 액세스 서버 IP 주소를 획득합니다.

수동 문제 검색 및 복구 단계. 관리자가 복구 작업을 수행한 후에도 브라우저 및 운영 체제 DNS 캐싱 동작으로 인해 클라이언트 연결이 이루어지지 않을 수 있습니다. 이 솔루션은 RPC 클라이언트 액세스, Outlook Web App, Exchange 웹 서비스 및 Exchange 제어판과 같은 여러 프로토콜에 대한 선호도가 적용되지 않도록 합니다.

+++

$

부하 분산 장치 없음

각 클라이언트 액세스 서버에 대해 각기 다른 호스트 이름이 수동으로 할당됩니다.

수동 문제 검색 및 장애 조치 단계. 클라이언트 DNS 캐시로 장애 조치가 느려집니다.

+

해당 없음

각 옵션에는 몇 가지 장단점이 있습니다.

  • 하드웨어 부하 분산 장치에는 일반적으로 SSL 오프로딩 및 트래픽 검사와 같은 성능 및 보안 기능이 포함되어 있습니다.

  • 각기 다른 서버 계층에 있는 소프트웨어 부하 분산 장치는 일반적으로 사전 인증, SSL 오프로딩 및 광범위한 트래픽 검사와 같은 역방향 프록시 기능과 함께 더 큰 소프트웨어 패키지의 일부로 포함되어 있습니다. 소프트웨어 부하 분산 장치가 사용자를 사전 인증하면, 선호 클라이언트 액세스 서버에 장애가 발생하는 경우 사용자가 다시 인증할 필요가 없습니다. 하지만 일부 소프트웨어 부하 분산 장치에서는 클라이언트와 역방향 프록시 서버 간의 선호도가 필요합니다. 이 경우 역방향 프록시 서버가 클라이언트 액세스 서버에 대한 부하 분산 작업을 수행하려면 역방향 프록시 서버 앞에 추가 부하 분산 계층이 있어야 합니다.

 © 2010 Microsoft Corporation. 모든 권리 보유.