Exchange 2010邮件可靠性策略

　在Exchange Server 2010中引入了一种称为Shadow Redundancy(影子冗余)的新概念。此功能提供了整个传递过程中的冗余信息，如果想删除一个带有影子冗余的在HUB服务器上或者Edge服务器上的ESE 基础的消息队列 (mail.que)，则操作会延时到验证完所有的HOPS信息都已经通过，否则就会报错并重新投递，同时传输转储也得到了极大地提高。

　　Shadow Redundancy的优点：

　　他不再依赖于中心或边缘服务器，他只存在于服务器拓扑结构中，任何服务器都可以被支配。

　　如果一个服务器传输失败，你可以简单的移除，不用担心空队列或者信息丢失。

　　如果你想对一台Hub服务器或者Edge服务器进行升级，你可以随时让他脱机，而不用担心信息丢失的问题。

　　不再对存储服务器的硬件冗余有需求

　　相较于在各种服务器上保存副本，Shadow Redundancy占用更少的带宽。唯一的额外消耗是在Exchange服务不使用的传输服务器间，传输服务器来维护这种状态的信息。

　　提供了更有弹性的和简化的从故障中的恢复方式。

　　                                     图 Shadow Redundancy工作原理示意

　　A. MAPI/WindowsMobile终端客户提交邮件。

　　B. 邮件服务器向Hub服务器传输信息。

　　C. 一条信息从Hub服务器返回给邮件服务器。

　　D. 邮件在Exchange服务器和Hub服务器间做传递。

　　E. 邮件从Exchange2010服务器向不支持影子冗余的服务器传递。

　　F. 邮件从不支持影子冗余的服务器向Exchange2010服务器传递。

　　蓝色线表示使用了Shadow Redundancy功能。绿色线表示使用了Transport Dumpster功能。紫色线表示延时的SMTP确认通知。红色线表示没有附加冗余信息。
　中心服务器投递邮件给边缘服务器的过程：

　　Hub开启edge的Smtp Session

　　Edge说我支持Shadow Redundancy

　　Hub说Edge你测试一下Discard Status

　　Hub投递邮件给Edge

　　Edge拿到邮件就查一下该邮件的收件人，Hub记录，以便发送该邮件的Discard 信息

　　Hub将该邮件移到Shadow队列中，并标记Edge是该邮件的主服务器，而Hub则是Shadow服务器

　　Edge服务器投递给给终端节点的过程：

　　Edge投递邮件给下一节点服务器

　　下一节点服务器获取该邮件的收信人信息

　　Edge标记该邮件的Discard Status为投递完成

　　Hub向Edge查询Discard Status(与Edge连接成功)

　　当与Edge 的Smtp Session终止前，Hub会向Edge查询上次头肩偷心的Sidcard Status。如果很久都没有Smtp Session连接，Hub也会在等待一个设定的时间后开启一个Smtp Session找Edge查询状态。

　　Edge检查本地的Discard Status ，然后告诉Hub一份已投递邮件列表，并一处Discard信息

　　Hub拿到已投递邮件列表后，从Shardow Queue中删除这些邮件

　　Hub向Edge查询Discard Status，然后重发邮件(与Edge连接失败)

　　hub如果连不到edge，就将自己升为主服务器，并重新投递shadow 队列中的邮件

　　重新投递的邮件会发往另外一台edge上，并重新开始投递过程。

　　但是考虑到Exchange 2010与其他服务器的共存环境，过程会变成这样

　　Hub与不支持Shadow Redundancy的服务器连接

　　Hub连到该服务器

　　该服务器说，我不支持Shadow Redundancy

　　投递邮件到该服务器

　　srm标记该邮件已经投递给下一结点

　　当邮件全部投递给下一结点后，邮件被删除

　　不支持Shadow Redundancy的服务器与hub连接

　　发信服务器连接到Hub

　　Hub说我支持Shadow Redundancy

　　发信服务器不屌这条回应，继续投递邮件

　　Exchange拿到邮件就投递给下一结点或者创建一份Shadow Copy

　　返回发信服务器相关的信息