将卷影复制服务与 Exchange Server 2003 配合使用的最佳实践

 

上一次修改主题: 2005-10-18

Microsoft® Exchange Server 2003 使用包含在 Microsoft Windows Server™ 2003 操作系统中的卷影复制服务 (VSS) 生成 Exchange Server 2003 数据库和事务日志文件的卷影复本。 无论数据库大小,都可以使用 VSS 在几分钟之内还原它们。 这种快速还原能力主要取决于 VSS 解决方案的提供程序组件的功能。

由于有许多不同的 VSS 策略可用,因此必须了解和测试这些解决方案的功能、性能和恢复情况,以确保拥有成功部署所需的数据。 还必须确保任何潜在的解决方案在 VSS 框架中都是可操作的。 本文提供了有关为 Exchange Server 2003 选择、测试、部署和监视 VSS 解决方案的信息。

VSS 是一组用于实施架构的 COM API,该架构能够在备份卷的同时让系统上的应用程序继续写入卷。 “请求程序”、“编写器”和“提供程序”在 VSS 框架中相互通信,以创建和还原“卷影副本”。 卷影副本可及时复制某一指定时刻的卷中的所有数据。

备份过程包括以下步骤:

  1. 请求程序启动备份过程。 请求程序会指示编写器准备用于备份的数据集。
  2. 编写器准备用于备份的数据。 Exchange Server 2003 和其他应用程序会根据编辑器应用程序的特定要求执行准备数据的编写器。 数据集准备好后,编写器发信号通知请求程序备份数据集。
  3. 提供程序与磁盘系统交互并管理卷影副本。 接到请求程序的指示时,提供程序会创建卷影副本。
  4. 请求程序发信号通知编写器备份过程是成功还是失败,并完成备份过程。

VSS 框架通过将请求程序、编写器和提供程序的功能进行分离,使这些组件之间相互独立。 一个请求程序能够与不同的提供程序或多个编写器交互。 有关请求程序、编写器和提供程序的详细信息,请参阅 Basic VSS Concepts(英文网页)。

Exchange 编写器随 Exchange Server 2003 自动安装。仅当 Exchange Server 2003 安装在 Windows Server 2003 操作系统上时请求程序才能访问 Exchange 编写器。 如果 Exchange Server 2003 安装在 Microsoft Windows® 2000 Server 上,则不能对 Exchange Server 2003 执行 VSS 备份。

Exchange 编写器在接到请求程序发出的这种指令时,会为备份准备 Exchange 数据库。 编写器通过暂停对数据库的所有磁盘写入 I/O 多达 20 秒来完成准备工作。 此暂停操作也称为“冻结”数据库。 提供程序必须能够在此窗口中完成卷影复制操作,否则,备份过程将被中止。 备份完成后,编写器将“解冻”数据库并恢复正常的 I/O 操作。

note注意:
Windows Server 2003 的 Windows 备份能够使用默认的基于软件的 Windows VSS 提供程序对磁盘卷和文件执行普通的 VSS 备份。 但是,Windows 备份不能与 Exchange 编写器进行通信,因此也不应用于对 Exchange 数据库文件进行 VSS 备份。 多个非 Microsoft 备份应用程序可实现与 Exchange 编写器一起使用的请求程序。

提供程序能够以多种不同的方式执行卷影复制请求。 尽管 Exchange 编写器不知道提供程序如何创建卷影副本,但是请确保您了解解决方案提供程序的工作原理,以便能够对性能和容量做出规划。 尽管对卷影副本备份方法没有行业标准定义或命名约定,但是大多数备份方法大致分为两类:即克隆卷影副本和快照卷影副本。

“克隆”卷影副本是对卷影副本集中的卷的完整拷贝。 “卷影副本集”是一组在同一时间点同步的卷影副本。

与普通副本一样,克隆副本独立于原始数据。 即使所有原始数据都丢失,克隆副本仍保持完好无损。 它不同于快照卷影副本,后者并不完全独立于原始数据。 有关快照的详细信息,请参阅本文稍后部分中的“快照卷影副本”。

使用克隆备份方法时必须考虑容量规划。 为了确保如果在备份期间出现故障有可还原的副本,必须使用 N+1 方案,其中 N 是在任何时候都可以还原的备份克隆的数量。 例如,如果决定只进行一次备份,但仍需要 2 个 (1+1) 目标克隆来轮换使用,以防在备份期间发生故障导致数据丢失。

  • 提供程序供应商决定某个解决方案如何实现以特定方式创建克隆卷影副本。

镜像 某些解决方案预先准备了镜像副本。 然后,这些镜像副本被拆分以进行备份,从而为您提供一个只读副本和一个实时生产卷。 该策略在备份和校验和完整性验证过程中对生产逻辑单元号 (LUN) 几乎没有影响。 但是,它会在备份前对生产 LUN 造成明显的 I/O 负载。

必须确保在轮换多个克隆卷影副本时,安排时间将不再需要的克隆重新同步到生产 LUN。 对于还原,此解决方案可能会将只读副本重新同步到生产 LUN,这样可能会在复制完所有数据之前,对使用同一生产 LUN 的所有其他联机存储组产生影响。 在还原期间,某些存储阵列仅更改指向只读副本的指针。 从而使只读副本可写。

克隆 某些解决方案在备份时创建克隆,其中 LUN 中的所有数据都必须复制到另一个 LUN 中。 然后这些数据被标记为只读。 此策略在开始时消耗的容量较少,但是要求在备份时复制所有的数据。 使用此策略时,除了要知道复制期间对生产数据库 LUN 的影响之外,还必须知道特定存储控制器每小时能够传输的字节数(以 GB 为单位)。 这样可使您能够正确设计 LUN 以获取最大的吞吐量,并规划此操作的时间,从而最大程度地减少对生产 LUN 的影响。

