Exchange Server 中的阴影冗余

  • 项目

在 Exchange 2010 中引入了卷影冗余，以便在邮件传递到邮箱之前提供邮件的冗余副本。 在 Exchange 2010 中，影子冗余延迟从中心传输服务器上的队列数据库中删除邮件，直到服务器验证邮件传递路径中的下一跃点已完成传递。 如果下一跃点在报告成功传递回中心传输服务器之前失败，服务器会将邮件重新提交到下一跃点。 Exchange 2010 中心传输服务器使用 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 会尝试在边界内的邮箱服务器上保留邮件的两个冗余副本。 当邮件离开传输高可用性边界时，Exchange 将不再维护邮件的冗余备份。
主邮件 提交到传输管道用于传递的邮件。
卷影邮件 在确认主服务器已成功处理主邮件之前一直由卷影服务器保留的邮件的冗余副本。
主服务器 当前正在处理主邮件的邮箱服务器。
卷影服务器 保存主服务器的影子邮件的邮箱服务器。 邮箱服务器可能是某些邮件的主服务器，也可以是其他邮件的影子服务器。
卷影队列 卷影服务器存储卷影邮件的传递队列。 对于具有多个收件人的邮件，主邮件的每个下一个跃点都需要单独的卷影队列。
丢弃状态 邮箱服务器为影子邮件维护的信息，指示主邮件已成功处理。
丢弃通知 卷影服务器从主服务器接收的响应，指示准备何时丢弃卷影邮件。
安全网络 Exchange 2013 或更高版本中传输转储的改进版本。 已通过邮箱服务器上的传输服务成功处理或传递给邮箱收件人的邮件将被移动到安全网络。 有关详细信息，请参阅 Exchange Server 中的安全网。
卷影冗余管理器 管理卷影冗余的传输组件。
检测信号 主服务器和卷影服务器验证彼此的可用性的过程。

卷影冗余的要求

尽管看起来很明显，但影子冗余需要多个邮箱服务器：

  • 如果邮箱服务器不是 DAG 的成员，则本地 Active Directory 站点中必须存在其他邮箱服务器。

  • 如果邮箱服务器是 DAG 的成员，则其他邮箱服务器必须属于同一 DAG。 其他 DAG 成员可以位于本地 Active Directory 站点中，也可以位于远程站点中。 默认情况下，如果 DAG 跨越多个 Active Directory 站点，则影子冗余更倾向于在远程站点中创建消息的冗余副本来实现站点复原。

在以下位置，卷影冗余无法保护传输中的邮件：

  • 单个 Exchange 服务器环境。

  • 配置不充分的 DAG。

  • 在邮件卷影冗余中涉及的两台或更多邮箱服务器同时发生故障期间。

默认情况下启用卷影冗余

默认情况下，在所有邮箱服务器上的传输服务中全局启用卷影冗余。 下表介绍了启用阴影冗余的参数。

参数 默认值 描述
Set-TransportConfig 上的 ShadowRedundancyEnabled $true $true：在组织中的所有邮箱服务器上启用影子冗余。

$false：在组织中的所有邮箱服务器上禁用影子冗余。
Set-TransportConfig 上的 RejectMessageOnShadowFailure $false $false：当无法创建邮件的卷影副本时，组织中的邮箱服务器仍然接受主邮件。 这些消息在传输过程中不会冗余地持久保存。

$true：在成功创建邮件的卷影副本之前，组织中的任何邮箱服务器都不接受或确认邮件。 如果无法创建消息的卷影副本，则拒绝主消息并出现暂时性错误，但发送服务器可以再次传输消息。 SMTP 响应代码为 451 4.4.0 Message failed to be made redundant。 组织中的所有邮件在传输时冗余存在。

注意： $true 仅当同一 DAG 或 Active Directory 站点中有多个邮箱服务器，以便可以创建邮件的卷影副本时，才使用 。

仅当 ShadowRedundancyEnabled 为 $true时，此参数才有意义。

如何创建卷影邮件

卷影冗余的主要目标是在邮件传输过程中始终在传输高可用性边界内保留两个邮件副本。 创建消息冗余副本的位置和时间取决于消息来自何处以及消息的去向。 创建影子消息有三个决定因素：

  • 从传输高可用性边界外部接收的消息 (DAG 或非 DAG 环境中的 Active Directory 站点) 。

  • 传输高可用性边界外发送的邮件。

  • 从传输高可用性边界内的邮箱服务器的邮箱传输提交服务收到的邮件。

