邮箱服务器存储设计

 

适用于： Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

上一次修改主题： 2009-04-03

具有足够的容量至关重要。当数据库磁盘空间耗尽时，数据库将脱机。事务日志磁盘空间耗尽时，会导致该存储组中的所有数据库脱机。通常难以迅速增加空间，并且执行脱机压缩来回收空间可能需要很长时间。在大多数情况下，磁盘空间不足会导致一个或多个数据库的可用性中断一段时间，通常超出大部分还原时间目标 (RTO)。

此主题提供有关以下内容的信息：

• Exchange 2007 的邮箱存储计算器

• 数据库 LUN 容量

• 日志 LUN 容量

• 事务性 I/O

• 预测 Exchange 2007 基线 IOPS

• 非事务性 I/O

• LUN 和物理磁盘

• 连续复制对存储设计的影响

Exchange 2007 的邮箱存储计算器

Exchange Server 2007 邮箱服务器角色存储要求计算器（存储计算器）使您能够根据一组输入要素确定您的存储要求（I/O 性能和容量）以及最佳逻辑单元号 (LUN) 布局。有很多输入要素需要说明，然后才能为 Exchange 2007 邮箱服务器设计最佳存储解决方案。整个主题将介绍这些输入要素。

存储计算器使您能够输入特定于您的组织的值，并且为您提供 I/O 要求、容量要求以及最佳 LUN 布局的建议。

有关包括使用细节等在内的储存计算器详细信息，请参阅 Exchange 工作组日志上的 Exchange 2007 邮箱服务器角色储存要求计算器（您可在此下载计算器）。

注意：
UNRESOLVED_TOKEN_VAL(exBlog)

数据库 LUN 容量

可以使用多个数据点来确定如何调整数据库逻辑单元号 (LUN) 的大小。另外，还要考虑其他因素。在考虑并计算所有因素后，建议您还要考虑增加 20％ 的数据库 LUN 开销这一因素。此值将考虑到在计算邮箱大小和空白空间时未必会看到的驻留在数据库中的其他数据。例如，数据库中的数据结构（表、视图和内部索引）也会增加数据库的总大小。举例来说，如果您在读取以下子部分后确定需要 120 千兆字节 (GB)，我们建议您提供 144 GB，其中包含 20％ 的安全开销用于存储组的数据库 LUN。

邮箱配额

要了解的第一个指标是邮箱大小。通过了解允许一位最终用户在其邮箱上存储的数据量，能够确定在该服务器上可驻留多少位用户。尽管最终的邮箱大小和配额可以更改，但考虑目标容量是确定所需容量的第一步。例如，如果一个服务器上有 5,000 位用户且邮箱配额为 250 MB，则需要至少 1.25 TB 的磁盘空间。如果没有对邮箱配额设置硬性限制，将很难估计所需的容量。

数据库空白空间

物理磁盘上的数据库大小并非只是用户数乘以用户配额得出的值。当大多数用户未接近其邮箱配额时，数据库将占用较少空间，在计算容量时不考虑空白空间。数据库本身将始终具有分散在各处的可用页（或称空白空间）。在联机维护期间，删除数据库中标记为删除的项目会释放这些页。空白空间的百分比随着紧跟在联机维护后的最高百分比和紧跟在联机维护前的最低百分比不断变化。

根据用户使用数据库中的邮箱发送和接收的邮件量，可以估计数据库中空白空间的大小。例如，如果数据库中拥有 100 个 2 GB 的邮箱（共 200 GB），其中用户平均每天发送和接收 10 MB 的邮件，则空白空间大约为 1 GB (100 * 10 MB)。

如果联机维护不能完成全面检查，则空白空间可能增长到超过此近似值。使操作活动每晚具有足够时间运行联机维护非常重要，这样可在一周或更短的时间内完成一次全面检查。

数据库垃圾站

每个数据库都包含用于存储软删除邮件的垃圾站。默认情况下，邮件在 Microsoft Exchange Server 2007 中存储 14 天，其中包括从已删除邮件文件夹中删除的邮件。默认情况下，与 Exchange Server 2003 相比，Exchange 2007 会增加数据库垃圾站所占用的开销，原因是现在已删除邮件的存储时间增加了一倍。垃圾站中的实际数量将取决于每个邮件的大小以及组织的特定保留设置。

保留期过后，将在联机维护循环期间从数据库中删除这些邮件。最终，将达到稳定状态，此时垃圾站大小相当于两周传入/传出邮件的大小，以占数据库大小的百分比表示。确切的百分比取决于已删除的邮件量和各个邮箱的大小。

垃圾站根据邮箱大小和该邮箱的邮件传递速率增加数据库的开销百分比。例如，如果邮件的恒定传递速率为每周 52 MB，则 250 MB 极重负载配置文件邮箱会在垃圾站中存储约 104 MB，即增加 41％ 的开销。在垃圾站中存储同一 104 MB 的 1 GB 邮箱将增加 10％ 的开销。

实际邮箱大小

随着时间的推移，用户邮箱将达到邮箱配额，所以将需要删除相当于传入邮件的邮件量以使其保持低于邮箱配额。这意味着，垃圾站增加到的最大大小相当于两周传入/传出邮件的大小。如果大多数用户未达到邮箱配额，则只删除部分传入/传出邮件，因此增长将在垃圾站和邮箱大小增加之间划分。例如，一个 250 MB 极重负载邮件配置文件邮箱每周接收 52 MB 的邮件（平均邮件大小为 50 KB），它会在垃圾站中占用 104 MB (41％) 并占用 7.3 MB 空白空间，邮箱总大小为 360 MB。再举一个例子，一个 2 GB 极重负载邮件配置文件邮箱每周接收 52 MB 的邮件，它会在垃圾站中占用 104 MB (5％) 并占用 7.3 MB 空白空间，邮箱总大小为 2.11 GB。五十个 2 GB 的邮箱在存储组中总共占用 105.6 GB。