克隆卷影副本和快照卷影副本之间最重要的区别是:快照卷影副本并不完全独立于原始数据。 通常,快照卷影副本是通过在某个时间点定义一个标记,并确保数据能够回滚到该时点来创建的。 可以同时保留多个快照,并且快照通常比克隆需要的额外磁盘空间少。

可以通过多种不同方法创建快照。 最常用的方法是“写入时复制”。

“写入时复制”方法在某个时间点定义一个快照,然后监视原始数据集的变化。 如果发生变化,则会在其他位置记录并跟踪更改。 因此,快照的大小会随着时间的增加而持续增长,特别是当快照由迅速变化的数据集组成时。

快照管理器可以提供数据集的不同视图,通常就好像它们是该数据的不同完整备份一样。 快照管理器还可以根据需要切换到任何可用的数据视图,从而在某种意义上说是还原了数据。

请注意,快照并不是真正独立于数据的副本。 由于快照中只包含对数据的最新更改,因此,如果原始数据损坏,快照数据也不能发挥任何作用。

这种备份方法为您提供了回滚机制,但不是真正的数据备份。 这种备份方法的优点在于,您只需向磁盘中写入更改而无需写入所有数据,因此实际创建快照会非常快。 缺点是如果原始数据损坏,将没有可恢复的备份。

因为快照备份并不提供真正的备份,因此大多数解决方案都实施了额外的步骤,即将快照备份流式传输到磁带。 将快照备份流式传输到磁带会对生产数据库 LUN 显著增加顺序 I/O 负载。

在常规操作期间,Exchange 数据库所在磁盘的 I/O 模式是非常随机的,但流式备份的 I/O 模式却是严格按照顺序进行的。 顺序负载和随机负载的混合会使缓存很难继续保持高效,并会导致额外延迟和显著减少高峰 I/O 吞吐量。 如果计划完全依赖快照作为 Exchange Server 2003 的备份源,这将是一个重要的考虑因素。

许多 Exchange Server 管理员都计划通过在非高峰时间执行流式备份来减少该问题的影响。 尽管这可能是一个有效的策略,但是真正的非高峰时间也许并不明显。

除了响应客户端的请求之外,Exchange 数据库还需要时间来执行联机维护。 管理员能够计划该维护的时间,但是多数情况下每天需要几个小时才能完成。 即使最终用户负载较低,数据库可能也要忙于维护任务。 还必须考虑准备或执行备份所需的额外服务器负载。 最好避免备份窗口与联机维护或高峰用户需求间隔重叠。

若要确定数据库活动的高峰时间,必须通过至少几天的基线期才能真正概括出数据库负载情况。

Exchange 数据库文件分为一系列大小相同的页面。 每个页面都包含用于验证该页面上 Exchange 数据完整性的校验和。 如果页面上的任何数据在 Exchange 服务器的控制范围之外发生了更改(例如,发生磁盘或控制器错误), 校验和验证过程将会检测到此问题。 Exchange 事务日志文件也会实施校验和方案,但它不是基于页面。 因此,验证过程也能检测到事务日志文件的损坏。

Microsoft 支持流式备份 API,从而能够在 Exchange 数据库运行时对它们进行备份。 流式备份 API 在所有版本的 Windows 和 Exchange Server 的 Windows 备份以及很多非 Microsoft 备份应用程序中实施。

note注意:
必须在运行 Windows Server 的计算机上安装 Exchange Administrator 程序,才能让 Windows 备份执行 Exchange 联机流式 API 备份。

实际上,流式备份按顺序一次一页地将数据库复制到备份媒体上。 备份期间,每页的校验和都要经过验证,并且仅当数据库中的所有页面都通过验证时备份才算成功完成。 备份中包含的事务日志文件也要经过验证。 这样可以保证特定数据库的上一个备份没有问题。

创建卷影副本时没有机会验证数据库的页面完整性或事务日志。 因此,必须在创建卷影副本后执行校验和完整性验证。 Microsoft 准则明确了执行此验证的责任者应为请求程序。

请求程序或备份应用程序在备份完成后对数据库和日志文件运行校验和完整性验证。 这对数据库和事务日志逻辑单元号 (LUN) 而言是非常重的流式 I/O 负载。 请求程序通过运行 Exchange Server 数据库实用程序 (Eseutil.exe) 执行校验和完整性验证。 该过程会读取整个备份文件集,以单独验证每个数据库页面和事务日志文件的完整性。

默认情况下,Eseutil.exe 运行的速度与存储读取数据的速度一样快,这对独立于生产 LUN 的典型克隆是最佳速度。 但是,不是所有的 VSS 备份集都独立于原始数据。 有关各类 VSS 备份的详细信息,请参阅本文稍后部分中的“VSS 备份方法”。

有时,通过在一定数量的 I/O 后添加人为暂停,可以帮助降低校验和完整性验证的 I/O 率。 通过使用 Exchange Server 2003 Service Pack 2 (SP2),可以添加下列开关,以在一定数量的 I/O 后增加 1 秒钟的暂停:

/p<x>

这里的 x 表示经过多少 I/O 后出现暂停。 例如,下面的命令将在每 100 个 I/O 后添加一秒钟的人为暂停:

eseutil /K /p100    

这种 I/O 限制只对数据库文件验证实施,不适用于事务日志文件验证。

制定备份过程时必须仔细考虑和规划校验和完整性验证所带来的 I/O 负载。 该验证是备份过程的重要部分,不能被忽视。 但是,可以根据 Microsoft 知识库文章 822896 Exchange Server 2003 数据备份和卷影复制服务中介绍的严格准则临时推迟验证。 本文将提供有关校验和完整性验证要求的详细信息,备份请求程序必须满足这些要求才能符合 Microsoft 可支持建议。

快照不能完全独立于生产 LUN。 因此,对快照运行校验和验证肯定会影响生产 LUN。 对克隆的校验和验证可能影响也可能不影响生产系统,具体取决于克隆存储的位置和访问方式。