卷影冗余从不跨传输高可用性边界跟踪卷影邮件。 当邮件跨过传输高可用性边界时，卷影冗余便会开始或重新启动。 这可以减少影子消息维护流量，并防止影子消息跨传输高可用性边界重新提交。 Exchange 2010 集线器传输服务器是一种特殊情况，将在本主题后文讨论。

从传输高可用性边界外接收的邮件

当邮箱服务器上的传输服务从传输高可用性边界外部接收邮件时，邮箱服务器不关心发送服务器是否支持或缺乏对影子冗余的支持。 只要启用卷影冗余，收到该邮件的邮箱服务器便会在传输高可用性边界内的另一台邮箱服务器上制作该邮件的冗余备份，然后确认收到返回给发送服务器的邮件。 以下是此过程工作方式的示例：

影子消息创建。

  1. 邮件服务器将邮件传输到邮箱服务器上的传输服务。 邮箱服务器是主服务器，邮件是主邮件。

  2. 虽然与邮件服务器的原始 SMTP 会话仍然处于活动状态，但主服务器上的传输服务会在组织中的其他邮箱服务器上与传输服务打开一个新的同时 SMTP 会话，以创建邮件的冗余副本。

    • 如果主服务器是 DAG 的成员，则主服务器会连接到同一 DAG 中的不同邮箱服务器。 如果 DAG 跨越多个 Active Directory 站点，则默认首选其他 Active Directory 站点中的邮箱服务器， (Set-TransportConfig cmdlet 上的 ShadowMessagePreferenceSetting 参数的默认值为 PreferRemote，但你可以将其更改为 RemoteOnly 或LocalOnly) 。

    • 如果主服务器不是 DAG 的成员，则无论 ShadowMessagePreferenceSetting 参数) 的值如何，主服务器都会 (连接到同一 Active Directory 站点中的其他邮箱服务器。

  3. 主服务器将邮件副本传输到另一个邮箱服务器上的传输服务，另一个邮箱服务器上的传输服务确认邮件副本已成功创建。 该邮件的副本是卷影邮件，而其所在的邮箱服务器是主服务器的卷影服务器。 该邮件在卷影服务器上的卷影队列中。

  4. 主服务器收到来自影子服务器的确认后，主服务器将确认在原始 SMTP 会话中将主邮件接收到原始邮件服务器，SMTP 会话将关闭。

传输高可用性边界外发送的邮件

当邮箱服务器在传输高可用性边界之外传输邮件时，另一端的邮件服务器确认邮件成功接收，并且邮箱服务器会将邮件移动到安全网。 在整个传输高可用性边界内成功传输主邮件后，不会从安全网络重新提交邮件。 有关安全网的详细信息，请参阅 Exchange Server 中的安全网。

传输高可用性边界内传输的邮件

消息路由经过优化，因此，当最终目标位于 DAG 或 Active Directory 站点中时，通常不需要目标 DAG 或站点中的服务器之间的多个跃点。 在目标 DAG 或 Active Directory 中的邮箱服务器上的传输服务接受邮件后，邮件的下一跃点通常是最终目标本身 (例如，保存目标邮箱的活动副本的邮箱服务器) 。 当消息的一个卷影副本存在于 DAG 或 Active Directory 站点中的任何 位置 时，就实现了卷影冗余的目标，即保留传输中消息的两个副本。 通常，只有在 DAG 中需要 Redirect-Message cmdlet 来清空邮箱服务器上的活动邮件队列的故障转移方案，才需要在同一传输高可用性边界内使用多个跃点。

Exchange 2016 组织中的同一 Active Directory 站点中的 Exchange 2010 中心传输服务器的卷影冗余

当 Exchange 2010 中心传输服务器将邮件传输到同一 Active Directory 站点中的 Exchange 2016 邮箱服务器时，Exchange 2010 中心传输服务器使用 XSHADOW 命令播发对卷影冗余的支持，但邮箱服务器不会播发对影子冗余的支持。 这可以防止 Exchange 2010 中心传输服务器在 Exchange 2016 邮箱服务器上创建邮件的卷影副本。

当 Exchange 2016 邮箱服务器上的传输服务将邮件传输到同一 Active Directory 站点中的 Exchange 2010 中心传输时，Exchange 2016 邮箱服务器会为 Exchange 2010 中心传输服务器的邮件隐藏。 Exchange 2016 邮箱服务器从 Exchange 2010 中心传输服务器收到已成功接收邮件的确认后，Exchange 2016 邮箱服务器会将成功处理的邮件移动到安全网。 但是，Exchange 2016 邮箱存储在安全网中成功处理的邮件永远不会重新提交到 Exchange 2010 中心传输服务器。

SMTP 超时

在尝试创建邮件的冗余副本期间，服务器 (发送服务器和主服务器之间的 SMTP 连接，或者主服务器和影子服务器) 可能会超时。 接收连接器和发送连接器都具有 ConnectionInactivityTimeOut 参数，用于在连接器上实际传输数据的时间。 接收连接器还具有绝对 ConnectionTimeOut 参数。

如果任何 SMTP 会话在邮件的卷影副本成功创建和确认之前超时，则结果由 Set-TransportConfig cmdlet 上的 RejectMessageOnShadowFailure 参数控制。 默认情况下，此参数 $false的值为 ，这意味着接受主消息而不创建卷影副本。 如果此参数 $true 的值为 ，则主消息被拒绝并出现暂时性错误 451 4.4.0。

如果已成功创建邮件的卷影副本，但发送服务器与主服务器之间的 SMTP 会话超时，则主服务器将接受并处理主消息。 发送服务器将重新传递未确认的邮件，但重复邮件检测将阻止 Exchange 邮箱用户看到重复邮件。 当发送服务器重新提交消息时，主服务器将创建消息的另一个卷影副本。 发送服务器在重新提交消息期间创建的影子消息之间没有关系。

下表介绍控制卷影邮件创建的参数

Source 默认值 描述
Set-TransportConfig 上的 ShadowMessagePreferenceSetting PreferRemote 仅当尝试创建邮件卷影副本的主服务器是跨多个 Active Directory 站点的 DAG 的成员时，才使用此参数。
  • PreferRemote：根据 MaxRetriesForRemoteSiteShadow 参数指定的尝试次数，尝试在不同的 Active Directory 站点中的 DAG 成员上创建邮件的卷影副本。 如果操作失败，请尝试根据 MaxRetriesForLocalSiteShadow 参数指定的尝试次数，在本地 Active Directory 站点的 DAG 成员上创建消息的卷影副本。
  • LocalOnly：根据 MaxRetriesForLocalSiteShadow 参数指定的尝试次数，尝试仅在本地 Active Directory 站点的 DAG 成员上创建邮件的卷影副本。
  • RemoteOnly：根据 MaxRetriesForRemoteSiteShadow 参数指定的尝试次数，尝试仅在其他 Active Directory 站点中的 DAG 成员上创建邮件的卷影副本。
Set-TransportConfig 上的 MaxRetriesForRemoteSiteShadow 4 此参数指定当 ShadowMessagePreferenceSetting 参数 PreferRemote 的值 (默认值) 或 RemoteOnly时，在 DAG 中另一台服务器上创建邮件卷影副本的最大尝试次数。

仅当邮箱服务器是跨多个 Active Directory 站点的 DAG 的成员时，才使用此参数。

如果在指定的尝试次数后未成功创建邮件的卷影副本，则结果取决于 RejectMessageOnShadowFailure 参数的值：

  • $true：主消息被拒绝并出现暂时性错误。
  • $false：仍然接受主消息，但不会冗余地持久保存。
Set-TransportConfig 上的 MaxRetriesForLocalSiteShadow 2 此参数指定在本地 Active Directory 站点的另一个邮箱服务器上创建邮件卷影副本的最大尝试次数：
  • 邮箱服务器是跨多个 Active Directory 站点的 DAG 的成员， ShadowMessagePreferenceSetting 参数 PreferRemote 的值 (默认值) 或 LocalOnly。
  • 邮箱服务器是位于一个 Active Directory 站点中的 DAG 的成员。
  • 邮箱服务器不是 DAG 的成员。

如果在指定的尝试次数后未成功创建邮件的卷影副本，则结果取决于 RejectMessageOnShadowFailure 参数的值：

  • $true：主消息被拒绝并出现暂时性错误。
  • $false：仍然接受主消息，但不会冗余地持久保存。
Set-ReceiveConnector 上的 ConnectionInactivityTimeout 邮箱服务器上的传输服务中的接收连接器的 5 分钟 此参数指定在关闭连接之前，与源消息传送服务器的打开 SMTP 连接可以保持空闲的最长时间。 此参数的值必须大于 ConnectionTimeout 参数的值。
Set-ReceiveConnector 上的 ConnectionTimeout 邮箱服务器上的传输服务中的接收连接器的 10 分钟 此参数指定与源消息传送服务器的 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 命令来确定主消息的丢弃状态。 否则，影子服务器将在 set-TransportConfig cmdlet 上的 ShadowHeartbeatFrequency 参数 (预配置的时间间隔后自动打开与主服务器的 SMTP 会话;默认值为 2 分钟) 。

在卷影服务器与主服务器打开 SMTP 会话后，主服务器将响应适用于查询影子服务器的消息 的放弃通知 。 放弃通知存储在磁盘上， (不在内存中，) 因此，如果 Microsoft Exchange 传输服务重新启动，放弃通知将保留。 服务启动后，主服务器仍知道已成功处理的消息，并且该信息可供影子服务器使用。

影子服务器与主服务器之间的 SMTP 通信用作确定服务器可用性的 检测信号 。 如果影子服务器在预先配置的时间间隔后无法打开与主服务器的 SMTP 会话， (Set-TransportConfig cmdlet 上的 ShadowResubmitTimeSpan 参数;默认值为 3 小时，) 影子服务器将自身提升为主服务器，将影子消息提升为主消息，并将消息传输到下一跃点。 但是，每当影子服务器检测到主服务器的队列数据库 ID 已更改时，影子服务器也会将自身提升为主服务器，将影子消息提升为主消息，并将消息传输到下一跃点。 这可能在 ShadowResubmitTimeSpan 参数值传递之前发生。

卷影冗余管理器 是邮箱服务器上负责管理卷影冗余的核心组件。 影子冗余管理器负责维护服务器当前正在处理的所有主消息的以下信息：

  • 正在处理的每个主消息的影子服务器。

  • 卷影冗余管理器负责卷影服务器在其卷影队列中包含的所有卷影邮件的下列内容：

影子冗余管理器负责对影子服务器在其影子队列中的所有影子消息执行以下操作：

  • 比较存储邮件主副本的队列数据库的原始数据库 ID 和当前数据库 ID。

  • 核查每个主服务器是否可以对卷影邮件进行排队。

  • 处理来自主服务器的丢弃通知。

  • 在收到所有预期的丢弃通知之后将卷影邮件从卷影队列中删除。

  • 决定卷影服务器何时应该取得卷影邮件的所有权，从而成为主服务器。

  • 跟踪邮件分流和其他副作用邮件（如传递状态通知 (DSN) 和日志报告），以验证在邮件的所有支流得到全面处理之前不会发布邮件的冗余备份。

  • 跟踪消息分叉和其他副作用消息（如传递状态通知）， (也称为 DSN、未送达报告、NDR或退回邮件) 和日记报告，以验证邮件的冗余副本在完全处理完邮件的所有分支之前是否未发布。

下表描述了控制如何维护影子消息的参数。

参数 默认值 描述
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.

请注意，如果发现主服务器的队列数据库具有不同的数据库 ID，则影子服务器还可以在此参数的值之前将自身提升为主服务器。
Set-TransportConfig 上的 ShadowMessageAutoDiscardInterval 2 天 How long a server retains discard events for successfully delivered messages. 主服务器将放弃事件排队，直到影子服务器查询它。 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 cmdlet 上的 SafetyNetHoldTime 和 MessageExpirationTimeout 参数值的总和之后从安全网过期。
Set-TransportService 上的 MessageExpirationTimeout 2 天 How long a message can remain in a queue before it expires.

Message processing after an outage

下表总结了影子冗余如何最大程度地减少因服务器中断而导致的消息丢失。 为清楚起见，发生中断的服务器名为 Mailbox01。

执行的操作 Mailbox01 会使用新的数据库重新联机。
默认情况下，在 ShadowResubmitTimeSpan 参数的值传递 (（) 3 小时）之前，Mailbox01 与新的队列数据库重新联机。

当队列数据库由于数据损坏或硬件故障而无法恢复时，可能会出现这种情况。

 在 Mailbox01 上检测到新的队列数据库 ID 时，每个为 Mailbox01 排队的影子邮件的服务器都将承担这些邮件的所有权并重新提交它们。 然后，消息将传递到其目标。

检测到新队列数据库后，消息提交的最大延迟是 默认为 ShadowHeartbeatFrequency 参数 (的值，) 2 分钟。
默认情况下， 当 ShadowResubmitTimeSpan 参数的值传递 (（) 3 小时）后，Mailbox01 将使用相同的数据库重新联机。

这种情况可能发生在网卡故障或服务器上耗时的维护之后。

 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. 但是，其他邮件系统上的收件人可能会看到重复的邮件副本。

消息提交的最大延迟是 ShadowResubmitTimeSpan 参数的值。