以下是计算使用 2 GB 邮箱的数据库大小的公式：

邮箱大小 = 邮箱配额 + 空白空间 + (每周传入邮件 × 2)

邮箱大小 = 2,048 MB + (7.3 MB) + (52 MB × 2)

2,159 MB = 2,048 MB + 7.3 MB + 104 MB（大于配额 5%）

确定预计实际邮箱大小后，可以使用该值确定每个数据库的最大用户数。其方法是算出预计邮箱大小后，用建议的最大数据库大小除以该值。此值还有助于确定处理预计用户数所需的数据库数（假设为完全填充的数据库）。请注意，由于存在非事务输入/输出 (I/O) 或硬件限制，可能必须修改位于单个服务器上的用户数。某些管理员希望使用更多数据库来进一步减小数据库大小。此方法有助于备份和还原窗口，但其代价是在每个服务器上管理更多数据库增加了复杂性。

内容索引

内容索引将创建索引或编录，使用户可以快速轻松地搜索其邮件项目，而不用手动搜索邮箱。Exchange 2007 将创建大约为总数据库大小的 5％ 的索引，该索引与数据库位于同一个 LUN 上。还需考虑对数据库 LUN 大小增加额外的 5% 容量，以用于内容索引。

维护

如果需要脱机修复或压缩某数据库，则需要目标数据库大小加 10％ 的容量。无论是否为单个数据库、存储组或备份集分配了足够空间，都需要有可用的额外空间以执行下列操作。

恢复存储组

如果计划在灾难恢复规划中使用恢复存储组，则需要有足够的可用容量以处理您希望能够在该服务器上同时还原的所有数据库。

备份到磁盘

许多管理员以流式联机备份的方式将内容备份到目标磁盘。如果备份和还原设计涉及备份到磁盘，则需要在服务器上有足够的可用空间以驻留备份。根据使用的备份类型，此容量可以较小，只能存储数据库和日志；也可以很大，足以存储数据库和上次完整备份以来的所有日志。

日志 LUN 容量

事务日志文件将记录数据库引擎执行的每个事务。所有事务将先写入日志，然后再慢慢写入数据库。与以前版本的 Exchange 不同，Exchange 2007 中的事务日志文件大小已从 5 MB 减小到 1 MB。此更改旨在支持连续复制功能，并将主存储失败时的数据损失量降到最低。

可以使用下表来估计将在 Exchange 2007 邮箱服务器上生成的事务日志数量，其中平均邮件大小为 50 KB。

每个邮箱配置文件生成的事务日志数量

邮箱配置文件	邮件配置文件	生成的日志/邮箱
轻负载	发送 5 次/接收 20 次	6
平均负载	发送 10 次/接收 40 次	12
重负载	发送 20 次/接收 80 次	24
极重负载	发送 30 次/接收 120 次	36
超重负载	发送 40 次/接收 160 次	48

为邮件大小如何影响日志生成速率建立了以下准则：

• 如果平均邮件大小是 100 KB 的两倍，则每个邮箱生成的日志增加 1.9 倍。该数字表示包含附件和邮件表（邮件正文和附件）的数据库的百分比。

• 因此，邮件大小超过 100 KB 的两倍时，每个邮箱的日志生成速率也会增加一倍。

例如：

• 如果您有一个重负载的邮箱配置文件并且平均邮件大小为 100 KB，则每个邮箱生成的日志为 24 × 1.9 = 46。

• 如果您有一个重负载的邮箱配置文件并且平均邮件大小为 200 KB，则每个邮箱生成的日志为 24 × 3.8 = 91。

备份和还原因素

执行夜间完整备份的大多数企业会在事务日志 LUN 上的存储组中分配大约 3 天日志文件的容量。这样可防止备份失败导致填满日志驱动器而卸除存储组。

日志 LUN 大小在一定程度上取决于备份和还原设计。例如，如果设计允许后退两周并重播自那时起生成的所有日志，则需要两周日志文件的空间。如果备份设计包括每周完整备份和每日差异备份，则日志 LUN 需要大于整周日志文件的空间，以允许在还原期间进行备份和重播。

移动邮箱操作

移动邮箱是大型邮箱部署的主要容量因素。许多大型公司每夜或每周将一定百分比的用户移动到不同的数据库、服务器或网站。如果您的组织也是如此，您可能会发现为日志 LUN 多提供一些空间以容纳用户迁移是非常必要的。尽管源服务器会记录小型记录删除，目标服务器仍必须先将所有传输数据写入事务日志。如果一天生成 10 GB 的日志文件，并且将 30 GB 的缓冲区保留 3 天，则移动 50 个 2 GB 的邮箱 (100 GB) 将填满目标日志 LUN 并导致停机。在上述情况下，可能必须为日志 LUN 分配额外容量以支持移动邮箱。

日志增长因子

对于大多数部署来说，我们建议您在创建日志 LUN 时向日志大小增加 20% 的开销因素（考虑其他所有因素之后），这样可以确保出现意外的日志生成时存在必要的容量。

邮箱容量规划示例

以下示例说明在群集连续复制 (CCR) 环境下，单个群集邮箱服务器上有 4,000 个 1 GB 的极重邮件配置文件邮箱时的适当 LUN 大小。这些邮箱平均每周接收 52 MB 的邮件，平均邮件大小为 50 KB。下表提供了确定实际邮箱大小的值示例。

用于确定磁盘上实际邮箱大小的值示例

邮箱大小	垃圾站大小（2 周）	空白空间	磁盘总大小
1 GB	104 MB (2 × 52 MB)	7.3 MB	1.11 GB (+ 11%)