必须仔细监视 I/O 负载以及验证过程对最终用户和普通数据库维护的影响。 谨慎使用 Eseutil.exe 限制机制也许还能更好地平衡验证性能和其他 I/O 需求。

对于大部分管理员,基于 VSS 的备份解决方案的最大优势是允许迅速还原大量数据。 对于包含还原时间少于 60 分钟的大型数据库的部署而言,VSS 解决方案是最佳的选择。 此需求超出了当前流式或基于磁带的备份解决方案的能力。 VSS 解决方案具有以下优势:

  • 还原时间缩短
  • 与使用传统的流式联机备份解决方案备份数据相比,VSS 解决方案能够在典型备份窗口中备份和还原更多的数据。

有关 VSS 解决方案的常见错误理解是这些解决方案允许几乎瞬时进行备份并且不会影响生产服务器。 从应用程序的角度而言,这种情况也许能够实现;但是 VSS 备份需要与流式备份同样多的基本准备工作并生成同样多的负载,特别是在使用克隆时。 与使用基于磁带的解决方案相比,备份到磁盘和还原到磁盘能够为您提供更多的吞吐量和更好的性能。 但是,无论选择什么样的备份方法,此操作都不会改变必须将数据从一个位置复制到另一个位置的事实。 此复制过程可以通过 VSS 解决方案得到优化和计划,但是该过程必须完成,并且复制大量数据必然会消耗系统资源。

大部分生产 Exchange Server I/O 涉及许多对数据库的较小的随机 I/O 事务。 在备份和还原期间,存储子系统的 I/O 吞吐量可能会成为人工限制备份和还原速度的瓶颈。 请确保有足够的吞吐量和负载平和,以保证能够满足备份和还原需求。

每个 Exchange Server 2003 存储组都由最多 5 个数据库、几个事务日志文件和一个检查点文件组成。 VSS 将数据库 (*.edb) 和流式 (*.stm) 文件看作是数据库组件,而将事务日志 (*.log) 和检查点文件 (*.chk) 看作是日志组件的一部分。

如果将 VSS 用于备份解决方案,建议运行 Windows Server 2003 Service Pack 1 (SP1) 操作系统。 请与存储供应商联系,以确定是否支持 Windows Server 2003 SP1。 有关无法升级到 Windows Server 2003 SP1 时可用的 VSS 更新程序包的信息,请参阅 Microsoft 知识库文章 833167 卷影复制服务 (VSS) 更新程序包可用于 Windows Server 2003。 有关在无法运行 Windows Server 2003 SP1 时必须应用的其他修补程序的列表,请参阅本文稍后部分中的“附录”。

必须确保任何用于 Exchange Server 2003 的潜在 VSS 解决方案适用于 VSS 框架并且是受支持的解决方案。 有关受支持的 VSS 解决方案的信息,请参阅 Microsoft 知识库文章 822896 Exchange Server 2003 数据备份和卷影复制服务

运行校验和完整性验证是一项占用大量 I/O 和内存的操作。 对于独立和群集 Exchange 服务器,建议将此任务转移到备份服务器上,该服务器可装入和运行对只读卷影副本的校验和完整性验证。 能够执行此操作时,最好是对未与生产 LUN 驻留在同一物理磁盘上的卷影副本运行校验和完整性验证。

可以对整个服务器或单个存储组使用的备份类型包括完整备份、副本备份、差异备份或增量备份。 有关 VSS 备份类型的详细信息,请参阅 Backup Operations(英文网页)。

完整备份 完整备份类型可用于 Exchange Server 部署。 此备份类型可以对存储组中所有数据库、事务日志文件和检查点文件进行备份,并在备份完成后截断这些日志文件。

日志文件截断是删除多余事务日志文件的过程,在还原或前滚最新备份时不需要使用这些事务日志文件。 必须在执行日志文件截断前确认最新备份的校验和完整性。 截断操作能够删除将系统从上一个备份前滚到最新备份所需的日志文件。 尽管截断操作不会使之前的备份无效,但是截断之后,只能将数据库还原到上次备份数据库时的状态。

副本备份 执行副本备份的步骤与完整备份相同,但是不会截断事务日志文件。 可以使用副本备份创建数据库的副本,以供测试或分析使用。

增量备份 必须运行 Exchange Server 2003 Service Pack 1 (SP1) 或更高版本才能使用增量备份类型。 增量备份可备份事务日志,以记录自从上次增量或完整备份以来所发生的更改,然后再截断事务日志。 若要还原增量备份,必须首先还原上次的完整备份,然后再还原所有增量备份。 增量备份可为您提供速度更快的备份窗口,但是会增加还原时间和日志重播时间。

差异备份 差异备份类型要求使用 Exchange Server 2003 SP1 或更高版本。 差异备份可备份事务日志,以记录自从上次完整备份以来所发生的更改,但是并不截断事务日志。 若要还原差异备份,必须首先还原上次的完整备份,然后再还原最新的差异备份。 差异备份能够为您提供速度更快的备份窗口,但却占用较多内存且需要较长的还原时间。

卷影备份通常包括下列阶段,这些阶段由请求程序和编写器管理:

  • 同步 从备份服务器删除之前的卷影副本集并与生产 LUN 同步。
  • 中断   卷影副本同步时冻结对源 LUN 的写入,然后中断卷影副本同步,再恢复对源 LUN 的写入。
  • 传输和校验和   向装入主机传输并公开卷影副本数据和事务日志 LUN。 对卷影副本集运行校验和完整性验证。 有关校验和完整性验证的详细信息,请参阅本文稍后部分中的“Exchange 请求程序与校验和完整性验证”。
  • 日志截断   通过成功截断存储组事务日志完成备份,并将完整备份标记为已完成。

可以选择还原整个存储组,或者,如果数据库驻留在其他 LUN 上,还可以还原存储组中的一个或多个数据库,但不建议这样做。

