전송 시 SMTP 장애 조치 및 부하 분산 이해

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

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

조직에서 여러 허브 전송 서버를 사용하는 경우 Exchange는 메일 트래픽을 조직 내의 모든 허브 전송 서버에 자동으로 분산시킵니다. 모든 서버를 사용할 수 있을 때 부하 분산이 균등하게 이루어집니다. 그러나 하나 이상의 서버를 사용할 수 없는 경우, 특히 조직이 여러 Active Directory 사이트에 분산되어 있는 경우에는 나머지 서버에 균등하지 않게 부하가 분산될 수 있습니다.

Microsoft Exchange Server 2010 SP1(서비스 팩 1)에서는 허브 전송 서버에 부하를 분산시키는 결정 메커니즘이 여러 가지로 개선되었습니다.

메시지 라우팅과 관련된 관리 작업에 대한 자세한 내용은 메시지 라우팅 관리를 참조하십시오.

목차

Exchange Server 2010 RTM의 동작

Exchange 2010 SP1의 향상된 기능

전송 서버가 포함된 Windows 네트워크 부하 분산 또는 타사 부하 분산 솔루션

Exchange Server 2010 RTM의 동작

Exchange 2010의 RTM(Release To Manufacturing) 버전에서 전송 서버가 여러 메시지를 동일한 대상에게 라우팅해야 하는 경우 처음에는 서버가 그러한 메시지에 대해 다음 홉을 결정합니다. 다음 홉에 대한 대상 서버가 여러 개인 경우에는 연결 부하를 분산시켜 향상된 DNS(Domain Name System)가 제공하는 라운드 로빈 기능을 사용하여 대상 서버에 균등하게 메시지를 전달합니다. 예를 들어 다음 그림과 같이 각각 3개의 허브 전송 서버를 가진 2개의 Active Directory 사이트가 있는 토폴로지가 있다고 가정해 봅니다. 사이트 A의 허브 전송 서버(예: Hub02)가 사이트 B로 메시지를 전송해야 하는 경우 해당 메시지의 다음 홉은 사이트 B입니다. 다음 홉에는 가능한 대상이 3개, 즉 Hub04, Hub05, Hub06이 있습니다. 서버는 다음 그림과 같이 이 3개 대상에 연결 수를 균등하게 분산시킵니다. 이러한 작업으로 인해 시간이 가면 연결 전체에 메시지가 균등하게 분산됩니다.

Exchange Server 2010 RTM에서의 부하 분산

마찬가지로 사이트 B의 허브 전송 서버는 사이트 A의 받는 사람에게 전송된 메시지를 Hub01, Hub02, Hub03에 균등하게 분산합니다. 또한 사이트 A는 Edge01을 구독하므로 인터넷으로 전송된 메시지의 다음 홉 대상은 Hub01, Hub02 및 Hub03이 됩니다.

다음 홉에서 하나 이상의 서버를 사용할 수 없는 경우에는 문제가 발생합니다. 예를 들어, 사이트 B의 Hub04를 예약된 유지 관리 작업에 사용할 수 없는 경우가 있습니다. 사이트 A의 서버는 사이트 B에 있는 각 서버의 가용성 상태를 유지 관리하지 않습니다. 사이트 A의 서버는 사이트 B로 가게 될 부하를 해당 사이트의 세 허브 전송 서버에 분산시킵니다. 그러나 이 연결의 약 3분의 1은 Hub04로 전송되어도 성공하지 못하게 됩니다. 이 연결은 다음으로 사용 가능한 서버로 장애 조치(failover)가 되며, 사이트 B에 있는 허브 전송 서버 중 하나가 다음 그림과 같이 다른 서버보다 훨씬 많은 부하를 처리하게 됩니다.

불균등한 부하 분산

일반적으로 대상이 2개 이상인 다음 홉에 사용 불가능한 서버가 있는 경우 이런 원치 않는 상황이 발생할 수 있습니다. 다음 홉은 앞의 예제에 나오는 다른 Active Directory 사이트일 수도 있고 원본 서버로 열거된 여러 허브 전송 서버를 포함한 커넥터(예: 위 그림에 표시된 토폴로지에서 구독된 Edge 전송 서버에 대한 송신 커넥터)일 수도 있습니다.

이러한 문제는 사서함 서버에서의 메일 전송에는 해당되지 않습니다. 메일 전송 서비스는 사이트에서 사용할 수 없는 허브 전송 서버를 감지하고 해당 서버로 전송을 시도하지 않습니다. 앞의 예에서는 사이트 B의 허브 전송 서버 중 하나가 사이트 내 트래픽으로 인해 더 큰 부하를 받게 되더라도 사이트 B의 사서함 서버에 의해 발생된 부하는 Hub05와 Hub06에 균등하게 분산됩니다.

Exchange Server 2010 RTM의 동작

Exchange 2010 SP1의 향상된 기능

앞 섹션에서 설명한 문제를 해결하기 위해 정상 서버 선택기라는 새 구성 요소가 Exchange 2010 SP1에 추가되었습니다. 정상 서버 선택기는 사용 불가능한 서버 목록을 유지 관리합니다. 이 목록은 향상된 DNS가 부하 분산을 위해 라운드 로빈 로직을 적용할 때 사용 불가능한 서버를 필터링하는 데 사용합니다. 정상 서버 선택기가 부하 분산을 지원하는 방식을 살펴보기 위해 앞의 그림에 나온 문제 상황을 고려해 보겠습니다. Exchange 2010 SP1에서는 향상된 DNS가 먼저 다음 홉인 사이트 B에서 잠재적 대상 목록을 컴파일한 후 이 목록을 필터링하도록 Healthy Server Selector에 요청합니다. Healthy Server Selector는 다음 홉 사이트 B의 Hub04가 비정상이라고 보고합니다. 향상된 DNS는 다음 홉 사이트 B의 잠재적 대상 목록에서 Hub04를 제거한 후 다음 그림과 같이 Hub05 및 Hub06 사이에서만 라운드 로빈 부하 분산을 이용합니다.

Healthy Server Selector를 사용한 부하 분산

Healthy Server Selector

가장 간단한 형태의 Healthy Server Selector는 비정상 상태로 판단한 서버가 라운드 로빈 부하 분산에 포함되지 않도록 해당 서버를 추적합니다. Healthy Server Selector의 관점에서 비정상 서버란 연결 시도를 했을 때 Windows 소켓(Winsock) 오류 코드가 반환되는 서버를 의미합니다.

Healthy Server Selector는 각 비정상 서버에 대해 다음 정보를 보관합니다.

• 서버 IP 주소

• 다시 시도 횟수

• 마지막 다시 시도 시간

다시 시도 동작

서버가 비정상 상태로 표시되면 Healthy Server Selector는 그 특정 서버와의 연결을 다시 시도하여 서버가 온라인 상태가 되는 시점이 감지되는지 확인합니다. Healthy Server Selector는 다음 설정을 사용하여 비정상 서버에 대해 연결이 다시 시도되는 빈도를 결정합니다.

• QueueGlitchRetryInterval 및 QueueGlitchRetryCount   이 설정을 통해 특정 서버가 처음 비정상 상태로 표시될 때 Healthy Server Selector가 해당 서버에 대한 연결을 다시 시도하는 횟수와 간격이 결정됩니다. 이 설정은 EdgeTransport.exe.config 파일에서 구성됩니다. 이 설정의 기본값은 1분 및 4회 다시 시도입니다. 이 값은 기본 구성일 때 비정상 서버에 대한 연결이 1분에 4회 시도된다는 의미입니다.

• TransientFailureRetryInterval 및 TransientFailureRetryCount   비정상 서버를 사용할 수 없는 경우에는 Healthy Server Selector가 이 설정을 사용하여 다음 다시 시도 집합의 빈도를 결정합니다. 이 설정은 각 전송 서버에 대해 구성됩니다. 기본값은 5분(Edge 전송 서버에서는 10분) 및 6회 다시 시도입니다. 이 값은 기본 구성일 때 비정상 서버에 대한 연결이 처음 4분 후에는 5분마다 6회씩 시도된다는 의미입니다.

• OutboundConnectionFailureRetryInterval   비정상 서버를 사용할 수 없는 경우 Healthy Server Selector는 이 매개 변수에 지정된 빈도에 따라 계속 연결을 다시 시도합니다. 이 설정은 각 전송 서버에 대해 구성됩니다. 기본값은 10분(Edge 전송 서버에서는 30분)입니다. 이 값은 기본 구성일 때 비정상 서버에 대한 연결이 처음 34분 후에는 10분마다 시도된다는 의미입니다.

이 설정의 구성 방법에 대한 단계별 지침은 메시지 다시 시도, 다시 전송 및 만료 간격 구성을 참조하십시오.

연결을 다시 시도할 때가 되면 Healthy Server Selector는 비정상 서버에 대해 단 한 번의 연결 시도만 허용합니다. 그 연결이 성공하면 SMTP 아웃바운드 구성 요소는 Healthy Server Selector에 연결이 성공했음을 알립니다. 그러면 Healthy Server Selector는 비정상 서버 목록에서 해당 서버를 제거합니다.

Healthy Server Selector 및 섀도 중복성

전송의 섀도 중복성 구성 요소에는 하트비트 기능이 포함됩니다. 하트비트는 이전에 대상 서버로 전송되었던 메시지의 상태를 쿼리하는 데 사용되는 간단한 SMTP 연결입니다. Healthy Server Selector 필터링은 섀도 중복성 관리자가 하트비트 연결 시도를 실행하는 것을 막지 않습니다. 서버가 비정상 상태인 서버로 전송된 섀도 메시지를 갖고 있는 경우에는 해당 서버에 대한 하트비트 연결을 시도합니다. 비정상 서버에 대한 하트비트 연결이 성공하면 Healthy Server Selector는 그 대상 서버를 즉시 비정상 서버 목록에서 제거합니다.

섀도 중복성 및 하트비트에 대한 자세한 내용은 섀도 중복성 이해를 참조하십시오.

진단 정보

Exchange 2010 SP1에는 연결 로그에 Healthy Server Selector에 대한 진단 정보 및 향상된 부하 분산 기능이 포함됩니다. Healthy Server Selector가 비정상 서버 목록에 서버를 추가하면 이벤트가 연결 로그에 로깅됩니다. 이 이벤트를 찾으려면 연결 로그에서 MarkedUnhealthy 구문을 검색하면 됩니다. 이 구문을 포함한 행에서 다음 정보를 확인할 수 있습니다.

• 대상 호스트 IP 주소

• 대상 호스트 FQDN(정규화된 도메인 이름)

• 수신된 Winsock 오류

• 상태: MarkedUnhealthy

• 현재 실패 횟수

• 다음 다시 시도 시간

이 항목에서 Winsock 오류 코드를 평가하여 실패 원인을 확인할 수 있습니다. Winsock 오류 코드 목록과 그 정의에 대한 전체 목록은 Windows 소켓 오류 코드(영문)를 참조하십시오.

Current Failure Count 및 Next Retry Time 필드를 분석하여 실패한 연결 시도 횟수 및 대상 서버에 대해 남아 있는 다시 시도 횟수를 확인할 수도 있습니다.

이 진단 정보를 보려면 전송 서버에서 연결 로깅을 사용하도록 설정해야 합니다. 연결 로깅은 허브 전송 및 Edge 전송 서버에서 기본적으로 사용할 수 없습니다. 연결 로깅 구성에 대한 자세한 내용은 연결 로깅 구성을 참조하십시오.

Exchange Server 2010 RTM의 동작

전송 서버가 포함된 Windows 네트워크 부하 분산 또는 타사 부하 분산 솔루션

이 항목의 앞부분에서 설명했듯이 Exchange 2010에서는 향상된 DNS를 사용하여 모든 조직 간 메시지 트래픽의 부하를 Edge 전송, 허브 전송 및 사서함 서버 간에 자동으로 분산합니다. 하지만 이 기능은 외부 메일 서버, 타사 스팸 방지 또는 바이러스 백신 솔루션, Exchange 조직 외부의 내부 메일 서버, LOB(기간 업무) 애플리케이션, POP 기반 또는 IMAP 기반 전자 메일 클라이언트 등 Exchange 이외에서 받은 메시지의 부하는 분산하지 않습니다.

이러한 메일 출처가 하나 이상 있는 경우 조직 내의 전송 서버 간에 외부 전자 메일 메시지를 분산시키는 통합 SMTP 네임스페이스(예: smtp.contoso.com)를 사용하여 들어오는 SMTP 트래픽의 부하를 분산할 수 있습니다. Windows NLB(네트워크 부하 분산) 또는 타사 공급업체의 하드웨어 기반 부하 분산 솔루션이 모두 지원됩니다. Exchange 2010 요구 사항을 충족하기 위해 공급업체가 테스트하고 Microsoft에서 검토한 부하 분산 장치 목록은 Microsoft Unified Communications 부하 분산 장치 배포(영문)를 참조하십시오.

Edge 전송 서버 간에 인바운드 인터넷 메시지 부하 분산

가장 일반적인 경우는 인터넷에서 들어오는 메시지를 처리하는 것입니다. Edge 전송 서버 간에 부하를 분산하기 위해 부하 분산 솔루션을 배포할 필요는 없습니다. 다음 그림과 같이 기본 설정 값이 같은 MX 레코드(메일 교환 레코드)와 DNS 라운드 로빈을 사용하면 됩니다.

DNS 라운드 로빈과 MX 레코드를 사용하여 인터넷 메시지 부하 분산

Windows NLB 또는 하드웨어 부하 분산 솔루션을 사용하여 들어오는 인터넷 메시지를 분산하는 경우 부하 분산 솔루션을 가리키는 단일 MX 레코드를 게시해야 합니다. 부하 분산 장치는 다음 그림과 같이 들어오는 메시지를 구성에 나열된 모든 Edge 전송 서버로 분산합니다.

부하 분산 솔루션을 사용하여 인터넷 메시지 분산

허브 전송 서버 간에 비 Exchange 메시지 부하 분산

Exchange 2010에서는 수신 커넥터를 사용하여 들어오는 메시지를 수락합니다. 기본적으로 Exchange 2010 허브 전송 서버가 TCP 포트 25에서 SMTP를 통해 전자 메일 메시지를 받는 경우 기본 수신 커넥터라는 수신 커넥터에서 이 메시지를 처리합니다.

POP 또는 IMAP 클라이언트가 전자 메일 메시지를 Exchange 2010 허브 전송 서버로 전송하는 경우 기본적으로 메시지가 TCP 포트 587을 통해 전송됩니다. 즉, POP 또는 IMAP 클라이언트에서 전송된 전자 메일 메시지는 기본 클라이언트 수신 커넥터라는 별도의 수신 커넥터에 의해 처리됩니다.

허브 전송 서버 앞에 부하 분산 솔루션을 배치하려는 경우 해당 용도의 별도 수신 커넥터를 만들고 이 특정 커넥터에서 처리된 트래픽만 부하 분산되도록 해야 합니다. 이렇게 하려면 허브 전송 서버에 IP 주소를 추가하고 이 IP 주소를 새 수신 커넥터와 연결합니다. 또한 수신 커넥터에서 Exchange Server 인증 옵션을 사용하지 않도록 설정하여 Exchange 트래픽이 이 커넥터를 통해 라우팅되지 않도록 해야 합니다. 다음 그림은 부하 분산 장치를 사용하여 POP3 또는 IMAP4 클라이언트와 비 Exchange SMTP 서버로부터 받은 메시지를 허브 전송 서버 두 개에 분산하는 구성을 보여 줍니다.