在此环境中，每个用户将占用 1.11 GB 磁盘空间。因为在 CCR 环境中建议的最大数据库大小为 200 GB，所以在服务器的每个数据库中驻留的邮箱数不应超过 180 个。若要支持 4,000 个邮箱，则必须有 23 个数据库，并且此环境中还应有 23 个存储组。因为 CCR 环境需要每个存储组对应一个数据库，每个数据库位于自己的存储组中。这导致每个存储组的最终邮箱计数为 174。根据邮箱的数量以及邮箱的实际大小，数据库大小为 193 GB，如下表所示。

数据库容量要求

每个数据库的邮箱数	数据库总数	数据库大小要求
174	23	193 GB

若要确保邮箱不会由于空间分配问题而经受任何中断，也需要调整事务日志的大小以容纳将在备份集期间生成的所有日志。许多使用每日完整备份策略的组织规划在备份失败时将每天生成日志的速率提高到三倍。使用每周完整备份然后使用差异备份或增量备份时，需要至少一周的日志容量才能执行还原。每个极重负载邮件配置文件邮箱平均每天生成 42 个事务日志，因此 4,000 个邮箱服务器将每天生成 168,000 个事务日志。这意味着每个存储组将生成 7,304 个日志。每周在一天（星期六）移动 10％ 的邮箱，且备份制度包括每周完整备份和每日增量备份。此外，在不截断日志的情况下，服务器还可以承受三天。如下表所示，该服务器要求每个存储组的空间为 38.8 GB。

日志容量要求

每个存储组中的日志	日志文件大小	每天日志大小	移动邮箱大小	增量还原大小	日志大小要求
7,304	1 MB	7.13 GB	17 GB (17 × 1 GB)	21.4 GB (3 × 7.13 GB)	38.8 GB (17.4 + 21.4)

事务日志 LUN 需要足够大以便处理邮箱移动操作生成的日志，并需要拥有足够的空间来还原整周的日志。

事务性 I/O

事务 I/O 是由使用服务器的用户导致的磁盘 I/O。例如，接收、发送和删除邮件都会产生磁盘 I/O。高磁盘延迟会直接影响没有使用缓存 Exchange 模式的 Microsoft Outlook 用户，这也是存储设计中应考虑的最重要因素之一。对于存储，已降低了事务性 I/O 要求，且通过连续复制，高可用性不再意味着必须使用昂贵的光纤通道存储（尽管这仍是非常好的解决方案）。

了解 IOPS

在早期版本的 Exchange Server 中，调整存储大小所需的主要指标之一是每个用户每秒占用的数据库 I/O 量 (IOPS)。若要测量用户 IOPS，请用存储组的数据库 LUN 上的 I/O 总量（读取和写入）除以该存储组中的用户数。例如，1,000 个用户在数据库 LUN 上产生了 1,000 个 I/O 表示每个用户的 IOPS 为 1.0。

衡量基线 IOPS

如果正在使用早期版本的 Exchange Server，且已计算出基线 IOPS，则请记住 Exchange 2007 将从以下方面影响基线：

• 服务器上的用户数将影响每个用户的总数据库缓存。

• RAM 量将影响数据库缓存可增长的大小，数据库缓存越大，缓存读取命中越多，从而会减少您的数据库读取 I/O。

关键是要明白不能根据特定服务器上的 IOPS 对整个企业进行规划，因为每个服务器上的 RAM 量、用户数和存储组数很可能不同。获得实际的 IOPS 数之后，应始终对计算值增加 20％ 的 I/O 开销因素以获得一些富余空间，否则，活动重于正常情况就会降低用户体验。

数据库缓存

运行 64 位版本 Exchange 2007 的 64 位 Windows Server 操作系统将显著增加虚拟地址空间，并允许 Exchange 增加其数据库缓存、减少数据库读取 I/O，以及每个服务器最多支持 50 个数据库。

数据库读取减少取决于服务器的可用数据库缓存量和用户邮件配置文件。有关内存和存储组的指导，请参阅规划处理器配置。与 Exchange 2003 相比，按照该主题中的指导最多可减少 70％ 的事务 I/O。每个用户的数据库缓存量是实际 I/O 减少的主要因素。

下表说明了比较 Exchange 2003 中有默认的 900 MB 与 Exchange 2007 中每个用户有 5 MB 的数据库缓存时，每个用户的实际数据库缓存增加情况。正是此额外数据库缓存提高了在缓存中的读取命中率，从而减少了磁盘级别的数据库读取数。

基于邮箱数的数据库缓存大小

邮箱数	Exchange 2003 数据库缓存/邮箱 (MB)	Exchange 2007 数据库缓存/邮箱 (MB)	基于 Exchange 2003 的数据库缓存增加
4,000	0.225	5	23 倍
2,000	0.45	5	11 倍
1,000	0.9	5	6 倍
500	1.8	5	3 倍

预测 Exchange 2007 基线 IOPS

可用于预测 Exchange 2007 数据库 IOPS 的两个最主要因素是每个用户的数据库缓存量和每个用户每天发送和接收的邮件数。以下公式基于在缓存 Exchange 模式下使用 Office Outlook 2007 的标准工作者，并已经过测试，其准确性在正负 20％ 范围内。其他客户端类型和使用方案可能产生不准确的结果。该预测仅对介于 2 MB 和 5 MB 之间的用户数据库缓存大小有效。尚未使用每天发送和接收多于 150 封邮件的用户对该公式进行验证。虽然用于公式验证的平均邮件大小为 50 KB，但邮件大小并非 IOPS 的主要因素。

下表提供了每个用户 IOPS 的估计值，可用于预测基线 Exchange 2007 IOPS 要求。

基于用户配置文件和邮件活动的每个用户的数据库缓存和估计 IOPS

用户类型（使用情况配置文件）	每天大约发送/接收 50 KB 的邮件大小	每个用户的数据库缓存	每个用户的估计 IOPS
轻负载	发送 5 次/接收 20 次	2 MB	0.11
平均负载	发送 10 次/接收 40 次	3.5 MB	0.18
重负载	发送 20 次/接收 80 次	5 MB	0.32
极重负载	发送 30 次/接收 120 次	5 MB	0.48
超重负载	发送 40 次/接收 160 次	5 MB	0.64

若要估计数据库缓存大小，请从 Exchange 服务器中安装的内存总量中减去 2,048 MB（使用本地连续复制 (LCR) 时为 3,072 MB），然后用该内存量除以用户数。例如，对于拥有 3,000 位用户且 RAM 为 16 GB 的服务器，减去系统占用的 2 GB，剩下 14 GB 的 RAM，即每个用户 4.66 MB (14 GB ÷ 3,000 = 4.66 MB)。

知道每个用户的平均数据库缓存大小为 4.66 MB，以及平均每天发送和接收 60 封邮件，即可估计数据库读取和写入：

• 数据库读取   每天 60 封邮件乘以 0.0048，结果为 0.288。接下来，对每个邮箱的数据库缓存数量 (4.66 MB) 取 -0.65 次幂 (5 ^ -0.65)，结果为 0.3622。最后，将两个结果相乘，即得到每个用户 0.104 的数据库读取 (0.288 × 0.3622 = 0.104)。

• 数据库写入   用每个用户的邮件数 (60) 乘以 0.00152 即得到每个用户 0.0912 的数据库写入。

使用的公式为：

((0.0048 × M) × (D ^ -0.65)) + (0.00152 × M) = 总数据库 IOPS

其中，M 为每个用户的邮件数，D 为每个用户的数据库缓存。每个用户的总数据库 IOPS 是读取和写入之和，在此示例中为 0.189 IOPS：

((0.0048 × 60) × (4.66 ^ -0.65)) + (0.00152 × 60) = 0.189

下图演示了在运行具有 4,000 个 250 MB 邮箱的 Exchange 2007，从而模拟在 Exchange 模式下以及具有建议服务器内存的 Outlook 2007 时减少的数据库读取和写入。

与 Exchange Server 2003 相比，Exchange Server 2007 中的 IOPS 的减少

联机模式客户端的影响

与缓存的 Exchange 模式客户端不同，所有联机模式客户端操作都针对数据库。因此，读取 I/O 操作将增加对数据库的操作。因此，如果多数客户端将在联机模式下操作，应建立以下准则：

• 与缓存的 Exchange 模式客户端相比，250 MB 联机模式客户端将使数据库读取操作增加 1.5 倍。低于 250 MB，影响可以忽略不计。

• 随着邮箱大小加倍，数据库读取 IOPS 也将加倍（假设主要文件夹之间相同项目的分发仍然相同）。

下图演示了基于邮箱大小的 IOPS。

数据读取 IOPS 随着邮箱大小的增加而增加

测试也表明，增加每个邮箱数据库缓存超过 5 MB 将不会大量降低数据库读取 I/O 要求。下图描述了使用联机模式客户端的 2 GB 邮箱，以及增加缓存超过 5 MB 对降低数据库读取 I/O 要求的影响。

数据库读取 IOPS 减少每个邮箱缓存大小的增加

因此，对于该数据，有两个建议：

• 需要时部署缓存模式客户端。有关详细信息，请参阅下面的“每个文件夹的邮件计数”部分。

• 设计数据库存储时确保考虑 I/O 要求。

有关其他 IOPS 因素，如第三方客户端，请参阅 优化 Exchange Server 2003 的存储。

数据库读取/写入比率

在 Exchange 2003 中，数据库读取/写入比率通常为 2:1 或 66％ 的读取。使用 Exchange 2007，较大的数据库缓存将减少磁盘上数据库的读取数，从而导致读取以总 I/O 的某个百分比缩小。如果遵循建议的内存并使用缓存 Exchange 模式，则读取/写入比率应接近 1:1 或 50％ 的读取。

在联机模式下使用 Outlook 或使用桌面搜索引擎时，读取/写入比率在读取方面将略有增加（取决于邮箱大小）。在选择与写入具有重要成本关联的独立磁盘冗余阵列 (RAID) 类型（如 RAID5 或 RAID6）时，将更多写入作为总 I/O 的某个百分比具有特殊意义。有关为服务器选择适当的 RAID 解决方案的详细信息，请参阅存储技术。

日志数据库比率

在 Exchange 2003 中，存储组的事务日志需要大致相当于存储组中数据库 10％ 的 I/O。例如，如果数据库 LUN 使用 1,000 个 I/O，则日志 LUN 使用大约 100 个 I/O。由于 Exchange 2007 中数据库读取减少，并且日志文件大小缩小和支持更多存储组，日志/数据库写入比率大约为 3:4。例如，如果数据库 LUN 占用 500 个写入 I/O，则日志 LUN 将占用大约 375 个写入 I/O。

测量或预测事务日志 I/O 后，请考虑增加 20％ 的 I/O 开销因素以确保在比正常状态繁忙时有充足的富余空间。另外，使用连续复制时，必须读取已关闭的事务日志并将其发送到另一位置。此开销又会占用日志读取中的 10％。如果存储组的事务日志占用 375 个写入 I/O，则可以预计在使用连续复制时会额外增加 37.5 个读取 I/O。

每个文件夹的邮件计数

了解高项目计数和受限制视图数的性能影响说明关键文件夹中的邮件数以及正在使用的客户端类型和模式如何影响某些用户的磁盘性能。

减少服务器 I/O 的一种方式是在缓存 Exchange 模式下使用 Outlook 2007。最初的邮箱同步是一项高成本的操作，但随着时间的推移，邮箱大小不断增长，磁盘子系统的负担会从 Exchange 服务器转换到 Outlook 客户端。这意味着，即使用户的收件箱中有大量邮件或用户对邮箱进行搜索，对服务器产生的影响也是微乎其微的。这也意味着使用大型邮箱的缓存 Exchange 模式用户可能需要比使用小型邮箱的用户更快的计算机（取决于单个用户可接受性能的阈值）。当您部署在缓存的 Exchange 模式中运行 Outlook 2007 的客户端计算机时，请考虑以下与邮箱/.OST 大小相关的问题：

• 最多 5 GB：此大小能够在大多数硬件上提供良好的用户体验。

• 5 至 10 GB 之间：此大小通常取决于硬件。因此如果您的硬盘驱动器足够快并且 RAM 足够大，您将获得更好的体验。但是，较慢的硬盘驱动器，如便携式计算机上的硬盘或早期的固态硬盘 (SSD)，可能会在驱动器响应时发生应用程序暂停的情况。

• 大于 10 GB：使用此大小，大多数硬盘会出现短时暂停的情况。

• 非常大，如 25 GB 或更大：该大小会增加短时暂停的频率，特别是下载新的电子邮件时。您还可以使用“发送/接收”组来手动同步邮件。

注意：
此指南基于 Outlook 2007 Service Pack 1 或更高版本的积累更新程序的安装，如  Microsoft 知识库文章 961752，Description of the Outlook 2007 hotfix package (Outlook.msp):February 24, 2009（英文网页）中所述。

如是在使用缓存的 Exchange 模式下部署的 Outlook 2007 时出现与性能相关的问题，请参阅知识库文章 940226，How to troubleshoot performance issues in Outlook 2007（英文网页）。

处于联机模式的 Outlook Web Access 和 Outlook 都存储服务器数据副本的索引，并对服务器的数据副本进行搜索。对于中等大小的邮箱，这将导致同等大小的缓存 Exchange 模式客户端中，每个邮箱的 IOPS 大约增加一倍。对于大型邮箱，每个邮箱的 IOPS 甚至会更高。第一次按新方法排序视图时，将创建一个索引，产生许多数据库 LUN 的读取 I/O。活动索引的后续排序开销非常低。

当用户已超出 Exchange 将存储的索引数（对于 Exchange 2007 而言，为 11 个索引）后，实施此解决方案将非常困难。如果用户选择按新方式排序，则会创建第 12 个索引，这将导致额外的磁盘 I/O。由于未存储该索引，因此每次执行该排序时都将产生此磁盘 I/O 开销。由于此解决方案中可生成高 I/O，所以强烈建议您在核心文件夹（如“收件箱”和“已发送邮件”文件夹）中存储的项目不要超过 20,000 个。只要任一文件夹中的项目数不超过 20,000，则创建更多顶级文件夹或在“收件箱”或“已发送邮件”文件夹中创建子文件夹将显著降低创建此索引所导致的开销。有关项目计数如何影响邮箱服务器性能的详细信息，请参阅 建议的邮箱大小限制和 了解高项目计数和受限制视图数的性能影响。

注意：
UNRESOLVED_TOKEN_VAL(exBlog)

有关可用的改进的详细信息，请参阅知识库文章 968009，Outlook 2007 improvements in the February 2009 cumulative update（英文网页）。

非事务性 I/O

事务 I/O 的发生是对直接用户操作的响应，通常具有最高优先级，主要用于存储设计。事务 I/O 的减少使非事务 I/O 更加重要。使用大邮箱时，尤其是在使用 2 GB 邮箱的情况下，许多企业并不是仅使用户容量加一倍，有时，会使其增长十倍。例如，从 200 MB 增长到 2 GB。磁盘上的数据量像这样显著增加后，规划存储设计时必须考虑非事务 I/O。

内容索引

在 Exchange 2007 中，在收到邮件时即会对其进行索引，产生的磁盘 I/O 开销非常低。在 Exchange 2007 中搜索索引比在 Exchange 2003 中进行此搜索大约快 30 倍。

邮件记录管理

“邮件记录管理”(MRM) 是 Exchange 2007 中的新功能，帮助管理员和用户管理其邮箱。可以设置策略，以移动或删除达到特定阈值（如时间）的邮件。MRM 是在类似于备份和联机维护的同步读取操作中针对数据库运行的计划爬网。MRM 的磁盘开销取决于需要执行操作（例如，删除或移动）的项目数。

建议您不要在进行备份或联机维护的同时运行 MRM。如果您使用连续复制，可以将卷影复制服务 (VSS) 备份转移到被动副本，从而允许有更多的时间进行联机维护和 MRM，以便它们不会影响彼此或用户。

联机维护

数据库运行联机维护时会执行很多操作，如永久删除已删除邮件和执行数据库联机碎片整理。维护导致读取操作，而联机碎片整理导致读取和写入操作。完成维护所需的时间长度与数据库大小相对应，且可以成为允许数据库增长到多大的限制因素。有关联机维护的详细信息，请参阅 存储后台进程第 I 部分。

注意：
UNRESOLVED_TOKEN_VAL(exBlog)

备份和还原

管理员可以使用多种不同的备份和还原方法。备份和还原的主要指标是吞吐量，即每秒可复制到生产 LUN 和从生产 LUN 复制的 MB 数。确定吞吐量后，您需要判断它是否能充分满足备份和还原服务级别协议 (SLA) 的要求。例如，如果您需要能够在 4 小时内完成备份，则可能必须添加更多的硬件才能实现此目标。根据您的硬件配置情况，可能可以通过更改分配单位大小达到要求。这样有助于流式联机备份和 VSS 备份期间的 Exchange Server 数据库实用程序 (Eseutil.exe) 完整性检查。

在服务器有 2,000 个用户的情况下，将邮箱从 200 MB 增至 2 GB 会使数据库大小增加十倍。许多管理员都不习惯于必须在单个服务器上处理大量数据。可以考虑一个具有 2,000 个 2 GB 邮箱的服务器。在所用开销如上所示时，该服务器上的数据将超过 4 TB。假设您的备份速率可以达到 175 GB/小时（48 MB/分钟），则备份该服务器至少需要 23 个小时。对于不使用 LCR 或 CCR 的服务器，可使用另一种方法：每天对数据库的 1/7 执行完整备份，然后对剩余内容执行增量备份，如下表所示。

每周备份例程示例

备份类型	第 1 天	第 2 天	第 3 天	第 4 天	第 5 天	第 6 天	第 7 天
完整	DB 1-2	DB 3-4	DB 5-6	DB 7-8	DB 9-10	DB 11-12	DB 13-14
增量	DB 3-14	DB 1-2 DB 5-14	DB 1–4 DB 7–14	DB 1–6 DB 9–14	DB 1–8 DB 11–14	DB 1–10 DB 13–14	DB 1-12

从上面的表中可以看出，每晚备份的数据总量接近于 650 GB，若速率为 175 GB/小时，则完成备份需要 3.7 个小时。某些解决方案多于或少于此吞吐量。但是，大型邮箱可能需要采用其他方法。

如果使用 LCR 和 CCR，那么被动副本是第一道防线。如果主动副本和被动副本都出现故障或是因其他原因不可用，则只能从备份还原。恢复多天的增量日志会加长恢复操作所需的时间。因此，快速恢复解决方案（如 CCR 或 VSS 克隆）很少使用增量备份。如果使用 VSS 克隆，数据恢复的速度非常快，而且，为了使备份时间保持在备份 SLA 之内，增加一点时间来重播日志是可以接受的。

流式联机备份

如果使用流式备份，建议将流式 I/O（源和目标）分开，以便并发进行备份的多个存储组不会争用相同的磁盘资源。无论目标是磁盘还是磁带，每个硬件解决方案对物理磁盘和控制器的吞吐量限制都是唯一的。可能有必要将一些存储组相互隔离，以便最大程度地增加并发备份操作数和吞吐量，以尽量缩小备份窗口的大小。下表介绍了对 14 个数据库的两个并发备份示例。

并发备份例程示例

备份数量	LUN 1	LUN 2	LUN 3	LUN 4	LUN 5	LUN 6	LUN 7
第一个备份	存储组 (SG) 1	SG 2	SG 3	SG 4	SG 5	SG 6	SG 7
第二个备份	SG 8	SG 9	SG 10	SG 11	SG 12	SG 13	SG 14

如果将存储组 LUN 相互隔离，如上表所示，则可以并发运行流式备份（每个 LUN 中运行一个备份）。每个 LUN 上的第一个存储组中的备份作业应在第二个存储组开始备份之前完成，以隔离备份流。在同一物理磁盘上执行两个流式备份作业可能并不会使速度加倍，但如果按每秒的 MB 数算，应比单个流式备份任务快。

VSS 备份

Exchange 2007 使用 Windows Server 2003 中包含的 VSS 生成数据库和事务日志文件的卷影副本。有关 VSS（包括克隆和快照技术）的详细信息，请参阅 使用 Exchange Server 2003 的卷影复制服务的最佳实践。Exchange 2007 中的新增功能是可以为 LCR 或 CCR 环境中运行的存储组的被动副本生成 VSS 副本。在这些环境中，从被动副本拍摄 VSS 快照会在备份的校验和完整性检查阶段和到磁带或磁盘的后续复制期间删除主动 LUN 上的磁盘负载。还会使主动 LUN 上有更多时间运行联机维护、MRM 和其他任务。

LUN 和物理磁盘

在很多情况下，操作系统所识别的物理磁盘或 LUN 是从用于向操作系统提供磁盘的硬件中提取的。出于提高性能和恢复能力的原因，在 LUN 和物理磁盘这两个级别上将事务日志文件与数据库文件分开始终是至关重要的。在同一物理磁盘上既执行随机磁盘 I/O 又执行顺序磁盘 I/O 会显著降低性能，从恢复角度看，将存储组的日志文件和数据库文件分开可确保一组物理磁盘的灾难性故障不会导致数据库文件和日志文件都丢失。

在 Exchange 2007 中，最好将一个存储组中的所有数据库放到同一物理 LUN 中。每个存储组最多放置一个数据库也是一种最佳实践。Exchange 数据库 I/O 是随机的，在物理磁盘执行相同的工作量时，对大多数存储子系统有利。很多存储阵列经过专门设计，使多个物理磁盘首先汇集为一个磁盘组，然后利用该磁盘组的可用空间创建 LUN 并将其跨每个物理磁盘均匀分布。备份某个存储组的数据库 LUN 的目标物理磁盘也备份其他 LUN（这些 LUN 存储其他存储组和服务器的数据库），这是可以接受的。同样，将每个存储组的事务日志 LUN 隔离到单独的物理心轴上并不重要，虽然丢失顺序 I/O 会对性能造成轻微影响。

如果在单个服务器上配置了最大数目（50 个）的存储组，那么每个存储组会得到其自己的事务日志 LUN 和数据库 LUN。这超过了可用的驱动器号数目，因而必须使用 NTFS 文件系统卷装入点。配置为连续复制的 50 个存储组需要 200 个 LUN，这将超过某些存储阵列的最大值，在进行 LCR 时尤其如此，因为在这种情况中所有这 200 个 LUN 都需要提供给一个服务器。随着 LUN 数目的增长，监视变得更加重要，因为磁盘空间不足会导致卸除存储组。

LUN 设计

在许多情形下，操作系统识别出的 LUN 是从实际上位于该磁盘后面的物理硬件上提取的。对于提高性能和可恢复性而言，在 LUN 和物理磁盘这两个级别上都将事务日志与数据库分开始终是很关键的。在某些存储阵列上，在同一物理磁盘上既执行随机 I/O 又执行顺序 I/O 会降低性能。从恢复角度来讲，将存储组的事务日志和数据库分离可确保一组特定的物理磁盘的灾难性故障不会导致数据库和事务日志都丢失。

