卷影冗余
适用于：Exchange Server 2013
Microsoft Exchange Server 2010 中引入了卷影冗余，以便在将邮件传递给邮箱之前，提供邮件的冗余备份。 在 Exchange 2010 中，卷影冗余延迟了从传输服务器上的传输数据库删除邮件的时间，直到服务器验证邮件传递路径中的下一个跃点已完成传递。 如果在向传输服务器返回成功传递报告之前下一个跃点失败，则传输服务器会向下一个跃点重新提交邮件。 Exchange 2010 服务器使用 XSHADOW 动词来公布其卷影冗余支持。 如果 SMTP 服务器不支持卷影冗余，Exchange 2010 将使用基于接收连接器上设定的时间间隔的延迟确认来制作邮件的冗余备份。
Microsoft Exchange Server 2013 中卷影冗余功能的主要改进体现在，现在传输服务器能够在确认成功接收发回给发送服务器的邮件之前，为所收到的任何邮件制作冗余备份。 发送服务器是否支持卷影冗余并不重要。 这将有助于确保 Exchange 2013 传输管道中的所有邮件在传输过程中都变得冗余。 如果 Exchange 2013 确定原始邮件在传输过程中丢失，将重新传递邮件的冗余备份。
卷影冗余组件
下表介绍卷影冗余的组件。 本主题中将使用以下术语。
| 术语 | 描述 |
|---|---|
| 传输服务器 | 包含邮件队列、负责路由邮件的 Exchange 服务器。 在 Exchange 2013 中，传输服务器即邮箱服务器（邮箱服务器上的传输服务）。 |
| 传输数据库 | Exchange 2013 传输服务器上的邮件队列数据库。 卷影队列和安全网络也存储在传输数据库中。 |
| 传输高可用性边界 | 数据库可用性组 (DAG) 环境中的 DAG，或非 DAG 环境中的 Active Directory 站点。 当邮件到达传输高可用性边界中的传输服务器上时，Exchange 会尝试在边界内维护传输服务器上的 2 个邮件的冗余备份。 当邮件离开传输高可用性边界时，Exchange 将不再维护邮件的冗余备份。 |
| 主邮件 | 提交到传输管道用于传递的邮件。 |
| 卷影邮件 | 在确认主服务器已成功处理主邮件之前一直由卷影服务器保留的邮件的冗余副本。 |
| 主服务器 | 当前正在处理主邮件的传输服务器。 |
| 卷影服务器 | 保留主服务器的卷影邮件的传输服务器。 传输服务器可以是某些邮件的主服务器，同时还是其他邮件的卷影服务器。 |
| 卷影队列 | 卷影服务器存储卷影邮件的传递队列。 对于具有多个收件人的邮件，主邮件的每个下一个跃点都需要单独的卷影队列。 |
| 丢弃状态 | 传输服务器为卷影邮件维护的指示已成功处理主邮件的信息。 |
| 丢弃通知 | 卷影服务器从主服务器接收的响应，指示准备何时丢弃卷影邮件。 |
| Safety Net | 传输垃圾站改进的 Exchange 2013 版本。 已通过邮箱服务器上的传输服务成功处理或传递给邮箱收件人的邮件将被移动到安全网络。 有关详细信息，请参阅Safety Net。 |
| 卷影冗余管理器 | 管理卷影冗余的传输组件。 |
| 检测信号 | 主服务器和卷影服务器验证彼此的可用性的过程。 |
卷影冗余的要求
显然，卷影冗余需要多个 Exchange 2013 邮箱服务器。 邮箱服务器可以是独立的服务器，邮箱服务器和客户端访问服务器也可以安装在同一台计算机上。
- 如果邮箱服务器不是 DAG 的成员，则本地 Active Directory 站点中必须存在其他邮箱服务器。
- 如果邮箱服务器是 DAG 的成员，则其他邮箱服务器必须属于同一 DAG。 其他属于 DAG 的邮箱服务器可以在本地 Active Directory 站点中，也可以在远程 Active Directory 站点中。 如果 DAG 跨越多个 Active Directory 站点，则卷影冗余首选在远程 Active Directory 站点创建邮件的冗余备份，以实现站点恢复功能。
在以下位置，卷影冗余无法保护传输中的邮件：
- 单个 Exchange 服务器环境。
- 配置不充分的 DAG。
- 涉及邮件卷影冗余的两个或更多传输服务器同时发生故障时。
默认情况下启用卷影冗余
默认情况下，使用 Set-TransportConfig cmdlet 上的 ShadowRedundancyEnabled 参数在所有邮箱服务器上的传输服务中全局启用卷影冗余。 默认情况下，如果邮箱服务器上的传输服务无法创建邮件的冗余备份，则不会拒绝该邮件。 但是，如果未使用 Set-TransportConfig cmdlet 上的 RejectMessageOnShadowFailure 参数创建邮件的冗余副本，则可以将 Exchange 2013 配置为拒绝邮件。 拒绝邮件时出现暂时性故障，但发送服务器可以再次传输该邮件。 SMTP 响应代码为 451 4.4.0 Message failed to be made redundant. “应将 Exchange 2013 配置为仅当组织有多个可用的 Exchange 2013 邮箱服务器时，才能拒绝无法成为冗余的邮件。
下表介绍启用卷影冗余的参数。
启用卷影冗余的参数
| 参数 | 默认值 | 描述 |
|---|---|---|
| Set-TransportConfig 上的 ShadowRedundancyEnabled | $true |
|
| Set-TransportConfig 上的 RejectMessageOnShadowFailure | $false |
仅当 ShadowRedundancyEnabled 为 |
如何创建卷影邮件
卷影冗余的主要目标是在邮件传输过程中始终在传输高可用性边界内保留两个邮件副本。 何时何地创建邮件的冗余备份取决于邮件的收件人和发件人。 有三个主要决定因素：
- 从传输高可用性边界外接收的邮件。
- 传输高可用性边界外发送的邮件。
- 从传输高可用性边界内的邮箱服务器的邮箱传输提交服务收到的邮件。
传输高可用性边界可以是下列之一：
- DAG，表示属于 DAG 的邮箱服务器。 这包括跨越多个 Active Directory 站点的 DAG。
- Active Directory 站点，表示不属于 DAG 的邮箱服务器。
卷影冗余从不跨传输高可用性边界跟踪卷影邮件。 当邮件跨过传输高可用性边界时，卷影冗余便会开始或重新启动。 这会减少卷影邮件维护通信量，并防止整个传输高可用性边界发生卷影邮件重新提交。 Exchange 2010 集线器传输服务器是一种特殊情况，将在本主题后文讨论。
从传输高可用性边界外接收的邮件
当 Exchange 2013 邮箱服务器上的传输服务从传输高可用性边界外收到一封邮件时，邮箱服务器并不关心发送服务器是否支持卷影冗余。 只要启用卷影冗余，收到该邮件的邮箱服务器便会在传输高可用性边界内的另一台邮箱服务器上制作该邮件的冗余备份，然后确认收到返回给发送服务器的邮件。 以下是此过程工作方式的示例：
.gif "阴影消息创建")
SMTP 服务器向邮箱服务器上的传输服务传输邮件。 邮箱服务器是主服务器，邮件是主邮件。
当 SMTP 服务器的原始 SMTP 会话仍处于活动状态时，主服务器上的传输服务会打开与组织中的另一个邮箱服务器上的传输服务同时发生的新 SMTP 会话，以创建邮件的冗余备份。
- 如果主服务器是 DAG 的成员，则主服务器会连接到同一 DAG 中的不同邮箱服务器。 如果 DAG 跨越多个 Active Directory 站点，则默认情况下首选不同 Active Directory 站点的邮箱服务器。 此设置由 Set-TransportService cmdlet 上的 ShadowMessagePreference 参数控制。 默认值
PreferRemote为 ，但你可以将其更改为RemoteOnly或LocalOnly。 - 如果主服务器不是 DAG 的成员，则无论 ShadowMessagePreference 参数的值如何，主服务器都会连接到同一 Active Directory 站点中的其他邮箱服务器。
- 如果主服务器是 DAG 的成员，则主服务器会连接到同一 DAG 中的不同邮箱服务器。 如果 DAG 跨越多个 Active Directory 站点，则默认情况下首选不同 Active Directory 站点的邮箱服务器。 此设置由 Set-TransportService cmdlet 上的 ShadowMessagePreference 参数控制。 默认值
主服务器向其他邮箱服务器上的传输服务传输邮件的副本，同时其他邮箱服务器上的传输服务确认已成功创建邮件的副本。 该邮件的副本是卷影邮件，而其所在的邮箱服务器是主服务器的卷影服务器。 该邮件在卷影服务器上的卷影队列中。
当主服务器收到卷影服务器的确认后，主服务器向原始 SMTP 服务器的原始 SMTP 会话确认收到主邮件，同时 SMTP 会话关闭。
传输高可用性边界外发送的邮件
当 Exchange 2013 传输服务器在传输高可用性边界外传输邮件时，另一侧的 SMTP 服务器确认成功收到邮件，传输服务器会将邮件移动到安全网络中。 在整个传输高可用性边界内成功传输主邮件后，不会从安全网络重新提交邮件。 有关安全网络的详细信息，请参阅Safety Net。
传输高可用性边界内传输的邮件
Exchange 2013 中已对邮件路由进行优化，因此当最终目标是位于 DAG 或 Active Directory 站点中时，该 DAG 或 Active Directory 站点的邮箱服务器上的传输服务之间通常不需要多个跃点。 当保留邮件最终目标的 DAG 或 Active Directory 站点的邮箱服务器上的传输服务接受邮件后，该邮件的下一个跃点通常是最终目标本身。 当 DAG 或 Active Directory 站点内的任何地方存在邮件的卷影副本时，卷影冗余将实现保存两个传输中邮件的副本的目标。 通常，只有在 DAG 中需要用 Redirect-Message cmdlet 来耗尽邮箱服务器上的活动队列的故障转移方案，才需要同一传输高可用性边界内存在多个跃点。
同一 Active Directory 站点的 Exchange 2010 集线器传输服务器上的卷影冗余
当 Exchange 2010 集线器传输服务器向同一个 Active Directory 站点的 Exchange 2013 邮箱服务器传输邮件时，Exchange 2010 集线器传输服务器将使用 XSHADOW 命令公布卷影冗余支持，但邮箱服务器不公布此支持。 这可以防止 Exchange 2010 集线器传输服务器在 Exchange 2013 邮箱服务器上创建邮件的卷影副本。
当 Exchange 2013 邮箱服务器上的传输服务向同一个 Active Directory 站点的 Exchange 2010 集线器传输服务器传输邮件时，Exchange 2013 邮箱服务器会对此 Exchange 2010 集线器传输服务器隐藏该邮件。 当 Exchange 2013 邮箱服务器从 Exchange 2010 集线器传输服务器收到成功收到该邮件的确认后，Exchange 2013 邮箱服务器会将成功处理的邮件移动到安全网络中。 但是，由 Exchange 2013 邮箱服务器存储在安全网络中的成功处理的邮件永远不会重新提交到 Exchange 2010 集线器传输服务器。
SMTP 超时
在尝试制作邮件的冗余备份时，发送 SMTP 服务器和主服务器之间的 SMTP 连接或主服务器和卷影服务器之间的 SMTP 会话可能超时。 接收连接器和发送连接器都具有 ConnectionInactivityTimeOut 参数，用于在连接器上实际传输数据的时间。 接收连接器还具有绝对 ConnectionTimeOut 参数。
如果任何 SMTP 会话在邮件的卷影副本成功创建和确认之前超时，则结果由 Set-TransportConfig cmdlet 上的 RejectMessageOnShadowFailure 参数控制。 默认情况下，此参数 $false的值为 ，这意味着接受主消息而不创建卷影副本。 如果此参数 $true 的值为 ，则主消息被拒绝并出现暂时性错误 451 4.4.0。
如果成功创建邮件的卷影副本，但是发送 SMTP 服务器和主服务器之间的 SMTP 会话超时，则主服务器会接受和处理主邮件。 发送 SMTP 服务器将重新传递未确认的邮件，但是重复邮件检测将阻止 Exchange 邮箱用户看到重复邮件。 当发送 SMTP 服务器重新提交邮件时，主服务器会创建邮件的另一个卷影副本。 邮件重新提交期间发送 SMTP 服务器创建的卷影邮件之间没有任何关系。
下表介绍控制卷影邮件创建的参数
卷影邮件创建参数
| 来源 | 默认值 | 描述 |
|---|---|---|
| Set-TransportConfig 上的 ShadowMessagePreferenceSetting | PreferRemote |
此参数仅当尝试制作邮件的卷影副本的主服务器是属于跨越多个 Active Directory 站点的 DAG 的邮箱服务器时才有意义。 |
| Set-TransportConfig 上的 MaxRetriesForRemoteSiteShadow | 4 | 当邮箱服务器是跨越多个 Active Directory 站点的 DAG 成员时使用此参数。
When a shadow copy of the message can't be successfully created:
|
| Set-TransportConfig 上的 MaxRetriesForLocalSiteShadow | 2 | 当邮箱服务器是跨越多个 Active Directory 站点的 DAG 成员。
When a shadow copy of the message can't be successfully created:
|
| Set-ReceiveConnector 上的 ConnectionInactivityTimeout | 在客户端访问服务器上的前端传输服务 5 分钟。 在边缘传输服务器上 1 分钟。 1 minute on Edge Transport servers. |
此参数指定与源邮件服务器的打开 SMTP 连接在连接关闭之前可以保持空闲的最长时间。 此参数的值必须小于 ConnectionTimeout 参数指定的值。 |
| Set-ReceiveConnector 上的 ConnectionTimeout | 在客户端访问服务器上的前端传输服务 10 分钟。 在边缘传输服务器上 5 分钟。 5 minutes on Edge Transport servers. |
此参数指定与源消息传送服务器的 SMTP 连接保持打开状态的最长时间，即使源消息服务器正在传输数据也是如此。 此参数的值必须大于 ConnectionInactivityTimeout 参数指定的值。 |
| Set-SendConnector 上的 ConnectionInactivityTimeOut | 10 分钟 | This parameter specifies the maximum time that an open SMTP connection with a destination messaging server can remain idle before the connection is closed. |
How shadow messages are maintained
成功创建影子消息后，阴影冗余的工作才刚刚开始。 主服务器和影子服务器需要彼此保持联系，以跟踪消息的进度。
当主服务器成功将消息传输到下一跃点，并且下一跃点确认收到消息时，主服务器将邮件的 丢弃状态 更新为传递完成。 The discard status is basically a message that contains of list of messages that are being monitored. A successfully delivered message doesn't need to be kept in a shadow queue, so once the shadow server knows the primary server has successfully transmitted the message to the next hop, the shadow server moves the shadow message from the shadow queue into Safety Net.
影子服务器通过查询主服务器来确定影子队列中影子消息的丢弃状态。 如果影子服务器出于任何原因（包括传输其他不相关的邮件）与主服务器打开 SMTP 会话，则影子服务器会发出 XQDISCARD 命令来确定主消息的放弃状态。 如果影子服务器在预配置的时间间隔后未与主服务器打开 SMTP 会话，则影子服务器将打开与主服务器的 SMTP 会话，并发出 XQDISCARD 命令。 时间间隔由 Set-TransportConfig cmdlet 上的 ShadowHeartbeatFrequency 参数控制。 The default value is 2 minutes. 在卷影服务器与主服务器打开 SMTP 会话后，主服务器将响应适用于查询影子服务器的消息 的放弃通知 。 在 Exchange 2013 中，放弃通知存储在磁盘上，而不是存储在内存中。 因此，如果 Microsoft Exchange 传输服务重新启动，则会保留放弃通知。 服务启动后，主服务器仍知道已成功处理的消息，并且该信息可供影子服务器使用。
影子服务器与主服务器之间的 SMTP 通信用作确定服务器可用性的 检测信号 。 If the shadow server can't open an SMTP session with the primary server after a preconfigured time interval, or if the transport database of the primary server has a different database ID, the shadow server promotes itself as the primary server, promotes the shadow messages as primary messages, and transmits the messages to the next hop. 时间间隔由 Set-TransportConfig cmdlet 上的 ShadowResubmitTimeSpan 参数控制。 The default value is 3 hours.
卷影冗余管理器 是负责管理卷影冗余的 Exchange 2013 传输服务器的核心组件。 影子冗余管理器负责维护服务器当前正在处理的所有主消息的以下信息：
- 要发送到卷影服务器的丢弃状态。
- 卷影冗余管理器负责卷影服务器在其卷影队列中包含的所有卷影邮件的下列内容：
维护每个卷影邮件的主服务器的列表。
- 比较存储邮件主副本的队列数据库的原始数据库 ID 和当前数据库 ID。
- 核查每个主服务器是否可以对卷影邮件进行排队。
- 处理来自主服务器的丢弃通知。
- 在收到所有预期的丢弃通知之后将卷影邮件从卷影队列中删除。
- 决定卷影服务器何时应该取得卷影邮件的所有权，从而成为主服务器。
- 跟踪邮件分流和其他副作用邮件（如传递状态通知 (DSN) 和日志报告），以验证在邮件的所有支流得到全面处理之前不会发布邮件的冗余备份。
- 下表介绍控制卷影邮件维护方式的参数。
参数
| 默认值 | 默认值 | 描述 |
|---|---|---|
| Set-TransportConfig 上的 ShadowHeartbeatFrequency | 2 分钟 | The maximum amount of time a shadow server waits before opening an SMTP connection to the primary server to check the discard status of messages. |
| Set-TransportConfig 上的 ShadowResubmitTimeSpan | 在确定主服务器出现故障前服务器等待时间的长短，并为无法访问的主服务器假定卷影队列中的卷影邮件的所有权。 | How long a server waits before deciding that a primary server has failed and assumes ownership of shadow messages in the shadow queue for the primary server that's unreachable. |
| Set-TransportConfig 上的 ShadowMessageAutoDiscardInterval | 2 天 | How long a server retains discard events for successfully delivered messages. A primary server queues discard events until queried by the shadow server. However, if the shadow server doesn't query the primary server for the duration specified in this parameter, the primary server deletes the queued discard events. |
| Set-TransportConfig 上的 SafetyNetHoldTime | 2 天 | How long successfully processed messages are retained in Safety Net. 在 Set-TransportService 上 SafetyNetHoldTime 和 MessageExpirationTimeout 的总和之后，未确认的影子消息最终从安全网过期。 |
| Set-TransportService 上的 MessageExpirationTimeout | 2 天 | How long a message can remain in a queue before it expires. |
Message processing after an outage
卷影冗余可最大程度地减少因服务器中断而导致的消息丢失。 当传输服务器在中断后恢复联机时，有两种情况：
服务器与新的传输数据库一起恢复联机：在此方案中，传输数据库由于数据损坏或硬件故障而无法恢复。 在这种情况下，由于传输服务器将具有新的数据库 ID，因此组织中的其他传输服务器会将它识别为新路由。 这也适用于无法恢复服务器，并且新服务器已预配为替换服务器的情况。
服务器将使用相同的传输数据库重新联机：在此方案中，特定传输服务器不会发生故障，但脱机的时间足够长，以便影子服务器拥有消息的所有权并重新提交它们。 为清晰起见，假定中断的服务器名为 Mailbox01。
The following table summarizes how shadow redundancy reacts to these two scenarios. For clarity, assume that the server that had an outage is named Mailbox01.
Message processing in recovery scenarios
| 执行的操作 | Mailbox01 会使用新的数据库重新联机。 |
|---|---|
| 当 Mailbox01 不可用时，每个为 Mailbox01 进行卷影邮件排队的服务器将承担这些邮件的所有权并重新提交邮件。然后将邮件传递到目的地。 | When Mailbox01 becomes unavailable, each server that has shadow messages queued for Mailbox01 will assume ownership of those messages and resubmit them. The messages then get delivered to their destinations. 消息的最大延迟是 Set-TransportConfig cmdlet 上 ShadowHeartbeatFrequency 参数的值。 The default value is 2 minutes. |
| Mailbox01 重新联机后，它会传递队列中的邮件，为 Mailbox01 保留邮件卷影副本的服务器已传递这些邮件。这将导致重复传递这些邮件。由于采用了重复邮件检测，Exchange 邮箱用户看不到这些重复邮件。然而，非 Exchange 邮件系统中的收件人可能会收到重复的邮件副本。 | After Mailbox01 comes back online, it will deliver the messages in its queues, which have already been delivered by the servers that hold shadow copies of messages for Mailbox01. This will result in duplicate delivery of these messages. Exchange mailbox users won't see duplicate messages due to duplicate message detection. However, recipients on non-Exchange messaging systems may receive duplicate copies of messages. 消息的最大延迟是 Set-TransportConfig cmdlet 上 ShadowResubmitTimeSpan 参数的值。 The default value is 3 hours. |