NetApp Tech OnTap

充分利用 Exchange 2007 复制

SP1 的最佳实践

大约一年以前,我曾撰写一篇在 Tech OnTap 中刊发的文章 讨论 Microsoft® Exchange Server 2007 的最新复制功能和其它诸多事项。最近发布的 Exchange 2007 Service Pack 1 (SP1) 不仅针对我所谈到的功能提供错误修复和功能增强,而且它还包括实实在在的新功能,并且它还影响您设计用于 Exchange 的 NetApp® 存储的体系结构。本文是对存储具有极大影响的变更以及为设计 Exchange 存储而重新测试最佳实践的概述。有关这些主题的详细信息,请参阅我最近的技术报告《Microsoft Exchange 2007 SP1 连续复制的最佳实践指南 》。

重要的增强功能和新功能

在 Exchange 2007 SP1 的许多改进中,有五点肯定是您应该知道的。

SP1 是 Exchange 2007 唯一支持 Windows® Server 2008 的版本。SP1 仍然支持 Windows Server 2003。

SP1 提供一种复制新风格,备用连续复制 — SCR。SCR 让您可以分隔高可用性和站点弹性功能,并让您创建许多新的冗余情况。它可以配置为与任何类型的 Exchange 服务器一起使用,只要没有将它还配置用于本地连续复制。(您也不能在目标 SCR 服务器上使用 LCR。)对于每个存储组,您可以具有多个 SCR 对象。例如,您可能具有一个本地副本和一个远程副本。您还可以配置一个 SCR 服务器,作为多个源服务器的目标。

为使存储更为有效,SP1 完全重新设计了复制目标上存储的使用方式。所有复制目标上的 I/O(LCR、CCR 和 SCR)从 Exchange 2007 最初发布的水平显著减少。以前,在复制目标上数据库 I/O 可能比其在源数据库上的 I/O 多 200% 至 300%。在 SP1 中,目标数据库 I/O 现在要比源数据库少 78%。在 SP1 中,目标日志的 I/O 也已减少。

联机碎片整理的积极程度得以降低并获得监控。您现在可以查看完成碎片整理花费的时间以及完全的整理数据库碎片的频率。您可以使用此信息来调整联机维护时间,从而减少影响 Snapshot™ 空间占用的磁盘改动。

数据库扫描现在可以在联机维护时执行,以检查是否损坏。在 SP1 之前,在不脱机的情况下确保数据库没有损坏的唯一方法是执行联机流备份,强制读取并验证数据库中的每页。这也是按许多安全方案中的要求将已删除文件强制清零的唯一方法。如果您一直在副本而不是在活动数据库上执行 VSS 备份,这可能意味着您的生产数据库从未经过完全验证。

在实践中,NetApp 和 Microsoft 都建议使用 Visual SourceSafe® (VSS) 进行备份。备份应用程序会验证备份数据,但是在实际数据上绝不会再次真正运行检查。那将在不知不觉中累积微小但是真实的数据库损坏危险。

在具有 SP1 的 Exchange 服务器的注册表中启用之后,数据库扫描和页面清零会每天在联机维护时间运行,以验证活动数据库并清零已删除的页面。

最佳实践

在这点上,您可能会说,“那太好了,但是我如何才能在自己的 NetApp 环境中利用这些新功能的优势呢?”

Windows Server 2008。如果想要自己的 Exchange 服务器运行最新的操作系统,您就必需在运行 Windows 2008 的新服务器上安装 SP1;升级运行中的服务器的操作系统是不支持的。您不必在安装 SP1 之前安装 Exchange 2007;服务包中已包含一切。

不论何种操作系统,我建议都升级到 SP1,从而获得对存储影响很大的错误修复和增强功能。

LUN 复制配置。Microsoft 建议的最佳实践是为每个副本的源端和目标端提供相同的 LUN 配置 — 您自然而然会在单独的存储系统上分别安装源 LUN 和目标 LUN。介于最初发布的 Exchange 2007 对目标服务器造成的高 I/O 负载,我们过去常常推荐您为每个集群节点配置单独的日志和数据库聚合。如果存储系统支持多个复制服务器(源和/或目标),它需要许多独立的聚合。

随着 SP1 中 I/O 负载的减少,这样的要求将不复存在。我们还建议您在单独聚合中分别保留日志和数据库(并且仍应保持源存储和目标存储分离),但是您现在可以将来自分离群集的多个数据库分组到单个聚合,这同样适用于日志。这将消除存储“孤岛”,简化存储配置并且还可以提高利用率。

CCR 群集

图 1) 用 Exchange 2007 SP1 进行的 LUN 副本配置。与过去需要 12 个聚合相比,现在总共需要 4 个的聚合,源存储系统和目标存储系统均采用 1 个聚合用于数据库,1 个聚合用于日志(每个系统上 2 个)。

联机碎片整理。碎片整理对 NetApp Snapshot 副本必须保留的块数量具有很大的影响。碎片整理过程会更改块,并且 NetApp Snapshot 副本会通过保留更改的块来保持稳定的时间点映像。因此,您通过碎片整理更改的块越多,您就需要更多的空间来存储 Snapshot 副本。

这就是新指标出现的原因。Microsoft 建议碎片整理应在 14 天内完成,因此如果您检查指标并发现碎片整理很快完成,您就可以缩短每日联机维护时间以减少每日磁盘改动的数量,这进而将减少 Snapshot 的空间占用。

为了更精确,可以记录两种性能计数器以确定您的联机碎片整理趋势:

  • MSExchange 数据库 ==> 实例\释放的联机碎片整理页/秒
  • MSExchange 数据库 ==> 实例\读取的联机碎片整理页/秒
如果读取页与释放页之间的比率大于 100 比 1,则减少联机维护时间。如果读取页与释放的比率低于 50 比 1,则增加联机维护时间。

数据库扫描和页面清零。默认情况下,数据库扫描处于开启或关闭状态。如果开启,扫描会在每晚的联机维护时间内运行。这没什么问题,但是您必须问自己是否您真的需要如此频繁地验证数据库,因为实际上扫描会逐块读取整个数据库。这自然会在存储系统上产生许多额外的负载。

如果页面清零对您而言并非至关重要并且您具有 NetApp SnapManager® for Exchange,则可以采用替代方法,配置不截短日志的每周副本备份。这将检查损坏并验证您的活动数据库。您可以在工作量较轻时利用周末来安排日程。

如果您一定需要页面清零,则每晚运行数据库扫描是确保其发生的最佳方式。注意,如果数据库没有从开始即启用页面清零,则在数据库首次运行时,它会造成一个极高的 I/O 负载。要减少首次页面清零的影响,您可以启用限制。

 

充分利用 Exchange 2007 SP1

Exchange 2007 SP1 提供很多增强功能和新功能,以致于它几乎类似于 Exchange 的一次最新发布。通过留意最佳实践,您可以充分利用 Exchange 安装和 NetApp 存储。这里有当前针对 Exchange 2007 SP1 的 NetApp 最佳实践建议的摘要。

LUN 配置和复制
  • 在单独的存储系统上隔离活动和目标服务器存储。
  • 根据容量和性能,将活动 LUN 和目标 LUN 配置为一样。
  • 在它们各自的聚合中分隔日志和数据库。
  • 为每个存储组创建单独的 NetApp FlexVol® 卷。
  • 使用 NetApp RAID-DP® 以获得最佳性能和保护。
  • 在目标节点上运行 SnapManager for Exchange 备份并调整活动节点上的联机维护时间。
  • 在复制 Exchange 数据库、日志和中心传输数据时,不妨考虑 NetApp ReplicatorX™ 和/或 SnapMirror® 以获得少于 5 分钟的 RPO。
碎片整理和数据库扫描
  • 如果在两周内完成整个过程并且读取与释放的比率大于 100 比 1,则减少联机维护时间。
  • 与联机数据库扫描相比,不妨考虑使用副本备份(这样不截短日志)以及校验和完整性来验证数据库状况。
Robert Quimbey

Robert Quimbey
NetApp 的 Microsoft 联盟工程师


Robert 在 Microsoft Exchange 产品团队负责存储和高可用性工作长达 8 年,此后他于 2007 年加入 NetApp。自从加入 NetApp 以来,他的活动一直围绕 Exchange 2007,包括设计最佳实践和群集连续复制 (CCR) I/O 的深入分析。他最近工作的努力方向是 Exchange 参考体系结构的创建。

了解