即使要还原一个数据库,也必须首先使存储组中的所有数据库脱机。 然后,在还原过程结束后,可通过装入存储组中的任何数据库来对整个存储组调用自动数据库恢复(事务日志文件重播)。

若要成功执行自动恢复,必须至少满足下列条件:

  • 数据库文件名和逻辑文件路径必须与备份时的名称和路径一致。 例如,如果文件名为 Priv1.edb 和 Priv1.stm,并且存储文件的路径为 D:\Databases,则还原位置也必须为 D:\Databases 并且不能更改这些文件名。
  • 存储组前缀必须与要重播的任何事务日志文件的文件名匹配。
  • 如果要还原到原始服务器,除非自从完成备份后更改过数据库路径,否则将自动满足这些条件。
  • 一些 VSS 请求程序允许还原到备选服务器。 在实验室服务器上装入数据库或在原始服务器不可用的高级恢复方案中此操作可能非常有用。 有关备份和还原 Exchange Server 2003 的详细信息,请参阅 Exchange 2003 Disaster Recovery Operations Guide(英文网页)。

恢复分为以下两种形式:

  • 前滚恢复   前滚恢复是指恢复到出现故障时的状态。 如果当前日志 LUN 可用,则可以完成前滚恢复。 在这种情况下,可以从备份中还原数据库文件,但是不能还原事务日志文件,并使用服务器上的当前日志前滚数据库。 如果自从上次备份后生成的所有日志文件都可用,则还原备份时就不会丢失数据。
  • 时点恢复 时点恢复是指只恢复上次备份的数据。 所有较新的数据都会丢失。 使用时点恢复时,只使用包含在备份集中的事务日志文件。 而不使用自从备份以来生成的其他日志文件,并且那些数据库只恢复到备份时的状态。

许多企业解决方案都利用 Windows 群集来提高服务器的可用性。 在群集中运行 Windows Server 2003 SP1 和 Exchange Server 2003 时,可使用名为维护模式的新增功能来帮助制定一些还原方法。 群集会给 VSS 带来一些独特的挑战,您必须对这些挑战进行了解和计划才能获得成功。 请确保您知道群集解决方案的备份和还原影响。

备份期间,将对卷影副本运行校验和完整性验证。 校验和完整性验证是占用大量内存和磁盘空间的操作,大部分管理员不希望在驻留生产 Exchange 虚拟服务器的群集节点上运行该操作。 在校验和完整性验证期间,LUN 以只读形式存在。 这可能会导致原始 LUN 的磁盘签名出现问题,并使其脱机。 因此,大部分群集解决方案都实施装入备份 LUN 的备份服务器,以运行校验和完整性验证。

在还原期间,可通过 IsAlive 和 LooksAlive 检测信号请求监视群集物理磁盘资源。 用于卸除生产 LUN 和装入备份 LUN 的还原解决方案可能会遇到以下计时问题: 如果群集服务在生产 LUN 和备份 LUN 的切换期间将这些检测信号请求发送到物理磁盘,则群集物理磁盘资源可能出错,从而导致发生群集故障转移。 而将备份 LUN 重新同步到生产 LUN 的解决方案则不会造成群集故障转移的风险。

如果要在群集环境中运行 Exchange,并使用导致 LUN 对该群集暂时不可用的卷影副本备份或还原提供程序,强烈建议使用 Microsoft Windows Server 2003 Service Pack 1 (SP1) 操作系统,并且该提供程序使用磁盘资源维护模式功能。 有关磁盘资源维护模式功能的详细信息,请参阅 Microsoft 知识库文章 903650 Windows Server 2003 中群集物理磁盘资源的扩展维护模式功能

此外,如果无法运行 Windows Server 2003 SP1 或 VSS 提供程序尚不支持磁盘资源维护模式,则可以通过将 IsAlive 和 LooksAlive 的资源值提高到 5 分钟,来降低(而不是消除)关键操作期间出现群集故障转移的可能性。 请注意,不应将这些值保持在 5 分钟不变;应将其还原为常用值以实现常规操作。 有关提高 IsAlive 和 LooksAlive 值的信息,请参阅 Frequently Asked Questions(英文网页)。

规划备份策略时,必须创建一个定义所需备份和还原窗口的服务级别协议 (SLA)。 使用此协议,可以准确地确定为达到所需的备份窗口而需要的数据库、存储组和 Exchange 服务器的数量。 大部分管理员还通过该协议定义用于联机数据库维护、联机数据库碎片整理和操作系统维护的其他窗口。

创建 VSS 解决方案时,可以使用以下两种策略中的一种:

  • 升级当前基础结构以支持 VSS。
  • 设计具有高可用性的新 Exchange Server 2003 VSS 解决方案。

有关实现 Exchange Server 2003 的高可用性的详细策略信息,请参阅 Exchange 2003 High Availability Guide(英文网页)。 有关如何规划灾难恢复的信息,请参阅 Worksheet: Disaster Recovery Preparation for Microsoft Exchange Server 2003(英文网页)。

无论是设计新解决方案还是升级现有解决方案,首先需要评估当前备份和还原方法、时间窗口、数据库和存储组的大小、当前存储容量消耗和可用空间。 应该在生产和备份窗口期间衡量存储解决方案的性能基准。

还应了解邮箱配置文件,其中包括单个邮箱大小以及每位用户的数据库 I/O 数量。 这一点对于 VSS 来说非常重要,因为备份和还原操作会给存储子系统带来额外负载,所以在设计时必须慎重,以确保低延迟。 有关定义邮箱配置文件的步骤信息,请参阅 Optimizing Storage for Exchange Server 2003(英文网页)。

