微软公司针对Exchange Server 2010在一些底层数据结构上作了一些主要的变更，而这些显著的变更会对后续的针对Exchange Server 2010的存储需求和部署带来较大的影响。

微软所作的最大的变更则是去掉了单一实例存储（single-instance storage，SIS）。在之前的版本中，如果一条消息被转发给多个收件人，那么只有这条消息的一份副本会被存储到mailbox数据库中。用户将会收到针对这份单一副本的一个指针而不是这个副本的完全拷贝。

那么，既然微软取消了对单一实例存储的支持，也就意味着同样的消息会被发送给多个收件人，每个收件人都会受到一份实体消息副本。从存储空间规划角度来看，这个巨大变更对规划的影响，主要取决于带有附件的邮件的数量了。

文本或者HTML格式的消息一般都是非常小的，所以它们对存储空间规划的影响不会很大，而且微软针对这些消息都会有自动压缩机制以进一步降低影响。然而，如果你的环境中总是有用户不断的发送带有大附件的邮件给多个收件人的话，那么这些邮件就会对数据库的增量产生较大影响。微软这次重新设计数据库底层架构的目标就是为了降低数据库的I/O负载续期。所以，微软这次选择了不对邮件附件进行压缩，以便节省压缩/解压缩过程中对存储I/O的额外耗费。

看起来可能有些奇怪，曾几何时，存储管理领域在大肆搞数据缩减，比如重复数据删除等，但是为何微软这次却在Exchange Server 2010中去掉了数据缩减功能。因为微软如果针对Exchange邮箱数据库放弃使用单一实例存储的话，那么数据库会运作的更加高效，微软宣称，Exchange Server 2010的数据库I/O负载需求已经有了大概70%的降低。

另外一种经常使用的能够保持Exchange Server 2010邮箱数据库不至于变得太大的办法就是使用邮箱限额。邮箱限额功能可以防止某邮箱的尺寸超过预设的大小。在Exchange Server 2010中，邮箱限额的功能与之前的版本几乎都一致，除了一点之外。Exchange Server 2010引入了一个叫做归档邮箱的概念（我们稍后讨论）。如果某个用户拥有一个归档邮箱，那么邮箱限额在计算这个用户到底使用了多少底层空间的时候，并不将归档邮箱的内容尺寸算在里面。Exchange同时也允许你通过额外的限额配置来专门针对归档邮箱做限额。

邮箱限额这个功能是一个被充分证明很有效的用于限制数据存储过快被占用的方法。但是微软一直在鼓励企业使用低成本的存储系统而不是用邮箱限额来节省成本。其出发点是企业可以在保证邮箱数据不断增长的前提下，避免花费太多成本在昂贵的存储系统和解决方案上。

之所以推荐使用低成本的存储系统，并不只是基于单纯存储的成本考虑的。很多企业被迫对邮箱设置非常严格限额策略，以至于对应的邮箱用户不得不将一些重要的邮件也删除掉。显然，如果使用廉价的存储系统，那么企业就可以放开设置邮箱限额，甚至根本不适用限额了。

之前，在Exchange Server环境中使用最低端的廉价存储系统好像是一件前所未闻的事情，但是本次Exchange Server 2010中对I/O负载需求的降低使得诸如SATA硬盘这种存储选项变得可以接受了。而且Exchange Server 2010对底层可使用存储的要求已经非常灵活了，它可以使用直连存储（direct-attached storage，DAS）或者存储区域网络SAN设备，甚至也可以使用经由iSCSI协议连接的存储。然而，微软在Exchange Server方面却并不支持那种必须映射成一个网络盘符才可以存取数据的存储，比如NAS。所以，Exchange Server并不支持在NAS中存储邮箱数据库，除非这台NAS支持使用iSCSI协议访问。

额外的考虑

虽然地段存储系统也可以提供足够的性能，但是依然有必要选择一台能够同时满足企业可靠性需求的存储系统。比如，如果你选用了基于SATA硬盘的存储系统，那么你最好创建一个具有较高容错性的SATA Raid组。微软推荐使用基于RAID10模式的Raid。某些企业也选择使用Raid5，因为Raid5相比Raid10来讲更加廉价经济，而且仍然能够提供容错性，但是通常认为Raid10能够提供更好的性能。

数据库的大小对性能没有直接的影响。通常来讲，一台单独的邮箱服务器上的邮箱数据库的大小应该被限制在200GB或者更少。如果某个邮箱数据库增长到大于200GB了，此时你可以将数据库分割为多个更小的数据库。对于Database Availability Group中的邮箱数据库，推荐的最大数据库尺寸为2TB。

判断存储需求

