Exchange Server 그림자 중복성
섀도 중복성은 사서함에 배달되기 전에 메시지의 중복 복사본을 제공하기 위해 Exchange 2010에 도입되었습니다. Exchange 2010에서는 서버가 메시지 배달 경로의 다음 홉이 배달을 완료했음을 확인할 때까지 섀도 중복성이 허브 전송 서버의 큐 데이터베이스에서 메시지 삭제를 지연시켰습니다. 허브 전송 서버로 성공적으로 배달을 보고하기 전에 다음 홉이 실패한 경우 서버는 해당 다음 홉에 메시지를 다시 제출했습니다. Exchange 2010 Hub 전송 서버는 XSHADOW 동사를 사용하여 섀도 중복 지원을 보급했습니다. 원본 메시징 서버가 섀도 중복성을 지원하지 않는 경우 Exchange 2010은 수신 커넥터에서 구성된 시간 간격에 따라 지연된 승인을 사용하여 메시지의 중복 복사본을 생성했습니다.
Exchange 2016 및 Exchange 2019는 Exchange 2013에서 섀도 중복성을 개선한 것과 동일하게 개선되었습니다. 사서함 서버의 전송 서비스는 이제 보내는 서버에 대한 메시지 수신을 승인하기 전에 받은 메시지의 중복 복사본을 만듭니다. 전송 중인 메시지의 중복 복사본을 유지하는 것은 현재 섀도 중복성이 보내는 서버의 지원되는 기능에 의존하지 않기 때문에(섀도 중복에 대한 지원 또는 지원 부족은 중요하지 않으므로) 작동하지 않을 수 있는 최선의 노력 이상입니다. 이렇게 하면 전송 파이프라인의 모든 메시지가 전송 중에 중복되도록 할 수 있습니다. Exchange에서 전송 중 원본 메시지가 손실되었다고 판단하면 메시지의 중복 복사본이 다시 배달됩니다.
Exchange Server 고가용성 기능 전송에 대한 자세한 내용은 Exchange Server 고가용성 전송을 참조하세요. 메시지가 성공적으로 전달된 후의 메시지 중복성에 대한 자세한 내용은 Exchange Server 안전망을 참조하세요.
섀도 중복성 구성 요소
이 표에서는 사서함 서버의 전송 서비스에서 섀도 중복의 구성 요소에 대해 설명합니다. 이 항목에서는 다음 용어가 사용되고 있습니다.
| 용어 | 설명 |
|---|---|
| 전송 고가용성 경계 | DAG 환경의 DAG(데이터베이스 사용 가능 그룹) 또는 DAG가 아닌 환경의 Active Directory 사이트입니다. 여러 Active Directory 사이트에 걸쳐 있는 DAG의 경우 DAG 자체는 여전히 경계(사이트가 아님)입니다. 전송 고가용성 경계의 사서함 서버에 메시지가 도착하면 Exchange는 경계 내의 사서함 서버에서 메시지의 중복 복사본 2개를 유지하려고 시도합니다. 메시지가 전송 고가용성 경계를 벗어나면 Exchange는 메시지의 중복 복사본 유지를 중지합니다. |
| 기본 메시지 | 메시지가 배달을 위해 전송 파이프라인에 제출되었습니다. |
| 섀도 메시지 | 기본 서버가 기본 메시지를 성공적으로 처리했음이 확인될 때까지 섀도 서버에서 유지하는 메시지의 중복 복사본입니다. |
| 기본 서버 | 현재 기본 메시지를 처리 중인 사서함 서버입니다. |
| 섀도 서버 | 주 서버에 대한 섀도 메시지를 포함하는 사서함 서버입니다. 사서함 서버는 일부 메시지의 주 서버이고 다른 메시지의 경우 섀도 서버일 수 있습니다. |
| 섀도 큐 | 섀도 서버가 섀도 메시지를 저장하는 배달 큐입니다. 받는 사람이 여러 명인 메시지의 경우 기본 메시지에 대한 다음 홉 각각에 별도의 섀도 큐가 필요합니다. |
| 삭제 상태 | 기본 메시지가 성공적으로 처리되었음을 나타내기 위해 사서함 서버가 섀도 메시지에 대해 유지 관리하는 정보입니다. |
| 삭제 알림 | 섀도 서버가 기본 서버에서 수신하는 응답이며 섀도 메시지를 삭제할 준비가 되었음을 나타냅니다. |
| 보안 네트워크 | Exchange 2013 이상의 향상된 전송 쓰레기통 버전입니다. 사서함 서버의 전송 서비스를 통해 성공적으로 처리되거나 사서함으로 배달된 메시지는 보안 네트워크로 이동됩니다. 자세한 내용은 Exchange Server 안전망을 참조하세요. |
| 섀도 중복성 관리자 | 섀도 중복성을 관리하는 전송 구성 요소입니다. |
| 하트 비트 | 기본 서버와 섀도 서버가 서로의 가용성을 확인할 수 있는 프로세스입니다. |
섀도 중복성에 대한 요구 사항
분명해 보일 수 있지만 섀도 중복에는 여러 사서함 서버가 필요합니다.
사서함 서버가 DAG의 구성원이 아닌 경우에는 다른 사서함 서버가 로컬 Active Directory 사이트에 있어야 합니다.
사서함 서버가 DAG의 구성원인 경우 다른 사서함 서버가 동일한 DAG에 속해야 합니다. 다른 DAG 멤버는 로컬 Active Directory 사이트 또는 원격 사이트에 있을 수 있습니다. 기본적으로 DAG가 여러 Active Directory 사이트에 걸쳐 있는 경우 섀도 중복성은 사이트 복원력을 위해 원격 사이트에 메시지의 중복 복사본을 만드는 것을 선호합니다.
전송 중인 메시지를 섀도 중복성으로 보호할 수 없는 상황은 다음과 같습니다.
단일 Exchange 서버 환경
프로비전 중인 DAG
메시지의 섀도 중복과 관련된 두 개 이상의 사서함 서버가 동시에 실패하는 동안
섀도 중복성은 기본적으로 사용하도록 설정됨
기본적으로 섀도 중복성은 모든 사서함 서버의 전송 서비스에서 전역적으로 사용하도록 설정됩니다. 이 표에서는 섀도 중복을 사용하도록 설정하는 매개 변수에 대해 설명합니다.
| 매개 변수 | 기본값 | 설명 |
|---|---|---|
| Set-TransportConfig의 ShadowRedundancyEnabled | $true |
$true: 섀도 중복성은 조직의 모든 사서함 서버에서 사용하도록 설정됩니다.
|
| Set-TransportConfig의 RejectMessageOnShadowFailure | $false |
$false: 메시지의 섀도 복사본을 만들 수 없는 경우 조직의 사서함 서버에서 기본 메시지를 수락합니다. 이러한 메시지는 전송 중에 중복으로 유지되지 않습니다.
참고: 메시지의 섀도 복사본을 만들 수 있도록 동일한 DAG 또는 Active Directory 사이트에 사서함 서버가 여러 개 있는 경우에만 사용합니다 이 매개 변수는 ShadowRedundancyEnabled 가 인 경우에만 의미가 있습니다 |
섀도 메시지가 만들어지는 방법
섀도 중복성의 기본 목적은 메시지가 전송 중일 때 전송 고가용성 경계 내에 항상 두 개의 메시지 복사본이 존재하도록 만드는 것입니다. 메시지의 중복 복사본이 생성되는 위치와 시기는 메시지의 원본 위치 및 메시지의 위치에 따라 달라집니다. 섀도 메시지를 만드는 데는 다음 세 가지 결정 요소가 있습니다.
전송 고가용성 경계 외부에서 받은 메시지(DAG 또는 비 DAG 환경의 Active Directory 사이트).
전송 고가용성 경계 외부로 전송된 메시지
전송 고가용성 경계 내의 사서함 서버의 사서함 전송 제출 서비스에서 받은 메시지
섀도 중복성은 전송 고가용성 경계를 넘어 섀도 메시지를 추적하지 않습니다. 메시지가 전송 고가용성 경계를 넘으면 섀도 중복성이 시작되거나 다시 시작됩니다. 이렇게 하면 섀도 메시지 유지 관리 트래픽이 줄어들고 전송 고가용성 경계에서 섀도 메시지 재제출이 방지됩니다. Exchange 2010 허브 전송 서버는 특별한 경우이며 이 항목의 뒷부분에서 설명합니다.
전송 고가용성 경계 외부에서 받은 메시지
사서함 서버의 전송 서비스가 전송 고가용성 경계 외부에서 메시지를 받으면 사서함 서버는 보내는 서버의 섀도 중복에 대한 지원 또는 지원 부족에 대해 걱정하지 않습니다. 섀도 중복성이 사용 설정되어 있으면 메시지를 받는 사서함 서버는 보내는 서버에 메시지의 수신을 알리기 전에 전송 고가용성 경계 내의 다른 사서함 서버에 메시지의 중복 복사본을 만듭니다. 예를 들면 이 프로세스는 다음과 같은 방식으로 작동합니다.
메시징 서버는 사서함 서버의 전송 서비스로 메시지를 전송합니다. 사서함 서버는 기본 서버이며 메시지는 기본 메시지입니다.
메시징 서버가 있는 원래 SMTP 세션은 여전히 활성 상태이지만 주 서버의 전송 서비스는 조직의 다른 사서함 서버에서 전송 서비스와 함께 새로운 동시 SMTP 세션을 열어 메시지의 중복 복사본을 만듭니다.
기본 서버가 DAG의 구성원이면 기본 서버가 동일한 DAG의 다른 사서함 서버에 연결합니다. DAG가 여러 Active Directory 사이트에 걸쳐 있는 경우 다른 Active Directory 사이트의 사서함 서버가 기본적으로 선호됩니다(Set-TransportConfig cmdlet의 ShadowMessagePreferenceSetting 매개 변수의 기본값은
PreferRemote이지만 또는LocalOnly로 변경할RemoteOnly수 있음).주 서버가 DAG의 멤버가 아닌 경우 주 서버는 ShadowMessagePreferenceSetting 매개 변수 값에 관계없이 동일한 Active Directory 사이트의 다른 사서함 서버에 연결합니다.
주 서버는 메시지의 복사본을 다른 사서함 서버의 전송 서비스로 전송하고, 다른 사서함 서버의 전송 서비스는 메시지 복사본이 성공적으로 생성되었음을 인정합니다. 메시지의 복사본은 섀도 메시지이며 이 메시지가 있는 사서함 서버는 기본 서버에 대한 섀도 서버입니다. 메시지는 섀도 서버의 섀도 큐에 존재합니다.
주 서버가 섀도 서버로부터 승인을 받은 후 주 서버는 원래 SMTP 세션의 원래 메시징 서버에 대한 기본 메시지 수신을 승인하고 SMTP 세션이 닫힙니다.
전송 고가용성 경계 외부로 전송된 메시지
사서함 서버가 전송 고가용성 경계 외부에 메시지를 전송하고 다른 쪽의 메시징 서버가 메시지의 성공적인 수신을 승인하면 사서함 서버가 메시지를 Safety Net으로 이동합니다. 기본 메시지가 전송 고가용성 경계를 넘어 성공적으로 전송된 후에는 보안 네트워크에서 메시지의 다시 전송이 발생할 수 없습니다. Safety Net에 대한 자세한 내용은 Exchange Server 안전망을 참조하세요.
전송 고가용성 경계 내에서 전송된 메시지
메시지 라우팅은 최종 대상이 DAG 또는 Active Directory 사이트에 있는 경우 대상 DAG 또는 사이트 내의 서버 간에 여러 홉이 일반적으로 필요하지 않도록 최적화됩니다. 대상 DAG 또는 Active Directory의 사서함 서버에서 전송 서비스에서 메시지를 수락한 후 메시지에 대한 다음 홉은 일반적으로 최종 대상 자체(예: 대상 사서함의 활성 복사본을 보유하는 사서함 서버)입니다. 메시지의 섀도 복사본 1개가 DAG 또는 Active Directory 사이트 내 어디에나 있을 때 전송 중인 메시지의 두 복사본을 유지하겠다는 섀도 중복의 목표가 충족됩니다. 일반적으로 사서함 서버의 활성 메시지 큐를 드레이닝하려면 Redirect-Message cmdlet이 필요한 DAG의 장애 조치 시나리오만 동일한 전송 고가용성 경계 내에서 여러 홉이 필요합니다.
Exchange 2016 조직의 동일한 Active Directory 사이트에 있는 Exchange 2010 Hub 전송 서버의 섀도 중복성
Exchange 2010 Hub 전송 서버가 동일한 Active Directory 사이트의 Exchange 2016 사서함 서버에 메시지를 전송하는 경우 Exchange 2010 Hub 전송 서버는 XSHADOW 명령을 사용하여 섀도 중복에 대한 지원을 보급하지만 사서함 서버는 섀도 중복에 대한 지원을 보급하지 않습니다. 이렇게 하면 Exchange 2010 Hub 전송 서버가 Exchange 2016 사서함 서버에 메시지의 섀도 복사본을 만들지 못하게 됩니다.
Exchange 2016 사서함 서버의 전송 서비스가 동일한 Active Directory 사이트의 Exchange 2010 Hub 전송에 메시지를 전송하면 Exchange 2016 사서함 서버는 Exchange 2010 Hub 전송 서버에 대한 메시지를 숨기게 됩니다. Exchange 2016 사서함 서버가 메시지가 성공적으로 수신되었다는 Exchange 2010 Hub 전송 서버의 승인을 받은 후 Exchange 2016 사서함 서버는 성공적으로 처리된 메시지를 Safety Net으로 이동합니다. 그러나 Exchange 2016 사서함으로 Safety Net에 저장된 성공적으로 처리된 메시지는 Exchange 2010 Hub 전송 서버에 다시 전송되지 않습니다.
SMTP 시간 제한
메시지의 중복 복사본을 만드는 동안 서버(보내는 서버와 주 서버 또는 주 서버와 섀도 서버) 간의 SMTP 연결은 시간 초과가 될 수 있습니다. 수신 커넥터와 송신 커넥터에는 데이터가 실제로 커넥터에서 전송되는 경우에 대한 ConnectionInactivityTimeOut 매개 변수가 있습니다. 수신 커넥터에는 절대 ConnectionTimeOut 매개 변수도 있습니다.
메시지의 섀도 복사본이 성공적으로 만들어지고 승인되기 전에 SMTP 세션이 시간 초과되면 Set-TransportConfig cmdlet의 RejectMessageOnShadowFailure 매개 변수에 의해 결과가 제어됩니다. 기본적으로 이 매개 변수의 값은 입니다 $false. 즉, 섀도 복사본을 만들지 않고 기본 메시지가 허용됩니다. 이 매개 변수의 값이 $true 이면 일시적인 오류 451 4.4.0로 기본 메시지가 거부됩니다.
메시지의 섀도 복사본이 성공적으로 만들어졌지만 보내는 서버와 주 서버 간의 SMTP 세션 시간이 초과되면 주 서버는 기본 메시지를 수락하고 처리합니다. 보내는 서버는 승인되지 않은 메시지를 다시 배달하지만 중복된 메시지 검색으로 인해 Exchange 사서함 사용자가 중복 메시지를 볼 수 없습니다. 보내는 서버가 메시지를 다시 제출하면 주 서버가 메시지의 또 다른 섀도 복사본을 만듭니다. 보내는 서버에서 메시지를 다시 제출하는 동안 생성된 섀도 메시지 간에는 관계가 없습니다.
다음 표에서는 섀도 메시지의 생성을 제어하는 매개 변수를 설명합니다.
| 원본 | 기본값 | 설명 |
|---|---|---|
| Set-TransportConfig의 ShadowMessagePreferenceSetting | PreferRemote |
이 매개 변수는 메시지의 섀도 복사본을 만들려는 주 서버가 여러 Active Directory 사이트에 걸쳐 있는 DAG의 멤버인 경우에만 사용됩니다.
|
| Set-TransportConfig의 MaxRetriesForRemoteSiteShadow | 4 | 이 매개 변수는 ShadowMessagePreferenceSetting 매개 변수 PreferRemote 의 값이 (기본값) 또는 RemoteOnly인 경우 DAG의 다른 서버에서 메시지의 섀도 복사본을 만들려는 최대 시도 횟수를 지정합니다. 이 매개 변수는 사서함 서버가 여러 Active Directory 사이트에 걸쳐 있는 DAG의 멤버인 경우에만 사용됩니다. 지정된 횟수의 시도 후에 메시지의 섀도 복사본이 성공적으로 만들어지지 않으면 결과는 RejectMessageOnShadowFailure 매개 변수 값에 따라 달라집니다.
|
| Set-TransportConfig의 MaxRetriesForLocalSiteShadow | 2 | 이 매개 변수는 다음과 같은 경우 로컬 Active Directory 사이트의 다른 사서함 서버에 메시지의 섀도 복사본을 만들려는 최대 시도 횟수를 지정합니다.
지정된 횟수의 시도 후에 메시지의 섀도 복사본이 성공적으로 만들어지지 않으면 결과는 RejectMessageOnShadowFailure 매개 변수 값에 따라 달라집니다.
|
| Set-ReceiveConnector의 ConnectionInactivityTimeout | 사서함 서버의 전송 서비스에서 수신 커넥터의 경우 5분 | 이 매개 변수는 연결이 닫히기 전에 원본 메시징 서버와의 열린 SMTP 연결이 유휴 상태로 유지될 수 있는 최대 시간을 지정합니다. 이 매개 변수의 값은 ConnectionTimeout 매개 변수 값보다 커야 합니다. |
| Set-ReceiveConnector의ConnectionTimeout | 사서함 서버의 전송 서비스에서 수신 커넥터의 경우 10분 | 이 매개 변수는 서버가 데이터를 전송하는 경우에도 원본 메시징 서버와의 SMTP 연결이 열려 있을 수 있는 최대 시간을 지정합니다. 이 매개 변수의 값은 ConnectionInactivityTimeout 매개 변수 값보다 커야 합니다. |
| Set-SendConnector의 ConnectionInactivityTimeOut | 10분 | 이 매개 변수는 대상 메시징 서버와의 열린 SMTP 연결이 닫히기 전에 유휴 상태를 유지할 수 있는 최대 시간을 지정합니다. |
섀도 메시지가 유지되는 방법
섀도 메시지가 성공적으로 만들어지면 섀도 중복성 작업이 시작된 것입니다. 기본 서버와 섀도 서버는 메시지의 진행 상태를 추적하기 위해 서로 연결된 상태를 유지해야 합니다.
기본 서버가 메시지를 다음 홉으로 성공적으로 전송하고 다음 홉이 메시지의 수신을 확인하면 기본 서버는 메시지의 삭제 상태를 배달 완료로 업데이트합니다. 삭제 상태는 기본적으로 모니터링 중인 메시지의 목록이 포함된 메시지입니다. 성공적으로 배달된 메시지는 섀도 큐에 유지할 필요가 없으므로, 기본 서버가 메시지를 다음 홉으로 성공적으로 전송했음을 섀도 서버가 확인한 후에는 섀도 서버가 섀도 메시지를 섀도 큐에서 보안 네트워크로 이동합니다.
섀도 서버는 기본 서버를 쿼리하여 해당 섀도 큐에 있는 섀도 메시지의 삭제 상태를 확인합니다. 섀도 서버가 어떤 이유로든 주 서버와 함께 SMTP 세션을 여는 경우(관련 없는 다른 메시지의 전송 포함) 섀도 서버는 XQDISCARD 명령을 실행하여 기본 메시지의 삭제 상태를 확인합니다. 그렇지 않으면 미리 구성된 시간 간격(Set-TransportConfig cmdlet의 ShadowHeartbeatFrequency 매개 변수, 기본값은 2분) 후에 섀도 서버가 주 서버와 함께 SMTP 세션을 자동으로 엽니다.
섀도 서버가 기본 서버와의 SMTP 세션을 열면 기본 서버는 쿼리하는 섀도 서버에 적용되는 메시지에 대한 삭제 알림으로 응답합니다. 삭제 알림은 메모리가 아닌 디스크에 저장되므로 Microsoft Exchange 전송 서비스가 다시 시작되면 삭제 알림이 유지됩니다. 서비스가 시작된 후에도 기본 서버는 여전히 성공적으로 처리한 메시지에 대해 알고 있으며 섀도 서버가 이 정보를 사용할 수 있습니다.
섀도 서버와 기본 서버 간의 SMTP 통신은 서버의 가용성을 확인하는 하트비트로 사용됩니다. 미리 구성된 시간 간격(Set-TransportConfig cmdlet의 ShadowResubmitTimeSpan 매개 변수, 기본값은 3시간) 후 섀도 서버가 주 서버와 함께 SMTP 세션을 열 수 없는 경우 섀도 서버는 자신을 주 서버로 승격하고, 섀도 메시지를 기본 메시지로 승격하고, 메시지를 다음 홉으로 전송합니다. 그러나 섀도 서버가 주 서버의 큐 데이터베이스 ID가 변경되었음을 감지할 때마다 섀도 서버는 자신을 주 서버로 승격하고, 섀도 메시지를 기본 메시지로 승격하고, 메시지를 다음 홉으로 전송합니다. 이는 ShadowResubmitTimeSpan 매개 변수 값이 전달되기 전에 발생할 수 있습니다.
섀도 중복 관리자는 섀도 중복 관리를 담당하는 사서함 서버의 핵심 구성 요소입니다. 섀도 중복성 관리자는 서버에서 현재 처리 중인 모든 기본 메시지에 대한 다음 정보를 유지 관리합니다.
처리 중인 각 기본 메시지에 대한 섀도 서버입니다.
섀도 서버로 보낼 삭제 상태
섀도 중복 관리자는 섀도 서버가 섀도 큐에 있는 모든 섀도 메시지에 대해 다음 작업을 담당합니다.
각 섀도 메시지에 대한 기본 서버 목록을 유지 관리합니다.
메시지의 기본 복사본이 저장된 큐 데이터베이스의 원래 데이터베이스 ID와 현재 데이터베이스 ID를 비교합니다.
섀도 메시지를 큐에 넣을 각 기본 서버의 가용성을 확인합니다.
기본 서버에서의 삭제 알림을 처리합니다.
예상된 모든 삭제 알림을 받은 후 섀도 큐에서 섀도 메시지를 제거합니다.
섀도 서버가 섀도 메시지의 소유권을 갖게 되어 기본 서버가 되는 시점을 결정합니다.
메시지 분기 및 배달 상태 알림(DSN이라고도 함, 배달되지 않는 보고서, NDR 또는 반송 메시지라고도 함) 및 저널 보고서와 같은 기타 부작용 메시지를 추적하여 메시지의 모든 포크가 완전히 처리될 때까지 메시지의 중복 복사본이 해제되지 않는지 확인합니다.
이 표에서는 섀도 메시지를 유지 관리하는 방법을 제어하는 매개 변수에 대해 설명합니다.
| 매개 변수 | 기본값 | 설명 |
|---|---|---|
| Set-TransportConfig의 ShadowHeartbeatFrequency | 2분 | 메시지의 삭제 상태를 확인하기 위해 기본 서버에 대한 SMTP 연결을 열기 전에 섀도 서버가 기다리는 최대 시간입니다. |
| Set-TransportConfig의 ShadowResubmitTimeSpan | 3시간 | 기본 서버가 실패했다고 결정하고 연결할 수 없는 기본 서버의 섀도 큐에 있는 섀도 메시지의 소유권을 갖기 전까지 서버가 대기하는 시간입니다. 주 서버의 큐 데이터베이스에 다른 데이터베이스 ID가 있는 것으로 확인되면 섀도 서버가 이 매개 변수 값 이전에 주 서버로 승격할 수도 있습니다. |
| Set-TransportConfig의 ShadowMessageAutoDiscardInterval | 2일 | 성공적으로 배달된 메시지에 대한 삭제 이벤트가 서버에 유지되는 시간입니다. 주 서버는 섀도 서버에서 쿼리할 때까지 이벤트를 삭제합니다. 그러나 섀도 서버가 이 매개 변수로 지정된 기간 동안 기본 서버를 쿼리하지 않으면 기본 서버가 대기 중인 삭제 이벤트를 삭제합니다. |
| Set-TransportConfig의 SafetyNetHoldTime | 2일 | 성공적으로 처리된 메시지가 보안 네트워크에 유지되는 시간입니다. 승인되지 않은 섀도 메시지는 Set-TransportService cmdlet의 SafetyNetHoldTime 및 MessageExpirationTimeout 매개 변수 값을 합한 후 결국 Safety Net에서 만료됩니다. |
| Set-TransportService의 MessageExpirationTimeout | 2일 | 메시지가 만료되기 전에 큐에 남아 있을 수 있는 시간입니다. |
중단 후 메시지 처리
이 표에서는 섀도 중복성이 서버 중단으로 인한 메시지 손실을 최소화하는 방법을 요약합니다. 명확하게 하기 위해 중단이 있었던 서버의 이름은 Mailbox01입니다.
| 복구 시나리오 | 수행한 작업 |
|---|---|
| Mailbox01은 ShadowResubmitTimeSpan 매개 변수 값이 전달되기 전에 새 큐 데이터베이스와 함께 다시 온라인 상태가 됩니다(기본적으로 3시간). 이 시나리오는 데이터 손상 또는 하드웨어 오류로 인해 큐 데이터베이스를 복구할 수 없는 경우에 발생할 수 있습니다. |
Mailbox01에서 새 큐 데이터베이스 ID가 검색되면 Mailbox01에 대해 대기 중인 섀도 메시지가 있는 각 서버는 해당 메시지의 소유권을 가정하고 다시 제출합니다. 그러면 메시지가 대상에 배달됩니다. 새 큐 데이터베이스가 검색된 후 메시지 제출의 최대 지연 시간은 ShadowHeartbeatFrequency 매개 변수의 값(기본적으로 2분)입니다. |
| Mailbox01은 ShadowResubmitTimeSpan 매개 변수 값이 통과된 후(기본적으로 3시간) 동일한 데이터베이스로 다시 온라인 상태가 됩니다. 이 시나리오는 네트워크 카드 오류 또는 서버에서 시간이 많이 걸리는 유지 관리 후에 발생할 수 있습니다. |
Mailbox01이 다시 온라인 상태가 되면 Mailbox01에 대한 메시지의 섀도 복사본을 저장하는 서버가 이미 배달한 큐의 메시지를 배달합니다. 이로 인해 이러한 메시지의 배달이 중복됩니다. 중복된 메시지가 검색되더라도 Exchange 사서함 사용자에게 중복된 메시지가 표시되지는 않습니다. 그러나 다른 메시징 시스템의 받는 사람에게는 중복된 메시지 복사본이 표시될 수 있습니다. 메시지 제출의 최대 지연 시간은 ShadowResubmitTimeSpan 매개 변수의 값입니다. |