还必须确定是否能够使用流式备份解决方案或 VSS 备份解决方案。 流式联机备份使用 Exchange 备份 API 来备份已装入的数据库和存储组。 在流式备份期间,将对每个页面运行校验和完整性验证,以便明确这一点:备份成功后,将有一个可靠的备份。 备份期间对生产 LUN 的流式 I/O 负载与对卷影副本的校验和完整性验证期间产生的负载一样严重,因此必须相应地调整存储基础结构大小,以满足备份和还原 SLA。

由于事务日志文件管理冲突,不能在同一存储组中将 Exchange 识别的流式备份与 Exchange 识别的 VSS 备份混合使用。 一种备份类型可能会截断另一种备份类型所需的日志文件。 但是,可以对 VSS 卷影副本备份集执行一般的流式文件备份,以便在该备份集被后续备份覆盖之前将其永久保存。

在流式备份环境中,物理磁盘或网络的带宽、物理磁盘隔离和磁带速度都是重要考虑因素和瓶颈,它们通常有助于防止一台 Exchange 服务器的备份影响另一台 Exchange 服务器的备份。

通常情况下,根据 VSS 对 Exchange Server 2003 的要求,存储机箱和存储控制器除了处理典型的随机 I/O 需求之外,还要处理所有的备份顺序 I/O。 因此,必须确保对备份和还原期间的吞吐量进行测试。 请确保了解在每天备份操作期间的预期生产负载下,控制器在同步时每小时能够承载的数据量(以 GB 为单位),以便能够满足 SLA 要求。

使用 VSS 时,必须创建 SLA 以定义备份窗口和可接受的特定中断停机时间。 这将对存储设计产生影响。 还必须考虑为可导致您还原的各种方案创建一个 SLA。 定义备份策略时,必须根据相关成本平衡较短的备份窗口和还原时间窗口;例如,10 分钟的 SLA 还原比 72 小时的 SLA 还原需要在硬件和技术专业知识方面投入更多的成本。

有关 SLA 和可用性管理的详细信息,请参阅 Microsoft Solutions for Management: Availability Management(英文网页)。 有关针对 Exchange Server 2003 的 SLA 的详细信息,请参阅 Exchange 2003 High Availability Guide(英文网页)。

作为 SLA 的一部分,请定义下列内容:

  • 恢复点目标 (RPO) RPO 是指可以容忍的数据丢失量。 例如,如果不能容忍丢失任何数据,则 RPO 为零。
  • 恢复时间目标 (RTO)   RTO 是指从中断到恢复服务的时间期间。 为了满足 RTO,一些解决方案要求更频繁的备份窗口,以便在还原期间,日志重播时间能够满足还原 SLA 要求。 通常,需要为以下组件指定 RTO:
    • 邮箱 建议使用内置功能(如 Microsoft Office Outlook® 2003 中的“恢复已删除的邮件”功能或 Exchange Server 2003 中的邮件保留策略)还原单个邮箱或邮箱中的数据。 有关“恢复已删除的邮件”功能的详细信息,请参阅 Microsoft Office Assistance: Recover Deleted Items from Any Folder(英文网页)。 有关邮件保留策略的详细信息,请参阅如何 在 Exchange Server 2003 中使用系统策略配置邮箱存储限制
    • 存储组   要还原损坏的数据或数据库,或存储组中的日志文件数据,必须从备份进行还原。 此外,解决方案还必须满足已定义的 SLA 和还原窗口要求。 尽管可以使用 VSS 备份和还原存储组中的单个数据库,但是仍建议最好同时备份和还原整个存储组。 逐个备份和还原数据库的操作更加复杂,而且只能将单个数据库存储在特定的 LUN 上。 支持逐个备份数据库,虽然可能存在某些首选考虑要素决定了此选项适合于您的环境,但是也应当考虑到其缺点。
    • 服务器   服务器出现故障时,使用备选服务器还原 VSS 备份也是不错的方法。 一些存储供应商能够还原在不同时间复制到不同站点的 VSS 备份。 为此,请求程序必须能够使用 VSS 还原到具有同一路径和主机名的不同服务器。
    • 站点   一个站点出错时,Exchange Server 数据必须在另一个站点可用。 可以使用复制或将 VSS 备份复制到磁带(也可以同时使用这两种方法),并且在场外存储这些磁带,以便它们在从备选站点还原时可用。

定义复制策略是实施 VSS 解决方案的重要部分,由于一些复制方法会影响生产 LUN 的延迟,因此必须谨慎设计这些策略以满足 SLA 要求。 Exchange Server 2003 不提供用于邮箱数据库的应用程序级别的复制机制。 建议将 Windows 群集用于服务器复原,但是也尊重存储合作伙伴的存储和站点复原解决方案。

随着企业逐步改变其对邮件的观点,从“可有可无”到任务关键的应用程序,复制功能也变得越来越重要。 尽管大部分解决方案分为同步解决方案和异步解决方案,但是仍能够以多种方式实施复制功能。 有关 Exchange Server 2003 复制支持的详细信息,请参阅 Deployment Guidelines for Exchange Server Multi-Site Data Replication(英文网页)和 Microsoft 知识库文章 895847 Exchange 2003 和 Exchange 2000 的多站点数据复制支持

在评估当前基础结构和定义新的 SLA 后,接下来是与存储供应商紧密合作,设计能够满足 SLA 要求的存储解决方案。 向存储供应商提供有关以下内容的信息:存储组的准确大小和 I/O 性能、备份和还原窗口、生产和备份期间可接受的性能级别以及希望备份数据的频率。 然后,存储供应商会向您提供建议的解决方案,您可以稍后对这些解决方案进行验证。

设计存储基础结构时,必须验证整个端对端解决方案符合 Microsoft 的要求并出现在 Windows 目录中。 解决方案用于备份数据的策略会严重影响存储设计。

大部分存储机箱是按照容量进行采购的。 您很可能已经有足够的存储容量以备未来发展需要,但最终用户通过解决方案能够成功感受到以较低的延迟传递足够的 I/O,也是存储解决方案成功的关键。 如果出现下列情况,则磁盘子系统的性能较差:读写延迟平均值超过 20 毫秒,高于 50 毫秒延迟高峰持续时间长达几秒。