在一个Exchange Server 2010的部署环境中，判断出准确的存储需求是个不小的工作，但是微软提供了一个免费的工具可以用来协助你完成这项任务。Exchange 2010 Mailbox Server Role Requirements Calculator (http://msexchangeteam.com/files/12/attachments/entry453145.aspx)是一个Excel扩展表，它可以根据你的企业对Exchange的使用情况来判断Exchange Server对存储的需求。

使用Exchange 2010 Mailbox Server Role Requirements Calculator 时，你只需回答一系列如Exchange Server的配置和使用情况相关的问题，要填入一系列的表格单元值即可完成。例如，表格中会问你平均每份邮件的大小以及每天用户可能发送的邮件数量等问题。表格中内置的脚本会根据你所回答问题的答案来自动计算出存储的各方面需求。

但是要注意一点，虽然Exchange 2010 Mailbox Server Role Requirements Calculator可能是用来预估Exchange邮箱服务器对存储需求的最好的工具，但是它的一些推荐页仅仅是根据你所提供的数据所计算出的，所以它的准确性完全依赖于你所提供的数据的准确性。为了保险起见，微软推荐提供足够的磁盘空间，至少是所计算出的所需空间的120%。

Exchange归档邮箱

在影响Exchange Server存储规划的因素中，还有一些其他需要考虑的，比如你是否需要实施用户归档邮箱，这是Exchange Server提供的一个新的，而且是可选的功能。用户归档邮箱相对于主邮箱来讲属于一种二级邮箱，它专门用于存放一些长期不了浏览的邮件。归档邮箱与Exchange归档模式之间的区别是，前者不是一种传统的归档，比如日志邮箱，而是用户依然拥有归档邮箱中的邮件。所以，用户的归档邮箱也是随时可以被访问的。

归档邮箱是被设计用来替换PST文件的。但是并不像PST文件，归档邮箱会被存储在可被管理员管理的邮箱数据库中。

在一开始的Exchange 2010 RTM版本中，用户归档邮箱与用户的主邮箱是一同被存储在相同的邮箱数据库中的。在SP1版本中，微软提供了选项，可以将用户归档邮箱重定向存储到一个单独的邮箱数据库中，从而可以让针对归档邮箱的访问I/O卸载到其他存储空间，从而防止对主邮箱访问的影响。

微软通常会推荐将用户归档邮箱存储在低端的服务器上以及低端的直连模式的存储中，比如SATA硬盘阵列。要记住的是，一个只存储归档邮箱的邮箱数据库对I/O负载的需求根本不像存储有用户主邮箱的邮箱数据库要求的那样高。针对归档邮箱数据库使用低端存储的另一个好处就是这样做可以针对归档邮箱设置比较宽松的限额。

对日志邮箱的误解

需要考虑的另外一个问题就是日志邮箱。如果你在Exchange的hub transport情况下使用日志方式来归档邮件的话，那么所有的归档邮件都会被放入日志邮箱了。

我个人从没看到过任何微软发布的如何放置日志邮箱的最佳实践，但是我倾向于将日志邮箱就放到它自己的邮箱数据库中。这是因为日志过程是一个对I/O要求比较高的处理过程，将日志邮箱放到它自身的邮箱数据库中可以确保能够获得足够的I/O性能，并且不会影响其他的邮箱数据库。如果所有邮件都被推入了日志，那么在访问日志邮箱的时候，由于日志邮箱与用户主邮箱都处于同一个邮箱数据库中，所以这时的I/O负载需求就会加倍，因为Exchange 2010已经不支持单一实例存储了。也就是说，使用了日志邮箱之后，所有的邮件都会在同一个邮箱数据库中被复制一份存放。

如果你真的在与用户主邮箱相同的邮箱数据库中创建了日志邮箱，那么可能会对数据的复制过程产生一定的影响。

如果将日志邮箱存储在与用户主邮箱不同的单独的邮箱数据库中，这样做的一个优势就是可以让管理存储限额和保留周期变得更容易。你可以针对用户主邮箱创建一套策略，而针对日志邮箱则可以根据需求再创建另一套策略。

Discovery邮箱

在规划Exchange Server 2010存储时，最后一种需要考虑的邮箱类型就是discovery邮箱了。Discovery邮箱的唯一用途是用于做多邮箱联动搜索（比如电子发现过程）。搜索的结果就会被存储到discovery邮箱中。

默认情况下，discovery邮箱会被分配给50GB的限额。这看起来是挺大，但是在一个较大的企业中，如果真的做起电子发现过程，那么这个数值就显得非常小了。

当要考虑将discovery邮箱的存储规划时，一般情况下容量比性能更加重要。虽然电子发现过程对I/O负载要求是很高的，但是这些I/O会被分摊在存储用户邮箱的邮箱数据库以及存储discovery邮箱的的数据库上。

如果你将来不需要实施电子发现，那么你根本就可以不创建discovery邮箱，直到你什么时候需要时，现用现创建即可。如果你必须前期创建discovery邮箱，那么你最好将它放到一个底层使用大容量低端存储系统的邮箱数据库中。

结论

显然，在规划Exchange Server存储架构时，有非常多的东西需要考虑，虽然Exchange 2010并不像之前版本那样对I/O性能有较高要求，但是I/O性能依然是设计过程中所要首先考虑的。还有一些其他要考虑的，比如容量以及容错等，这里就不展开讲了。

相关链接1：Exchange Server的归档和电子发现功能会取代第三方产品么？

在Exchange Server 2010版本发布之前，第三方针对Exchange Server有一个完整的归档和电子发现产业链。而如今Exchange Server 2010自身就提供了原生的用户归档以及内建的电子发现支持。那就非常自然的让人有所联想，Exchange Server 2010内建的电子发现功能是否会取代原来的第三方产品呢？

Exchange 2010内置的电子发现和归档功能或许对一些小企业来讲已经足够了，但是对于大企业来讲却显得并不是非常专业，因为Exchange 2010内置的归档和电子发现在功能等方面确实相比第三方专业产品来讲还是有一些限制和不足的。

例如，Exchange 2010的归档邮箱并不是一种纯归档解决方案。归档邮箱允许用户将重要的邮件转到二级邮箱，二级邮箱并不受严格的保留期限约束以及存储空间限额。但是如果你依然想做纯归档方案的话，你就必须使用Exchange的日志特性了。日志方式是可以工作，但是第三方的归档产品可以提供对邮件归档的更好的控制能力、保留期限以及其他处理过程。

对于Exchange2010的多邮箱联动电子发现搜索特性来讲，情况也是一样的。多邮箱联动搜索有很多限制，比如，仅支持Exchange 2010的邮箱，一旦遇到之前版本的Exchange或者PST文件，那么你就必须要使用第三方产品了。

Exchange 2010内置的多邮箱归档功能也缺乏一些多样的报表选项，以及缺乏导出功能等，而这些功能一般在第三方专业产品中都是标配。

相关链接2：保护Exchange的数据

Exchange Server的数据通常比较难于对其实施保护。如果你打算做一个每晚的数据备份，那么一个很小的错误就可能导致一整天的邮件丢失。对于大多数公司来讲，这种损失是不可接受的。

Exchange的管理员会有多种不同的方法和步骤来防止潜在的数据丢失。在Exchange 2007中，例如，采用连续的数据复制从而将邮箱数据复制到另一台邮箱服务器就被认为是一种很好的而且经常使用的方式。连续的数据复制解决方案可以提供数据的容错性同时也可以作为一种除了备份之外的数据保护方式。当然，使用诸如System Center Data Protection Manager这种数据连续复制保护方案也是一种很好的选择。

一些分析者认为微软正在致力于彻底让Exchange Server的数据不再需要备份，比如使用Database Availability Groups特性，从而让Exchange足够强大而根本不用备份。

Database Availability Groups是Exchange Server 2010中的一个特性，它可以让你创建最高16份针对邮箱数据库的备份副本。这些副本被存放在其他的邮箱服务器上，不仅如此，甚至还可以将数据副本创建在其他数据中心里。虽然现在针对Database Availability Groups是否真的可以保护邮箱数据方面有很大的争论，不管怎么样，你还是不要放弃传统的备份。

针对每个数据库都有多份备份副本会对于保护Exchange Server的数据变得更加容易，但是如果一旦一个邮箱数据库损坏或者中了病毒等，也就是发生逻辑错误，那么同样的逻辑损毁或者病毒均被被体现在其他副本中，因为他们之间是完全同步的。

但是微软也确实提供了一种延后的数据回放特性，其中，一些数据尚未完全同步的服务器被用来放置这些有害的数据操作被同步的提交到副本数据中。如果一旦发现数据除了问题，那么由于数据的复制是延后的，所以此时你就有足够时间来阻止这些有害数据被同步到副本数据中。经过这种处理方式，在发生问题之后你就可以使用未经损毁的数据来回到之前完好的状态了。

虽然这个方法在理论上看起来很牛，但是如果真想将其做成产品，还需要很多工作要做。当前，这个方法所涉及的一些步骤，都需要接受特殊的培训课程，其中会告诉你哪笔交易日志含有受损的第一个数据位，然后你需要人工操作一些很复杂的步骤来裁剪日志文件。所以，虽然Exchange 2010的存储架构可以通过使用Database Availability Groups来让数据保护变得更容易，但是并不要将其视作保护Exchange Server数据的唯一办法。

本文选自存储经理人2011年4月刊：虚拟环境下的灾难恢复，请下载并阅读PDF版本。