Exchange 数据库 I/O 随机分配，当各物理磁盘执行相同的工作量时，对大多数存储子系统都有利。许多存储阵列都使用虚拟存储，以便多个物理磁盘首先集中到一个磁盘组中，然后在该磁盘组中的可用空间中创建 LUN 并将其均匀分配给每个物理磁盘。不使用连续复制时，备份某个存储组的数据库 LUN 的目标物理磁盘也备份其他 LUN（这些 LUN 存储其他存储组和服务器的数据库），这对物理磁盘来说是可以接受的。同样，即使丢失顺序 I/O 会对性能造成轻微影响，将每个存储组的事务日志 LUN 隔离到单独的物理心轴上也并不重要。将相同存储组中的日志 LUN 和数据库 LUN 隔离到单独的物理磁盘很重要。当您请求 30 IOPS 和 5％ 的容量时，无法将两个或四个 500 GB 的物理磁盘专用于单个存储组的事务日志 LUN。

虽然可以使用多种方法设计 Exchange 2007 中的 LUN，但建议采用以下两种设计来限制复杂性：

• 每个存储组两个 LUN

• 每个备份集两个 LUN

每个存储组两个 LUN

为一个存储组创建两个 LUN（一个用于日志，一个用于数据库）对 Exchange 2003 来说是标准的最佳实践。如果使用 Exchange 2007，并且是在最多 50 个存储组的情况下，则您提供的 LUN 的数目取决于备份策略。如果您的 RTO 很小，或者如果您将 VSS 克隆用于快速恢复，则最好是将每个存储组置于其自身的事务日志 LUN 和数据库 LUN 中。由于此方法将超出可用的驱动器号个数，因此必须使用卷装入点。

此策略的一些好处包括：

• 在存储组级别启用基于硬件的 VSS，从而实现单个存储组备份和还原。

• 具有在不同存储组之间隔离性能的灵活性。

• 增强可靠性。单个 LUN 上出现容量问题、损坏问题或病毒问题只会影响一个存储组。

此策略中需要关注的一些事项包括：

• 使用连续复制的 50 个存储组可能需要 200 个 LUN，这会超出某些存储阵列的最大值，在需要将全部 200 个 LUN 都提供给一个服务器的 LCR 环境下尤其如此。

• 为每个存储组提供一个单独的 LUN 会导致每个服务器的 LUN 数增加，从而增大了管理成本。

每个备份集两个 LUN

备份集是在一夜内完整备份的一定数目的数据库。如果一种解决方案每夜对数据库的 1/7 执行完整备份，则它可以通过将要备份的所有存储组放到同一日志和数据库 LUN 上来降低复杂性。这样可减少服务器上的 LUN 数。

此策略的一些好处包括：

• 简化了存储管理，因为要管理的 LUN 更少。

• 可能会减少备份作业的数量。

此策略中需要关注的一些事项包括：

• 限制了执行基于硬件的 VSS 备份和还原的能力。

• 限制会对容量规模产生影响，原因是主启动记录 (MBR) 分区的限制为 2 TB。

卷装入点

在许多情况下（如在多节点单一副本群集 (SCC) 中），需要的 LUN 数量多于可用的驱动器号数量。在这些情况下，必须使用卷装入点。驱动器号是用于识别分区或磁盘的旧版 MS-DOS 操作系统功能，最好避免使用过多的驱动器号。相对来讲，将所有事务日志 LUN 和数据库 LUN 置于卷装入点上以方便管理要容易得多。如果您有 20 个存储组，每个存储组带有一个数据库，这时会很难记住哪个驱动器号驻留有数据库 17。下表显示了一个使用卷装入点的示例。

使用卷装入点的文件夹布局示例

事务日志 (L:)	数据库 (P:)
L:\SG1LOG	P:\SG1DB
L:\SG2LOG	P:\SG2DB
L:\SG3LOG	P:\SG3DB
L:\SG4LOG	P:\SG4DB

在此示例中，L:和 P: 是定位 LUN，分别驻留所有的日志 LUN 和数据库 LUN。这些驱动器上的每个文件夹都是单独 LUN 的卷装入点。

基于硬件的 VSS

使用基于硬件的 VSS 时，对于将 Exchange 数据放置在 LUN 上有以下几点建议。对于基于硬件的 VSS 解决方案，每个事务日志 LUN 和数据库 LUN 应只存放来自所选备份集的文件。如果要在不影响其他所有存储组的情况下恢复某个存储组，则每个存储组都需要单独的事务日志 LUN 和数据库 LUN。如果要通过使其他数据库和存储组脱机来恢复单个数据库，您可以将多个存储组置于单个的事务日志 LUN 和数据库 LUN 上。

基于软件的 VSS

使用基于软件的 VSS 时，备份是一个两步策略，对大型邮箱和连续复制而言尤其如此。首先，拍摄 VSS 快照，然后将平面文件导流向磁盘或磁带。

LUN 可靠性

将存储组的事务日志和数据库放在单独的物理磁盘上总是很重要的，因为该操作可增加可靠性。使用连续复制，将主动 LUN 和被动 LUN 隔离到完全独立的存储上同样很重要。如果使用 CCR 和 LCR，在主存储发生灾难性故障时您需要具备存储恢复能力。

LUN 示例

请考虑以下方案，此方案基于以上的容量示例构建并将上述信息应用到了 LUN 的创建中。在此示例中，备份制度是每日一次的完整备份。您需要启用内容索引，并将其放到数据库 LUN 上。193 GB 的 5% 大约是 10 GB。您需要将此值添加到最终 LUN 大小。193 GB 的增长因子应该是最终数据库大小的 20%。193 GB 的 20% 是 39 GB。结果如下表所示。

用于确定数据库 LUN 大小的值示例

数据库大小	增长因子	内容索引	数据库 LUN 大小
193 GB	39 GB	10 GB	241 GB

每个存储组每天创建 7.13 GB 的日志，而您需要存储至少 3 天的日志。

用于确定日志 LUN 大小的值示例

日志（1 天）	日志（3 天）
7.13 GB	21.4 GB

移动邮箱