目前,大部分 Exchange Server 系统结构设计师都将 Exchange Server 数据库和事务日志文件保存在 RAID10 LUN 上,目的是为了提高系统性能和帮助保护数据库。 如果解决方案已经过全面测试并满足 SLA 要求,则可以考虑使用其他 RAID 级别。 许多存储供应商都会对在 Exchange Server 2003 上部署自己的产品提出具体建议。客户应向其存储供应商询问有关 Exchange 专用磁盘配置和容错能力建议。

采购存储后,许多管理员尝试使用 RAID5 获得每个字节的可用容量。 如果已分配了足够的心轴,则可以使用 RAID5 以保证预期的性能和延迟,有时性能甚至更优于使用 RAID10 时的性能。 但是,更多的情况下,要正确确定心轴性能的高低,RAID5 比 RAID10 需要更多的物理磁盘。 此外,还应测试在各种 RAID 级别的磁盘重建操作期间导致的性能下降。 无论选定哪个级别的 RAID,都应使用在“测试 VSS 解决方案”部分中讨论的 Jetstress 来测试实际的 LUN 配置,以确保该 LUN 配置满足 Exchange I/O 要求。 有关 RAID 级别的详细信息,请参阅 Optimizing Storage for Exchange Server 2003(英文网页)。

总之,磁盘容量只是在规划 Exchange Server 2003 存储时应考虑的众多因素之一。此外,还必须平衡下列几项关键因素:

  • 容错能力。 解决方案是否能够提供高度冗余以及驱动器和媒体故障复原?
  • I/O 配置文件。 RAID 级别和心轴数量是否同时支持所需的 I/O 负载和实际的 I/O 混合(读取与写入、随机和后续)?
  • 恢复配置文件。 发生故障后,在驱动器设置恢复时是否出现明显的性能下降?

进行 VSS 解决方案的基本设计时应考虑下列事项:

  • 是否对存储组启用了循环日志记录?
    建议禁用循环日志记录。 启用循环日志记录后,只能还原时点存储组。 这可能导致数据丢失。 原因是启用循环日志记录后,将无法还原单个数据库,而且也不能前滚日志。 这样会影响 SLA 的 RPO。
  • VSS 解决方案是否使用 Exchange 编写器只备份和还原 Exchange Server 数据?
    Exchange Server 2003 要求 Exchange 编写器只能备份和还原 Exchange Server 数据。

进行 VSS 解决方案的群集设计时应考虑下列事项:

  • 还原是否完全自动进行,并且不需要手动干预来调整群集资源相关性?
    建议由请求程序处理全部所需的群集资源相关性变化。
  • 恢复操作是否影响物理磁盘资源运行状况?
    建议对群集使用 Exchange Server 2003 SP1 和识别群集维护模式的请求程序。 这样可以通过临时禁用 IsAlive 和 LooksAlive 检查来防止在还原期间出现资源故障。

选择用于 VSS 解决方案的提供程序时应考虑下列事项:

  • 存储阵列的 VSS 提供程序具有快照功能还是克隆功能,还是同时具有这两个功能?
    Exchange Server 2003 要求具有 VSS 识别的提供程序。 提供程序负责与存储设备通信,以创建和删除卷影副本。
  • 提供程序是否支持群集 Exchange 配置?

选择用于 VSS 解决方案的请求程序时应考虑下列事项:

  • 请求程序是否对卷影副本备份集执行校验和完整性验证?
    Exchange Server 2003 要求对卷影副本运行校验和完整性验证,以确定备份是否存在问题。 不支持对尚未运行校验和完整性验证的数据执行恢复操作。
  • 请求程序是否一次只对一个 LUN 运行单次校验和完整性验证过程?
    在多个数据库位于同一 LUN 上时,顺次对每个数据库运行校验和完整性验证可能会更高效。 这样可以防止额外的磁头管理并保持顺序读取操作。
  • 请求程序是否自动将当前卷影副本导入到备份服务器,以进行校验和完整性验证?
    建议将 Eseutil.exe 校验和完整性验证转移到备份服务器上。
  • 请求程序是否支持群集 Exchange 配置?
  • 请求程序是否支持计划和排队?
    不同的解决方案有自己的性能特征。 某个解决方案可能在同时创建所有 LUN 的卷影副本时性能最佳;而其他解决方案可能在按顺序创建卷影副本时性能较好。 该解决方案应该有计划灵活性或允许进行计划的优化功能,以同时提高性能和管理员的便利性。
  • 请求程序是否在开始备份前扫描潜在故障,并在发现故障时中止备份?
    某些请求程序会查找数据库故障事件(-1018、-1019、-1022),以确保损坏的数据库不会覆盖上一个完好的备份。 如果请求程序不具备此功能,则可以使用 Microsoft Operations Manager (MOM) 或其他事件扫描程序,也可以手动检查事件日志,以检测故障。
    监视事件日志中是否有这些错误无法取代备份校验和完整性验证。 这是因为监视时只记录数据库中实际访问的页面的事件。 而不经常访问的页面上的错误无法可靠地通过监视事件日志检测到。 监视事件日志可为您提供有关损坏数据库的更多较早警告。
  • 请求程序是否使用事件指示故障和成功?
    建议请求程序使用可由脚本监视的事件以及诸如 MOM 等工具。 这些事件有助于主动监视 Exchange Server VSS 解决方案。
  • 该请求程序在还原存储组之前是否使用 CDOEXM 将其完全卸除?
    建议请求程序在还原存储组之前将其卸除。 如果请求程序不执行此操作,则必须在开始还原存储组之前将其手动卸除。
  • 请求程序是否支持 Eseutil.exe 校验和完整性验证 I/O 限制?
  • 请求程序是否在无需管理员手动干预的情况下管理卷影副本保留和删除操作?

