邮箱服务器处理器容量规划

Exchange 2010
 

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

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

由于 Microsoft Exchange 中提供了邮箱恢复机制,因此邮箱服务器容量规划与以前的 Exchange Server 2010 版本相比发生了重大变化。Exchange 2010 已围绕“邮箱恢复”这一概念进行了重新设计,其中更改了体系结构,因此现在可在个别邮箱数据库级别(而非服务器级别)提供自动故障转移保护。影响邮箱服务器角色容量规划处理的主要更改有两个:

  • 在同一台服务器上托管主动和被动的数据库副本

  • 提供数据库副本数

可以使用本主题中的信息更好地了解这些更改,并将这些信息作为配置邮箱恢复时计算邮箱服务器大小的设计指导。

目录

在同一台服务器上托管主动和被动的数据库副本

数据库副本计数

设计步骤

在 Exchange 2010 中,如果对服务器配置邮箱恢复,那么可以在同一服务器上托管主动和被动的数据库副本。每个服务器上的处理器将为主动邮箱(托管在已安装的主动数据库上)以及被动邮箱(托管在被动数据库上)的工作负荷提供服务。执行 Exchange 2010 邮箱容量规划时,必须考虑被动邮箱和数据库的处理器需求。被动数据库副本使用 CPU 资源检查或验证重复的日志、将重复日志重播到数据库中并维护与数据库副本相关联的内容索引。通常托管每个被动邮箱(托管在被动数据库副本上)等同于托管主动邮箱(托管在主动数据库副本上)所需使用的 CPU 的 15%。

Exchange 2010 邮箱容量规划关键的一点是,为实现邮箱恢复进行配置时,确定对每个服务器计划激活多少数据库副本。您可以从一系列设计中进行选择,但是我们建议您使用以下模型:

  • 针对所有已激活数据库副本的设计    在此模型中,将服务器设计为可处理 100% 正成为主动副本的托管数据库副本。

  • 针对目标故障情况的设计   在此模型中,将服务器设计为在最糟糕的故障情况时处理主动邮箱负载。

有关详细信息,请参阅以下主题:

返回顶部

使用 Exchange 2010 邮箱恢复,可以配置多个数据库副本(每个数据库最多 16 个副本)。每多一个数据库副本,都将增加托管主动副本的服务器必须执行的 CPU 工作。具有活动副本的服务器上的额外工作主要是复制日志和建立内容索引,因为每个被动副本都将检索内容以从活动副本建立索引。

每多一个数据库副本,都必须将托管主动数据库副本的服务器的每个邮箱 CPU 需求增加 10%(例如,一个副本 = 10%,两个副本 = 20%,依此类推)。此因子只适用于托管主动数据库副本的服务器的 CPU 需求。此计算不适用于托管被动数据库副本的 CPU。有关详细信息,请参阅了解处理器配置和 Exchange 性能

返回顶部

由于采用新的计算大小因子,因此配置邮箱恢复时,需要额外的步骤以计算邮箱服务器的大小。一般步骤如下:

  1. 请考虑整体解决方案体系结构的高可用性要求。请考虑邮箱恢复或独立的解决方案、站点恢复、所需数据库副本的数量以及处理一般故障情况的服务器或数据库可用性组 (DAG) 的数量。

  2. 如果使用邮箱恢复,那么请选择要设计的数据库激活模型。(设计用于目标故障情况,或设计用于已激活的所有数据库副本。)

  3. 使用下表来根据设计估算 CPU 和内存需求。请考虑主动邮箱的 CPU 和内存需求、被动邮箱的 CPU 需求以及主动邮箱上额外数据库副本的 CPU 需求。请使用激活模型选择定义设计可以容纳的邮箱的最大数量。

下表提供了基于用户配置文件的估算值。估算值是根据知识工作者工作日两个小时的峰值时间段(例如从 10:00 直到正午)计算得出的。以每天 8-10 小时计算,该峰值时间段的工作量通常是平均工作量的两倍。已忽略用户配置文件描述,因为随着电子邮件使用的增多,配置文件的范围也已扩大。

每个邮箱数据库的缓存、IOPS 和 CPU 都是根据用户配置文件和邮件活动估算的

每天每个邮箱发送或接收的邮件数 每个邮箱以兆字节 (MB) 为单位的数据库缓存大小 每个邮箱具有估算的 IOPS 的单个数据库副本(独立) 每个邮箱具有估算的 IOPS 的多个数据库副本(邮箱恢复) 主动邮箱或独立邮箱的兆周期数 被动邮箱的兆周期数

