Exchange 2010 邮箱服务器角色设计示例

适用于： Exchange Server 2010 SP2, Exchange Server 2010 SP3

上一次修改主题： 2016-11-28

本主题将介绍一个关于如何确定邮箱服务器角色及其随附的体系结构的适当内存、容量、I/O 和 CPU 性能要求的示例。

您可以使用 Exchange Server 2010 邮箱服务器角色要求计算器，通过指定一组输入要素来确定邮件服务器角色的适当要求。该计算器可以确定在此示例中所讨论的要求。有关此计算器（和下载此计算器）的详细信息，请参阅 Exchange Server 工作组博客文章 Exchange 2010 邮件服务器角色要求计算器。

注意：
每个博客的内容及其 URL 如有更改，恕不另行通知。每个博客中的内容均“原样”提供，既不承担任何担保，也未赋予任何权利。对包含的脚本示例或代码的使用受 Microsoft 使用条款中指定的条款的约束。

有关邮箱服务器角色存储设计的详细信息，请参阅邮箱服务器存储设计。

本示例中所用方案是三个使用 JBOD（只是一批磁盘）存储的数据库副本解决方案。对于此示例，请考虑以下的体系结构要求：

• 参与单个数据库可用性组 (DAG) 的六个邮箱服务器

• Exchange 邮箱服务器还承载集线器传输服务器和客户端访问服务器角色

• 三个高可用性邮箱数据库副本，无延迟数据库副本

• 使用 7.2 K (7,200 RPM) 1 TB 的 SATA 心轴

• JBOD 存储配置（1 逻辑单元号 (LUN)/数据库 LUN 体系结构）

• 对于备份体系结构，使用通过单个项目恢复和邮箱弹性提供的本机数据保护功能

• 部署还原 LUN，用于维护和恢复操作

• 每个 LUN 具有至少 20% 的可用空间

• 该解决方案应经受得住双重服务器故障事件

• 安装的唯一服务器角色是邮箱服务器角色

目录

邮箱容量要求

数据库副本要求

邮箱内存要求

邮箱 I/O 要求

邮箱 CPU 要求

邮箱容量要求

以下示例说明某个环境的适当大小的确定，该环境中有每天 24,000 个 100 封 2 GB 邮件的配置文件邮箱，这些邮箱分布于六个邮箱服务器中，而这些服务器参与了 DAG（其中每个数据库具有三个副本）。这些邮箱平均每个工作周（每周五个工作日）接收 37 MB 的邮件，平均邮件大小为 75 KB。单个项目恢复已启用，并具有 14 天已删除邮件保留时间窗口。下列计算用于确定邮箱大小：

邮箱大小 = 邮箱限制 + 空白空间 + 垃圾站

空白空间 = 每天 100 封邮件 x 75/1024 MB = 7.32 MB

垃圾站 =（每天 100 封邮件/天 x 75/1024 MB * 14 天）+ (2048 MB x 0.012) + (2048 MB x 0.03) = 188.6 MB

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

因为此环境利用 JBOD 存储，所以可部署的最大数据库大小取决于磁盘的大小。若要确定 JBOD 方案的最大数据大小，请使用以下公式，其中 1TB 磁盘格式化后的容量为 931 GB，可用空间百分比要求为 20%，内容索引百分比为 10%：

最大数据库大小 = [格式化后磁盘容量 x (1 – 可用空间百分比要求)] / (1 + 内容索引百分比)

= [931 GB x (1 - 0.2)] / ( 1+ 0.10)

= 744.8 GB / 1.1

= 677 GB

在此环境中，每个用户的邮箱将占用 2.25 GB 磁盘空间。若要支持 24,000 个邮箱（数据库大小为 677 GB），必须具有 102 个数据库。此要求将导致每个数据库最多有 235 个邮箱。

但是，因为该解决方案使用的是 JBOD 存储体系结构，所以必须确保每个数据库的邮箱数目不超过单个磁盘上可实现的随机 I/O 的数量。因为该解决方案使用的是大形状因数 7.2K SATA 心轴，所以在充分利用该心轴时可以实现最多 55 个每秒随机 I/O (IOPS)。在 20% I/O 开销增长缓冲区中进行因数分解，这意味着心轴总共可以处理 44 个随机 IOPS。

如果用户群具有每天 100 封邮件配置文件，每个邮箱预计耗用 0.1 IOPS，因此磁盘最多可以支持 440 个使用该 IOPS 配置文件的邮箱。因为容量计算确定了最多可支持 235 个邮箱，少于根据 IOPS 配置文件确定的 440 个邮箱，所以该解决方案可在单个磁盘上部署。

若要确定实际的数据库大小，请使用以下公式：

数据库大小 = 邮箱数目 x 磁盘上的邮箱大小 x 数据库开销增长因子

根据邮箱数目、邮箱实际大小和 20% 的数据库开销增长因子，数据库大小为 619 GB，如下表所示。

数据库容量要求

若要确保邮箱服务器不会由于空间分配问题而经受任何中断，也需要调整事务日志的大小以容纳将在备份集期间生成的所有日志。如果该体系结构使用邮箱弹性和单个项目恢复功能作为备份体系结构，日志容量应分配三次每日日志生成速率，以防三天内未修复失败的副本。（任何失败的副本都会防止日志截断的发生。）

一个每天 100 封邮件的配置文件邮箱平均每天生成 20 个事务日志，所以 24,000 个邮箱的环境每天将生成 576,000 个事务日志。因此，每个数据库每天将生成 5,647 个日志。每周一天（周六）移动 1% 的邮箱。该解决方案使用 Exchange 内的本机数据保护功能，因此不执行备份且其大小调整为可容纳三天的数据量而不发生日志截断。

如下表所示，该服务器要求每个数据库副本的空间为 23 GB。

日志容量要求

如果这是具有三个副本的邮箱弹性和 JBOD 配置，则每个数据库及其相应的事务日志将放置在相同的 LUN 上。所需的 LUN 大小为：

LUN 容量 = 数据库大小 ÷ (1 - 可用空间百分比要求)

=（数据库大小 + 事务日志大小 + 内容索引大小） ÷ (1 - 0.2)

= (619 GB + 23 GB + 61.9 GB)/0.8

= 879 GB

确定所需的 LUN 大小

返回顶部

数据库副本要求

如果总共需要 102 个数据库支持 24,000 个邮箱，并且每个数据库具有三个副本，则 DAG 将总共支持 306 个数据库。有 306 个数据库分布于六个邮箱服务器上，这意味着每个邮箱服务器将存放 51 个数据库副本。数据库副本在 DAG 中服务器间的分布方式应为：服务器级故障使主动数据库将故障尽可能转移至其余服务器（数据库副本以不对称方式分布）。

若要最大程度地提高参与 DAG 的邮箱服务器的效率，主动数据库应在所有邮箱服务器上均匀分布。结果，当所有六个邮箱服务器都运行时，每个服务器应驻留 17 个主动服务器副本。

如果单个邮箱服务器发生故障，17 个数据库将重新分布在其余邮箱服务器上，使每个服务器的主动数据库副本数增加至 21。

如果两个邮箱服务器发生故障，则 34 个数据库将重新分布在其余邮箱服务器上，使每个服务器的主动数据库副本数增加至 26。正是此主动副本计数将用于确定邮箱服务器的内存大小和 CUP 要求。

有关如何在邮箱服务器间分布数据库副本的详细信息，请参阅数据库副本布局设计。

返回顶部

邮箱内存要求

使用 100 封邮件/天的邮件配置文件时，每个邮箱用以支持数据库缓存需要的最小内存为 6 MB。在每个服务器的主动邮箱数据库数为 26 的最坏情况下，每个服务器无法驻留总计 6,110 个的实时邮箱。此外，每个服务器共有 51 个数据库。邮箱服务器至少需要 12 GB 的数据库缓存。因此，支持数据库缓存所需的内存容量为：

最小所需数据库缓存 = MAX（（实时邮箱数目 x 所需内存/邮箱），数据库的最小内存）

= MAX (6110 x 6/1024 GB, 12 GB)

= MAX (36 GB, 12 GB)

= 36 GB

在部署多角色体系结构时，根据了解邮箱数据库缓存中的表格，支持此配置所需的物理内存总量为 64 GB。

返回顶部

邮箱 I/O 要求

每个邮箱每天发送或接收 100 封邮件。因此，每个邮箱具有 0.1 的 IOPS 配置文件。每个数据库可容纳 235 个邮箱。因此，数据库卷 I/O 总量为：

数据库卷 I/O = 邮箱数目 x IOPS 配置文件 x（1 + I/O 开销增长因子）

= 235 x 0.1 x 1.2

= 28.2 IOPS

此体系结构的数据库读取 I/O 百分比为 60%。因此，每个数据库卷生成的读取 I/O 为 16.92 IOPS，写入 I/O 为 11.28 IOPS。

在该体系结构中，每个日志流生成 50% 的数据库写入 I/O。因此，每卷的日志写入 I/O 为 5.64 IOPS。

26 个主动数据库副本也生成等于 10% 的日志写入 I/O 的日志读取 I/O；因此，这些数据库的日志读取 I/O 为 0.56 IOPS。

考虑到每个大形状因数 7.2K SATA 磁盘生成 55 个随机 IOPS，因此无需担心磁盘无法处理数据库的 I/O 要求。

返回顶部

邮箱 CPU 要求

在双重服务器故障事件期间，其余每个服务器驻留 26 个数据库，而每个服务器总共有 6,110 个主动邮箱。根据邮箱服务器处理器容量规划中得出的计算结果，每个服务器具有以下 CPU 兆周期要求。

确定 CPU 兆周期要求

如果所选服务器平台总共可以支持 26,400 个兆周期，则服务器 CPU 平台可在双重服务器故障事件期间支持该环境。

返回顶部

 © 2010 Microsoft Corporation。保留所有权利。