进行 VSS 解决方案的存储设计时应考虑下列事项:

  • 还原 VSS 解决方案的存储组是否会影响其他存储组或 Exchange 服务器?
    建议为存储设计 LUN 配置,以便还原存储组不会影响其他生产存储组或 Exchange 服务器。 最好按每个存储组隔离物理磁盘,如果无法执行此操作,则除了还原 I/O 工作负载还要测试解决方案生产工作负载,以确保用户能够接受这些影响。
  • 解决方案是否能够在还原期间将卷影副本数据从备份同步到生产 LUN?
    支持同步的解决方案(无论是使用快照还是克隆功能)需要将数据从卷影副本复制到原始 LUN。 复制所需的时间取决于必须复制的数据量。 还原的时间长度还受存储组装入时数据库硬恢复期间必须重播的日志文件数量影响。
  • VSS 解决方案是否符合站点复原计划?
    Exchange Server 2003 要求将 VSS 备份复制到其他站点的解决方案使用 VSS 还原第二个站点的数据。 有关复制的详细信息,请参阅 Exchange 2003 High Availability Guide(英文网页)。

使用克隆备份需要复制所有的数据。 这种复制方法需要资源和时间,具体取决于要复制的 LUN 的大小。 因此,必须了解此过程对生产 LUN 的影响,以及存储供应商是否提供能使您将此影响降至最低的功能。 存储控制器对克隆数据的速度有所限制。 如果了解此限制,可以通过定位 LUN 和 Exchange 服务器提高总吞吐量,以利用存储控制器。

设计克隆备份 VSS 解决方案时应考虑下列事项:

  • 克隆目标是否使用一组不同于源生产 LUN 的物理磁盘?
    建议克隆使用不同于源生产 LUN 的物理磁盘。 如果克隆使用相同的物理磁盘,校验和完整性检查会明显影响生产 LUN 的延迟,因此必须安排在活动性较低时出现的备份,以最大程度低降低对用户的影响。
  • 如果克隆目标是另外一组物理磁盘,它是否会使用同一类型的 RAID ?
    如果生产 LUN 使用的是 RAID10,而克隆目标使用的是 RAID5,则性能在进行备份时同样出色。 如果在还原期间,RAID5 LUN 与新的生产 LUN 同样可用,则必须在设计存储解决方案时考虑可能出现的较慢存储对性能的影响。
  • 请求程序是否支持多个克隆目标?
    建议解决方案至少支持两个克隆目标循环使用,以防止在备份期间由于出现灾难而导致数据丢失。 这样可以从上一个已知完好的备份迅速恢复。
  • 请求程序是否在运行校验和完整性验证之前一直等待,直到克隆中断或完全同步?
    建议请求程序在运行校验和完整性验证之前一直等待,直到克隆中断或被规范化。 为了防止对生产 LUN 的数据块依赖性,也为了防止生产 LUN 经历高滞后,这是必需的。
  • 解决方案是否在生产 LUN 硬件出现故障时提供还原克隆的机制?
    如果克隆到其他物理磁盘,但是出现磁盘或机箱故障,则必须能够还原该克隆。 如果 VSS 解决方案不提供还原克隆的机制,则 SLA 必须在磁盘或机箱出现故障时记录备选的还原方法,而且您还必须对该备选方法进行测试。
  • 克隆目标是否使用近线存储?
    就转速和磁头寻道时间而言,速度较慢的磁盘类型 (SATA) 不是随机工作负载的最佳选择。 降低成本的存储即使对于大部分的连续工作负载或具有低生产 I/O 工作负载的环境也能够正常运行。 许多存储公司都在向存储机箱中增加 SATA 和 FATA 设备;这些设备在 VSS 环境中作为备份目标运行良好,提供程序在备份和还原期间将按顺序访问 VSS 环境中这些设备上的数据。 必须确保完成对较慢存储的校验和操作所需的时间能够满足 SLA 要求。 在还原期间将质量较低的存储提供给主机作为生产 LUN 的解决方案存在风险。 必须调整提供减速后的存储作为生产 LUN 的解决方案的大小,以确保该解决方案能够处理生产负载。
  • 解决方案在还原期间是否交换克隆 LUN 和生产 LUN?
    支持交换 LUN 的解决方案通常使用克隆备份,无论数据大小,都可以通过将生产 LUN 替换为备份 LUN 来执行迅速还原。 此策略还受存储组装入时数据库硬恢复期间必须重播的日志文件数量影响。 需要还原时,对各种 RAID 类型(RAID10 和 RAID5)的考虑因素很重要。

设计快照备份 VSS 解决方案时应考虑下列事项:

  • 除了快照,是否还有其他制作完全独立备份的候选方案?
  • 快照是否根据需要分配空间?
    大部分解决方案都根据需要或变化消耗容量。 部分解决方案根据每个快照分配整个生产 LUN 大小,以便为每位数据发生变化的事件做好准备。 如果每天需要多个快照,则在规划容量时必须考虑此问题。 如果没有预先分配空间,则仍必须考虑随着“写入时复制”快照与实时数据集中的更改数量成比例增长时可能需要额外空间。
  • 多个快照会产生哪些性能影响?
    同时跟踪多个快照的要求可能会导致性能开销。 必须评估该性能影响,以便决定无论在任何时候都能够实际接受的快照数。 由于索引必须得到更新,而且有时必须重组物理磁盘上的数据才能将空间重新分配给阵列,所以删除快照也可能产生性能影响。

VSS 会对存储基础结构产生影响。 在设计完 VSS 解决方案后,必须通过评估该解决方案的效果并确保它满足 SLA 要求对该解决方案进行验证。 必须使用概念证明的方法来验证希望在 SLA 中支持的所有还原方案。