50

3

0.06

0.05

1

0.15

100

6

0.12

0.1

2

0.3

150

9

0.18

0.15

3

0.45

200

12

0.24

0.2

4

0.6

250

15

0.3

0.25

5

0.75

300

18

0.36

0.3

6

0.9

350

21

0.42

0.35

7

1.05

400

24

0.48

0.4

8

1.2

450

27

0.54

0.45

9

1.35

500

30

0.6

0.5

10

1.5

注释注意:
在主动副本之后,每多出一个数据库副本,都必须将每个主动邮箱的兆周期数增加 10%。

下一节“邮箱服务器容量规划示例”中的例子使用的是基准处理器配置,即 2 x 4 核心 Intel Xeon x5470 3.33 GHz 处理器,每处理器核心产生 3,333 兆周数。但是,这种处理器配置很可能不是您要部署的处理器配置。您可以使用以下步骤执行兆周数调整,以确定服务器设计可以支持的可用兆周数。

  1. 打开一个 Web 浏览器,然后转到 Standard Performance Evaluation Corporation (标准性能评估机构)。

  2. 单击“结果”,突出显示“CPU2006”,然后选择“搜索 CUP2006 结果”。

  3. 在“可用配置”下拉框中,选择“SPECint2006 速率”。在“搜索表单请求”中,选择“简单”选项,然后单击“执行”。在“简单请求”下,输入搜索条件(例如处理器与 x5550 匹配)。

  4. 找到您计划部署的服务器和处理器,单击“执行简单获取”,然后记录结果值。

例如,考虑您要部署带有 Intel x5550 2.67GHz 处理器 (2,670 MHz) 的 Dell PowerEdge M710 8 核服务器。对于这种配置,SPECint_rate2006 的结果值为 240,每个核的值为 30(在公式中称为“每个核值的新平台”)。

基准系统 HP DL380 G5 x5470 3.33GHz 8 核 (3,333 MHz) 的 SPECint_rate2006 结果值为 150,或每个核的值为 18.75(在公式中称为“每个核值的基准”)。

要确定 M710 平台示例的兆周期数,请使用以下公式:

((每个核值的新平台)*(基准平台的每个核的赫兹))/(每个核值的基准)= 每个核调整后的兆周数

每个核的兆周数为 30 × 3,333 ÷ 18.75 = 5,333 或每个服务器的兆周数为 42,662

下面的示例说明处理器计算大小的过程。此示例包括下列设计假设:

  • 邮箱数   12,000。

  • 邮箱配置文件   每天发送或接收 150 封邮件。

  • 可用性要求   单个站点内具有邮箱恢复机制,具有对双服务器故障的容错能力。

  • 存储体系结构   只是一批磁盘(JBOD,非 RAID)存储具有三个数据库副本,每个数据库有 300 个邮箱,每个服务器的 40 个数据库具有 30 个数据库副本(或者每个 DAG 具有 120 个数据库副本)。这三个数据库副本随机分布在四个节点上,因此每个服务器都各不相同。

  • 激活模型   目标故障情况是承受双服务器故障且中断时间最短。这会在发生两个服务器故障事件之后激活每个服务器 30 个副本中的 20 个数据库。

  • 服务器平台   2 x 4 内核 Intel Xeon x5470 3.33 GHz 处理器。