我们的示例组织每周移动邮箱的 10%，并在星期六移动所有邮箱内容；这样，日志 LUN 必须在某一天处理整个负载。Microsoft 使用的移动邮箱策略是将加入的用户平均分布到各个存储组。这意味着具有 4,000 位用户的示例服务器每个星期六都要移动大约 400 位用户。如果使用 23 个存储组，则每个存储组都必须接收 17 个 1 GB 的邮箱，如下表所示。

用于确定移动邮箱日志 LUN 大小的值示例

日志（3 天）	邮箱移动	日志 LUN 大小
21.4 GB	17.64 GB（17 个 1 GB 用户）	46.6 GB (38.8 GB + 20%)

使用此布局，您永不能在一天内将 17 位以上的用户移动到存储组。因此，如果某天需要移动超过 10％ 的用户，则增加日志 LUN 的大小将显得更有意义。

连续复制对存储设计的影响

连续复制是 Exchange 2007 中的一项新功能，使用该功能可将存储组的数据库和日志文件复制到辅位置。在新事务日志关闭或已满时，将其复制到辅位置并进行验证，然后将其重新写入数据库的被动副本中。若要获得存储弹性，建议将被动副本放置在一个与实际的生产 LUN 完全隔开的存储阵列中。由于出现故障时根据被动副本处理生产负载，因此被动副本的存储应与存储组的主动副本使用的存储解决方案的性能和容量相匹配。

使用连续复制时，每个存储组只能包含一个数据库，因此每个数据库副本将需要四个 LUN。每个数据库副本都将位于各自的存储组中，存储组需要用于主动副本的单独日志和数据库以及用于被动副本的单独日志和数据库。

最佳实践是：

• 将存储隔离到硬件级别的各个 LUN 中，并且不在操作系统内创建 LUN 的多个逻辑分区。

• 将事务日志和数据库隔离，并将它们存放在单独的物理磁盘上以增加容错能力。

• 将主动 LUN 和被动 LUN 隔离到完全不同的存储阵列上，以使存储不是单点故障。

• 如果驻留存储组或数据库来自同一存储阵列上的多个群集邮箱服务器，则应该确保使用单独的物理磁盘构建每个 LUN。

存储设计还应通过将存储控制器隔离在不同的外围组件互连 (PCI) 总线上来最大化容错能力。此外，应将被动副本的存储设计为在容量和性能方面与主动副本使用的存储相匹配。在主动副本的存储发生灾难性故障时，被动副本的存储是第一道防线，发生故障转移时，被动副本将变为主动副本。将被动副本的 LUN 放置在完全不同的存储硬件上，可确保对被动副本执行任何操作都不会影响主动副本。

使用连续复制时，将发生更多事务 I/O。计算服务器大小时，必须考虑此因素。主动事务日志是按顺序写入的内容，必须在其关闭后读取并将其复制到副本事务日志 LUN 隔离文件夹。该日志必须在副本位置进行检验，然后将其移动到副本 LUN 上的最终目标位置。最后，读取日志并将其写入数据库。主动和副本事务日志的 LUN 必须读取，并几乎 100% 按顺序写入在独立的邮箱服务器上找到的活动。此更改行为可能要求评估存储控制器上的缓存设置。建议的设置为，在由电池供电的存储控制器上 25％ 用于读取，75％ 用于写入。

连续复制和数据库大小

使用连续复制时可以使用更大的最大数据库大小。建议 Exchange 2007 使用以下最大数据库大小：

• 不使用连续复制时邮箱服务器上驻留的数据库：100 GB

• 使用连续复制和 Gigabit 以太网时邮箱服务器上驻留的数据库：200 GB

  注意：
  大型数据库可能还需要较新的存储技术以提供更高的带宽来满足修复方案的要求。

  要点：
  数据库实际的最大大小应由您的组织已有的 SLA 决定。确定可在组织的 SLA 中指定的时间段内备份和还原的最大大小的数据库，就是确定数据库最大大小的方法。

LCR 存储选项

LCR 启用单个服务器上的日志传送。如果存放数据库的主动副本或日志文件的存储发生灾难性故障，管理员可以手动激活数据库的被动副本。被动副本的存储应完全与主动副本的存储隔离。此外：

• 控制器卡应该位于不同的 PCI 总线上。

• 每个存储解决方案都应具有自已的不间断电源 (UPS)。

• 每个存储解决方案都应位于单独的电路上。

CCR 存储选项

CCR 启用主动/被动故障转移群集中的被动节点日志传送。通过将日志传送到一个完全不同的服务器上并在那里维护被动副本，将降低操作时对主动节点的影响并在服务器上拥有容错能力。

在地理位置分散的 CCR 部署中，被动副本可以位于不同于主动节点的物理位置中的某个节点上，由此提供网站弹性。虽然 Exchange Server 多网站数据复制的部署指南 文章中的信息仍适用，但在连续复制后基于请求的技术意味着高延迟不会影响用户体验。这与地理位置分散的群集解决方案形成了鲜明的对比，在该解决方案中，同步复制延迟对活动的服务器有消极的影响。使用 CCR 时，复制过程可能在后面运行，从而增加了主动副本和被动副本不同步的时间。不过，如果灾难影响了主动副本，没有复制到被动节点的任何邮件都是可恢复的，这是因为集线器传输服务器提供了传输垃圾站功能。

单一副本群集存储选项

用于 SCC 的硬件必须列在 Windows 服务器编录的群集类别中。地理位置分散的 SCC 中使用的硬件必须列在 Windows 服务器编录中的地理位置分散的群集类别中，才能受到支持。

使用共享存储的群集邮箱服务器具有与独立服务器相同的功能存储注意事项。在使用同步复制时，可能会在复制过程中人为地增加磁盘延迟。必须最大化存储阵列中的复制点。有关 SCC 的复制的详细信息，请参阅 Exchange Server 多网站数据复制的部署指南。