概括解决方案要求后,必须验证整个端对端解决方案。 其中包括下列详细信息:

  • 在备份窗口期间,存储控制器在预期的 Exchange Server 负载下每小时能够备份多少千兆字节的数据。
  • 能够以多快的速度还原这些数据库。

使用验证期间确定解决方案是否满足下列要求:

  • 对数据库 LUN 的典型读写延迟低于 20 毫秒,高于 50 毫秒的高峰持续时间不再长达几秒。
  • 可以在已定义的备份窗口执行备份和校验和完整性验证。
  • 还原满足 SLA 要求,可以进行恢复,并且不会影响其他存储组或 Exchange 服务器。

必须以希望在生产环境中部署真正的端对端解决方案的方式来对其进行测试。 通过测试可以确保该解决方案使用 VSS 框架并满足 Exchange Server 2003 的要求,同时让您有机会了解该解决方案的一些性能影响。 必须根据您自己的 SLA 设计端对端测试。 在不考虑性能影响的情况下部署 Exchange Server 2003 VSS 解决方案可能导致性能下降并降低客户满意度。

请确保已测试下列内容:

  • 备份期间的生产 LUN 的性能
  • 校验和完整性验证的性能。 其中包括验证期间生产 LUN 的性能。 校验和完整性验证必须快速完成,以使其不会延长以致占用下次备份的时间。
  • 还原
  • 日志重播
  • 复制

请注意,每个存储组的用户数应与预期的部署数量匹配。

可以使用下列工具执行部署测试:

  • Microsoft Exchange Server 2003 Load Simulator (LoadSim)   LoadSim 能够模拟使用 Exchange Server 2003 的 Outlook MAPI 用户。可以使用 LoadSim 创建用户并通过邮件初始化邮箱。 这将创建与生产环境中的数据库大小近似的数据库。 LoadSim 要求使用 Outlook 2003。若要下载 LoadSim,请参阅 Microsoft Exchange Server 2003 Load Simulator ( LoadSim )(英文网页)。
  • Exchange Server 2003 Jetstress 工具   Jetstress 可模拟磁盘 I/O 负载,以验证存储阵列的性能和稳定性,并具有易于使用的图形用户界面。 若要下载 Jetstress,请参阅 Exchange Server 2003 JetStress Tool(英文网页)。

第 1 阶段的目标是测试解决方案的稳定性,以迅速明确 VSS 和存储配置以及稳定性问题。

下面是执行测试过程第 1 阶段的示例:

  • 对每个数据库和日志 LUN 运行 24 小时 Jetstress 压力测试。
  • 使用 LoadSim 创建生产规模大小的数据,并于 48 小时内以每 2 小时为间隔对服务器运行备份作业。
    应将 2 小时的备份窗口调整为建议的生产备份窗口。 使用基于生产环境配置的独立或群集服务器。

第 2 测试阶段的目标是确保 VSS 解决方案能够在 SLA 定义的备份和还原窗口中,在生产负载下备份和还原生产规模大小的压力数据库。

下面是执行测试过程第 2 阶段的示例:

  • 使用 MAPI Messaging Benchmark 3 (MMB3) 配置文件在 8 小时的 LoadSim 运行后再运行每夜备份。
  • 在每天上午开始下一次 LoadSim 测试前运行还原。 请确保测试的还原案例是在 SLA 中定义的、计划在生产环境中使用的案例。 3 种最常见的还原案例包括:
    • 前滚恢复,即恢复数据库并前滚日志
    • 时点恢复,即恢复日志
    • 完全还原,即必须还原整个存储组。

请确保监视校验和完整性验证的性能影响。 如果校验和完整性验证导致不可接受的延迟,则首先确定是否存在瓶颈问题。 存储控制器、处理器、缓存和存储带宽都有可能导致瓶颈问题。 如果是磁盘性能导致瓶颈问题,最好的解决方案是增加更多的物理心轴以支持 LUN。 请与存储供应商联系,以了解改善不可接受的延迟的策略。

必须监视解决方案的运行状况,以便对企业发展管理以及随着生产环境变化而出现的问题采取主动措施,例如,用户流程的改变、增加更多的用户或邮箱容量增加。 若要成功执行备份和还原,必须确保监视下列事项:

  • 延迟是否发生变化。
  • 是否实现预期的备份和校验和完整性验证比率。
  • 备份和还原过程中可能发生的问题的通知。

监视的第一步是建立运行状况良好的性能特征的基准。 随着时间的推移,根据已建立的基准继续监视异常情况。 有关监视的详细信息,请参阅 Exchange 2003 High Availability Guide(英文网页)。

Microsoft Operations Manager (MOM) 2005 和 Exchange 管理包提供了监视 Exchange Server 2003 性能和可用性的重要方法。 Exchange 管理包提供了警报知识库以及有关这些警报的建议和信息链接。 通过使用 Exchange 管理包,可以轻松跟踪以下事项:

  • 数据库大小
  • 邮箱数
  • 配置
  • 可用性
  • 客户端监视
  • 邮件流量分析

使用 Exchange 管理包,还可以在达到特定阈值时收到警报。 若要下载 Exchange 管理包,请参阅 Exchange Server Management Pack Guide for MOM 2005(英文网页)。 有关将 MOM 2005 与 Exchange Server 2005 配合使用进行监视的最佳案例信息,请参阅 Exchange 2003 Management Pack Configuration Guide(英文网页)。 有关解决 Exchange Server 2003 性能问题的信息,请参阅 Troubleshooting Exchange Server 2003 Performance(英文网页)。

存储供应商提供的管理包也非常有用。 这些管理包能够在存储超出容量、性能和容差能力阈值时发出警报。

部分 VSS 解决方案要求应用下列修复程序:

  • 对于 Windows Server 2003  SP1: 891957, 898790
  • 对于 Exchange Server 2003  SP1: 892514

若要确定是否需要这些修复程序,请与您的存储供应商联系。

 
显示: