섀도 중복성 이해

 

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

마지막으로 수정된 항목: 2015-03-09

Exchange에 대한 고가용성 전략은 사서함 데이터베이스에 저장된 데이터의 가용성 및 복구 기능에 초점을 맞추었습니다. 사서함 서버에 대한 고가용성 솔루션을 구현할 경우 전자 메일 메시지가 손실되지 않으며 사서함에 도착한 후 오류가 발생했을 때 쉽게 복구할 수 있습니다.

그러나 이러한 전략이 전송 중인 메시지까지 확장되지 않았습니다. 메시지를 처리하는 동안 허브 전송 서버에 오류가 발생하여 이를 복구할 수 없는 경우 데이터가 손실될 수 있습니다. 허브 전송 서버가 처리하는 메시지 양이 증가하면 관리자는 데이터가 손실될 가능성을 더 염려하게 됩니다.

Microsoft Exchange Server 2007에서는 허브 전송 서버 역할에 전송 휴지통 기능을 도입했습니다. Exchange 2007 허브 전송 서버는 클러스터된 사서함 서버에 사서함이 있는 받는 사람에게 최근에 배달된 메시지 큐를 유지 관리합니다. 장애 조치가 발생하는 경우 클러스터된 사서함 서버는 Active Directory 사이트의 모든 허브 전송 서버를 자동으로 요청하여 전송 휴지통 큐에서 메일을 다시 전송합니다. 이렇게 하면 클러스터를 장애 조치하는 데 걸리는 시간 동안 메일이 손실되지 않습니다. 이 방법은 기본 수준의 전송 중복성을 제공하지만 CCR(클러스터 연속 복제) 환경의 메시지 배달에만 사용할 수 있으며 허브 전송 및 Edge 전송 서버 간에 메시지가 전송 중일 때 발생할 수 있는 메시지 손실을 해결하지는 않습니다.

Exchange Server 2010에는 메시지를 전송하는 동안 내내 메시지에 대한 중복성을 제공하기 위해 섀도 중복성 기능이 도입되었습니다. 이 솔루션에는 전송 휴지통과 유사한 기술이 포함되어 있습니다. 섀도 중복성을 사용하면 전송 서버가 해당 메시지에 대한 다음 홉이 모두 배달되었음을 확인할 때까지 전송 데이터베이스에서 메시지를 삭제하는 작업이 지연됩니다. 성공적인 배달을 보고하기 전에 다음 홉 중 하나가 실패하면 메시지는 배달을 위해 해당 홉에 재전송됩니다.

섀도 중복성을 사용하면 다음과 같은 이점이 있습니다.

• 특정 허브 전송 또는 Edge 전송 서버의 상태에 의존할 필요가 없습니다. 중복 메시지 경로가 라우팅 토폴로지에 있는 경우 모든 전송 서버는 삭제 가능하게 됩니다.

• 전송 서버가 실패할 경우 해당 큐를 비우거나 메시지 손실을 초래할 필요 없이 프로덕션에서 해당 서버를 제거할 수 있습니다.

• 허브 전송 또는 Edge 전송 서버를 업그레이드하려는 경우 메시지 손실 위험 없이 해당 서버를 언제든지 오프라인으로 만들 수 있습니다.

• 전송 서버에 대한 저장소 하드웨어 중복성이 필요하지 않습니다.

• 여러 서버에서 중복된 메시지 복사본을 만드는 것보다 대역폭이 적게 사용됩니다. 섀도 중복성을 통해 생성된 유일한 추가 네트워크 트래픽은 전송 서버 간에 삭제 상태가 교환되는 것입니다. 삭제 상태는 각 전송 서버가 유지 관리하는 정보입니다. 삭제 상태는 메시지를 전송 데이터베이스에서 삭제할 준비가 된 시점을 나타냅니다.

• 복원 기능을 제공하며 전송 서버 오류로부터의 복구를 단순화합니다.

섀도 중복성은 SMTP 서비스를 확장하여 구현됩니다. 서비스 확장을 통해 SMTP 호스트는 섀도 중복성 지원을 협상하고 섀도 메시지의 삭제 상태를 교환할 수 있습니다.

전송 서버 관리와 관련된 관리 작업에 대한 자세한 내용은 전송 서버 관리를 참조하십시오.

섀도 중복성 구성 요소

다음 표에서는 섀도 중복성의 모든 구성 요소를 설명합니다.

섀도 중복성 구성 요소

구성 요소	설명
기본 메시지	배달을 위해 전송에 제출된 원본 메시지입니다.
섀도 메시지	해당 메시지에 대한 다음 홉이 모두 성공적으로 배달했다는 것을 확인할 때까지 전송 서버가 보유하는 메시지의 복사본입니다.
기본 서버	현재 메시지를 처리하고 있는 전송 서버입니다.
섀도 서버	메시지를 기본 서버에 배달한 후 메시지의 섀도 복사본을 보유하는 전송 서버입니다.
섀도 큐	전송 서버가 섀도 메시지를 저장하기 위해 사용하는 큐입니다. 전송 서버는 기본 메시지를 배달한 각 홉에 대해 별개의 섀도 큐를 가집니다.
삭제 상태	메시지를 삭제할 준비가 된 시점을 나타내는 전송 서버가 유지 관리하는 섀도 메시지에 대한 정보입니다.
삭제 알림	섀도 서버가 기본 서버에서 수신하는 메시지를 삭제할 준비가 되었음을 나타내는 응답입니다.
섀도 중복성 관리자	섀도 중복성을 관리하는 전송 구성 요소입니다.
하트비트	전송 서버가 서로의 가용성을 확인하는 프로세스입니다.

맨 위로 이동

섀도 중복성 메시지 흐름

섀도 중복성이 사용되는 메일 흐름을 설명하기 위해 허브 전송 서버가 경계 네트워크의 Edge 전송 서버를 통해 타사 메일 서버에 메시지를 보내는 간단한 시나리오를 가정해 보겠습니다.

섀도 중복성이 있는 메시지 흐름

이 시나리오에서 메시지 흐름은 다음과 같은 단계로 진행됩니다.

1. 허브 전송 서버가 Edge 전송 서버로 메시지를 배달합니다.

   1. 허브 전송 서버는 Edge 전송 서버와의 SMTP 세션을 엽니다.

   2. Edge 전송 서버는 섀도 중복성 지원을 보급합니다.

   3. 허브 전송 서버는 삭제 상태를 추적하도록 Edge 전송 서버에 알립니다.

   4. 허브 전송 서버는 Edge 전송 서버에 메시지를 전송합니다.

   5. Edge 전송 서버는 메시지 수신을 승인하고 메시지에 대한 삭제 정보를 보내기 위해 허브 전송 서버 ID를 기록합니다.

   6. 허브 전송 서버는 Edge 전송 서버의 섀도 큐에 메시지를 이동하고 Edge 전송 서버를 기본 서버로 표시합니다. 허브 전송 서버는 섀도 서버가 됩니다.

2. Edge 전송 서버는 다음 홉에 메시지를 배달합니다.

   1. Edge 전송 서버는 타사 메일 서버에 메시지를 전송합니다.

   2. 타사 메일 서버는 메시지 수신을 승인합니다.

   3. Edge 전송 서버는 배달 완료 시에 메시지의 삭제 상태를 업데이트합니다.

3. 허브 전송 서버는 Edge 전송 서버에서 삭제 상태를 쿼리합니다(성공한 경우).

   1. Edge 전송 서버와의 각 SMTP 세션이 끝날 때 허브 전송 서버는 이전에 전송된 메시지에 대한 삭제 상태를 Edge 전송 서버에서 쿼리합니다. 초기 메시지 전송 후에 허브 전송 서버가 Edge 전송 서버와의 SMTP 세션을 열지 않은 경우 허브 전송 서버는 특정 시간이 지난 후 단순히 삭제 상태를 쿼리하기 위해 Edge 전송 서버와의 SMTP 세션을 엽니다.

   2. Edge 전송 서버는 로컬 삭제 상태를 확인하고 배달된 메시지의 목록을 다시 보내며 삭제 정보를 제거합니다.

   3. 허브 전송 서버는 메시지 목록을 섀도 큐에서 삭제합니다.

4. 허브 전송 서버는 Edge 전송 서버에서 삭제 상태를 쿼리하고 메시지를 다시 전송합니다(실패한 경우).

   1. 허브 전송 서버가 Edge 전송 서버에 연결할 수 없는 경우 허브 전송 서버는 기본 서버 역할을 다시 시작하고 섀도 큐의 메시지를 다시 전송합니다.

   2. 다시 전송된 메시지는 다른 Edge 전송 서버에 배달되고 워크플로는 단계 1부터 시작됩니다.

      참고

      섀도 메시지에 사용할 수 있는 대체 경로가 없는 경우(예: 앞의 그림에 나온 두 번째 Edge 전송 서버) 메시지는 다시 전송되지 않지만 섀도 큐에 남아 있습니다.

여러 다른 시나리오의 메시지 흐름에 대한 자세한 내용은 섀도 중복성 메일 흐름 시나리오를 참조하십시오.

다중 홉 시나리오

섀도 중복성을 지원하는 여러 서버를 통해 메시지가 이동할 경우 메시지 경로의 다음 서버가 배달을 확인할 때까지 섀도 메시지는 서버에서 보유됩니다. 이 작업이 수행되는 방법을 설명하기 위해 허브 전송 서버가 설치된 5개의 Active Directory 사이트가 있는 조직을 가정해 보겠습니다. 다음 그림에 나온 것처럼 이러한 사이트는 서로 연결됩니다. 조직에서는 뉴욕 및 런던 사이트가 허브 사이트로 구성되어 있으므로 시카고 또는 애틀랜타에서 보내는 메시지는 더블린 사이트에 도착하기 위해 뉴욕 및 런던 사이트의 허브 전송 서버를 통과해야 합니다.

다중 홉 시나리오에 대한 샘플 토폴로지

시카고 사이트의 사용자가 더블린 사이트의 사용자에게 메시지를 보낸다고 가정해 봅니다. 이 메시지는 더블린에 도착하기 위해 뉴욕 및 런던 사이트를 통과해야 합니다. 이 경우 작업은 다음과 같이 수행됩니다.

1. 시카고의 허브 전송 서버는 뉴욕의 허브 전송 서버에 메시지를 보내고 메시지의 섀도 복사본을 보유합니다.

2. 뉴욕 허브 전송 서버는 런던의 허브 전송 서버에 메시지를 보내고 시카고 허브에 대한 삭제 상태를 큐에 넣습니다.

3. 시카고 허브는 뉴욕 허브에서 삭제 상태를 쿼리하고 메시지에 대한 삭제 알림을 수신합니다. 이 때 해당 데이터베이스에서 섀도 메시지를 제거할 수 있습니다. 메시지가 런던에서 더블린으로 배달되었는지 여부는 시카고 서버가 섀도 메시지를 삭제하는 시점에 영향을 주지 않습니다.

허브 전송 및 사서함 서버 역할을 DAG와 동시에 사용할 경우 섀도 중복성 보호

DAG(데이터베이스 가용성 그룹) 사용 시 이미 사서함 데이터베이스에 커밋된 메시지는 DAG 아키텍처로 보호됩니다. DAG의 일부인 사서함 데이터베이스로 전달된 메시지의 경우, 해당 메시지가 모든 DAG 구성원에게 복제될 때까지 해당 메시지의 섀도 복사본이 전송 휴지통에 보관됩니다. 마찬가지로 DAG 구성원에서 허브 전송 서버로 전송된 메시지에는 두 복사본이 있으며, 그 중 하나는 배달 대기 중인 허브 전송 서버 큐이며 나머지 하나는 보낸 사람의 보낸 편지함 폴더에 있는 섀도 복사본입니다. 이 방법은 섀도 중복성의 핵심 구성 요소입니다.

그러나 허브 전송 및 사서함 서버 역할을 동일한 서버와 동시에 사용하고 DAG의 일부인 사서함 데이터베이스가 있는 경우, 허브 전송 서버는 기본 메시지 및 섀도 메시지가 동일한 서버 하드웨어에 있지 않도록 추가 홉을 통해 메시지를 라우트해야 할 수 있습니다. 특히, 단일 서버의 오류가 기본 및 섀도 메시지 모두를 손실하게 할 수 있기 때문에 허브 전송 서버 역할은 다음 두 시나리오를 피합니다.

• 메시지 전달 중 메시지 받는 사람의 활성 사서함 데이터베이스 및 메시지의 섀도 복사본을 포함하는 전송 휴지통이 동일 서버에 있는 경우    이 시나리오를 피하려면 허브 전송 서버는 해당 사이트 내의 다른 허브 전송 서버를 통해 메시지를 라우트하여 섀도 메시지가 다른 서버 하드웨어에 있도록 합니다. 그러나 사용 가능한 다른 허브 전송 서버가 없는 경우 메시지를 바로 전달합니다.

• 메시지 전송 중 기본 메시지가 있는 전송 큐 및 보낸 사람의 보낸 편지함 폴더의 섀도 메시지가 동일 서버에 있는 경우   이 시나리오를 피하기 위해 저장소 드라이버는 메시지 전송을 위해 해당 사이트의 다른 허브 전송 서버를 선호합니다. 그러나 해당 사이트에 사용 가능한 다른 허브 전송 서버가 없는 경우 메시지를 로컬 허브 전송 서버로 전송합니다.

DAG 사용 시 허브 전송 및 사서함 서버 역할 동시 사용에 대한 자세한 내용은 DAG를 사용할 때 허브 전송 및 사서함 서버 역할 동시 사용을 참조하십시오.

상호 운용성

섀도 중복성이 사용되는지 여부는 새 SMTP 연결을 설정하는 동안 결정됩니다. SMTP 연결의 두 서버 모두에서 섀도 중복성을 지원할 경우 앞에 언급한 워크플로가 사용됩니다. 그러나 Exchange 2010 전송 서버가 섀도 중복성을 지원하지 않는 메일 서버와 메시지를 교환하는 경우가 있습니다. 타사 메일 서버, 이전 버전의 Exchange 또는 섀도 중복성을 사용하도록 설정하지 않은 Exchange 2010 조직 등을 예로 들 수 있습니다.

섀도 중복성을 지원하는 Exchange 2010 전송 서버가 섀도 중복성을 지원하지 않는 서버와의 연결을 설정할 경우 다음 이벤트가 발생합니다.

1. Exchange에서 대상 서버에 대한 SMTP 연결을 설정합니다.

2. 대상 서버는 섀도 중복성 지원을 보급하지 않습니다.

3. 대상 서버가 중복성을 지원하지 않으므로 Exchange에서는 각 메시지에 대해 다음을 수행합니다.

   1. 대상 서버에 메시지를 배달합니다.

   2. 섀도 중복성 관리자는 다음 홉에 메시지가 배달되었다는 것을 표시합니다.

   3. 다음 홉 모두에게 배달된 후 메시지를 삭제합니다.

섀도 중복성을 지원하지 않는 서버가 Exchange 2010 서버와의 연결을 설정할 경우 다음 이벤트가 발생합니다.

1. 보내는 서버는 Exchange에 대한 SMTP 연결을 설정합니다.

2. Exchange에서 섀도 중복성 지원을 보급합니다.

3. 보내는 서버는 섀도 중복성을 지원하지 않으므로 섀도 중복성을 사용하지 않습니다. 보내는 서버는 메시지를 Exchange 서버에 배달합니다.

4. Exchange는 수신하는 각 메시지에 대해 다음 작업을 수행합니다.

   1. 메시지를 다음 홉에 배달하거나 메시지의 섀도 복사본을 만듭니다.

   2. 보내는 서버에 승인을 보냅니다.

지연된 승인

섀도 중복성의 주요 원칙은 메시지가 다음 홉 모두에 성공적으로 배달되었다는 것을 서버에서 확인할 때까지 이전 홉에서 메시지의 복사본을 유지 관리하는 것입니다. 섀도 중복성을 지원하지 않는 메일 서버에서 Exchange 2010 전송 서버가 메시지를 수신하는 경우 이 작업은 불가능합니다. 이 메일 서버는 이전 버전의 Exchange를 실행하는 Exchange 서버, 표준 SMTP 클라이언트 또는 인터넷에 있는 비 Exchange 메일 서버일 수 있습니다. 이 경우 Exchange는 내부적으로 다음 홉 모두에 메시지가 성공적으로 배달되었다는 것을 확인할 때까지 메일 서버에 대한 승인을 지연시켜 섀도 중복성을 실현하려고 합니다. 이 방법에서 Exchange 2010 서버가 실패하면 보내는 메일 서버는 메시지가 Exchange에 배달되지 않았다고 가정하고 배달을 다시 시도합니다.

그러나 다음 홉에 메시지를 배달하는 작업은 라우팅 인프라의 복잡성이나 다음 홉 중 하나의 오류로 인해 오래 걸릴 수 있습니다. 이 경우 SMTP 세션이 시간 초과되는 것을 방지하기 위해 Exchange 2010 전송 서버는 보내는 메일 서버에 승인을 보냅니다. 이것은 메일 중복성이 보장되지 않지만 최선의 방법입니다. 예를 들어 다음과 같은 시나리오에서 메시지가 손실될 수 있습니다. 인터넷 메일 서버는 Edge 전송 서버로 메시지를 전송합니다. Edge 전송 서버는 네트워크 문제로 인해 허브 전송 서버와 통신할 수 없고 인터넷 메일 서버에 대한 메시지 수신을 승인합니다. 그런 다음 Edge 전송 서버에 오류가 발생하고 네트워크 문제가 해결되기 전에 복구할 수 없습니다. 이 때 메시지가 손실됩니다.

지연된 승인 시간 제한 값은 각 수신 커넥터의 MaxAcknowledgementDelay 특성으로 제어합니다. 기본값은 30초입니다. 이 특성을 구성하는 방법에 대한 자세한 내용은 섀도 중복 구성을 참조하십시오.

지연된 승인 무시

지연된 승인 초과 시간에 도달하기 전에 메시지가 전달되지 못하는 경우도 있습니다. 이러한 경우, 전송 서버는 다음 방법 중 하나를 사용하여 메시지를 처리합니다.

• 지연된 승인 건너뛰기 기본적으로 전송 서버는 지연된 승인을 건너뛰어 SMTP 수신 처리량을 유지 관리합니다. 기본적으로, 초과 시간에 도달하기 전에 전송 서버는 승인을 발행합니다.

• 섀도 중복성 확장    Microsoft Exchange Server 2010 SP1(서비스 팩1)에서는 지연된 승인을 건너뛰지 않고 해당 사이트에서 다른 전송 서버에 메시지를 릴레이하도록 전송 서버를 구성할 수 있습니다. 메시지를 섀도 중복성 파이프라인에 효과적으로 삽입하므로 해당 메시지를 보호합니다. 이 프로세스를 섀도 중복성 확장이라고 합니다. 이 방법은 지연된 승인 건너뛰기 방법과 비교하여 조직에서 보호되지 않은 메시지 수를 최소화합니다. 기본적으로 이 기능은 사용되지 않습니다. 섀도 중복성 확장을 사용하도록 설정하려면 관리자는 Edgetransport.exe.config 파일을 편집하고, shadowredundancypromotionenabled 키를 true로 변경하고, 파일의 변경 사항을 저장한 다음 Microsoft Exchange Transport Service(MSExchangeTransport.exe)를 다시 시작해야 합니다. 이 작업을 수행하는 방법에 대한 자세한 내용은 섀도 중복 구성 항목의 "섀도 중복성 확장 사용" 섹션을 참조하십시오.

다음 표에서는 전송 서버가 지연된 승인을 무시하는 다양한 시나리오를 나열하고 Exchange 2010 서버가 이러한 시나리오를 처리하는 방법을 보여줍니다.

시나리오	Exchange 2010 기본 동작(지연된 승인 건너뛰기)	향상된 섀도 중복성을 사용할 수 있는 Exchange 2010 SP1
해당 메시지의 대상 큐는 일시 중단되거나 다시 시도 상태입니다.	받는 전송 서버는 지연된 승인을 건너뜁니다.	받는 전송 서버는 향상된 섀도 중복성을 즉시 사용합니다.
메시지가 추가된 후 대상 큐가 다시 시도 상태가 됩니다.	대상 큐가 준비 상태로 돌아갈 때까지 받는 전송 서버는 이후 메시지에 대한 지연된 승인을 건너뜁니다.	대상 큐가 준비 상태로 돌아갈 때까지 받는 전송 서버는 이후 메시지에 대해 향상된 섀도 중복성을 사용합니다.
관리자는 대상 큐나 메시지를 일시 중단합니다.	관리자가 대상 큐를 일시 중단하면 대상 큐가 준비 상태로 돌아갈 때까지 받는 전송 서버는 지연된 승인을 건너뜁니다. 관리자가 해당 메시지를 일시 중단하면 받는 전송 서버는 이후의 메시지를 정상적으로 처리합니다.	관리자가 대상 큐를 일시 중단하면 대상 큐가 준비 상태로 돌아갈 때까지 받는 전송 서버는 향상된 섀도 중복성을 사용합니다. 관리자가 해당 메시지를 일시 중단하면 받는 전송 서버는 이후의 메시지를 정상적으로 처리합니다.
해당 메시지의 대상 큐에는 100개 이상의 메시지가 있습니다.	대상 큐의 크기가 100개 미만으로 떨어질 때까지 받는 전송 서버는 지연된 승인을 건너뜁니다.	대상 큐에 메시지가 있는 경우 큐가 지워질 때까지 받는 전송 서버는 이후의 메시지에 대해 향상된 섀도 중복성을 사용합니다.

맨 위로 이동

섀도 중복성 관리자

섀도 중복성 관리자는 섀도 중복성의 관리를 담당하는 Exchange 2010 전송 서버의 핵심 구성 요소입니다.

섀도 중복성 관리자는 서버에서 현재 처리 중인 모든 기본 메시지에 대한 다음 정보를 유지 관리합니다.

• 처리 중인 각 기본 메시지의 섀도 서버

• 섀도 서버로 보낼 삭제 상태

섀도 중복성 관리자는 서버가 섀도 큐에 갖고 있는 모든 섀도 메시지에 대해 다음을 수행합니다.

• 각 섀도 메시지에 대한 기본 서버 목록을 유지 관리합니다.

• 섀도 메시지를 큐에 넣을 각 기본 서버의 가용성을 확인합니다.

• 기본 서버에서의 삭제 알림을 처리합니다.

• 예상된 모든 삭제 알림을 받은 후에 데이터베이스에서 섀도 메시지를 제거합니다.

• 섀도 서버가 섀도 메시지의 소유권을 갖게 되어 기본 서버가 되는 시점을 결정합니다.

또한 섀도 중복성 관리자는 섀도 중복성과 관련된 성능 카운터를 관리합니다.

하트비트

섀도 중복성 관리자는 하트비트를 사용하여 섀도 메시지를 큐에 넣을 서버의 가용성을 확인합니다. 둘 다 섀도 중복성을 지원하는 두 서버 간의 SMTP 세션 도중 연결을 시작한 서버는 이전에 해당 서버에 전송된 메시지의 삭제 상태를 대상 서버에서 쿼리합니다. 시작 서버는 XQUERYDISCARD 명령을 실행하여 이 작업을 수행합니다. 대상 서버는 응답으로 삭제 알림을 반환합니다. 두 서버 간의 이 교환은 섀도 중복성에 대한 하트비트로 사용됩니다.

하트비트에 대한 시간 제한 값이 있습니다. 섀도 중복성 관리자가 해당 기간 동안 섀도 큐를 유지 관리하는 중인 서버와의 연결이 설정되지 않은 경우 서버는 특히 삭제 상태를 쿼리하고 타이머를 재설정하기 위해 기본 서버와의 SMTP 연결을 설정합니다. 시간 제한 값은 Set-TransportConfig cmdlet의 ShadowHeartbeatTimeoutInterval 매개 변수로 제어됩니다. 이 매개 변수의 기본값은 RTM(Release To Manufacture) 버전의 Exchange 2010에서는 300초이고, Exchange 2010 SP1에서는 900초입니다.

서버는 시간 제한 값에 도달했을 때 기본 서버와의 연결을 설정할 수 없는 경우 타이머를 재설정하고 다시 시도합니다. 시간 제한 값에 연속해서 12번(Exchange 2010 RTM에서는 연속해서 3번) 도달할 경우 서버는 기본 서버에 오류가 발생했다고 결정하고 섀도 메시지의 소유권을 갖고 와서 오류가 있는 기본 서버에 보낼 섀도 메시지에 대한 삭제 알림을 생성하기 시작합니다. 기본 서버에 오류가 발생했다고 결정하기 전에 서버가 기다리는 시간 제한 수는 Set-TransportConfig cmdlet의 ShadowHeartbeatRetryCount 매개 변수로 제어합니다.

섀도 중복성 하트비트를 구성하는 방법에 대한 자세한 내용은 섀도 중복 구성을 참조하십시오.

맨 위로 이동

중단 후 메시지 처리

섀도 중복성은 서버 중단으로 인한 메시지 손실을 최소화합니다. 중단 후 전송 서버가 다시 온라인 상태가 될 경우 다음과 같은 두 가지 시나리오가 있습니다.

• 서버가 새 전송 데이터베이스를 사용하여 다시 온라인 상태로 됩니다.   이 시나리오에서는 데이터 손상 또는 하드웨어 오류로 인해 전송 데이터베이스를 복구할 수 없습니다. 이 경우 전송 서버는 새 데이터베이스 ID를 가지므로 조직의 다른 전송 서버에서 새 경로로 인식됩니다. 또한 이 시나리오는 서버를 복구할 수 없고 새 서버가 대체 서버로 프로비전된 상황에 적용됩니다.

• 서버가 동일한 전송 데이터베이스를 사용하여 다시 온라인 상태로 됩니다.   이 시나리오에서는 특정 전송 서버가 실패하지 않았지만 오랜 시간 동안 오프라인 상태였습니다. 예를 들어 네트워크 카드 오류 또는 오랜 시간 동안의 서버 유지 관리로 인해 이 시나리오가 발생합니다.

다음 표에는 섀도 중복성이 사용하도록 설정된 경우 이러한 두 가지 시나리오에 전송이 대응하는 방법이 요약되어 있습니다. 이해를 돕기 위해 중단된 서버를 Hub01이라고 합니다.

복구 시나리오에서의 메시지 처리

복구 시나리오	대체 경로가 있는 메시지에 수행한 작업	대체 경로가 없는 메시지에 수행한 작업
Hub01은 새 데이터베이스를 사용하여 다시 온라인 상태가 됩니다.	Hub01을 사용할 수 없게 되면 Hub01에 대한 큐에 넣은 섀도 메시지를 가진 각 서버는 이러한 메시지의 소유권을 갖게 되고 메시지를 다시 전송합니다. 그러면 메시지는 대체 경로를 사용하여 대상으로 배달됩니다. 메시지에 대한 총 지연은 조직에서 구성된 하트비트 시간 제한 간격과 하트비트 재시도 횟수를 곱한 것과 같습니다.	이러한 메시지는 Hub01에 대한 큐에 넣은 섀도 메시지를 가진 각 서버의 섀도 큐에 남아 있습니다. Hub01이 새 데이터베이스 ID를 사용하여 다시 온라인 상태가 되면 섀도 서버는 새 데이터베이스라는 것을 감지하고 섀도 큐에 있는 메시지를 Hub01에 다시 전송합니다. 이 작업은 이러한 메시지에 대한 대체 경로를 갑자기 검색하는 것과 같습니다. 메시지에 대한 총 지연은 중단 기간에 따라 달라집니다.
Hub01은 동일한 데이터베이스를 사용하여 다시 온라인 상태가 됩니다.	Hub01은 해당 큐의 메시지를 배달합니다. 이로 인해 이러한 메시지의 배달이 중복됩니다. 중복된 메시지가 검색되어 Exchange 사서함 사용자에게 중복된 메시지가 표시되지는 않습니다. 그러나 외부 시스템의 받는 사람은 중복된 복사본을 받을 수도 있습니다. 메시지에 대한 총 지연은 조직에서 구성된 하트비트 시간 제한 간격과 하트비트 재시도 횟수를 곱한 것과 같습니다.	Hub 01은 해당 큐에 있는 메시지를 배달한 다음 삭제 알림을 섀도 서버에 보냅니다. 메시지에 대한 총 지연은 중단 기간에 따라 달라집니다.

맨 위로 이동

섀도 중복성에 필요한 확장 권한

Exchange 2010에는 섀도 중복성에 필요한 다음 두 가지 확장 권한이 도입되었습니다.

• ms-Exch-SMTP-Accept-XSHADOW

• ms-Exch-SMTP-Send-XSHADOW

Exchange 2010 전송 서버에 SMTP 연결이 설정되면 사용 중인 수신 커넥터에 ms-Exch-SMTP-Accept-XSHADOW 확장 권한이 있을 경우 섀도 중복성 지원이 보급됩니다. 또한 수신 커넥터의 인증 메커니즘은 Exchange Server 인증 또는 외부 보안이어야 합니다.

Exchange 2010 전송 서버는 섀도 중복성 지원을 보급하는 다른 서버에 대한 SMTP 연결을 설정할 때 ms-Exch-SMTP-Send-XSHADOW 확장 권한이 세션에 부여된 경우에만 XSHADOW 명령을 실행합니다.

기본적으로 이러한 확장 권한은 모든 내부 송신 커넥터 및 수신 커넥터의 Exchange Server 그룹에 부여됩니다.

참고

Set-TransportConfig cmdlet의 ShadowRedundancyEnabled 매개 변수를 사용하여 전체 조직에 대해 섀도 중복성을 사용하거나 사용하지 않도록 설정할 수 있습니다. 이 설정은 이 섹션에서 설명하는 확장 권한을 무시합니다. 조직에서 섀도 중복성이 사용하지 않도록 설정된 경우 Exchange는 SMTP 세션에 필요한 확장 권한이 부여된 경우에도 섀도 중복성 지원을 보급하거나 XSHADOW 명령을 실행하지 않습니다.

맨 위로 이동

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