허브 전송 서버 간에 비 Exchange 메시지 부하 분산

Windows 네트워크 부하 분산

Windows NLB는 Exchange 서버에 사용되는 가장 일반적인 소프트웨어 부하 분산 장치입니다. Exchange 2010 허브 전송 서버와 함께 Windows NLB를 배포하는 경우 다음과 같은 제한 사항이 있습니다.

• 허브 전송 및 사서함 서버 역할이 함께 사용되고 서버가 DAG(데이터베이스 가용성 그룹)에도 참여하는 Exchange 서버에서는 Windows NLB를 사용할 수 없습니다.

  이는 Windows NLB 기능이 Windows 장애 조치(failover) 클러스터와 호환되지 않기 때문입니다. Exchange 2010 DAG를 사용하며 Windows NLB를 사용하려는 경우 허브 전송 서버 역할과 사서함 서버 역할이 서로 다른 컴퓨터에서 실행되고 있어야 합니다. 뿐만 아니라 DAG 구성원과 허브 전송 서버 역할이 동일한 서버에서 함께 사용되는 경우 Windows NLB는 메시지 라우팅에 영향을 줍니다. 자세한 내용은 DAG를 사용할 때 허브 전송 및 사서함 서버 역할 동시 사용을 참조하십시오.

• Windows NLB로 부하가 분산되는 배열에 8대가 넘는 허브 전송 서버를 배치하지 않는 것이 좋습니다. 8대가 넘는 허브 전송 서버의 부하를 분산해야 하는 경우 하드웨어 기반 솔루션을 배포해야 합니다.

• Windows NLB는 서비스 중지를 검색하지 않습니다.

  IP 주소에 의한 서버 중지만 검색됩니다. Exchange 전송 서비스에서 오류가 발생하지만 서버가 계속 작동하는 경우 Windows NLB는 오류를 검색하지 못하고 들어오는 전자 메일 메시지를 해당 허브 전송 서버로 계속 라우팅합니다. 부하 분산 풀에서 중지된 허브 전송 서버를 제거하려면 수동으로 작업해야 합니다.

• Windows NLB 구성으로 인해 포트 서비스 장애가 발생하여 네트워크가 과부하될 수 있습니다.

  이는 Windows NLB가 들어오는 모든 클라이언트 패킷을 모든 스위치 포트에 동시에 배달하도록 설계되었기 때문입니다. 이 동작을 사용하면 Windows NLB에서 높은 처리량을 제공할 수 있지만 스위치 점유율도 증가할 수 있습니다.

Windows NLB를 구성하는 자세한 단계는 허브 전송 서버를 위한 Windows Network 부하 분산 구성을 참조하십시오.

하드웨어 부하 분산

비 Exchange 메시지 트래픽의 부하를 분산하려는 허브 전송 서버가 8대를 넘는 경우 보다 확장성이 큰 부하 분산 솔루션이 필요합니다. 강력한 소프트웨어 부하 분산 솔루션을 사용할 수는 있지만 가장 많은 용량을 제공하는 것은 하드웨어 부하 분산 솔루션입니다.

IP 주소로만 서버 중지를 검색하는 Windows NLB와 달리 하드웨어 부하 분산 장치는 Exchange 전송 서비스의 오류를 검색하도록 구성될 수 있으며 수동 작업 없이 들어오는 전자 메일 메시지를 다른 허브 전송 서버로 라우팅할 수 있습니다.

하드웨어 부하 분산 솔루션을 구성하는 자세한 단계는 허브 전송 서버를 위한 하드웨어 부하 분산 구성을 참조하십시오.

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