下列过程适用。

  1. 计算服务器数   需要具有四个节点的 DAG 以承受双服务器故障,因此设计的第一步是 DAG 中要有四个邮箱服务器。

  2. 根据激活模型计算每个服务器主动邮箱的最大数目   假设主动数据库平均分布在这些节点上,那么理想情况下,每个服务器应该托管 3,000 (12,000 ÷ 4) 个主动邮箱。要计算此示例在发生双节点故障之后的主动邮箱数,则请使用邮箱数除以剩余节点数 2,即每个节点 6,000 (12,000 ÷ 2) 个主动邮箱。

    在此示例中,Set-MailboxServer cmdlet 中的 MaximumActiveDatabases 参数配置为 20。

  3. 计算主动邮箱 CPU 需求   根据之前的表,将主动邮箱的最大数目(20 × 300 = 6,000 个主动邮箱)乘以每个主动邮箱的兆周期数(6,000 × 3 个兆周期 = 18,000 个兆周期)。每多一个附加的数据库副本,就请将此值乘以 10%。

    在此示例中,每个数据库具有一个主动副本和两个被动副本,因此要将 18,000 个兆周期增加 20%(18,000 × 1.2 = 21,600 个兆周期)。

  4. 计算被动邮箱 CPU 需求   根据之前的表,将被动邮箱的数目(当服务器托管的主动邮箱达到最大数目时)乘以每个被动邮箱的兆周期数(3,000 × 0.45 个兆周期 = 1,350 个兆周期)。

  5. 将主动和被动 CPU 需求相加以得到总 CPU 需求   在本示例中,21,600 个活动邮箱兆周 + 1,350 个被动邮箱兆周 = 22,950 个兆周的总 CPU 需求。

  6. 将总 CPU 需求应用于硬件平台   此示例使用基于 2 x 4 内核的 Intel Xeon x5470 3.33 GHz 处理器的服务器。这等同于 26,664 个兆周 (8 × 3,330 MHz)。将所需的兆周数除以基于服务器平台可用的兆周数,从而估算发生双节点故障之后峰值时段的 CPU 使用率(22,950 ÷ 26,664 = 86% 的预测 CPU 使用率)。86% 的 CPU 使用率表示几乎已完全使用服务器,没有剩余空间,但是由于这基于峰值时间段内发生的双故障情况,因此该使用率是可以接受的。

    建议将独立服务器设计为在峰值时间段内使用率不超过 70%,将只能承受单个节点故障的两个节点和三个节点的配置设计为在峰值时间段内使用率不超过 80%(在发生节点故障期间)。

如果调整新虚拟化部署的大小,则不希望过量订阅处理器。因此,希望主机上逻辑内核与虚拟 CPU 的比例为 1:1。在这里,使用本主题中讨论的物理大小设置指导,然后将 10% 用于虚拟机监控程序 CPU 开销。例如,如果将物理部署的大小设置为每个核心 500 名用户,则虚拟部署的大小将为每个核心 450 名用户。

了解服务器角色比率和 Exchange 性能中所讨论的那样,您需要基于邮箱服务器的负载调整集线器传输服务器、客户端访问服务器和全局编录服务器的大小。

一般假设处理器核心比率指导基于所部署的邮箱核心总数;但是,情况并非如此。通常,邮箱服务器不会在所有时间都以 100% 的 CPU 使用率运行。设计良好的解决方案绝不会在基于上节所述的 70% 和 80% 的设计阈值情况下,在很长持续时间内保持 100% 的 CPU 使用率。

若要计算集线器传输服务器、客户端访问服务器和全局编录服务器处理器核心的最小数量,您需要确定在最糟糕故障模型期间支持活动邮箱数据库所需的邮箱核心数。

用于计算数据中心内所需邮箱核心数的公式为:

所需邮箱核心数 =(活动邮箱 CPU 要求)÷(每个核调整后的兆周数)×(剩余服务器数)×(DAG 数)

如果不部署高可用性解决方案,则公式为:

所需邮箱核心数 =(活动邮箱 CPU 要求)÷(每个核调整后的兆周数)×(数据中心内的邮箱服务器数)

继续使用前面的示例,解决方案可以承受两个服务器故障,每个剩余服务器需要 18,000 兆周。因此:

所需邮箱核心数 = (18,000 ÷ 3,333) × 2

= 5.4 × 2

= 总共 11 个核心

这意味着在此数据中心内,在目标故障模型期间,将使用 16 个可用邮箱核心中的总共 11 个核心(或每个剩余邮箱服务器使用 5.5 个核心)。

基于此数据,应在数据中心内为集线器传输服务器、客户端访问服务器和全局编录服务器部署的处理器核心最小数量为:

每个数据中心的集线器传输服务器(具有防病毒功能)处理器核心最小数量 =(每个数据中心所需的邮箱核心数)÷ 5

= 11 ÷ 5

= 3 个核心

每个数据中心的客户端访问服务器处理器核心最小数量 =(每个数据中心所需的邮箱核心数)× 3 ÷ 4

= 11 × 3 ÷ 4

= 33 ÷ 4

= 9 个核心

每个数据中心的全局编录服务器(64 位)处理器核心最小数量 =(每个数据中心所需的邮箱核心数)÷ 8

= 11 ÷ 8

= 2 个核心

返回顶部

 © 2010 Microsoft Corporation。保留所有权利。
显示: