Exchange 2010 测试解决方案：在 Cisco Unified Compute 系统刀片服务器和 EMC CLARiiON 存储上运行 Hyper-V 的三个站点中的 32,400 个邮箱
上一次修改主题： 2016-12-14
Rob Simpson，Microsoft Exchange 的程序主管；Boris Voronin，EMC 的 Exchange 解决方案工程的高级解决方案工程师；Mike Mankovsky，Cisco 的 Microsoft 解决方案架构师
日期
2011 年 6 月
Exchange 2010 测试解决方案
在 Exchange 2010 测试解决方案中，Microsoft 与参与的服务器、存储和网络合作伙伴一起检查常见客户方案以及面向计划部署 Microsoft Exchange Server 2010 的客户的关键设计决策点。通过此系列的白皮书，我们提供了在由我们的一些服务器、存储和网络合作伙伴提供的硬件上部署的设计良好、经济高效的 Exchange 2010 解决方案示例。
可以从 Microsoft 下载中心下载本文档。
适用于
Microsoft Exchange Server 2010 Service Pack 1 (SP1)
Windows Server 2008 R2
Windows Server 2008 R2 Hyper-V
目录
简介
解决方案摘要
客户要求
邮箱配置文件要求
地理位置要求
服务器和数据保护要求
设计假设
服务器配置假设
存储配置假设
解决方案设计
确定高可用性策略
估计邮箱存储容量需求
估计邮箱 I/O 要求
确定存储类型
确定是想要使用 DAS 还是 SAN 存储解决方案
选择存储解决方案
估计邮箱内存要求
计算所需数据库缓存
估计邮箱 CPU 要求
汇总邮箱要求
确定服务器型号
计算服务器型号 CPU 容量
确定所需物理邮箱服务器数
确定正常运行和故障情况下每个邮箱服务器的活动邮箱数
确定是否将客户端访问和集线器传输服务器角色部署在单独物理服务器上
确定所需的物理客户端访问和集线器传输组合服务器数
确定所需物理服务器总数
确定是否使用服务器虚拟化
确定是否可以使用虚拟化减少物理服务器数
计算 Hyper-V 根服务器的 CPU 容量
针对虚拟化开销调整可用兆周期数
确定 VM 的 CPU 容量
验证主邮箱服务器 VM 的 CPU 容量
验证辅助邮箱服务器 VM 的 CPU 容量
确定每个主邮箱服务器 VM 所需的内存
确定每个辅助邮箱服务器 VM 所需的内存
确定每个客户端访问和集线器传输组合服务器所需的内存
确定每个 Hyper-V 根服务器所需的内存
设计数据库可用性组
设计数据库副本布局
数据中心激活协调模式
确定文件共享见证的位置
规划命名空间
确定客户端访问服务器阵列和负载平衡策略
确定硬件负载平衡型号
确定存储设计
解决方案概述
逻辑解决方案图
物理解决方案图
Hyper-V 根服务器配置摘要
客户端访问和集线器传输服务器配置
邮箱服务器配置
数据库布局
存储硬件摘要
存储配置
解决方案验证方法
存储设计验证方法
服务器设计验证
功能验证测试
数据库切换验证
服务器切换验证
服务器故障转移验证
数据中心切换验证
主数据中心服务还原验证
测试设施
解决方案验证结果
功能验证结果
存储设计验证结果
服务器设计验证结果
结论
其他信息
简介
本文档提供了一个示例，来说明对于在思科统一计算系统刀片服务器和 EMC CLARiiON 存储解决方案上部署了 32,400 个邮箱的客户环境，如何设计、测试和验证运行 Windows Server 2008 R2 Hyper-V 技术的 Exchange Server 2010 解决方案。设计大型 Exchange 2010 环境的一个重大挑战是检查当前可用的服务器和存储选择，并选择可在解决方案预期生命周期中提供最佳价值的合适硬件。按照本文档中的分步方法，我们将演练帮助解决这些重大挑战、同时确保满足客户核心业务要求的重要设计决策点。在我们为此客户确定了最佳解决方案之后，会对该解决方案执行标准验证过程，以确保它对于正常运行、维护和故障情况，可承受模拟的生产工作负载。
Exchange 2010 测试解决方案
解决方案摘要
以下各表汇总此解决方案的关键的 Exchange 组件和硬件组件。
Exchange 组件
| Exchange 组件 | 值或描述 |
|---|---|
目标邮箱计数 |
32400 |
目标平均邮箱大小 |
2 GB（以 600 MB 初始大小进行精简配置） |
目标平均邮件配置文件 |
每天 100 封邮件 |
数据库副本计数 |
3 |
卷影复制服务 (VSS) 备份 |
无 |
是否具有站点弹性 |
是 |
站点数 |
3 |
数据库可用性组 (DAG) 模型 |
主动/主动分布（多个 DAG） |
虚拟化 |
Hyper-V |
Exchange 服务器计数 |
4 个虚拟机 (Vm) |
物理服务器计数 |
2 |
硬件组件
| 硬件组件 | 值或描述 |
|---|---|
服务器合作伙伴 |
Cisco |
服务器型号 |
M200 |
服务器类型 |
刀片 |
处理器 |
Intel Xeon X5570 |
存储合作伙伴 |
EMC |
存储型号 |
CX4-480 |
存储类型 |
存储区域网络 (SAN) |
磁盘类型 |
450 GB 15,000 SAS 3.5" |
负载平衡合作伙伴 |
Cisco |
硬件负载平衡型号 |
Ace |
Exchange 2010 测试解决方案
客户要求
Exchange 解决方案设计中最重要的前几个步骤之一是准确汇总对进行正确设计决策至关重要的业务和技术要求。以下各节概述了此解决方案的客户要求。
Exchange 2010 测试解决方案
邮箱配置文件要求
应尽可能准确地确定邮箱配置文件要求，因为这些要求可能会影响设计的所有其他组件。如果您是刚刚接触 Exchange，则可能必须进行一些有根据的推测。如果您拥有现有 Exchange 环境，则可以使用 Microsoft Exchange Server 配置文件分析器工具帮助收集大多数信息。以下各表汇总了此解决方案的邮箱配置文件要求。
邮箱计数要求
| 邮箱计数要求 | 值 |
|---|---|
邮箱计数（包括资源邮箱在内的邮箱总数） |
30000 |
邮箱计数的预计增长百分比 (%)（在解决方案生命周期中的预计邮箱计数增加） |
8% |
预期邮箱并发百分比（在任何时间的最大活动邮箱数） |
100% |
目标邮箱计数（包括增长 x 预期并发在内的邮箱计数） |
32400 |
邮箱大小要求
| 邮箱大小要求 | 值 |
|---|---|
平均邮箱大小（以 MB 为单位） |
600 MB |
平均邮箱存档大小（以 MB 为单位） |
不适用 |
邮箱大小（以 MB 为单位）的预计增长 (%)（在解决方案生命周期中的预计邮箱大小增加） |
230% |
目标平均邮箱大小（以 MB 为单位） |
2,048 MB |
邮箱配置文件要求
| 邮箱配置文件要求 | 值 |
|---|---|
目标邮件配置文件（每个用户每天发送和接收的平均邮件总数） |
每天 100 封邮件 |
目标平均邮件大小（以 KB 为单位） |
75 |
MAPI 缓存模式下的百分比 |
100 |
MAPI 联机模式下的百分比 |
0 |
Outlook Anywhere 缓存模式下的百分比 |
0 |
Microsoft Office Outlook Web App 中的百分比（Exchange 2007 和以前版本中的 Outlook Web Access） |
0 |
Exchange ActiveSync 中的百分比 |
0 |
Exchange 2010 测试解决方案
地理位置要求
在进行与高可用性和站点弹性有关的设计决策时，了解邮箱用户和数据中心的分布十分重要。
下表概述了使用 Exchange 系统的人员的地理分布。
人员的地理分布
| 邮箱用户站点要求 | 值 |
|---|---|
包含邮箱用户的主要站点数 |
3 |
站点 1 中的邮箱用户数 |
10800 |
站点 2 中的邮箱用户数 |
10800 |
站点 3 中的邮箱用户数 |
10800 |
下表概述了可能支持 Exchange 电子邮件基础结构的数据中心的地理分布。
数据中心的地理分布
| 数据中心站点要求 | 值 |
|---|---|
数据中心总数 |
3 |
邻近数据中心 1 的活动邮箱数 |
10800 |
邻近数据中心 2 的活动邮箱数 |
10800 |
邻近数据中心 3 的活动邮箱数 |
10800 |
是否要求 Exchange 驻留在多个数据中心中 |
是 |
Exchange 2010 测试解决方案
服务器和数据保护要求
为环境定义服务器和数据保护要求也十分重要，因为这些要求将支持与高可用性和站点弹性有关的设计决策。
下表列出了服务器保护要求。
服务器保护要求
| 服务器保护要求 | 值 |
|---|---|
站点中同时发生的服务器或 VM 故障数 |
1 |
站点故障过程中同时发生的服务器或 VM 故障数 |
0 |
下表列出了数据保护要求。
数据保护要求
| 数据保护要求 | 值或描述 |
|---|---|
是否要求在 Exchange 环境外部维护 Exchange 数据库备份（例如第三方备份解决方案） |
否 |
是否要求在 Exchange 环境内部维护 Exchange 数据库备份（例如 Exchange 本机数据保护） |
是 |
是否要求在主数据中心中维护邮箱数据的多个副本 |
是 |
是否要求在辅助数据中心中维护邮箱数据的多个副本 |
否 |
是否要求维护任何 Exchange 数据库的滞后副本 |
否 |
滞后副本周期（以天为单位） |
不适用 |
数据库副本的目标数量 |
3 |
已删除邮件文件夹保留期（以天为单位） |
14 |
Exchange 2010 测试解决方案
设计假设
本节包含的信息通常不属于收集客户要求范围内的信息，但是对于设计和用于验证设计的方法都至关重要。
Exchange 2010 测试解决方案
服务器配置假设
下表介绍在正常运行情况以及站点服务器故障或服务器维护情况下的峰值 CPU 利用率目标。
服务器利用率目标
| 目标服务器 CPU 利用率设计假设 | 值 |
|---|---|
邮箱服务器正常运行 |
<70% |
客户端访问服务器正常运行 |
<70% |
集线器传输服务器正常运行 |
<70% |
多个服务器角色（客户端访问、集线器传输和邮箱服务器）正常运行 |
<70% |
多个服务器角色（客户端访问和集线器传输服务器）正常运行 |
<70% |
邮箱服务器发生节点故障 |
<80% |
客户端访问服务器发生节点故障 |
<80% |
集线器传输服务器发生节点故障 |
<80% |
多个服务器角色（客户端访问、集线器传输和邮箱服务器）发生节点故障 |
<80% |
多个服务器角色（客户端访问和集线器传输服务器）发生节点故障 |
<80% |
邮箱服务器发生站点故障 |
<80% |
客户端访问服务器发生站点故障 |
<80% |
集线器传输服务器发生站点故障 |
<80% |
多个服务器角色（客户端访问、集线器传输和邮箱服务器）发生站点故障 |
<80% |
多个服务器角色（客户端访问和集线器传输服务器）发生站点故障 |
<80% |
Exchange 2010 测试解决方案
存储配置假设
以下各表汇总了在设计存储配置时进行的一些数据配置和输入/输出 (I/O) 假设。
数据配置假设
| 数据配置假设 | 值或描述 |
|---|---|
数据开销因子 |
20% |
每周进行的邮箱移动 |
1% |
专用维护或还原逻辑单元号 (LUN) |
否 |
LUN 可用空间 |
20% |
是否启用日志传送压缩 |
是 |
是否启用日志传送加密 |
是 |
I/O 配置假设
| I/O 配置假设 | 值或描述 |
|---|---|
I/O 开销因子 |
20% |
其他 I/O 要求 |
无 |
Exchange 2010 测试解决方案
解决方案设计
下节提供了用于设计此解决方案的分步方法。此方法采用了客户要求和设计假设，并演练了在设计 Exchange 2010 环境时需要考虑的关键设计决策点。
Exchange 2010 测试解决方案
确定高可用性策略
在设计 Exchange 2010 环境时，针对高可用性策略的许多设计决策点都会影响其他设计组件。建议您在设计过程的第一步中确定高可用性策略。强烈建议您在开始此步骤之前检查以下信息：
步骤 1：确定是否需要站点弹性
如果您有多个数据中心，则必须决定是在单个数据中心中部署 Exchange 基础结构，还是跨两个或更多数据中心进行分布。组织的恢复服务级别协议 (SLA) 应定义在出现主数据中心故障之后所需的服务级别。此信息应构成此决策的基础。
*设计决策点*
在此解决方案中，有三个物理数据中心位置。SLA 会指出所有关键任务服务（包括电子邮件）是否需要数据中心弹性。Exchange 2010 设计将基于具有针对邮件服务和数据的站点弹性的多站点部署。
步骤 2：确定邮箱用户位置与数据中心位置之间的关系
在此步骤中，我们需了解所有邮箱用户是否主要位于一个站点中，或是这些用户是否跨许多站点进行分布以及这些站点是否与数据中心关联。如果邮箱用户跨许多站点进行分布并且有数据中心与这些站点关联，则您需要确定是否要求在邮箱用户与该站点所关联的数据中心之间维持关联。
*设计决策点*
在此示例中，三个数据中心各自与若干个区域办事处设在一起。需要在正常运行情况中，在用户位置与其邮箱的主主动副本位置之间维持关联。
步骤 3：确定数据库分布模型
因为客户已决定在多个物理位置中部署 Exchange 基础结构，所以客户需要确定最适合于组织需求的数据库分布模型。有三种数据库分布模型：
主动/被动分布 将活动邮箱数据库副本部署在主数据中心中，仅将被动数据库副本部署在辅助数据中心中。辅助数据中心充当备用数据中心，在正常运行情况下，该数据中心中不会承载任何活动邮箱。如果发生影响主数据中心的中断，会手动切换到辅助数据中心，在其中承载活动数据库，直至主数据中心重新联机。
主动/被动分布
主动/主动分布（单个 DAG） 将活动邮箱数据库部署在主数据中心和辅助数据中心中。对应的被动副本位于备用数据中心中。所有邮箱服务器都是单个 DAG 的成员。在此模型中，两个数据中心之间的广域网 (WAN) 连接可能成为单点故障。丢失 WAN 连接会导致某个数据中心中的邮箱服务器由于丢失仲裁而进入故障状态。
主动/主动分布（单个 DAG）
主动/主动分布（多个 DAG） 此模型利用多个 DAG 使 WAN 连接不再成为单点故障。一个 DAG 的主动数据库副本位于第一个数据中心中，而其对应的被动数据库副本位于第二个数据中心中。第二个 DAG 的主动数据库副本位于第二个数据中心中，而其对应的被动数据库副本位于第一个数据中心中。如果丢失 WAN 连接，则每个站点中的主动副本会继续向本地邮箱用户提供数据库可用性。
主动/主动分布（多个 DAG）
*设计决策点*
在此示例中，因为活动邮箱数据库会部署在三个数据中心位置的各个位置中，所以数据库分布模型是具有多个 DAG 的主动/主动模型。在部署具有多个 DAG 的主动/主动数据库发布模型时还有其他一些设计考虑事项，将在后面的步骤中进行说明。
步骤 4：确定备份和数据库弹性策略
Exchange 2010 包括几个新功能和核心更改，在正确部署和配置后，这些功能和更改可提供本机数据保护，无需进行传统的数据备份。一直以来，备份都用于灾难恢复、意外删除项目的恢复、长期数据存储以及时间点数据库恢复。Exchange 2010 可以在无需进行传统备份的情况下实现所有这些方案：
灾难恢复 如果硬件或软件发生故障，则 DAG 中的多个数据库副本可通过快速故障转移实现高可用性，且不会丢失数据。DAG 可扩展到多个站点，并且可以针对数据中心故障提供弹性。
意外删除项目的恢复 使用 Exchange 2010 中新的“可恢复的项目”文件夹以及适用于此文件夹的保留策略，可在指定的时间段内保留所有删除和修改的数据，因此，恢复这些项目既方便又快捷。有关详细信息，请参阅邮件策略和遵从性、了解可恢复的项目和了解保留标记和保留策略。
长期数据存储 有时，备份也用于进行存档。通常，将磁带用于在更长的时间段内保留数据的时间点快照，以满足遵从性要求的约束。Exchange 2010 中的新存档、多邮箱搜索和邮件保留功能提供了一种机制，可在更长的时间段内高效地保留数据并使最终用户可以访问。有关详细信息，请参阅了解个人存档、了解多邮箱搜索和了解保留标记和保留策略。
时间点数据库快照 如果组织需要邮箱数据的某个过去时间点副本，则 Exchange 可在 DAG 环境中创建滞后副本。此功能对于某种少见事件会有所用处，即逻辑损坏在 DAG 中跨数据库复制，从而导致需要返回到前一时间点。如果管理员意外删除了邮箱或用户数据，此功能也非常有用。
对于作为替代传统备份而内置于 Exchange 2010 中的这些功能，在使用之前，您应该考虑一些技术原因和问题。在进行此决策之前，请参阅了解备份、还原和灾难恢复。
*设计决策点*
在此示例中，对于当前 Exchange 实现，传统备份解决方案的主要用途是从邮件项目的意外删除中恢复。对于单个项目恢复的 80% 的请求是针对 15 天以内的邮件。因此，已删除邮件的保留期将是 14 天。因为传统 VSS 备份对于还原单个项目不是必需的，并且不满足恢复时间目标，所以 Exchange 本机数据保护和“已删除邮件”文件夹保留功能将用作数据库弹性策略。
步骤 5：确定所需的数据库副本数
制定数据库弹性策略时的下一个重要决策是确定要部署的数据库副本数。我们强烈建议在取消对数据库的传统形式的保护（如独立磁盘冗余阵列 (RAID) 或传统的基于 VSS 的备份）之前，至少应部署三个邮箱数据库副本。
在进行此决策之前，请参阅了解邮箱数据库副本。
*设计决策点*
在此示例中，因为不会部署传统的 VSS 备份解决方案，所以会至少部署三个数据库副本，以确保满足恢复时间目标和恢复点目标要求。两个副本将位于主数据中心中，而第三个副本将位于备用数据中心中以提供站点弹性。
步骤 6：确定数据库副本类型
有两种类型的数据库副本：
高可用性数据库副本 此数据库副本的重播延迟时间配置为零。顾名思义，高可用数据库副本由系统保持为最新状态，可以由系统自动激活，并用于为邮箱服务和数据提供高可用性。
滞后数据库副本 此数据库副本配置为将事务日志重播延迟一段时间。滞后数据库副本旨在提供时间点保护，该保护可以用于从存储逻辑损坏、管理错误（例如，删除或清除断开连接的邮箱）和自动化错误（例如，批量清除断开连接的邮箱）恢复。
*设计决策点*
在此示例中，所有三个邮箱数据库副本都会作为高可用性副本进行部署。SLA 不需要数据的滞后副本。因为在过去未遇到过逻辑损坏，并且不使用操作邮件数据的任何其他应用程序，所以不需要滞后副本。对于其他唯一需要滞后副本的是能够恢复单个已删除邮件，但是使用“已删除邮件”文件夹保留功能可更加方便并经济高效地满足此要求。
步骤 7：确定邮箱服务器弹性策略
Exchange 2010 已针对邮箱弹性重新进行了工程设计。现在可在邮箱数据库级别（而不是服务器级别）提供自动故障转移保护。可以从策略上将主动和被动数据库副本分布到 DAG 中的邮箱服务器。确定计划在每个服务器上激活的数据库副本数是 Exchange 2010 容量规划的重要方面。您可以部署不同的数据库分布模型，但是通常建议使用以下模型之一：
针对所有已激活副本的设计 在此模型中，会确定邮箱服务器角色大小，以在服务器上容纳所有数据库副本的激活。例如，一个邮箱服务器可以承载四个数据库副本。在正常运行情况下，该服务器可能具有两个主动数据库副本和两个被动数据库副本。在故障或维护情况下，所有四个数据库副本都可能在该邮箱服务器上成为主动状态。此解决方案通常成对部署。例如，如果部署四个服务器，则第一对是服务器 MBX1 和 MBX2，第二对是服务器 MBX3 和 MBX4。此外，在针对此模型进行设计时，您需确定每个邮箱服务器的大小，使其在正常运行情况下容纳不超过 40% 的可用资源。在具有三个数据库副本和六个服务器的站点恢复能力部署中，此模型可以按三个服务器为一组（其中第三个服务器位于辅助数据中心中）来部署。此模型为使用主动/被动站点弹性模型的解决方案提供三服务器构建基块。
此模型可用于以下方案：
故障域（例如、机架、刀片机箱和存储阵列）需要在主数据中心中方便隔离数据库副本的主动/被动多站点配置
预期增长可能需要可方便添加成规模的逻辑单元的主动/被动多站点配置
无需承受 DAG 中同时失去任意两个邮箱服务器的配置
此模型要求对于单站点部署，成对部署服务器，而对于多站点部署，三个为一组地部署服务器。下表说明了此模型的示例数据库布局。
针对所有已激活副本的设计
在上表中，适用以下各项：
C1 = 正常运行过程中的主动副本（激活首选项值为 1）
C2 = 正常运行过程中的被动副本（激活首选项值为 2）
C3 = 站点故障情况中的被动副本（激活首选项值为 3）
针对目标故障情况的设计 在此模型中，邮箱服务器角色设计为在服务器上容纳数据库副本子集的激活。子集中的数据库副本数取决于设计所针对的特定故障情况。此设计的主要目标是在 DAG 的剩余邮箱服务器间均匀分布数据库负载。
此模型应该用于以下方案：
具有三个或更多数据库副本的所有单站点配置
需要承受 DAG 中同时失去任意两个邮箱服务器的配置
此模型的 DAG 设计需要 3 至 16 个邮箱服务器。下表说明了此模型的示例数据库布局。
针对目标故障情况的设计
在上表中，适用以下各项：
C1 = 正常运行过程中的主动副本（激活首选项值为 1）
C2 = 正常运行过程中的被动副本（激活首选项值为 2）
C3 = 正常运行过程中的被动副本（激活首选项值为 3）
*设计决策点*
在上面的步骤中，决定部署具有多个 DAG 的主动/主动数据库分布模型。因为此模型中的每个 DAG 的主动/被动配置在主数据中心中只有两个高可用性数据库副本，所以针对所有已激活副本设计的邮箱服务器弹性策略是最合适的。
步骤 8：确定数据库可用性组的数量
DAG 是 Exchange 2010 中内置的高可用性和站点恢复能力框架的基础组件，是一组邮箱服务器（最多可包含 16 个邮箱服务器），其中承载了一组复制的数据库，可提供从影响各个服务器或数据库的故障中自动执行数据库级别恢复的功能。
DAG 是邮箱数据库复制、数据库和服务器切换与故障转移以及名为“活动管理器”的内部组件的边界。活动管理器是负责管理切换和故障转移的 Exchange 2010 组件。活动管理器在 DAG 中的每个服务器上运行。
从规划角度来看，您应尝试将部署的 DAG 数减到最小。如果发生出现以下情况，则应考虑使用多个 DAG：
部署 16 个以上的邮箱服务器。
在多个站点中拥有活动邮箱用户（主动/主动站点配置）。
需要单独的 DAG 级别管理边界。
拥有单独域中的邮箱服务器。（DAG 与域绑定。）
*设计决策点*
在上面的步骤中，决定部署主动/主动数据库分布模型。可以部署在每个站点中都拥有活动邮箱用户的单个 DAG。但是，如果某个站点中的 DAG 成员临时失去与其他站点中的 DAG 成员的连接，则该站点中的群集会丢失仲裁并停止正常运行。因此，将部署三个 DAG。每个 DAG 将包含主数据中心中的邮箱服务器，用于承载主数据库副本和辅助数据库副本。每个 DAG 还将包含备用数据中心之一的服务器，用于承载第三个数据库副本。形成的设计是三个主动/被动 DAG，其中每个数据中心承载来自一个 DAG 的主副本和辅助副本，以及来自另一个 DAG 的第三个副本。
步骤 9：确定每个 DAG 的邮箱服务器数
在此步骤中，您需要确定支持 DAG 设计所需的最小邮箱服务器数。此数量可能与支持工作负载所需的服务器数不同，因此在后面的步骤中进行服务器数的最终决策。
*设计决策点*
在上面的步骤中，决定部署三个主动/被动 DAG，并针对所有已激活副本设计服务器弹性策略。每个 DAG 必须以三个服务器的增量（两个位于主站点中，一个位于备用站点中）进行部署。因为会部署三个 DAG，所以支持 DAG 设计所需的最小服务器数是九个。根据支持工作负载所需的服务器数的不同，解决方案会具有 9、18 或 27 个服务器。下表概述了可能的配置。
每个 DAG 的邮箱服务器数
| DAG1 主数据中心 | DAG1 辅助数据中心 | DAG2 主数据中心 | DAG2 辅助数据中心 | DAG3 主数据中心 | DAG3 辅助数据中心 | 邮箱服务器总计数 |
|---|---|---|---|---|---|---|
2 |
1 |
2 |
1 |
2 |
1 |
9 |
4 |
2 |
4 |
2 |
4 |
2 |
18 |
6 |
3 |
6 |
3 |
6 |
3 |
27 |
.gif "注释") 注意： |
|---|
| 在三节点 DAG 模型中，如果您丢失了主数据中心中的两个节点，则群集会丢失仲裁和自动激活。辅助数据中心中的第三个副本会提供附加的数据可用性，但是恢复辅助数据中心中的服务将是手动操作。 |
Exchange 2010 测试解决方案
估计邮箱存储容量需求
许多因素可影响邮箱服务器角色的存储容量要求。有关其他信息，建议您查看了解邮箱数据库和日志容量因素。
以下步骤概述如何计算邮箱容量要求。这些要求随后会用于对哪些存储解决方案选择满足容量要求进行决策。后面一节介绍了在所选存储平台上正确设计存储布局所需的其他计算。
Microsoft 创建了邮箱服务器角色要求计算器，该工具可为您执行这类工作中的大部分工作。若要下载该计算器，请参阅 E2010 邮箱服务器角色要求计算器。有关使用该计算器的其他信息，请参阅 Exchange 2010 邮箱服务器角色要求计算机器。
步骤 1：计算磁盘上的邮箱大小
在尝试确定总存储要求之前，您应了解磁盘上的邮箱大小将是多少。具有 1 GB 配额的完整邮箱需要 1 GB 以上的磁盘空间，因为您必须考虑禁止发送/接收限制、用户每天发送或接收的邮件数、“已删除邮件”文件夹保留期（启用或不启用日历版本日志记录和单个项目的恢复）以及每个邮箱的平均数据库每日变化。邮箱服务器角色要求计算器会为您进行这些计算。您也可以使用以下信息手动进行计算。
以下计算用于为此解决方案中具有 2 GB 邮箱限制的邮箱确定磁盘上的邮箱大小：
空白空间 = 100 封邮件/天 × 75 ÷ 1024 MB = 7.3 MB
垃圾站 = (100 封邮件/天 × 75 ÷ 1024 MB × 14 天) + (2048 MB × 0.012) + (2048 MB × 0.058) = 246 MB
磁盘上的邮箱大小 = 邮箱限制 + 空白空间 + 垃圾站
= 2048 + 7.3 + 246
= 2,301 MB
步骤 2：计算数据库存储容量要求
在此步骤中，确定所有邮箱数据库所需的高级存储容量。计算得到的容量包括数据库大小、目录索引大小和 20% 的可用空间。
若要确定所有数据库所需的存储容量，请使用以下公式：
数据库大小 = (邮箱数 × 磁盘上的邮箱大小 × 数据库开销增长因子) + (20% 的数据开销)
= (32400 × 2301 × 1) + (14910480)
= 89,462,880 MB
= 87,366 GB
数据库索引大小 = 10% 的数据库大小
= 87366 × 0.10
= 8,737 GB
总数据库容量 = (数据库大小) + (索引大小) ÷ 0.80，以增加 20% 的卷可用空间
= (87366 + 8737) ÷ 0.8
= 120,128 GB
步骤 3：计算事务日志存储容量要求
若要确保邮箱服务器不会由于空间分配问题而经受任何中断，也需要调整事务日志的大小以容纳将在备份集期间生成的所有日志。如果该体系结构使用邮箱弹性和单个项目恢复功能作为备份体系结构，日志容量应分配三次每日日志生成速率，以防三天内未修复失败的副本。（任何失败的副本都会防止日志截断的发生。）如果服务器未在三天内重新联机，则您需要临时删除副本以允许进行截断。
若要确定所有事务日志所需的存储容量，请使用以下公式：
日志文件大小 = (日志文件大小 × 每个邮箱每天的日志数 × 替换故障基础结构所需的天数 × 邮箱用户数) + (1% 的邮箱移动开销)
= (1 MB × 20 × 4 × 32400) + (32400 × 0.01 × 2048 MB)
= 3,255,552 MB
= 3,179 GB
总日志容量 = 日志文件大小 ÷ 0.80，以增加 20% 的卷可用空间
= (3179) ÷ 0.80
= 3974
步骤 4：确定总存储容量要求
下表汇总了此解决方案的高级存储存储容量要求。在后面的步骤中，您将使用此信息对要部署的存储解决方案进行决策。随后会在后面的步骤中更进一步地了解特定存储要求。
存储容量要求的摘要
| 磁盘空间要求 | 值 |
|---|---|
磁盘上的平均邮箱大小 (MB) |
2301 |
所需数据库容量 (GB) |
120128 |
所需日志容量 (GB) |
3974 |
所需总容量 (GB) |
124102 |
三个数据库副本所需的总容量 (GB) |
372306 |
三个数据库副本所需的总容量 (TB) |
364 |
每个站点所需的总容量 (TB) |
122 |
Exchange 2010 测试解决方案
估计邮箱 I/O 要求
在设计 Exchange 环境时，您需要了解数据库和日志性能因素。建议您查看了解数据库和日志性能因素。
步骤 1：计算总邮箱 I/O 要求
因为这是充分确定存储大小所需的重要事务性 I/O 指标之一，所以您应了解每个邮箱用户占用的数据库每秒 I/O (IOPS) 量。在每个邮箱服务器的 IOPS 计算中不考虑纯顺序 I/O 操作，因为存储子系统处理顺序 I/O 比处理随机 I/O 要高效得多。这些操作包括后台数据库维护、日志事务性 I/O 和日志复制 I/O。在此步骤中，会使用以下这些信息计算支持所有邮箱用户所需的总 IOPS：
每个用户邮箱的估计 IOPS = 0.10
所需总 IOPS = 每个邮箱用户的 IOPS × 邮箱数 × I/O 开销因子
= 0.10 × 32400 × 1.2
= 3888
| 注意： |
|---|
| 若要为不同的邮件配置文件确定 IOPS 配置文件，请参阅了解数据库和日志性能因素中的“基于邮件活动的每个邮箱的数据库缓存和估计 IOPS”表。 |
步骤 2：计算每个站点的总邮箱 I/O 要求
因为这是多站点部署，所以您需要根据站点考虑 IOPS 要求，以正确确定每个站点的存储大小。在上面的步骤中，决定每个站点都承载来自主 DAG 的主数据库副本和辅助数据库副本，以及来自备用 DAG 的第三级数据库副本。在此模型中，最坏情况是单个站点发生故障，其中来自主 DAG 的 10,800 个邮箱和来自备用 DAG 的 10,800 个邮箱在该站点的存储中处于活动状态。使用下面的计算：
每个站点所需的总 IOPS = 每个邮箱用户的 IOPS × 邮箱数 × I/O 开销因子
= 0.10 × 21600 × 1.2
= 2592
Exchange 2010 测试解决方案
确定存储类型
Exchange 2010 包括性能、可靠性和高可用性方面的改进，这些改进使组织可以在众多存储选择上运行 Exchange。
在检查可用的存储选择时，能够平衡性能、容量、可管理性与成本要求对于为 Exchange 实现成功存储解决方案十分必要。
有关为 Exchange 2010 选择存储解决方案的详细信息，请参阅邮箱服务器存储设计。
Exchange 2010 测试解决方案
确定是想要使用 DAS 还是 SAN 存储解决方案
有各种各样的存储选择可用于 Exchange 2010。可以通过确定是要部署直接附加存储 (DAS) 解决方案（包括使用本地磁盘）还是 SAN 解决方案来缩减选择列表。选择某项而不是另一项的原因有很多，您应与首选存储供应商合作，来确定最符合您业务和总拥有成本 (TCO) 要求的解决方案。
*设计决策点*
在此示例中，会部署 SAN 基础结构，并且 SAN 用于存储环境中的所有数据。将继续使用 SAN 存储解决方案，并浏览用于部署 Exchange 2010 的选择。
Exchange 2010 测试解决方案
选择存储解决方案
使用以下步骤可选择存储解决方案。
步骤 1：确定首选存储供应商
在此示例中，多年以来一直使用 EMC 存储，因此会将 EMC 存储解决方案用于 Exchange 2010 部署。EMC Corporation 提供了高性能存储阵列（如 CLARiiON 和 Symmetric）。
步骤 2：检查首选供应商提供的可用选择
EMC CLARiiON 系列提供了多个存储层（如企业级闪存驱动器、光纤通道和串行 ATA (SATA)），这样可减少成本，因为可以使用单一管理接口来管理多个层。
CLARiiON 虚拟资源调配可提供比传统精简配置更多的好处，包括简化存储管理和提高容量利用率。您可以向主机提供大容量，随后根据需要从共享池使用空间。
CLARiiON CX4 系列提供了具有灵活容量、功能和性能级别的四个型号。每个型号的功能如下表所述。
CLARiiON CX4 系列功能
| Feature | CX4 型号 120 | CX4 型号 240 | CX4 型号 480 | CX4 型号 960 |
|---|---|---|---|---|
最大磁盘数 |
120 |
240 |
480 |
960 |
存储处理器 |
2 |
2 |
2 |
2 |
每个存储处理器的物理内存 |
3 GB |
4 GB |
8 GB |
16 GB |
最大写入高速缓存 |
600 MB |
1.264 GB |
4.5 GB |
10.764 GB |
每个系统的最大发起程序数 |
256 |
512 |
512 |
1024 |
高可用性主机数 |
128 |
256 |
256 |
512 |
最小外观大小 |
6U |
6U |
6U |
9U |
最大标准 Lun 数 |
1024 |
1024 |
4096 |
4096 |
是否支持 SnapView 快照 |
是 |
是 |
是 |
是 |
是否支持 SnapView 克隆 |
是 |
是 |
是 |
是 |
是否支持 SAN Copy |
是 |
是 |
是 |
是 |
是否支持 MirrorView/S |
是 |
是 |
是 |
是 |
是否支持 MirrorView/A |
是 |
是 |
是 |
是 |
是否支持 RecoverPoint/S |
是 |
是 |
是 |
是 |
是否支持 RecoverPoint/A |
是 |
是 |
是 |
是 |
步骤 3：选择磁盘类型
在此示例中，选择了 450 GB 光纤通道 15,000 rpm 磁盘，这种磁盘可提供良好的 I/O 性能和容量，以满足初始 Exchange 用户要求。
| 注意： |
|---|
| 自测试以来，600 GB 10,000 rpm 磁盘的成本已下降，也是用于此部署的良好选择。 |
步骤 4：选择阵列
在此示例中，解决方案需要提供 122 TB 的可用存储和 2,592 IOPS。上表中的任何选择都可满足 IOPS 要求，因此会基于容量要求进行决策。CLARiiON CX4 型号 240 仅通过 RAID-5 配置中的 450 GB 磁盘提供大约 100 TB 的可用容量。选择了 EMC CLARiiON CX4 型号 480，因为该型号可提供支持所有 Exchange 2010 要求所需的容量和 I/O 性能。
Exchange 2010 测试解决方案
估计邮箱内存要求
正确确定内存大小是设计状态良好的 Exchange 环境的一个重要步骤。建议您查看了解内存配置和 Exchange 性能和了解邮箱数据库缓存。
Exchange 2010 测试解决方案
计算所需数据库缓存
可扩展存储引擎 (ESE) 使用数据库缓存减少 I/O 操作。通常，可用数据库缓存越多，在 Exchange 2010 邮箱服务器上生成的 I/O 便越少。但是，存在一个点，在该点添加更多数据库缓存也不会再显著减少 IOPS。因此，向 Exchange 服务器添加大量物理内存而不确定所需的最佳数据库缓存量可能会导致较高成本，而只产生最低性能优势。
在上面的步骤中完成的 IOPS 估计假设采用每个邮箱的最小数据库缓存量。这些最小量汇总在了解邮箱数据库缓存中的“基于邮件活动和邮箱数据库缓存的每个邮箱的估计 IOPS”表中。
下表概述了针对各个邮件配置文件的每个用户的数据库缓存。
每个用户的数据库缓存
| 每个邮箱每日发送或接收的邮件（平均邮件大小约等于 75 KB） | 每个用户的数据库缓存 (MB) |
|---|---|
50 |
3 MB |
100 |
6 MB |
150 |
9 MB |
200 |
12 MB |
在此步骤中，您为整个环境确定高级内存要求。在后面的步骤中，您使用此结果确定每个邮箱服务器所需的物理内存量。使用下面的计算：
数据库缓存 = 特定于配置文件的数据库缓存 × 邮箱用户数
= 6 MB × 32400
= 194,400 MB
= 190 GB
Exchange 2010 测试解决方案
估计邮箱 CPU 要求
由于 Exchange 2010 中提供了新邮箱数据库弹性模型，因此邮箱服务器容量规划与以前版本的 Exchange 相比发生了重大变化。有关其他信息，请参阅邮箱服务器处理器容量规划。
在以下步骤中，您会计算主动和被动数据库副本的高级兆周期要求。这些要求会在后面的步骤中用于确定支持工作负载所需的邮箱服务器数。请注意，所需邮箱服务器数还取决于邮箱服务器弹性模型和数据库副本布局。
使用兆周期要求确定 Exchange 邮箱服务器可以支持的邮箱用户数不十分科学。许多因素可能导致测试和生产环境中出现意外兆周期结果。兆周期应仅用于获得 Exchange 邮箱服务器可以支持的近似邮箱用户数。在设计过程的容量规划部分中，保守始终比激进更好。
以下计算基于下表中汇总的已发布兆周期估计。
兆周期估计
| 每天每个邮箱发送或接收的邮件数 | 活动邮箱数据库每个邮箱的兆周期数 | 远程被动邮箱数据库每个邮箱的兆周期数 | 本地被动邮箱每个邮箱的兆周期数 |
|---|---|---|---|
50 |
1 |
0.1 |
0.15 |
100 |
2 |
0.2 |
0.3 |
150 |
3 |
0.3 |
0.45 |
200 |
4 |
0.4 |
0.6 |
步骤 1：计算活动邮箱 CPU 要求
在此步骤中，您会使用以下公式计算支持主动数据库副本所需的兆周期数：
所需活动邮箱兆周期数 = 特定于配置文件的兆周期数 × 邮箱用户数
= 2 × 32400
= 64800
步骤 2：计算活动邮箱远程数据库副本 CPU 要求
在每个数据库有三个副本的设计中，存在与在远程服务器上维护数据库副本所需的传送日志相关联的处理器开销。对于所服务的每个远程副本，此开销通常是活动邮箱兆周期数的 10%。使用以下公式计算要求：
所需远程副本兆周期数 = 特定于配置文件的兆周期数 × 邮箱用户数 × 远程副本数
= 0.1 × 32400 × 2
= 6480
步骤 3：计算本地被动邮箱 CPU 要求
在每个数据库有三个副本的设计中，存在与维护每个数据库的本地被动副本相关联的处理器开销。在此步骤中，会计算支持本地被动数据库副本所需的高级兆周期数。这些数量会在后面步骤中进行细化，以便与服务器弹性策略和数据库副本布局相匹配。使用以下公式计算要求：
所需本地被动邮箱兆周期数 = 特定于配置文件的兆周期数 × 邮箱用户数 × 被动副本数
= 0.3 × 32400 × 2
= 19440
步骤 4：计算总 CPU 要求
使用以下公式计算总要求：
所需兆周期总数 = 活动邮箱 + 远程被动 + 本地被动
= 64800 + 6480 + 19440
= 90720
每个邮箱的平均兆周期数 = 90720 ÷ 32400 = 2.8
Exchange 2010 测试解决方案
汇总邮箱要求
下表汇总了此环境所需的近似兆周期数和数据库缓存。此信息会在后面的步骤中用于确定将在解决方案中部署的服务器。
邮箱要求摘要
| 邮箱 CPU 要求 | 值 |
|---|---|
整个环境所需的兆周期总数 |
97200 |
整个环境所需的总数据库缓存 |
190 GB |
Exchange 2010 测试解决方案
确定服务器型号
您可以使用以下步骤来确定服务器型号。
步骤 1：确定首选服务器供应商
在此解决方案中，首选服务器平台是 Cisco 统一计算系统，这是一种数据中心平台，可将计算、网络、存储访问和虚拟化合并到为减少 TCO 和提高灵活性而设计的系统中。该系统将低延迟 10 千兆以太网统一网络结构与企业级 x86 体系结构服务器集成。凭借融体系结构、技术、合作关系和服务于一体的系统方法，Cisco 统一计算系统简化了数据中心资源、扩展了服务交付并减少了需要设置、管理、供电、冷却和接线的设备数。
步骤 2：检查首选供应商提供的可用选择
Cisco 统一计算系统是包含四个主要系统组件的刀片服务器系统。这些系统组件是结构互连、机箱、结构扩展器（I/O 模块）和刀片服务器。
以下刀片服务器型号是适用于此解决方案的潜在选择。
选择 1：B200 刀片服务器
Cisco 统一计算系统 B200 刀片服务器是半宽度、双插槽刀片服务器。系统使用两个 Intel Xeon 5500 或 5600 系列处理器、最多 96 GB 的 DDR3 内存、两个可选的可热交换小型 SAS 磁盘驱动器以及一个用于最多每秒 20 千兆位 (Gbps) I/O 吞吐量的夹层连接器。对于生产级别虚拟化和其他主流数据中心工作负载而言，该服务器使简单性、性能和密度达到了平衡。
选择 2：B250 刀片服务器
Cisco 统一计算系统 B250 扩展内存刀片服务器是采用 Cisco 扩展内存技术的全宽度、双插槽刀片服务器。系统支持两个 Intel Xeon 5500 或 5600 系列处理器、最多 384 GB 的 DDR3 内存、两个可选的小型 SAS 磁盘驱动器以及两个用于最多 40 Gbps I/O 吞吐量的夹层连接。该服务器针对虚拟化和大型数据集工作负载提高了性能和容量。
选择 3：B440 刀片服务器
Cisco 统一计算系统 B440 刀片服务器旨在为企业应用程序（如大型数据集和事务密集型数据库、企业资源计划 (ERP) 程序以及决策支持系统 (DSS)）提供强大功能。借助 Intel Xeon 7500 系列处理器的可伸缩性能和可靠性功能，Cisco 统一计算系统 B440 帮助扩大了工作负载虚拟化的范围，并在集成、简化的基础结构中统一了性能密集型独立应用程序。Cisco 统一计算系统 B440 支持最多 32 个处理核心和 256 GB 的主内存，并具有高达 40 Gbps 的 I/O 吞吐量。
步骤 3：选择服务器型号
选择了具有 Intel Xeon X5570 处理器的 Cisco 统一计算系统 B200，因为对于该部署来说，此刀片服务器在处理能力、内存容量和外观尺寸几方面达到了最佳平衡。基于所有相关因素（包括可伸缩性和成本），双插槽服务器平台通常是针对 Exchange 2010 部署的良好选择。Cisco 统一计算系统 B250 支持更高内存配置和更高 I/O 吞吐量，但是这不是该解决方案所需要的。
| 注意： |
|---|
| 自测试以来，600 GB 10,000 rpm 磁盘的成本已下降，也是用于此部署的良好选择。 |
Exchange 2010 测试解决方案
计算服务器型号 CPU 容量
在前面的步骤中，您计算了支持活动邮箱用户数所需的兆周期数。在以下步骤中，您会确定服务器型号和处理器可以支持的可用兆周期数，从而确定每个服务器可以支持的活动邮箱数。
步骤 1：确定服务器和处理器的基准值
因为兆周期要求基于基线服务器和处理器型号，所以您需要针对该基线调整服务器的可用兆周期数。为此，可使用标准性能评估机构 (SPEC) 维护的独立性能基准。SPEC 是非盈利组织，其组成是为了建立、维护和支持一套标准化相关基准，这些基准可以应用于最新一代的高性能计算机。
为了帮助简化获取服务器和处理器的基准值的过程，建议您使用 Exchange 处理器查询工具。此工具可自动执行手动步骤，以确定您计划处理器的 SPECint 2006 评级值。若要运行此工具，您的计算机必须连接到 Internet。该工具使用您的计划处理器作为输入，然后对标准性能评估机构网站运行查询，从而返回针对该特定处理器型号的所有测试结果数据。该工具还基于计划在每个邮箱服务器中使用的处理器数，计算平均 SPECint 2006 评级值。使用下面的计算：
处理器 = Intel X5570 2.93 GHz
SPECint_rate2006 值 = 256
每个处理器核心的 SPECint_rate2006 值 = 256 ÷ 8
= 32
步骤 2：计算调整的兆周期数
在上面的步骤中，您基于每个邮箱兆周期估计，计算了整个环境所需的兆周期数。这些估计是在基线系统（HP DL380 G5 x5470 3.33 GHz，8 个核心）上测量的，该系统的 SPECint_rate2006 值为 150（对于 8 核心服务器），即每个核心为 18.75。
在此步骤中，您需要针对基线处理器，调整所选服务器和处理器的可用兆周期数，以便可以将所需兆周期数用于容量规划。
若要确定 Cisco B200-M1 Intel X5570 2.93 GHz 平台的兆周期数，请使用以下公式：
每个核心的调整兆周期数 = (新平台每核心值) × (基线平台的每核心赫兹) ÷ (基线每核心值)
= (32 × 3330) ÷ 18.75
= 5683
每个服务器的调整兆周期数 = 每个核心的调整兆周期数 × 核心数
= 5683 × 8
= 45466
步骤 3：计算每个邮箱服务器的可用兆周期数
现在已知道了每个服务器的调整兆周期数，您需要针对目标最大处理器利用率进行调整。在上面的一节中，决定在峰值工作负载或故障情况下，不会超过 80% 的处理器利用率。使用下面的计算：
调整的可用兆周期数 = 每个服务器的可用兆周期数 × 目标最大处理器利用率
= 45466 × 0.80
= 36372
每个服务器都具有 36,372 个兆周期的可用容量。
Exchange 2010 测试解决方案
确定所需物理邮箱服务器数
可以使用以下步骤确定所需物理邮箱服务器数。
步骤 1：确定单个邮箱服务器所支持的最大活动邮箱数
若要确定邮箱服务器所支持的活动邮箱数，请使用下面的计算：
活动邮箱数 = 每个服务器的可用兆周期数 ÷ 每个邮箱的兆周期数
= 36372 ÷ 2.8
= 12990
步骤 2：确定每个站点所需的最小邮箱服务器数，以支持每个 DAG 的所需工作负载
每个 DAG 都具有 10,800 个活动邮箱。若要确定支持 DAG 中所有邮箱所需的最小邮箱服务器数，请使用下面的计算：
所需服务器数 = 每个 DAG 的总邮箱计数 ÷ 每个服务器的活动邮箱数
= 10800 ÷ 12990
= 0.83
每个 DAG 至少需要一个邮箱服务器才能支持 10,800 个邮箱的工作负载。
步骤 3：确定为每个 DAG 支持邮箱弹性策略所需的服务器数
在上面的步骤中，确定针对主动/被动 DAG 中的所有激活副本进行设计。此模型要求对于每个 DAG，三个一组地部署邮箱服务器角色。
邮箱服务器和 DAG 的数量
| DAG1 主数据中心 | DAG1 辅助数据中心 | DAG2 主数据中心 | DAG2 辅助数据中心 | DAG3 主数据中心 | DAG3 辅助数据中心 | 邮箱服务器总计数 |
|---|---|---|---|---|---|---|
2 |
1 |
2 |
1 |
2 |
1 |
9 |
4 |
2 |
4 |
2 |
4 |
2 |
18 |
6 |
3 |
6 |
3 |
6 |
3 |
27 |
根据 DAG 设计，每个 DAG 中至少需要三个物理邮箱服务器，即全部三个 DAG 中总共有九个物理邮箱服务器。
Exchange 2010 测试解决方案
确定正常运行和故障情况下每个邮箱服务器的活动邮箱数
可以使用以下步骤确定正常运行和故障情况下每个邮箱服务器的活动邮箱数。
步骤 1：确定正常运行过程中每个邮箱服务器的活动邮箱数
若要确定正常运行过程中每个邮箱服务器承载的活动邮箱数，请使用下面的计算：
每个服务器的邮箱数 = DAG 中的总邮箱计数 ÷ 主数据中心中的邮箱服务器数
= 10800 ÷ 2
= 5400
步骤 2：确定在主数据中心中的某个邮箱服务器出现故障时，每个邮箱服务器的活动邮箱数
如果主数据中心中的某个邮箱服务器出现故障，则故障服务器上的 5,400 个活动邮箱会在此剩余服务器上成为活动状态。在这种情况下，剩余邮箱服务器将具有 10,800 个活动邮箱。
步骤 3：确定在主数据中心中的两个邮箱服务器都出现故障时，每个邮箱服务器的活动邮箱数
如果主数据中心脱机，则主数据中心中的 10,800 个活动邮箱会在辅助数据中心中激活。在此情况下，辅助数据中心中的一个服务器将具有 10,800 个活动邮箱。
Exchange 2010 测试解决方案
确定是否将客户端访问和集线器传输服务器角色部署在单独物理服务器上
当确定要在具有较少服务器的环境中部署的客户端服务器角色和集线器服务器角色数量时，可以考虑将这两个角色部署在相同物理计算机上。这样可减少要管理的物理计算机数、要更新和维护的服务器操作系统数以及需要购买的 Windows 和 Exchange 许可证数。将客户端访问和集线器传输服务器角色组合在一起的另一个好处是可简化设计过程。在分开部署角色时，建议您为每四个邮箱服务器逻辑处理器部署一个集线器传输服务器逻辑处理器，并为每四个邮箱逻辑处理器部署三个客户端访问服务器逻辑处理器。这可能会令人混淆，尤其当您考虑必须在多个物理服务器出现故障或进行维护的情况下提供足够客户端访问和集线器传输服务器时。在将客户端访问和集线器传输服务器与邮箱服务器部署在相同物理服务器或相同 VM 上时，可以为站点中的每个邮箱服务器都部署一个客户端访问和集线器传输服务器组合。
*设计决策点*
在此解决方案中，决定使集线器传输和客户端访问服务器角色一起共存于相同物理计算机上。这会减少要管理的操作系统数并且可更简单地规划服务器弹性。
Exchange 2010 测试解决方案
确定所需的物理客户端访问和集线器传输组合服务器数
在上面的步骤中，您确定每个站点中需要三个邮箱服务器（两个邮箱服务器来自为该站点承载活动邮箱的 DAG，一个邮箱服务器来自在该 DAG 的主数据中心出现故障时支持站点弹性的备用 DAG）。
建议您为每个邮箱服务器都部署一个客户端访问和集线器传输组合服务器，如下表所示。
所需的物理客户端访问和集线器传输组合服务器数
| 服务器角色配置 | 建议处理器核心比率 |
|---|---|
邮箱:客户端访问和集线器传输组合服务器角色 |
1:1 |
如果在相同站点中表示了多个 DAG，则您需要先检查最坏故障情况，然后才能确定所需的客户端访问和集线器传输组合服务器数。在此解决方案中，最坏故障情况是丢失主 DAG 中两个邮箱服务器中的一个，并且同时发生站点故障，此时另一个站点的活动邮箱现在正承载于相同站点中。在此情况下，您会在运行于两个邮箱服务器之上的站点中拥有 21,600 个活动邮箱，因此每个站点中至少需要两个客户端访问和集线器传输组合服务器，如下图所示。
客户端访问和集线器传输服务器
Exchange 2010 测试解决方案
确定所需物理服务器总数
到目前为止，您确定对于三个数据中心中的 32,400 个活动邮箱，支持客户端访问、集线器传输和邮箱服务器角色需要 15 个物理服务器。
所需物理服务器数
Exchange 2010 测试解决方案
确定是否使用服务器虚拟化
当考虑对 Exchange 使用服务器虚拟化时，有几个因素十分重要。有关支持的虚拟化配置的详细信息，请参阅 Exchange 2010 系统要求。
出于以下原因，请考虑对 Exchange 使用虚拟化：
如果您预期服务器容量未充分利用并且希望进行更好的利用，则可以使用虚拟化，从而采购较少服务器。
在将客户端访问、集线器传输和邮箱服务器角色部署在相同物理服务器上时，您可能需要使用 Windows 网络负载平衡 (NLB)。
如果您的组织在所有服务器基础结构中都使用虚拟化，则您可能需要对 Exchange 使用虚拟化，以便与公司标准策略保持一致。
若要确定是否应在此部署中使用虚拟化，请考虑预期处理器利用率并确定服务器是否可能未充分利用。
步骤 1：确定正常运行情况下邮箱服务器的预期 CPU 利用率
若要确定单个邮箱服务器上 5,400 个活动邮箱的 CPU 利用率，请使用下面的计算：
处理器百分比（正常运行时的峰值）= 所需兆周期数 ÷ 可用兆周期数
= (5400 × 2.8) ÷ 45466
= 33.2%
步骤 2：计算最坏故障情况下邮箱服务器的预期 CPU 利用率
若要确定单个邮箱服务器上 10,800 个活动邮箱的 CPU 利用率，请使用下面的计算：
处理器百分比（故障情况下的峰值）= 所需兆周期数 ÷ 可用兆周期数
= (10800 × 2.8) ÷ 45466
= 66.5%
*设计决策点*
因为对于最坏故障情况，服务器计划是处于 80% 的利用率目标之下，所以可以有机会使用虚拟化减少服务器计数。这会在以下步骤中进行进一步探讨。
Exchange 2010 测试解决方案
确定是否可以使用虚拟化减少物理服务器数
在以下步骤中，您会确定是否可以使用虚拟化减少此解决方案中所需的物理服务器数。Microsoft Hyper-V 将用作虚拟化平台。
步骤 1：向现有物理服务器计数添加虚拟化
测试时，Microsoft Hyper-V 支持每个 VM 最多四个虚拟处理器。在物理设计中，主 DAG 的邮箱服务器角色部署中两个物理服务器（总共具有 16 个逻辑处理器）上。通过添加虚拟化，主 DAG 的邮箱服务器角色现在部署在四个 VM 中，每个 VM 具有四个虚拟处理器，总共 16 个虚拟处理器。
在物理设计中，备用 DAG 的邮箱服务器角色部署在一个物理服务器（具有八个逻辑处理器）上。通过添加虚拟化，备用 DAG 的邮箱服务器角色现在部署在两个 VM 中，每个 VM 具有四个虚拟处理器，总共八个虚拟处理器。
在物理设计中，客户端访问和集线器传输组合服务器部署在两个物理服务器（总共具有 16 个逻辑处理器）上。通过添加虚拟化，客户端访问和集线器传输组合服务器现在部署在四个 VM 中，每个 VM 具有四个虚拟处理器，总共 16 个虚拟处理器。
在使用具有八个逻辑处理器的 Hyper-V 根服务器时，最佳做法是在每个 Hyper-V 根服务器上部署一个邮箱服务器 VM 以及一个客户端访问和集线器传输组合服务器 VM。
解决方案现在在每个站点中的五个物理服务器上运行 10 个 VM，如下图所示。
虚拟机
步骤 2：减少物理服务器计数
基于上面步骤中的计算，您预期四个物理服务器可以处理最坏情况下工作负载的兆周期要求。在此步骤中，您会将物理服务器计数从五个减少为四个，并将备用 DAG 中的邮箱服务器重新分布到剩余四个物理服务器中。若要在四个物理服务器间保持对称，您需要将两个邮箱服务器 VM（具有四个虚拟处理器）更改为四个邮箱服务器 VM（具有两个虚拟处理器）。
这样做的结果是在每个站点中的四个物理服务器上运行 12 个 VM，如下图所示。
虚拟机
虚拟机
步骤 3：确定分配给每个 VM 的虚拟处理器数
在此步骤中，您会估计每个 VM 所需的虚拟处理器数。在以下步骤中，您会执行计算以验证所做的假设。
在正常运行情况下，主 DAG 中的四个邮箱服务器 VM 各自支持该 DAG 中 10,800 个活动邮箱的 25%，即各自支持 2,700 个邮箱。发生服务器故障时，仍然正常运行的邮箱服务器 VM 将必须支持 5,400 个活动邮箱。
发生站点故障时，主 DAG 中的四个邮箱服务器 VM 各自支持该 DAG 中 10,800 个活动邮箱的 25%，即各自支持 2,700 个邮箱。在此情况下，邮箱会在数据库的第三个和最后一个副本上运行。发生服务器或 VM 故障时，仍然正常运行的 VM 不必支持 5,400 个活动邮箱。最大邮箱数始终为 2,700 个。
备用 DAG 中的 VM 的虚拟处理器数是主 DAG 中的 VM 的一半比较合理。在此解决方案中，向主 DAG 中的 VM 分配四个虚拟处理器，而向备用 DAG 中的 VM 分配两个虚拟处理器。
如果您将逻辑与虚拟处理器之比保持为 1:1，则这会为每个客户端访问和集线器传输组合服务器留下两个虚拟处理器。因为您要将邮箱服务器核心与客户端访问和集线器传输组合服务器核心之比保持为 1:1，所以向每个客户端访问和集线器传输组合服务器分配四个虚拟处理器。这样便会使虚拟处理器数超过根服务器上的物理处理器数。这称为“过度订阅”。在大多数情况下，建议您不要使用过度订阅。不过在此解决方案中，备用 DAG 中的邮箱服务器 VM 仅在站点故障事件中使用。因为这是较少发生的事件，所以轻微过度订阅是没有问题的。
下表显示了建议的虚拟处理器分配。
虚拟处理器分配
| 虚拟机 | 虚拟处理器计数 |
|---|---|
客户端访问和集线器传输组合 |
3 |
邮箱（主 DAG） |
4 |
邮箱（备用 DAG） |
2 |
总计 |
9 |
Exchange 2010 测试解决方案
计算 Hyper-V 根服务器的 CPU 容量
在前面的步骤中，您计算了支持活动邮箱用户数所需的兆周期数。在以下步骤中，您会确定服务器型号和处理器可以支持的可用兆周期数，从而可以确定每个虚拟服务器可支持的活动邮箱数。
Exchange 2010 测试解决方案
针对虚拟化开销调整可用兆周期数
在根服务器上部署 VM 时，您需要考虑支持虚拟机监控程序和虚拟化堆栈所需的兆周期数。此开销因各种服务器和不同工作负载而异。将使用可用兆周期数的 10% 这一保守估计，如下面的计算所示：
调整的可用兆周期数 = 可用的兆周期数 × 0.90
= 45466 × 0.90
= 40919
每个服务器都具有 40,919 个兆周期的 VM 可用容量。
每个逻辑处理器的可用容量是 5,115 个兆周期。
Exchange 2010 测试解决方案
确定 VM 的 CPU 容量
在上面的步骤中，您为三种 VM 类型确定了虚拟处理器分配，如下表所示。
虚拟处理器分配
| 虚拟机 | 虚拟处理器计数 |
|---|---|
客户端访问和集线器传输组合 |
3 |
邮箱（主 DAG） |
4 |
邮箱（备用 DAG） |
2 |
总计 |
9 |
步骤 1：确定每个虚拟处理器的可用兆周期数
因为在具有八个逻辑处理器的根服务器上运行九个虚拟处理器，所以一个虚拟处理器的兆周期容量与一个逻辑处理器的兆周期容量不相等。在此步骤中，计算每个虚拟处理器的可用兆周期数：
每个虚拟处理器的兆周期数 = 每个逻辑处理器的兆周期数 × (逻辑处理器数 ÷ 虚拟处理器数)
= 5115 × (8 ÷ 9)
= 4547
步骤 2：确定每个 VM 的可用兆周期数
在此步骤中，若要确定每个 VM 的可用兆周期数，请参阅下表。
每个 VM 的可用兆周期数
| 虚拟机 | 虚拟处理器计数 | 每个虚拟处理器的兆周期数 | 可用兆周期数 |
|---|---|---|---|
客户端访问和集线器传输组合 |
3 |
4547 |
13641 |
邮箱（主 DAG） |
4 |
4547 |
18188 |
邮箱（备用 DAG） |
2 |
4547 |
9094 |
步骤 3：确定每个 VM 的目标可用兆周期数
因为设计假设表示不会超过 80% 的处理器利用率，所以应调整可用兆周期数以反映 80% 这一目标，如下表所示。
每个 VM 的目标可用兆周期数
| 虚拟机 | 可用兆周期数 | 最大处理器利用率 | 目标可用兆周期数 |
|---|---|---|---|
客户端访问和集线器传输组合 |
13641 |
80% |
10913 |
邮箱（主 DAG） |
18188 |
80% |
14550 |
邮箱（备用 DAG） |
9094 |
80% |
7275 |
Exchange 2010 测试解决方案
验证主邮箱服务器 VM 的 CPU 容量
若要验证主邮箱服务器 VM 的 CPU 容量，请使用以下步骤。
步骤 1：确定最坏情况工作负载下的兆周期要求
主邮箱服务器的最坏情况工作负载是 5,400 个邮箱在主邮箱服务器上处于活动状态，而第二个和第三个远程副本正在进行维护的服务器故障或维护情况（例如，在被动副本正在更新，但是活动邮箱尚未移动回目标服务器的恢复事件之后）。在此步骤中，您会使用下面的计算，确定主邮箱服务器 VM 的兆周期要求：
所需邮箱兆周期数 = (邮箱用户数 × 特定于配置文件的兆周期数) + 远程数据库副本数 × (邮箱用户数 × 特定于配置文件的兆周期数 × 10%)
= (5400 × 2) + 2 × (5400 × 2 × 0.1)
= 10800 + 2160
= 12960
步骤 2：确定主邮箱服务器 VM 是否可以支持最坏情况工作负载
在此步骤中，您会确定可用兆周期数是否大于所需兆周期数。您需要 12,960 个兆周期，拥有 14,550 个兆周期，因此主邮箱服务器 VM 具有足够容量可支持 5,400 个活动邮箱。
Exchange 2010 测试解决方案
验证辅助邮箱服务器 VM 的 CPU 容量
若要验证辅助邮箱服务器 VM 的 CPU 容量，请使用以下步骤。
步骤 1：确定最坏情况工作负载下的兆周期要求
辅助邮箱服务器的最坏情况工作负载是 2,700 个邮箱在辅助邮箱服务器上处于活动状态，而第二个和第三个远程副本正在进行维护的站点故障情况（例如，在原始主副本和辅助副本正在更新，但是活动邮箱尚未移动回原始站点的原始站点重新联机之后）。在此步骤中，若要确定辅助邮箱服务器 VM 的兆周期要求，请使用下面的计算：
所需邮箱兆周期数 = (邮箱用户数 × 特定于配置文件的兆周期数) + 远程数据库副本数 × (邮箱用户数 × 特定于配置文件的兆周期数 × 10%)
= (2700 × 2) + 2 × (2700 × 2 × 0.1)
= 5400 + 1080
= 6480
步骤 2：确定主邮箱服务器 VM 是否可以支持最坏情况工作负载
在此步骤中，您会确定可用兆周期数是否大于所需兆周期数。您需要 6,480 个兆周期，拥有 7,275 个兆周期，因此辅助邮箱服务器 VM 具有足够容量可支持 2,700 个活动邮箱。
Exchange 2010 测试解决方案
确定每个主邮箱服务器 VM 所需的内存
可以使用以下步骤确定每个主邮箱服务器 VM 所需的内存。
步骤 1：确定最坏故障情况下每个服务器的数据库缓存要求
在上面的步骤中，您确定所有邮箱的数据库缓存要求是 190 GB，并且每个活动邮箱所需的平均缓存是 6 MB。
若要针对最坏故障情况进行设计，请基于剩余邮箱服务器 VM 上的 5,400 个活动邮箱来计算所需数据库缓存：
数据库缓存所需的内存 = 活动邮箱数 × 每个邮箱的平均缓存
= 5400 × 6 MB
= 32,400 MB
= 31.6 GB
步骤 2：确定最坏故障情况下每个邮箱服务器 VM 的总内存要求
在此步骤中，请参阅下表来确定建议的内存配置。
内存要求
| 服务器物理内存 (RAM) | 数据库缓存大小（仅限邮箱服务器角色） |
|---|---|
24 GB |
17.6 GB |
32 GB |
24.4 GB |
48 GB |
39.2 GB |
用于为邮箱服务器角色支持 31.6 GB 数据库缓存的建议内存配置是 48 GB。
Exchange 2010 测试解决方案
确定每个辅助邮箱服务器 VM 所需的内存
可以使用以下步骤确定每个辅助邮箱服务器 VM 所需的内存。
步骤 1：确定最坏故障情况下每个服务器的数据库缓存要求
在上面的步骤中，您确定所有邮箱的数据库缓存要求是 190 GB，并且每个活动邮箱所需的平均缓存是 6 MB。
若要针对最坏故障情况进行设计，请基于驻留在辅助邮箱服务器 VM 上的 2,700 个活动邮箱来计算所需数据库缓存：
数据库缓存所需的内存 = 活动邮箱数 × 每个邮箱的平均缓存
= 2700 × 6 MB
= 16,200 MB
= 15.8 GB
步骤 2：确定最坏故障情况下每个邮箱服务器 VM 的总内存要求
在此步骤中，请参阅下表来确定建议的内存配置。
内存要求
| 服务器物理内存 (RAM) | 数据库缓存大小（仅限邮箱服务器角色） | 数据库缓存大小（多个服务器角色，例如邮箱和集线器传输服务器角色） |
|---|---|---|
24 GB |
17.6 GB |
14 GB |
32 GB |
24.4 GB |
20 GB |
48 GB |
39.2 GB |
32 GB |
用于为邮箱服务器角色支持 15.8 GB 数据库缓存的建议内存配置是 24 GB。
Exchange 2010 测试解决方案
确定每个客户端访问和集线器传输组合服务器所需的内存
若要确定客户端访问和集线器传输组合服务器 VM 的内存配置，请参阅下表。
基于已安装的服务器角色的 Exchange 2010 服务器的内存配置
| Exchange 2010 服务器角色 | 最低支持 | 建议最高 |
|---|---|---|
客户端访问和集线器传输组合服务器角色（在同一物理服务器上运行的客户端访问和集线器传输服务器角色） |
4 GB |
每个核心 2 GB（最小 8 GB） |
因为客户端访问和集线器传输组合服务器 VM 具有三个虚拟处理器，所以向每个客户端访问和集线器传输组合服务器 VM 分配 6 GB 内存。
Exchange 2010 测试解决方案
确定每个 Hyper-V 根服务器所需的内存
若要确定每个 Hyper-V 根服务器所需的内存，请使用下面的计算：
根服务器内存 = 根操作系统内存 + 客户端访问和集线器传输组合服务器 VM 内存 + 主邮箱服务器 VM 内存 + 辅助邮箱服务器 VM 内存
= 4 GB + 6 GB + 48 GB + 24 GB
= 82 GB
根服务器的物理内存要求是 82 GB。为了符合建议的物理内存配置，服务器将装有 96 GB 内存。
Exchange 2010 测试解决方案
设计数据库可用性组
在上面的步骤中，您确定解决方案会包含三个 DAG，并且每个 DAG 会跨越三个物理位置中的两个。现在您已确定了支持工作负载和 DAG 要求所需的邮箱服务器数，便可以继续进行 DAG 设计。
DAG 设计
Exchange 2010 测试解决方案
设计数据库副本布局
使用以下步骤可设计数据库副本布局。
步骤 1：确定 DAG 中的唯一 Exchange 数据库数
若要确定要部署的最佳 Exchange 数据库数，请使用 Exchange 2010 邮箱服务器角色要求计算器。在输入选项卡上输入合适的信息，然后对“自动计算数据库/DAG 数”选择“是”。对于邮箱大小限制字段，使用完全配置的邮箱配额 2,048 MB。
DAG 中的 Exchange 数据库
在“角色要求”选项卡上，会出现建议的数据库数。对于此解决方案，此计算器建议每个 DAG 至少有 24 个唯一数据库。
*设计决策点*
按照该计算器的建议，将每个 DAG 部署 24 个数据库。
步骤 2：确定正常运行情况下的数据库布局
因为每个 DAG 有 24 个唯一数据库，并且 DAG 中有八个服务器，所有主站点中的四个服务器在正常运行情况下各自承载六个主动数据库副本。
首先将主动数据库副本添加到四个服务器，如下表所示。
正常运行情况下的数据库布局
| 数据库 | MBX1 | MBX2 | MBX3 | MBX4 |
|---|---|---|---|---|
DB1-6 |
A1 |
|||
DB7-12 |
A1 |
|||
DB13-18 |
A1 |
|||
DB19-24 |
A1 |
在上表中，适用以下各项：
- A1 = 主动数据库副本
在上面的步骤中，您确定要针对运行效率设计邮箱服务器弹性策略。邮箱服务器会成对部署。
因为 DAG 中有四个邮箱服务器，所以服务器 1 和 2 会是一对，而服务器 3 和 4 是一对。在此步骤中，您会将被动数据库副本 (P1) 添加到每对中的备用服务器，如下表所示。
正常运行情况下具有被动副本的数据库布局
| 数据库 | MBX1 | MBX2 | MBX3 | MBX4 |
|---|---|---|---|---|
DB1-6 |
A1 |
P1 |
||
DB7-12 |
P1 |
A1 |
||
DB13-18 |
A1 |
P1 |
||
DB19-24 |
P1 |
A1 |
在上表中，适用以下各项：
A1 = 主动数据库副本
P1 = 被动数据库副本
步骤 3：确定站点中服务器故障或维护情况下的数据库布局
在服务器故障或维护事件中，P1 副本会在备用服务器上激活。下表说明了在 MBX2 和 MBX4 停机进行维护时的这种情况。
站点中服务器故障或维护情况下的数据库副本布局
在上表中，适用以下各项：
A1 = 主动数据库副本
P1 = 被动数据库副本
步骤 4：将数据库副本添加到辅助数据中心以支持站点弹性
在此步骤中，将第三个数据库副本添加到辅助数据中心中的 DAG 成员以提供站点弹性，如下表所示。
添加到辅助数据中心以支持站点弹性的数据库副本
| 数据库 | SiteA MBX1 | SiteA MBX2 | SiteA MBX3 | SiteA MBX4 | SiteB MBX5 | SiteB MBX6 | SiteB MBX7 | SiteB MBX8 |
|---|---|---|---|---|---|---|---|---|
DB1-6 |
A1 |
P1 |
P2 |
|||||
DB7-12 |
P1 |
A1 |
P2 |
|||||
DB13-18 |
A1 |
P1 |
P2 |
|||||
DB19-24 |
P1 |
A1 |
P2 |
在上表中，适用以下各项：
A1 = 主动数据库副本
P1 = 本地被动数据库副本
P2 = 远程被动数据库副本
步骤 5：确定站点故障情况下的数据库布局
如果发生主数据中心故障，则 P2 副本会在辅助站点中激活，如下表所示。请注意，在主站点重新联机之前，只有数据库的一个副本。
站点故障情况下的数据库布局
在上表中，适用以下各项：
A1 = 主动数据库副本
P1 = 被动数据库副本
P2 = 被动数据库副本
Exchange 2010 测试解决方案
数据中心激活协调模式
数据中心激活协调 (DAC) 模式用于在发生影响 DAG 的灾难性故障（例如一个数据中心完全故障）时控制 DAG 的激活行为。DAC 模式未启用且发生了影响 DAG 中多个服务器的故障时，DAG 将在大多数 DAG 成员故障恢复后重新启动并尝试装入数据库。在多数据中心配置中，此行为可能导致“网络分区症状”（当所有网络都发生故障时发生此情况），并且 DAG 成员无法收到彼此的检测信号。当数据中心之间的网络连接断开时，也会发生网络分区症状。始终要求大多数 DAG 成员（在 DAG 成员为偶数时使用 DAG 见证服务器）可用并处于交互状态，使 DAG 能够正常工作，这样即可防止网络分区症状。有关详细信息，请参阅了解数据中心激活协调模式。
*设计决策点*
会为环境中的所有三个 DAG 都启用 DAC 模式，以防止出现网络分区症状。
Exchange 2010 测试解决方案
确定文件共享见证的位置
在 Exchange 2010 中，DAG 使用 Windows 故障转移群集中的最小组件集。这些组件中的一个是仲裁资源，通过该组件可在确定群集状态和进行成员资格决策时进行仲裁。每个 DAG 成员对如何配置 DAG 基础群集应具有一致的视图，这一点至关重要。仲裁充当了与群集相关的所有配置信息的权威性存储库。仲裁还用作关系断开裁判，以避免网络分区症状。网络分区症状是在 DAG 成员无法相互通信（但是可用并在运行）时发生的一种情况。始终要求大多数 DAG 成员（在 DAG 成员为偶数时使用 DAG 见证服务器）可用并处于交互状态，使 DAG 能够正常工作，这样即可防止网络分区症状。
“见证服务器”是 DAG 外部用于承载文件共享见证的服务器，当 DAG 的成员数为偶数时，使用该服务器可实现和维护仲裁。DAG 的成员数为奇数时，则不使用见证服务器。在创建 DAG 时，默认情况下会将文件共享见证添加到与 DAG 的第一个成员处于相同站点中的集线器传输服务器（未安装邮箱服务器角色）。如果运行集线器传输服务器的 VM 驻留在与运行邮箱服务器角色的 VM 相同的根服务器上，则建议您将文件共享见证的位置移动到另一个高可用服务器。可以将文件共享见证移动到域控制器，但是由于存在安全隐患，因此仅将此方法作为最后手段。
在 DAG 跨多个站点的解决方案中，建议为辅助站点定义备用文件共享见证。这会使群集可以在启用 DAC 模式时发生站点故障事件的情况下维持仲裁。
*设计决策点*
因为决定部署三个 DAG 并且所有 DAG 都包含多个站点中的成员，所以需要定义三个主见证目录和三个备用见证目录。这些目录位于每个站点中的文件服务器上。
Exchange 2010 测试解决方案
规划命名空间
在规划 Exchange 2010 组织时，必须做出的最重要的一个决策是如何排列组织的外部命名空间。命名空间是一种逻辑结构，通常由域名系统 (DNS) 中的域名进行表示。在定义命名空间时，必须考虑客户端及其邮箱所在的服务器的不同位置。除了客户端的物理位置之外，还必须评估客户端连接 Exchange 2010 的方式。回答下列问题后将可确定您必须拥有的命名空间数。通常，命名空间将与 DNS 配置相对应。建议包含一个或多个面向 Internet 的客户端访问服务器的区域中每个 Active Directory 站点均使用唯一的命名空间。通常，该命名空间在 DNS 中由 A 记录（例如 mail.contoso.com 或 mail.europe.contoso.com）表示。
有关详细信息，请参阅了解客户端访问服务器命名空间。
可通过许多不同方式排列外部命名空间，但是通常可以使用以下命名空间模型之一来满足您的要求：
合并数据中心模型 此模型由单个物理站点组成。所有服务器均位于该站点中，并且只有一个命名空间，例如 mail.contoso.com。
单命名空间和代理站点 此模型由多个物理站点组成。只有一个站点包含面向 Internet 的客户端访问服务器。其他站点不面向 Internet。该模型中的站点只有一个命名空间，例如 mail.contoso.com。
单命名空间和多站点 此模型由多个物理站点组成。每个站点都可以具有面向 Internet 的客户端访问服务器。或者，只有一个站点包含面向 Internet 的客户端访问服务器。该模型中的站点只有一个命名空间，例如 mail.contoso.com。
区域命名空间 此模型由多个物理站点和多个命名空间组成。例如，位于纽约市的站点将使用命名空间 mail.usa.contoso.com，位于多伦多的站点将使用命名空间 mail.canada.contoso.com，位于伦敦的站点将使用命名空间 mail.europe.contoso.com。
多个林 此 模型由拥有多个命名空间的多个林组成。使用此模型的组织可能是由两个合作伙伴公司组成，例如 Contoso 和 Fabrikam。命名空间可能包括 mail.usa.contoso.com、mail.europe.contoso.com、mail.asia.fabrikam.com 和 mail.europe.fabrikam.com。
*设计决策点*
对于此方案，选择了区域命名空间模型，因为该模型最适用于在多个站点中具有活动邮箱的组织。
此模型的优势是减少了代理，因为较大比例的用户能够连接到与其邮箱服务器位于相同 Active Directory 站点的客户端访问服务器。这样将改善最终用户的体验和使用性能。如果用户的邮箱位于没有面向 Internet 的客户端访问服务器的站点中，则仍将使用代理连接。
此解决方案还具有以下配置要求：
必须管理多个 DNS 记录。
必须获取、配置并管理多个证书。
管理安全性比较复杂，因为每个面向 Internet 的站点都需要 Microsoft Forefront Threat Management Gateway 计算机，或是其他反向代理或防火墙解决方案。
用户必须连接到自己的区域命名空间。这样可能会增加向技术支持求助的次数和培训的次数。
Exchange 2010 测试解决方案
确定客户端访问服务器阵列和负载平衡策略
在 Exchange 2010 中，向客户端访问服务器角色引入了 RPC 客户端访问服务和 Exchange 通讯簿服务，以改进将活动邮箱数据库副本移动到另一个邮箱服务器时（例如，在邮箱数据库故障和维护事件过程中）的邮箱用户体验。用于从 Microsoft Outlook 和其他 MAPI 客户端进行邮箱访问的连接终结点已从邮箱服务器角色移动至客户端访问服务器角色。因此，现在必须跨所有客户端访问服务器对内部和外部 Outlook 连接进行负载平衡，以实现容错。若要将 MAPI 终结点与一组客户端访问服务器（而不是特定客户端访问服务器）相关联，可以定义客户端访问服务器阵列。只能对每个 Active Directory 站点配置一个阵列，并且一个阵列不能跨多个 Active Directory 站点。有关详细信息，请参阅了解 RPC 客户端访问和Understanding Load Balancing in Exchange。
*设计决策点*
因为这是三站点部署，其中每个站点中有四个运行客户端访问服务器角色的服务器，所以总共需要三个客户端访问服务器阵列。将使用硬件负载平衡解决方案在每个站点的客户端访问服务器阵列间分布负载。
Exchange 2010 测试解决方案
确定硬件负载平衡型号
使用以下步骤可确定硬件负载平衡型号。
步骤 1：确定首选硬件负载平衡供应商
在此示例中，首选供应商是 Cisco，因为 Cisco 应用控制引擎 (ACE) 产品系列可与为此解决方案的服务器、网络和存储连接组件选择的 Cisco 统一计算系统结合使用。
Cisco ACE 产品系列提供了可以使 Exchange 2010 应用程序环境受益的高可用和可伸缩的数据中心解决方案。Cisco ACE 产品提供互操作性，具有以下优势：
性能、可伸缩性、吞吐量和应用程序可用性
基于标准的设计
具有设备分区的虚拟体系结构
基于角色的管理和集中式管理
通过深度数据包检查、访问控制列表 (ACL)、单播反向路径发送和网络地址转换 (NAT)/端口地址转换提供的安全服务
步骤 2：检查首选供应商提供的可用选择
Cisco ACE 产品系列包括两种不同的硬件负载平衡型号，这两种型号可满足适用于 Exchange 2010 应用程序环境的高可用和可伸缩数据中心解决方案的需求。这两种型号是 Cisco ACE 4710 设备以及 Cisco Catalyst 6500/Cisco 7600 路由平台中的集成服务模块。
Cisco ACE 4710 设备采用单机架单元 (1RU) 外观尺寸提供最多 4 Gbps 吞吐量，可通过软件许可证进行升级，这样便可提供长期投资保护和可伸缩性。在其基础上，4710 是 1U 机架机箱，其中包含 Cavium Nitrox Octeon 加速卡，该卡提供了四个千兆以太网端口（可以使用 Cisco EtherChannel 捆绑到一起并连接到交换机）。默认情况下，Cisco ACE 4710 支持具有一个管理员设备和五个用户设备的虚拟化、1-Gbps 带宽、1,000 个安全套接字层 (SSL) 事务/秒以及 100 兆位/秒 (Mbps) 的压缩。通过以下软件许可证升级，可以在无需新设备的情况下扩展解决方案：
吞吐量 1 Gbps 的默认吞吐量可以提高到 2 或 4 Gbps。
虚拟设备 虚拟设备数可以从 5 个增加到 20 个虚拟设备。
每秒的 SSL 事务数 每秒的 SSL 事务数值可以从 1,000 提高到 5,000 或 7,500。
压缩 压缩可以提高到 500 Mbps 或是 1 或 2 Gbps 的吞吐量。
基于角色的访问控制 通过应用程序网络管理器 GUI 或命令行接口 (CLI) 提供了基于角色的集中式管理。
高可用性 支持冗余配置（设备内和环境内）。
Cisco Catalyst 6500 系列交换机或 Cisco 7600 系列路由器的 Cisco ACE 模块采用单插槽模块外观尺寸，提供最多 16 Gbps 吞吐量，与 ACE 4710 设备类似，可通过软件许可证进行升级。可以在单个 Cisco Catalyst 6500 系列交换机或 Cisco 7600 系列路由器中最多安装四个 Cisco ACE 模块。每个模块可以通过利用交换机或路由器提供的各种连接选项，支持多个独立业务单位的业务流程。由系统管理员确定应用程序要求并分配合适的网络服务作为虚拟环境。每个环境都包含自己的一组策略、接口、资源和管理员：
吞吐量 负载平衡服务提供最多 16 Gbps 的吞吐量容量和每秒 345,000 个第 4 层连接。
虚拟设备 虚拟设备数可以从 5 个增加到 250 个。
每秒的 SSL 事务数 每秒的 SSL 事务数可以通过授权，在 ACE20 模块上提高到 15,000 个 SSL 会话，在 ACE30 模块上提高到 30,000 个。
压缩 压缩可以在 ACE30 模块上提高到 6 Gbps。
基于角色的访问控制 通过应用程序网络管理器 GUI 或 CLI 提供了基于角色的集中式管理。
高可用性 支持冗余配置（机箱内、机箱间和环境内）。
步骤 3：选择硬件负载平衡型号
选择了 Cisco ACE 4710 设备，因为该设备可提供最大化的应用程序可用性、全面的应用程序安全性、虚拟化体系结构以及投资价值和保护：
最大化应用程序可用性 Cisco ACE 4710 通过高可伸缩的第 4 层负载平衡和第 7 层内容切换（还可尽量降低应用程序或设备故障的影响）增强可用性，从而可帮助确保向最终用户提供业务连续性和服务。
全面的应用程序安全性 Cisco ACE 4710 充当服务器防御的最后一关，通过各种功能（如深度数据包检查、网络和协议安全以及高可伸缩的访问控制功能）提供针对应用程序威胁和拒绝服务攻击 (DoS) 的保护。
虚拟化体系结构 虚拟化体系结构是 Cisco ACE 的主要设计元素，与市场中的其他解决方案相比，是独一无二的卖点。IT 管理员可以在单个 Cisco ACE 4710 设备上配置最多 20 个虚拟设备。好处是在应用程序部署增大时可管理较少的设备、显著降低了供电和冷却费用以及使新应用程序可更快地投入使用。
Exchange 2010 测试解决方案
确定存储设计
设计良好的存储解决方案是成功部署 Exchange 2010 邮箱服务器角色的一个至关重要的方面。有关详细信息，请参阅邮箱服务器存储设计。
步骤 1：汇总存储要求
下表汇总了在上面的设计步骤中计算或确定的存储要求。
磁盘空间要求摘要
| 磁盘空间要求 | 值 |
|---|---|
2 GB 邮箱的磁盘上的邮箱大小 (MB) |
2301 |
所需总数据库容量 (GB) |
120128 |
所需总日志容量 (GB) |
3974 |
所需总容量 (GB) |
124102 |
三个数据库副本所需的总容量 (GB) |
372306 |
三个数据库副本所需的总容量 (TB) |
364 |
每个站点所需的总容量 (TB) |
122 |
步骤 2：确定是否使用虚拟资源调配或精简配置
许多客户希望在移动至 Exchange 2010 时显著提高其邮箱配额。但是，使邮箱大小从数百 MB 增长到几个 GB 可能需要一段时间。在这种情况下，对于某些组织，尝试推迟购买更多存储直到未来磁盘存储空间可能更加便宜时再进行，这可能比较有利。
许多存储供应商都提供某种类型的精简配置解决方案，以便您可以向 Exchange 服务器提供比物理可用存储更多的存储容量，随后可动态添加物理存储以便在不中断或停机的情况下满足不断增长的需求。这样做可通过减少存储容量的初始分配来降低 TCO，并通过减少支持增长所需的部署来简化管理。
EMC 精简配置统一存储实现通过其虚拟资源调配功能提供，可提供热备用、主动备用、不会中断的精简工具扩展以及能够在不停机的情况下在精简 LUN 与传统厚 LUN 之间迁移。这一灵活性将 EMC 统一存储虚拟资源调配与传统精简配置实现区分开来。
*设计决策点*
当前 Exchange 实现具有 200 MB 的定义邮箱配额。在移动至 Exchange 2010 之后，估计邮箱大小会在头 12 至 18 个月内增长大约 300%。计划购买足够存储以容纳 600 MB 的平均邮箱大小。在 Exchange 2010 实现的生命周期中，平均邮箱大小预计会接近 2 GB。因为针对 2 GB 邮箱配额进行投资的成本十分高昂，所以会实施精简配置，以便可以部署 600 MB 的初始邮箱配额。基础物理存储会在后续预算周期中进行扩展，以满足预期需求。
步骤 3：确定是否使日志和数据库共存于相同 LUN 上
在将 EMC 统一存储上的精简配置用于 Exchange 2010 部署时，最佳做法是将日志文件与数据库文件分隔。如果您预期邮箱大小会增加，但是邮件配置文件（每天发送/接收的邮件数）不会，则需要以增量方式增大数据库 LUN，而不增大日志 LUN。将日志置于精简配置的 LUN 上没什么好处。
将数据库与日志 LUN 分隔也可提供灵活性，以便将其置于不同磁盘类型上或使用不同 RAID 级别。
*设计决策点*
根据 EMC 最佳做法，数据库和日志会分隔在不同 LUN 上。因为预计邮件配置文件在接下来三年中会十分稳定，所以将日志置于精简配置的 LUN 上没什么好处。
步骤 4：确定每个 LUN 的数据库数
因为基于 VSS 的备份和还原在 LUN 级别上进行操作，所以每个 LUN 的数据库数通常由备份策略确定。在上面的步骤中，决定不将基于 VSS 的备份包含在数据库弹性策略中。针对每个 LUN 的数据库数的决策会以其他因素为根据。作为最佳做法，通常应每个 LUN 部署一个数据库。使每个 LUN 具有多个数据库可能会导致以下结果：
过载数据库影响正常数据库
对一个数据库进行的种子设定操作影响正常数据库
被动数据库 I/O 影响活动数据库
*设计决策点*
因为无需对每个 LUN 部署多个数据库，所以存储设计基于每个 LUN 一个数据库的模型。
步骤 5：为主数据中心邮箱服务器确定每个服务器的 LUN 数
在上面的步骤中，您确定每个主邮箱服务器会支持六个活动数据库和六个被动数据库。每个主数据中心邮箱服务器总共有 24 个 LUN，如下表所述。
每个邮箱服务器所需的 LUN 数
| LUN 类型 | 每个服务器的 LUN 数 |
|---|---|
活动数据库 LUN 数 |
6 |
活动日志 LUN 数 |
6 |
被动数据库 LUN 数 |
6 |
被动日志 LUN 数 |
6 |
总 LUN 数 |
24 |
步骤 6：为辅助数据中心邮箱服务器确定每个服务器的 LUN 数
在上面的步骤中，您确定每个辅助邮箱服务器会支持六个被动数据库。每个辅助数据中心邮箱服务器总共有 12 个 LUN，如下表所述。
每个邮箱服务器所需的 LUN 数
| LUN 类型 | 每个服务器的 LUN 数 |
|---|---|
被动数据库 LUN 数 |
6 |
被动日志 LUN 数 |
6 |
总 LUN 数 |
12 |
步骤 7：定义存储构建基块
若要简化存储设计步骤的剩余部分，请使用构建基块方法。在此解决方案中，每个数据库支持 450 个活动邮箱。每个邮箱服务器在 6 个数据库 LUN 和 6 个日志 LUN 上支持 6 个数据库或 2,700 个活动邮箱。会使用支持以 2,700 个邮箱为增量的 12 LUN 构建基块。
步骤 8：确定构建基块的 IOPS 要求
在此步骤中，会计算支持构建基块中 2,700 个活动邮箱用户所需的事务性 IOPS。在后续步骤中，您会使用 IOPS 要求，基于初始和完全配置邮箱配额确定要为构建基块部署的最小和最大心轴数。使用下面的计算：
构建基块所需的总事务性 IOPS = 每个邮箱用户的 IOPS × 邮箱数 × I/O 开销因子
= 0.10 × 2700 × 20%
= 324 IOPS
步骤 9：确定初始的磁盘上邮箱大小
在上面的步骤中，对于 2,048-MB 邮箱配额限制，您计算的磁盘上邮箱大小是 2,301 MB。因为会使用精简配置，所以需计算初始的磁盘上邮箱大小。此值会在后面的步骤中用于确定初始容量要求。
以下计算用于基于 600-MB 邮箱配额，为此解决方案确定初始的磁盘上邮箱大小：
空白空间 = 100 封邮件/天 × 75 ÷ 1024 MB = 7.3 MB
垃圾站 = (100 封邮件/天 × 75 ÷ 1024 MB × 14 天) + (600 MB × 0.012) + (600 MB × 0.058) = 144.2 MB
磁盘上的邮箱大小 = 邮箱限制 + 空白空间 + 垃圾站
= 600 MB + 7.3 MB + 144.2 MB
= 752 MB
步骤 10：确定构建基块的初始数据库容量要求
若要确定初始邮箱配额为 600 MB 的 2,700 个邮箱所需的初始存储容量，请使用以下计算：
数据库文件容量 = (邮箱数 × 磁盘上的邮箱大小 × 数据库开销增长因子) + (20% 的数据开销)
= (2700 × 752 × 1) + (406080)
= 2,436,480 MB
= 2,379 GB
数据库目录容量 = 数据库文件容量的 10%
= 238 GB
总数据库容量 = (数据库文件大小) + (索引大小) ÷ 0.80，以提供 20% 的卷可用空间
= (2379 + 238) ÷ 0.8
= 3,271 GB
构建基块中的六个数据库需要 3,271 GB 的初始存储容量。
步骤 11：确定构建基块的完全配置数据库容量要求
若要确定邮箱配额为 2,048 MB 的 2,700 个邮箱所需的完全配置存储容量，请使用以下计算：
数据库文件容量 = (邮箱数 × 磁盘上的邮箱大小 × 数据库开销增长因子) + (20% 的数据开销)
= (2700 × 2301 × 1) + (1242540)
= 7,455,240 MB
= 7,281 GB
数据库目录容量 = 数据库文件容量的 10%
= 728 GB
总数据库容量 = (数据库文件大小) + (索引大小) ÷ 0.80，以提供 20% 的卷可用空间
= (7281 + 728) ÷ 0.8
= 10,011 GB
构建基块中的六个数据库需要 10,011 GB 的完全配置存储容量。
步骤 12：确定构建基块的日志容量要求
若要确定构建基块中 2,700 个邮箱所需的日志存储容量，请使用以下计算：
所需构建基块日志容量 = 邮箱用户数 × 每个邮箱每天的日志数 × 日志大小 × (替换故障基础结构所需的天数) + (邮箱移动百分比开销)
= (2700 × 20 × 1024 × 4) + (2700 × 0.01 × 2048)
= 216,054 MB
= 211 GB
总日志容量 = 日志容量 ÷ 0.80，以提供 20% 的卷可用空间
= 211 ÷ 0.80
= 264
构建基块中的六个日志集需要 264 GB 的存储容量。
| 注意： |
|---|
| 因为日志卷不是精简配置，所以计算得到的存储容量表示完全配置环境的日志容量要求。 |
步骤 13：确定支持构建基块的 IOPS 要求所需的心轴数
在此步骤中，确定支持 IOPS 要求所需的心轴数。在下一步中，您会确定满足容量要求的心轴计数。
在上面的步骤中，确定支持 2,700 邮箱构建基块所需的 IOPS 是 324。在此步骤中，会使用下面的计算来计算满足 IOPS 要求所需的磁盘数：
磁盘计数 = (用户 IOPS × 读取比率) + 写入限制 × (用户 IOPS × 写入比率) ÷ 所选磁盘类型的 IOPS 容量
= (324 × 0.6) + 4 × (324 × 0.4) ÷ 155
= 4.6
可以通过 RAID-5 配置中的五个磁盘来满足 IOPS 要求。
| 注意： |
|---|
| 这些计算特定于此 EMC 解决方案。您应咨询存储供应商，以获取有关所选存储解决方案的心轴要求的指导。 |
步骤 14：确定支持构建基块的初始数据库容量要求所需的心轴数
在上面的步骤中，您确定 600 MB 初始配置邮箱的 2,700 邮箱构建基块需要 3,271 GB 的存储容量。CX4 型号 480 上 RAID-5 配置中的每个 450-GB 心轴的可用容量大约是 402 GB。若要确定所需的磁盘数，请使用下面的计算：
磁盘计数 = (所需总容量) ÷ (具有 RAID-5 的每个心轴的可用容量)
= 3271 GB ÷ 402 GB
= 8.1
可以通过九个磁盘来满足初始数据库容量要求。
使用精简配置在 EMC 统一存储上部署存储的 EMC 最佳做法是以五个磁盘的倍数配置 RAID-5 精简池。为包含 2,700 个邮箱的一个构建基块分配 10 个磁盘，这样便有空余空间用于将来的增长。
步骤 15：确定支持构建基块的完全配置数据库容量要求所需的心轴数
在上面的步骤中，您确定 2,048 MB 初始配置邮箱的 2,700 邮箱构建基块需要 10,011 GB 的存储容量。CX4 型号 480 上 RAID-5 配置中的每个 450-GB 心轴的可用容量大约是 402 GB。若要确定所需的磁盘数，请使用下面的计算：
磁盘计数 = (所需总容量) ÷ (具有 RAID-5 的每个心轴的可用容量)
= 10011 GB ÷ 402 GB
= 24.9
可以通过 25 个磁盘来满足完全配置数据库容量要求。
步骤 16：确定支持构建基块的日志容量要求所需的心轴数
在上面的步骤中，您确定 2,700 邮箱构建基块需要 264 GB 的日志存储容量。使用 CX4-480 上 RAID-1/0 配置中的两个 450 GB 驱动器可提供 402 GB 的可用存储容量。建议的双磁盘配置可满足 2,700 邮箱构建基块的日志容量要求。
步骤 17：确定精简池策略
现在已确定了支持构建基块的 IOPS 和容量要求所需的心轴数，您需要确定在使用虚拟或精简配置时，为该构建基块在阵列上配置 LUN 的最佳方式。
在设计要用于 Exchange 的精简池时，可以使用三种主要模型：
单个存储池 用于所有 Exchange 数据库和日志的一个大型存储池是最简单的方法，可提供最佳空间利用率。但是，在相同数据库的多个副本位于相同物理阵列上时，不建议使用单个精简池。
每个服务器一个存储池 在阵列上布局 LUN 时，对每个 Exchange 邮箱服务器都使用一个存储池可提供更高粒度。如果经过正确设计，则该模型可提供数据库副本隔离以分隔心轴集，并且可以尽量减少在种子设定/种子重新设定、备份和联机维护（后台数据库维护）等活动过程中可能出现的任何磁盘争用问题。但是，根据您拥有的邮箱服务器数，此模型可能会形成许多精简池，这可能更加难以管理。
每个数据库副本一个存储池 对每个数据库副本使用一个存储池可确保每个副本在阵列上的不同心轴集上隔离。因为大多数组织部署两到四个数据库副本，所以精简池的数量会保持在可管理的数量。在此模型中，多个邮箱服务器会在相同精简池中拥有数据库 LUN。一个邮箱服务器上的活动（如种子设定/种子重新设定、备份和联机维护（后台数据库维护））可能会影响其他邮箱服务器上的性能。
*设计决策点*
虽然每个服务器一个存储池模型的好处令人心动，但是这会在每个站点中形成八个精简池，即总共 24 个精简池。为简单起见，会使用每个数据库副本一个存储池模型，这会在每个站点中形成三个精简池，并保证每个数据库副本都驻留在唯一的心轴集上。在任何必须添加更多存储以适应增长的情况下，这还会确保维持数据库副本心轴隔离。
步骤 18：确定每个精简池的初始心轴数
第一个精简池会包含来自站点中四个主数据中心邮箱服务器的每个服务器的一个 2,700 邮箱构建基块。在上面的步骤中，确定支持构建基块的 IOPS 和容量要求需要 10 个心轴。支持 10,800 个活动邮箱的第一个精简池需要 40 个心轴。
第二个精简池也会包含来自站点中四个主数据中心邮箱服务器的每个服务器的一个 2,700 邮箱构建基块。支持 10,800 个被动邮箱的第二个精简池需要 40 个心轴。
第三个精简池也会包含来自站点中四个辅助数据中心邮箱服务器（备用 DAG 中支持站点弹性数据库副本的服务器）的每个服务器的一个 2,700 邮箱构建基块。支持 10,800 个被动邮箱的第三个精简池需要 40 个心轴。
支持初始数据库容量要求需要每个站点总共 120 个心轴。
步骤 19：确定每个精简池的完全配置心轴数
第一个精简池会包含来自站点中四个主数据中心邮箱服务器的每个服务器的一个 2,700 邮箱构建基块。在上面的步骤中，确定支持构建基块的 IOPS 和完全配置容量要求需要 25 个心轴。支持 10,800 个活动邮箱的第一个精简池需要 100 个心轴。
第二个精简池也会包含来自站点中四个主数据中心邮箱服务器的每个服务器的一个 2,700 邮箱构建基块。支持 10,800 个被动邮箱的第二个精简池需要 100 个心轴。
第三个精简池也会包含来自站点中四个辅助数据中心邮箱服务器（备用 DAG 中支持站点弹性数据库副本的服务器）的每个服务器的一个 2,700 邮箱构建基块。支持 10,800 个被动邮箱的第三个精简池需要 100 个心轴。
支持完全配置数据库容量要求需要每个站点总共 300 个心轴。
步骤 20：确定支持所有日志 LUN 所需的心轴数
在上面的步骤中，确定每个 2,700 邮箱构建基块需要两个心轴来支持日志 LUN 要求。
有四个构建基块支持主数据中心邮箱服务器上的活动邮箱数据库。支持 10,800 个活动邮箱的日志 LUN 需要八个心轴。
有四个构建基块支持主数据中心邮箱服务器上的被动邮箱数据库。支持 10,800 个被动邮箱的日志 LUN 需要八个心轴。
有四个构建基块支持辅助数据中心邮箱服务器上的被动邮箱数据库。支持 10,800 个被动邮箱的日志 LUN 需要八个心轴。
若要支持单个站点中的日志 LUN 要求，需要 24 个心轴。
步骤 21：验证存储阵列是否可以支持初始所需心轴计数
在此步骤中，使用下面的计算，来验证所选存储阵列是否可以支持所需总心轴计数：
每个站点所需的总心轴数 = 数据库 LUN 所需的心轴数 + 日志 LUN 所需的心轴数
= 120 + 24
= 144
带有 10 磁盘阵列机箱的 CX4-480 具有 150 个心轴，可满足要求。
步骤 22：确定支持完全配置环境所需的心轴数
在此步骤中，使用下面的计算，来计算支持完全配置环境所需的总心轴数：
每个站点所需的总心轴数 = 数据库 LUN 所需的心轴数 + 日志 LUN 所需的心轴数
= 300 + 24
= 324
带有 22 磁盘阵列机箱的 CX4-480 具有 330 个心轴，可满足要求。
Exchange 2010 测试解决方案
解决方案概述
上一节提供了有关在考虑 Exchange 2010 解决方案时进行的设计决策的信息。下一节概述了解决方案。
Exchange 2010 测试解决方案
逻辑解决方案图
此解决方案由采用多站点拓扑部署的总共 36 个 Exchange 2010 服务器组成。这 36 个服务器中的 12 个同时运行客户端访问和集线器传输服务器角色。其他 24 个服务器运行邮箱服务器角色。在每个站点中都有一个客户端访问服务器阵列（包含四个客户端访问和集线器传输组合服务器）。有三个 DAG，每个都包含八个邮箱服务器。每个站点中的文件服务器为每个 DAG 承载主文件共享见证服务器和备用文件共享见证服务器。
逻辑解决方案图
Exchange 2010 测试解决方案
物理解决方案图
三个站点各自包含四个 Cisco B200 刀片服务器，这些服务器通过冗余 Cisco Fabric Interconnect 6120 和 Cisco MDS 9134 交换机连接到 EMC CLARiiON CX4 型号 480 存储阵列。冗余 Cisco Nexus 5010 以太网交换机提供基础网络基础结构。客户端通信通过冗余 Cisco ACE 4710 负载平衡设备，在每个站点中的客户端访问服务器阵列间进行负载平衡。
物理解决方案图
Exchange 2010 测试解决方案
Hyper-V 根服务器配置摘要
下表汇总了此解决方案中使用的物理服务器硬件。
Cisco 统一计算系统摘要
| 项目 | 描述 |
|---|---|
刀片服务器 |
4 × B200 M1 |
处理器 |
2 × Intel Zeon x5570 (2.93 GHz) |
内存 |
96 GB RAM (12 × 8 GB DIMM) |
融合网络适配器 |
M71KR-Q（2 × 10 千兆以太网和 2 × 4 Gbps 光纤通道） |
内部刀片存储 |
2 × 146 GB SAS 10,000 RPM 磁盘 (RAID-1) |
机壳 |
5108 (6RU) |
结构扩展器 |
2 × 2104XP |
结构互连 |
2 × 6120XP |
结构互连扩展模块 |
2 × 8 端口 4 Gbps 光纤通道 |
下表汇总了此解决方案中使用的存储和网络硬件。
LAN 和 SAN 交换机
| 项目 | 描述 |
|---|---|
10 千兆以太网 (GbE) 交换机 |
2 × Nexus 5010（8 个固定 1 GbE/10 GbE 端口，12 个固定 10 GbE 端口，数据中心桥接） |
光纤通道交换机 |
2 × MDS 9134（32 个固定 4 Gbps 端口） |
下表提供有关此解决方案中使用的软件的信息。
解决方案软件摘要
| 项目 | 描述 |
|---|---|
虚拟机监控程序主机服务器 |
Windows Server 2008 R2 Hyper-V Enterprise |
Exchange Server VM |
Windows Server 2008 R2 Enterprise |
Exchange Server 2010 邮箱服务器角色 |
企业版 RU2 |
Exchange Server 2010 集线器传输和客户端访问服务器角色 |
标准版 RU2 |
多路径和 I/O 平衡 |
EMC PowerPath |
Exchange 2010 测试解决方案
客户端访问和集线器传输服务器配置
下表汇总了此解决方案中使用的客户端访问和集线器传输组合服务器配置。
客户端访问和集线器传输服务器配置
| 组件 | 值或描述 |
|---|---|
物理或虚拟 |
Hyper-V VM |
虚拟处理器 |
3 |
内存 |
8 GB |
存储 |
根服务器操作系统卷上的虚拟硬盘 |
操作系统 |
Windows Server 2008 R2 |
Exchange 版本 |
Exchange Server 2010 Standard Edition |
Exchange 更新级别 |
Exchange 2010 更新汇总 2 |
第三方软件 |
无 |
Exchange 2010 测试解决方案
邮箱服务器配置
下表汇总了此解决方案中使用的主邮箱服务器（为 DAG 承载主站点中的主辅助数据库副本和辅助数据库副本）配置。
主邮箱服务器配置
| 组件 | 值或描述 |
|---|---|
物理或虚拟 |
Hyper-V VM |
虚拟处理器 |
4 |
内存 |
53 GB |
存储 |
根服务器操作系统卷上的虚拟硬盘 |
操作系统 |
Windows Server 2008 R2 |
Exchange 版本 |
Exchange Server 2010 Enterprise Edition |
Exchange 更新级别 |
Exchange 2010 更新汇总 2 |
第三方软件 |
无 |
下表汇总了此解决方案中使用的辅助邮箱服务器（为 DAG 承载辅助站点中的第三级数据库副本）配置。
辅助邮箱服务器配置
| 组件 | 值或描述 |
|---|---|
物理或虚拟 |
Hyper-V VM |
虚拟处理器 |
2 |
内存 |
24 GB |
存储 |
根服务器操作系统卷上的虚拟硬盘 |
操作系统 |
Windows Server 2008 R2 |
Exchange 版本 |
Exchange Server 2010 Enterprise Edition |
Exchange 更新级别 |
Exchange 2010 更新汇总 2 |
第三方软件 |
无 |
Exchange 2010 测试解决方案
数据库布局
下图汇总了正常运行情况下此解决方案中使用的数据库副本布局：
数据库副本布局：1
数据库副本布局：2
数据库副本布局：3
Exchange 2010 测试解决方案
存储硬件摘要
下表提供有关此解决方案中使用的存储硬件的信息。
EMC 统一存储 NS-480（集成了 CLARiiON CX4-480）
| 项目 | 描述 |
|---|---|
存储 |
3 CLARiiON CX4-480（每站点 1 个） |
存储连接（光纤通道、SAS、SATA、iSCSI） |
光纤通道 |
存储缓存 |
32 GB（每个存储端口 600 MB 读取高速缓存和 10,160 MB 写入高速缓存） |
存储控制器数 |
每个存储框架 2 个 |
可用或使用的存储端口数 |
每个存储框架有 8 个（每个存储端口 4 个）可用，使用 4 个（每个存储端口 2 个） |
与主机之间的存储连接的最大带宽 |
8 × 4 Gbps |
解决方案中测试的总磁盘数 |
432 个（3 个站点间有 360 个用于数据库，72 个用于日志） |
存储中可以承载的最大心轴数 |
单个存储阵列中为 480 个 |
Exchange 2010 测试解决方案
存储配置
解决方案中使用的每个 CX4 型号 480 存储阵列都按下表所述进行配置。
存储配置
| 组件 | 值或描述 |
|---|---|
总存储机箱数 |
3 |
每个站点的总存储机箱数 |
1 |
每个机箱的总磁盘数 |
150 |
每个机箱的总存储池数 |
3 |
每个存储池的总磁盘数（初始） |
40 |
每个数据库 LUN 的总磁盘数（初始） |
10 |
每个日志 LUN 的总磁盘数 |
2 |
每个机箱使用的总磁盘数 |
144 |
数据库的 LUN 大小（初始） |
4,020 GB |
日志的 LUN 大小 |
402 GB |
数据库的 RAID 级别 |
5 |
日志的 RAID 级别 |
1/0 |
下表说明了如何在三个 CX4 型号 480 存储系统之间设计和分配可用存储。
CX4 型号 480 存储系统之间的存储配置
| 数据中心 | DAG | 数据库 | Array1 | Array2 | Array3 |
|---|---|---|---|---|---|
1 |
1 |
DB1-24 |
C1、C2 |
C3 |
|
2 |
2 |
DB25-48 |
C3 |
C1、C2 |
|
3 |
3 |
DB49-72 |
C3 |
C1、C2 |
Exchange 2010 测试解决方案
解决方案验证方法
在生产环境中部署 Exchange 解决方案之前，需验证是否正确地对解决方案进行了设计、大小调整和配置。此验证必须包括用于确保系统按需要运行的功能测试，以及用于确保系统可以处理所需用户负载的性能测试。本节介绍用于为此解决方案验证服务器和存储设计的途径和测试方法。具体而言，会详细定义以下测试：
性能测试
存储性能验证 (Jetstress)
服务器性能验证 (Loadgen)
功能测试
数据库切换验证
服务器切换验证
服务器故障转移验证
数据中心切换验证
Exchange 2010 测试解决方案
存储设计验证方法
连接到 Exchange 邮箱服务器角色的存储子系统的性能和可靠性级别会显著影响 Exchange 部署的整体运行状况。此外，糟糕的存储性能还会导致高事务延迟（主要反映为访问 Exchange 系统时的糟糕客户端体验）。若要确保实现可能的最佳客户端体验，请通过本节中介绍的方法来验证存储大小调整和配置。
工具集
对于验证 Exchange 存储大小调整和配置，建议使用 Microsoft Exchange Server Jetstress 工具。Jetstress 工具旨在通过直接与 ESE（也称为 Jet）交互，在数据库级别上模拟 Exchange I/O 工作负载。ESE 是 Exchange 用于在邮箱服务器角色上存储邮件数据的数据库技术。Jetstress 可以配置为在 Exchange 的所需性能约束下，测试对存储子系统可用的最大 I/O 吞吐量。或者，Jetstress 可以接受用户计数和每用户 IOPS 的目标配置文件，并验证存储子系统是否能够对目标配置文件维持可接受的性能级别。测试持续时间可以调整，可以运行最短时间段来验证足够性能，或运行较长时间段来另外验证存储子系统可靠性。
Jetstress 工具可以从 Microsoft 下载中心的下列位置获取：
随 Jetstress 安装程序包含的文档介绍如何在服务器硬件上配置和执行 Jetstress 验证测试。
存储验证方法
主要有两种类型的存储配置：
DAS 或内部磁盘方案
SAN 方案
对于 DAS 或内部磁盘方案，只有一个服务器访问磁盘子系统，因此可以分开验证存储子系统的性能。
在 SAN 方案中，解决方案使用的存储可以由许多服务器共享，并且将服务器连接到存储的基础结构也可以是共享依赖关系。这需要进行附加测试，因为必须充分模拟其他服务器对共享基础结构的影响，才能验证性能和功能。
存储验证的测试用例
以下存储验证测试用例针对解决方案执行，应视为存储验证的起点。特定部署可能具有可以通过附加测试满足的其他验证要求，因此此列表并不旨在作为详尽列表：
最坏数据库切换情况的验证 在此测试用例中，预计在最坏切换情况（在最少服务器上存在可能的最大主动副本数）下由存储子系统为 I/O 级别提供服务。根据存储子系统是 DAS 还是 SAN，此测试可能需要在多个主机上运行，以确保可以承受存储子系统上的端到端解决方案负载。
存储故障和恢复情况（例如，故障磁盘替换和重建）下的存储性能验证 在此测试用例中，会评估故障和重建情况下的存储子系统性能，以确保为实现最佳 Exchange 客户端体验维持所需性能级别。同样的告诫适用于 DAS 与 SAN 部署：如果多个主机依赖于共享存储子系统，则测试必须包括来自这些主机的负载，才能模拟故障和重建的整个影响。
分析结果
每个测试完成后，Jetstress 工具都会生成报告文件。为了帮助您分析报告，请使用 Jetstress 2010 Test Summary Reports中的指导。
具体来说，您应在检查报告的“测试结果”表中的数据时使用下表中的指导。
Jetstress 结果分析
| 性能计数器实例 | 性能测试指导 |
|---|---|
I/O Database Reads Average Latency (msec) |
平均值应小于 20 毫秒 (msec)（0.020 秒），最大值应小于 50 msec。 |
I/O Log Writes Average Latency (msec) |
日志磁盘写入是顺序的，因此平均写入延迟应小于 10 msec，而最大值不超过 50 msec。 |
处理器时间百分比 |
平均值应小于 80%，最大值应小于 90%。 |
Transition Pages Repurposed/sec（Windows Server 2003、Windows Server 2008、Windows Server 2008 R2） |
平均值应小于 100。 |
报告文件会显示 Exchange 系统执行的各种 I/O 类别：
事务性 I/O 性能 此表报告表示针对数据库的用户活动的 I/O（例如，Outlook 生成的 I/O）。此数据的生成方式是从测试过程中测量的总 I/O 中减去后台维护 I/O 和日志复制 I/O。此数据提供实际数据库 IOPS（随用于确定 Jetstress 性能测试是通过还是失败所需的 I/O 延迟测量一起生成）。
后台数据库维护 I/O 性能 此表报告由于进行 ESE 数据库后台维护而生成的 I/O。
日志复制 I/O 性能 此表报告从模拟的日志复制生成的 I/O。
总 I/O 性能 此表报告在 Jetstress 测试过程中生成的总 I/O。
Exchange 2010 测试解决方案
服务器设计验证
在验证存储子系统的性能和可靠性之后，需确保一起验证邮件系统中所有组件的功能、性能和可伸缩性。这表示从下向上以验证与 Exchange 产品进行的客户端软件交互以及与 Exchange 交互的任何服务器端产品。为了确保端到端客户端体验可接受并且整个解决方案可以承受所需用户负载，可以将本节中所述的方法应用于服务器设计验证。
工具集
对于端到端解决方案性能和可伸缩性的验证，建议使用 Microsoft Exchange Server 负载生成器工具 (Loadgen)。Loadgen 旨在针对 Exchange 部署生成模拟的客户端工作负载。此工作负载可用于评估 Exchange 系统的性能，还可用于分析在系统负载情况下，各种配置更改对整体解决方案的影响。Loadgen 能够模拟 Microsoft Office Outlook 2007（联机和缓存）、Office Outlook 2003（联机和缓存）、POP3、IMAP4、SMTP、ActiveSync 和 Outlook Web App（在 Exchange 2007 和早期版本中称为 Outlook Web Access）客户端活动。它可用于生成单协议工作负载，也可以将这些客户端协议组合在一起来生成多协议工作负载。
可以通过以下位置，从 Microsoft 下载中心获取 Loadgen 工具：
随 Loadgen 安装程序包含的文档介绍如何针对 Exchange 部署配置和执行 Loadgen 测试。
服务器验证方法
在验证服务器设计时，应在预期峰值工作负载下测试最坏情况。基于来自 Microsoft IT 和其他客户的许多数据集，峰值负载通常等于工作日其余时间内的平均工作负载的两倍。这称为峰值/平均值工作负载比率。
性能监视器
在此性能监视器快照（显示的是表示在生产邮箱服务器上随时间推移而执行的 Exchange 工作量的各种计数器）中，每秒 RPC 操作的平均值（突出显示的线条）大约是 2,386（全天平均值）。此计数器在峰值时间段（从 10:00 到 11:00）内的平均值大约是 4,971，因而峰值/平均值比率是 2.08。
若要确保 Exchange 解决方案能够承受在峰值平均值期间生成的工作负载，请修改 Loadgen 设置以在峰值平均值级别生成稳定负载量，而不是将工作负载分布于整个模拟工作日。Loadgen 基于任务的模拟模块（如 Outlook 模拟模块）可利用任务配置文件，该配置文件定义每个任务在模拟日中对普通用户进行的次数。
模拟日中需要运行的总任务数的计算方式是用户数乘以已配置任务配置文件中的任务计数之和。Loadgen 随后通过将要在模拟日中运行的总任务数除以模拟日长度，来确定应为配置的用户集运行任务的速率。例如，如果 Loadgen 需要在模拟日中运行 1,000,000 次任务，并且模拟日等于 8 个小时（28,800 秒），则 Loadgen 必须每秒运行 1,000,000 ÷ 28,800 = 34.72 次任务，才能满足所需工作负载定义。若要将负载量提高到所需峰值平均值，请将默认模拟日长度（8 小时）除以峰值/平均值 (2)，然后将此用作新模拟日长度。
再次使用任务速率示例，可得到 1,000,000 ÷ 14,400 = 69.44 次任务/秒。这将模拟日长度减少了一半，从而导致对服务器运行的实际工作负载翻番，实现了峰值平均工作负载这一目标。您无需在 Loadgen 配置中调整测试的运行长度持续时间。运行长度持续时间指定测试的持续时间，不会影响对 Exchange 服务器运行任务的速率。
服务器设计验证的测试用例
以下服务器设计验证测试用例针对解决方案执行，应视为服务器设计验证的起点。特定部署可能具有可以通过附加测试满足的其他验证要求，因此此列表并不旨在作为详尽列表：
正常运行情况 在此测试用例中，会在所有组件都处于其正常运行状态（不模拟故障）的情况下验证解决方案的基本设计。针对解决方案生成所需工作负载，并针对遵循的指标验证解决方案的整体性能。
单服务器故障或单服务器维护（站点中） 在此测试用例中，使单个服务器停机，以模拟该服务器的意外故障或该服务器的计划维护操作。通常由不可用服务器处理的工作负载现在由解决方案拓扑中的其他服务器处理，可验证解决方案的整体性能。
测试执行和数据收集
Exchange 性能数据在测试运行中以及测试运行间会发生某种自然变化。建议您采用多次运行的平均值以消除这种变化。对于 Exchange 测试解决方案，至少计算了三次独立测试运行（八小时持续时间）。在整个八小时测试持续时间内一直收集性能数据。性能摘要数据来自三到四小时的稳定时间段（排除测试的头两个小时和测试的最后一个小时）。对于每个 Exchange 服务器角色，每次测试运行的性能摘要数据会在服务器间进行平均，从而为每个数据点提供一个平均值。随后对每次运行的值进行平均，从而为具有相同服务器角色的所有服务器跨所有测试运行提供一个数据点。
预期负载的验证
在查看任何性能计数器或开始性能验证分析之前，请验证您预期运行的工作负载是否与实际运行的工作负载匹配。虽然可通过许多方式来确定模拟工作负载是否与预期工作负载匹配，但是最简单且最一致的方式是了解邮件传递速率。
计算预期峰值邮件传递速率
每个邮件配置文件都包含每天发送的平均邮件数与每天接收的平均邮件数之和。若要计算邮件传递速率，请从下表选择每天接收的平均邮件数。
峰值邮件传递速率
| 邮件配置文件 | 每天发送的邮件数 | 每天接收的邮件数 |
|---|---|---|
50 |
10 |
40 |
100 |
20 |
80 |
150 |
30 |
120 |
200 |
40 |
160 |
下面的示例假设每个邮箱服务器具有配置文件为每天 150 封邮件（每天发送 30 封邮件和接收 120 封邮件）的 5,000 个活动邮箱。
5000 个活动邮箱的峰值邮件传递速率
| 描述 | 计算 | 值 |
|---|---|---|
邮件配置文件 |
每天接收的邮件数 |
120 |
每个邮箱服务器的活动邮箱数 |
不适用 |
5000 |
每个邮箱服务器每天接收的总邮件数 |
5000 × 120 |
600000 |
每个邮箱服务器每秒接收的总邮件数 |
600000 ÷ 28800 |
20.83 |
针对峰值负载调整的总邮件数 |
20.83 × 2 |
41.67 |
您预计在运行 5,000 个活动邮箱（邮件配置文件为每天 150 封邮件）的每个邮箱服务器上，峰值负载期间每秒传递 41.67 封邮件。
测量实际邮件传递速率
可以在邮箱服务器上使用下面的计数器来测量实际邮件传递速率：MSExchangeIS Mailbox(_Total)\Messages Delivered/sec。如果测量的邮件传递速率与目标邮件传递速率每秒相差一或两封邮件，则可以确信成功运行了所需负载配置文件。
服务器验证：性能和运行状况条件
本节介绍用于确定 Exchange 环境是否正确调整了大小并能够在长时间峰值工作负载下以正常状态运行的性能监视器计数器和阈值。有关与 Exchange 性能相关的计数器的详细信息，请参阅性能和可伸缩性计数器及阈值。
Hyper-V 根服务器
若要验证在 VM 中运行的 Hyper-V 根服务器和应用程序的性能和运行状况条件，您应对 Hyper-V 体系结构以及该体系结构如何影响性能监视具有基本了解。
Hyper-V 具有三个主要组件：虚拟化堆栈、虚拟机监控程序和设备。虚拟化堆栈处理仿真的设备、管理 VM 并为 I/O 提供服务。虚拟机监控程序安排虚拟处理器、管理中断、为计时器提供服务并控制其他芯片级功能。虚拟机监控程序不处理设备或 I/O（例如，不存在虚拟机监控程序驱动程序）。设备是根服务器的一部分，或是作为集成服务的一部分安装在来宾服务器中。因为根服务器具有系统的完整视图并控制 VM，所以它还通过 Windows Management Instrumentation (WMI) 和性能计数器提供监视信息。
处理器
在验证根服务器上（或来宾 VM 中）的物理处理器利用率时，标准 Processor\% Processor Time 计数器并不十分有用。
而是可以检查 Hyper-V Hypervisor Logical Processor\% Total Run Time 计数器。此计数器显示在来宾和虚拟机监控程序运行时中花费的处理器时间百分比，应用于测量在根服务器上运行的虚拟机监控程序和所有 VM 的总处理器利用率。此计数器不应超过 80%，或是您设计的任何最大利用率目标。
| 计数器 | 目标 |
|---|---|
Hyper-V Hypervisor Logical Processor\% Total Run Time |
<80% |
如果需要了解在为来宾 VM 提供服务方面花费的处理器时间百分比，则可以检查 Hyper-V Hypervisor Logical Processor\% Guest Run Time 计数器。如果需要了解在虚拟机监控程序方面花费的处理器时间百分比，则可以查看 Hyper-V Hypervisor Logical Processor\% Hypervisor Run Time 计数器。此计数器应低于 5%。Hyper-V Hypervisor Root Virtual Processor\% Guest Run Time 计数器显示在虚拟化堆栈方面花费的处理器时间百分比。此计数器也应低于 5%。这两个计数器可以用于确定用于支持虚拟化的可用物理处理器时间百分比。
| 计数器 | 目标 |
|---|---|
Hyper-V Hypervisor Logical Processor\% Guest Run Time |
<80% |
Hyper-V Hypervisor Logical Processor\% Hypervisor Run Time |
<5% |
Hyper-V Hypervisor Root Virtual Processor\% Guest Run Time |
<5% |
内存
您需要确保 Hyper-V 根服务器具有足够内存来支持分配给 VM 的内存。Hyper-V 会自动为根操作系统保留 512 MB（这可能因不同 Hyper-V 版本而异）。如果您没有足够内存，则 Hyper-V 会阻止最后一个 VM 启动。通常，不用担心对 Hyper-V 根服务器上的内存的验证。更加需要关心的是确保向 VM 分配足够内存来支持 Exchange 角色。
应用程序运行状况
确定所有 VM 是否都处于正常状态的一种简单方式是查看 Hyper-V 虚拟机运行状况摘要计数器。
| 计数器 | 目标 |
|---|---|
Hyper-V Virtual Machine Health Summary\Health OK |
1 |
Hyper-V Virtual Machine Health Summary\Health Critical |
0 |
邮箱服务器
在验证邮箱服务器是否正确调整了大小时，请关注处理器、内存、存储和 Exchange 应用程序运行状况。本节介绍验证其中每个组件的方法。
处理器
在设计过程中，计算了服务器或处理器平台的调整兆周期容量。随后确定了在不超过 80% 的可用兆周期容量的情况下，服务器可以支持的最大活动邮箱数。还确定了在正常运行情况下以及各种服务器维护或故障情况下应具有的预计 CPU 利用率。
在验证过程中，需验证最坏情况工作负载是否不超过 80% 的可用兆周期数。还需验证在正常运行情况下以及各种服务器维护或故障情况下，实际 CPU 利用率是否接近于预计 CPU 利用率。
对于物理 Exchange 部署，请使用 Processor(_Total)\% Processor Time 计数器并验证此计数器的平均值是否小于 80%。
| 计数器 | 目标 |
|---|---|
Processor(_Total)\% Processor Time |
<80% |
对于虚拟 Exchange 部署，会在 VM 中测量 Processor(_Total)\% Processor Time 计数器。在这种情况下，该计数器不测量物理 CPU 利用率。它测量虚拟机监控程序提供的虚拟 CPU 的利用率。因此，它不提供物理处理器的准确读数，不应该用于设计验证。有关详细信息，请参阅 Hyper-V：时钟说谎了... 可以信任哪些性能计数器。
对于验证在 Microsoft Hyper-V 上运行的 Exchange 部署，请使用 Hyper-V Hypervisor Virtual Processor\% Guest Run Time 计数器。此计数器为来宾操作系统使用的物理 CPU 量提供更加准确的值。此计数器的平均值应小于 80%。
| 计数器 | 目标 |
|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<80% |
内存
在设计过程中，计算了在每个邮箱服务器上支持最大活动数据库数所需的数据库缓存量。随后确定了用于支持数据库缓存和系统内存要求的最佳物理内存配置。
验证 Exchange 邮箱服务器是否具有足够内存来支持目标工作负载不是个简单任务。使用可用内存计数器查看剩余的物理内存量并不十分有用，因为 Exchange 中的内存管理器设计为使用几乎所有的可用物理内存。信息存储 (store.exe) 会为数据库缓存保留很大一部分物理内存。数据库缓存用于在内存中存储数据库页。当在内存中访问某页时，不必从磁盘检索信息，从而可减少读取 I/O。数据库缓存还用于优化写入 I/O。
当修改某个数据库页（称为“脏页”）时，该页会在缓存中保留一段时间。该页在缓存中的保留时间越长，就更加可能在更改写入到磁盘之前对该页进行多次修改。将脏页保留在缓存中还可在同一操作中将多个页写入到磁盘（称为“写入合并”）。Exchange 会尽可能多地使用系统中的可用内存，这便是 Exchange 邮箱服务器上没有大量可用内存的原因。
若要了解 Exchange 邮箱服务器上的内存配置是否大小不足可能并不容易。在大多数情况下，邮箱服务器仍会运行，但是 I/O 配置文件可能会远高于预期。较高 I/O 可能会导致较高磁盘读取和写入延迟，这可能会影响应用程序运行状况和客户端用户体验。在结果部分中，不存在对内存计数器的任何引用。潜在内存问题将在存储验证和应用程序运行状况结果部分中（在其中可更加方便地检测到与内存相关的问题）进行标识。
存储
如果您的 Exchange 邮箱服务器存在性能问题，则这些问题可能是与存储相关的问题。如前所述，导致存储问题的原因可能是没有足够磁盘数来支持目标 I/O 要求、具有过载或设计糟糕的存储连接基础结构或是更改目标 I/O 配置文件的一些因素（如内存不足）。
存储验证的第一步是验证数据库延迟是否低于目标阈值。在以前的版本中，逻辑磁盘计数器可确定磁盘读取和写入延迟。在 Exchange 2010 中，您所监视的 Exchange 邮箱服务器可能同时具有活动和被动邮箱数据库副本。主动和被动数据库副本的 I/O 特征是不同的。因为 I/O 的大小在被动副本上要大得多，所以通常被动副本上的延迟也要高得多。被动数据库的延迟目标是 200 msec，这比主动数据库副本上的目标高 10 倍。这并不是什么大问题，因为被动数据库上的高延迟不会影响客户端体验。但是如果您使用传统逻辑磁盘计数器测量延迟，则必须检查包含活动和被动数据库的各个卷和单独卷。建议您使用 Exchange 2010 中的新 MSExchange 数据库计数器。
在 Exchange 2010 邮箱服务器上验证延迟时，建议您将下表中的计数器用于活动数据库。
| 计数器 | 目标 |
|---|---|
MSExchange Database\I/O Database Reads (Attached) Average Latency |
<20 msec |
MSExchange Database\I/O Database Writes (Attached) Average Latency |
<20 msec |
MSExchange Database\IO Log Writes Average Latency |
<1 msec |
建议您将下表中的计数器用于被动数据库
| 计数器 | 目标 |
|---|---|
MSExchange Database\I/O Database Reads (Recovery) Average Latency |
<200 msec |
MSExchange Database\I/O Database Writes (Recovery) Average Latency |
<200 msec |
MSExchange Database\IO Log Read Average Latency |
<200 msec |
| 注意： |
|---|
| 若要在性能监视器中查看这些计数器，必须启用高级数据库计数器。有关详细信息，请参阅如何启用扩展 ESE 性能计数器。 |
在验证运行于 Microsoft Hyper-V 之上的 Exchange 部署的磁盘延迟时，请注意，I/O 数据库平均延迟计数器（与许多基于时间的计数器一样）可能不准确，因为 VM 中的时间概念与物理服务器上的时间概念不同。下面的示例演示对于相同模拟工作负载，I/O Database Reads (Attached) Average Latency 在 VM 中为 22.8，但在物理服务器上为 17.3。如果基于时间的计数器的值超过目标阈值，则您的服务器可能仍在正常运行。当邮箱服务器角色部署在 VM 中时，请检查所有运行状况条件，以进行与服务器运行状况有关的决策。
虚拟和物理邮箱服务器的磁盘延迟计数器的值
| 计数器 | 虚拟邮箱服务器 | 物理邮箱服务器 |
|---|---|---|
MSExchange Database/ |
||
I/O Database Reads (Attached) / Average Latency |
22.792 |
17.250 |
I/O Database Reads (Attached) / sec |
17.693 |
18.131 |
I/O Database Reads (Recovery) / Average Latency |
34.215 |
27.758 |
I/O Database Writes (Recovery) / sec |
10.829 |
8.483 |
I/O Database Writes (Attached) / Average Latency |
0.944 |
0.411 |
I/O Database Writes (Attached) / sec |
10.184 |
10.963 |
MSExchangeIS |
||
RPC Averaged Latency |
1.966 |
1.695 |
RPC OPERATIONS/SEC |
334.371 |
341.139 |
RPC Packets / sec |
180.656 |
183.360 |
MSExchangeIS 邮箱 |
||
Messages Delivered / sec |
2.062 |
2.065 |
Messages Sent / sec |
0.511 |
0.514 |
除了磁盘延迟之外，还请检查 Database\Database Page Fault Stalls/sec 计数器。此计数器指示由于数据库缓存中没有可分配的页面而无法获得服务的页面错误速率。此计数器在正常服务器上应为 0。
| 计数器 | 目标 |
|---|---|
Database\Database Page Fault Stalls/sec |
<1 |
还请检查 Database\Log Record Stalls/sec 计数器，该计数器指示每秒因日志缓冲区已满而无法添加到日志缓冲区的日志记录数。此计数器的平均值应小于 10。
| 计数器 | 目标 |
|---|---|
Database\Log Record Stalls/sec |
<10 |
Exchange 应用程序运行状况
即使处理器、内存和磁盘方面不存在明显问题，仍然建议您监视标准应用程序运行状况计数器以确保 Exchange 邮箱服务器处于正常状态。
MSExchangeIS\RPC Averaged Latency 计数器最适合指示具有高数据库延迟的其他计数器是否实际影响 Exchange 运行状况和客户端体验。通常，高 RPC 平均延迟与高 RPC 请求数（应始终小于 70）关联。
| 计数器 | 目标 |
|---|---|
MSExchangeIS\RPC Averaged Latency |
平均值 <10 msec |
MSExchangeIS\RPC Requests |
始终 <70 |
接下来，确保传输层正常。传输中的任何问题或影响传输层的传输下游问题都可以通过 MSExchangeIS Mailbox(_Total)\Messages Queued for Submission 计数器检测到。此计数器应始终小于 50。此计数器可能会临时增大，但是计数器值不应随时间增长并且不应维持 15 分钟以上。
| 计数器 | 目标 |
|---|---|
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission |
始终 <50 |
接下来，确保数据库副本的维护处于正常状态。与日志传送或日志重播有关的任何问题都可以使用 MSExchange Replication(*)\CopyQueueLength 和 MSExchange Replication(*)\ReplayQueueLength 计数器进行标识。复制队列长度显示等待复制到被动副本日志文件文件夹的事务日志文件数，应始终小于 1。重播队列长度显示等待重播到被动副本中的事务日志文件数，应小于 5。较高值不影响客户端体验，但是会在执行切换、故障转移或激活时，导致存储安装时间较长。
| 计数器 | 目标 |
|---|---|
MSExchange Replication(*)\CopyQueueLength |
<1 |
MSExchange Replication(*)\ReplayQueueLength |
<5 |
客户端访问服务器
若要确定客户端访问服务器是否处于正常状态，请检查处理器、内存和应用程序运行状况。有关重要计数器的扩展列表，请参阅客户端访问服务器计数器。
处理器
对于物理 Exchange 部署，请使用 Processor(_Total)\% Processor Time 计数器。此计数器的平均值应小于 80%。
| 计数器 | 目标 |
|---|---|
Processor(_Total)\% Processor Time |
<80% |
对于验证在 Microsoft Hyper-V 上运行的 Exchange 部署，请使用 Hyper-V Hypervisor Virtual Processor\% Guest Run Time 计数器。此计数器为来宾操作系统使用的物理 CPU 量提供准确值。此计数器的平均值应小于 80%。
| 计数器 | 目标 |
|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<80% |
应用程序运行状况
若要确定 MAPI 客户端体验是否可接受，请使用 MSExchange RpcClientAccess\RPC Averaged Latency 计数器。此计数器应低于 250 msec。高延迟可能与大量 RPC 请求相关联。MSExchange RpcClientAccess\RPC Requests 计数器的平均值应低于 40。
| 计数器 | 目标 |
|---|---|
MSExchange RpcClientAccess\RPC Averaged Latency |
<250 msec |
MSExchange RpcClientAccess\RPC Requests |
<40 |
传输服务器
若要确定传输服务器是否处于正常状态，请检查处理器、磁盘和应用程序运行状况。有关重要计数器的扩展列表，请参阅传输服务器计数器。
处理器
对于物理 Exchange 部署，请使用 Processor(_Total)\% Processor Time 计数器。此计数器的平均值应小于 80%。
| 计数器 | 目标 |
|---|---|
Processor(_Total)\% Processor Time |
<80% |
对于验证在 Microsoft Hyper-V 上运行的 Exchange 部署，请使用 Hyper-V Hypervisor Virtual Processor\% Guest Run Time 计数器。此计数器为来宾操作系统使用的物理 CPU 量提供准确值。此计数器的平均值应小于 80%。
| 计数器 | 目标 |
|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<80% |
磁盘
若要确定磁盘性能是否可接受，请将 Logical Disk(*)\Avg.Disk sec/Read 和 Write 计数器用于包含传输日志和数据库的卷。这两个计数器都应小于 20 msec。
| 计数器 | 目标 |
|---|---|
Logical Disk(*)\Avg.Disk sec/Read |
<20 msec |
Logical Disk(*)\Avg.Disk sec/Write |
<20 msec |
应用程序运行状况
若要确定集线器传输服务器是否正确调整了大小并在正常状态下运行，请检查下表中概述的 MSExchangeTransport 队列计数器。所有这些队列会在不同时间包含邮件。您需要确保队列长度不会在一段时间内维持和增长。如果出现较大队列长度，则这可能表示存在过载的集线器传输服务器。或者，可能存在网络问题或是无法接收新邮件的过载邮箱服务器。您需要检查 Exchange 环境的其他组件以进行验证。
| 计数器 | 目标 |
|---|---|
MSExchangeTransport Queues(_total)\Aggregate Delivery |
<3000 |
MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length |
<250 |
MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length |
<250 |
MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length |
<100 |
MSExchangeTransport Queues(_total)\Submission Queue Length |
<100 |
Exchange 2010 测试解决方案
功能验证测试
可以使用以下各节中的信息进行功能验证测试。
Exchange 2010 测试解决方案
数据库切换验证
数据库切换是单个活动数据库切换到另一个数据库副本（被动副本）的过程，该被动数据库副本将成为新的主动数据库副本。数据库切换在数据中心内及数据中心之间都可进行。通过使用 Exchange 管理控制台 (EMC) 或 Exchange 命令行管理程序均可执行数据库切换。
若要验证数据库的被动副本是否可以在另一个服务器上成功激活，请运行下面的命令。
Move-ActiveMailboxDatabase <DatabaseName> -ActivateOnServer <TargetServer>
成功条件：在指定目标服务器上装入活动邮箱数据库。此结果可以通过运行下面的命令来确认。
Get-MailboxDatabaseCopyStatus <DatabaseName>
Exchange 2010 测试解决方案
服务器切换验证
服务器切换是将 DAG 成员上的所有主动数据库在一个或多个其他 DAG 成员上激活的过程。与数据库切换一样，服务器切换在数据中心内及数据中心之间都可进行，通过 EMC 和命令行管理程序均可启动。
若要验证某个服务器上数据库的所有被动副本是否可以在承载被动副本的其他服务器上成功激活，请运行下面的命令。
Get-MailboxDatabase -Server <ActiveMailboxServer> | Move-ActiveMailboxDatabase -ActivateOnServer <TargetServer>成功条件：在指定目标服务器上装入活动邮箱数据库。这可以通过运行下面的命令来确认。
Get-MailboxDatabaseCopyStatus <DatabaseName>若要验证每个活动数据库的一个副本是否可以在承载数据库的被动副本的其他邮箱服务器上成功激活，请通过执行下面的操作来关闭服务器。
关闭当前活动服务器。
成功条件：在 DAG 中的其他邮箱服务器上装入活动邮箱数据库。这可以通过运行下面的命令来确认。
Get-MailboxDatabaseCopyStatus <DatabaseName>
Exchange 2010 测试解决方案
服务器故障转移验证
当 DAG 成员无法再为 MAPI 网络提供服务，或者 DAG 成员上的群集服务无法再与其余 DAG 成员联系时，会发生服务器故障转移。
若要验证每个活动数据库的一个副本是否可以在承载数据库的被动副本的其他邮箱服务器上成功激活，请通过执行以下操作之一来关闭服务器：
按住服务器上的电源按钮，直至服务器关闭。
从服务器上拔下电源电缆，这会导致服务器关闭。
成功条件：在 DAG 中的其他邮箱服务器上装入活动邮箱数据库。这可以通过运行下面的命令来确认。
Get-MailboxDatabase -Server <MailboxServer> | Get-MailboxDatabaseCopyStatus
Exchange 2010 测试解决方案
数据中心切换验证
数据中心或站点故障的管理方式不同于可能引起服务器或数据库故障转移的故障类型的管理方式。在高可用性配置中，自动恢复将由系统启动，故障通常会使邮件系统处于全功能状态。相比之下，数据中心故障被认为是灾难恢复事件，因此，必须手动执行和完成恢复才可还原客户端服务并结束中断。您所执行的过程称为“数据中心切换”。与很多灾难恢复方案一样，数据中心切换的前期规划和准备工作可简化恢复过程并缩短中断的持续时间。
有关详细信息（包括执行数据中心切换的详细步骤），请参阅数据中心切换。
在决定激活第二个数据中心之后，需要完成以下四个基本步骤才能执行数据中心切换：
终止部分运行（故障）的数据中心。
验证和确认第二个数据中心的先决条件。
激活邮箱服务器。
激活客户端访问服务器。
以下各节介绍了用于验证数据中心切换的步骤。
终止部分故障的数据中心（假设 DAG 处于 DAC 模式下）
当 DAG 处于 DAC 模式时，可以终止主数据中心中任何仍然正常运行的 DAG 成员的特定操作取决于故障数据中心的状态。执行以下操作之一：
如果故障数据中心中的邮箱服务器仍可访问（情况通常并非如此），请在每个邮箱服务器上运行下面的命令。
Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename>如果故障数据中心中的邮箱服务器不可用，但是 Active Directory 在主数据中心中运行，请在域控制器上运行下面的命令。
Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly
| 注意： |
|---|
| 未能关闭故障数据中心中的邮箱服务器，或未能成功对服务器执行 Stop-DatabaseAvailabilityGroup 命令，均可能会发生跨两个数据中心的网络分区症状。可能需要通过电源管理设备分别关闭计算机以满足此要求。 |
成功条件：故障站点中的所有邮箱服务器都处于停止状态。这可以通过从故障数据中心中的服务器运行下面的命令来验证。
Get-DatabaseAvailabilityGroup | Format-List
验证和确认辅助数据中心的先决条件
必须对第二个数据中心进行更新，以表示哪些主数据中心服务器已停止。从辅助数据中心中的服务器，运行下面的命令。
Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly
此步骤的目的在于通知辅助数据中心中的服务器还原服务时，哪些邮箱服务器可用。
成功条件：故障数据中心中的所有邮箱服务器都处于停止状态。若要对此进行验证，请从辅助数据中心中的服务器运行下面的命令。
Get-DatabaseAvailabilityGroup | Format-List
激活邮箱服务器（假设 DAG 处于 DAC 模式下）
在激活辅助数据中心中的 DAG 成员之前，建议您验证辅助数据中心中的基础结构服务是否可以进行邮件服务激活。
当 DAG 处于 DAC 模式时，在第二个数据中心中完成激活邮箱服务器的过程所需步骤如下：
停止辅助数据中心中的每个 DAG 成员上的群集服务。可以使用 Stop-Service cmdlet 来停止此服务（例如 Stop-Service ClusSvc），或者在提升的命令提示符下使用 net stop clussvc。
若要激活辅助数据中心中的服务器，请运行下面的命令。
Restore-DatabaseAvailabilityGroup -Identity <DAGname> -ActiveDirectorySite <insertsitename>如果此命令成功，则仲裁条件将缩小为辅助数据中心中的服务器。如果此数据中心中的服务器数为偶数，则 DAG 将切换为使用 DAG 对象上的设置标识的备用见证服务器。
若要激活数据库，请运行以下命令之一。
Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinPrimarySite>或者
Move-ActiveMailboxDatabase -Server <DAGMemberInSecondarySite> -ActivateOnServer <DAGMemberinPrimarySite>检查事件日志并查看所有错误和警告消息以确保辅助站点正常。应在装入数据库之前对指示的任何错误执行后续操作和更正。
若要装入数据库，请运行下面的命令。
Get-MailboxDatabase <DAGMemberInSecondarySite> | Mount-Database
成功条件：在辅助站点中的邮箱服务器上装入活动邮箱数据库。若要进行确认，请运行下面的命令。
Get-MailboxDatabaseCopyStatus <DatabaseName>
激活客户端访问服务器
客户端连接到服务终结点以访问 Exchange 服务和数据。因此，激活面向 Internet 的客户端访问服务器会将 DNS 记录更改为指向将为新服务终结点配置的新 IP 地址。然后，客户端将通过以下两种方式之一自动连接到新服务终结点：
客户端将继续尝试连接，并且应在原始 DNS 条目的生存时间 (TTL) 过期以及客户端的 DNS 缓存条目过期之后进行自动连接。用户还可以在命令提示符下运行 ipconfig /flushdns 命令来手动清除其 DNS 缓存。如果使用 Outlook Web App，则 Web 浏览器可能需要关闭并重新启动，以清除浏览器使用的 DNS 缓存。在 Exchange 2010 SP1 中，可以通过配置 Outlook Web App 虚拟目录 owa 上的 FailbackURL 参数来缓解此浏览器缓存问题。
启动或重新启动的客户端将在启动时执行 DNS 查找，并会为服务终结点获取新 IP 地址，此 IP 地址将是第二个数据中心中的客户端访问服务器或数组。
若要验证使用 Loadgen 的方案，请执行以下操作：
将客户端访问服务器阵列的 DNS 条目更改为指向辅助站点中硬件负载平衡的虚拟 IP 地址。
在所有 Loadgen 服务器上运行 ipconfig /flushdns 命令。
重新启动 Loadgen 测试。
验证辅助站点中的客户端访问服务器现在是否正为负载提供服务。
若要验证使用 Outlook 2007 客户端的方案，请执行以下操作：
将客户端访问服务器阵列的 DNS 条目更改为指向辅助站点中硬件负载平衡的虚拟 IP 地址。
在客户端上运行 ipconfig /flushdns 命令，或等到 TTL 过期。
等待 Outlook 客户端重新连接。
Exchange 2010 测试解决方案
主数据中心服务还原验证
将服务还原到先前发生故障的数据中心的过程称为“故障回复”。用于执行数据中心故障回复的步骤与用于执行数据中心切换的步骤类似。一个重要区别是数据中心故障回复按计划执行，中断时间通常较短。
有一点非常重要，即在 Exchange 的基础结构依赖关系被重新激活，正常运行并已处于稳定状态，且进行验证之后，才会执行故障回复。如果这些依存关系不可用或没有正常运行，则故障回复过程将很可能导致比所需时间更长的中断，而且可能整个过程都将失败。
邮箱服务器角色应当是故障回复到主数据中心的第一个角色。以下步骤详细介绍邮箱服务器角色故障回复过程（假设 DAG 处于 DAC 模式下）。
若要重新合并主站点中的 DAG 成员，请运行下面的命令。
Start-DatabaseAvailabilityGroup -Identity <DatabaseAvailabilityGroupIdParameter> -ActiveDirectorySite <insertsitename>若要验证主数据中心中的数据库副本的状态，请运行下面的命令。
Get-MailboxDatabaseCopyStatus
将主数据中心中的邮箱服务器合并到 DAG 中之后，这些服务器需要一些时间来同步其数据库副本。此操作可能需要对数据库副本进行重新设定种子操作，具体取决于故障的性质、中断的时间长短以及管理员在中断期间所采取的操作。例如，如果在中断期间从故障主数据中心删除数据库副本以允许辅助数据中心中仍然正常工作的主动副本产生日志文件截断，则需要进行重新设定种子操作。此时，可以单独同步每个数据库。主数据中心中复制的数据库副本处于正常状态之后，可继续执行下一步骤。
在数据中心切换过程中，DAG 配置为使用备用见证服务器。若要重新配置 DAG 以使用主数据中心中的见证服务器，请运行下面的命令。
Set-DatabaseAvailabilityGroup -Identity <DAGName> -WitnessServer <PrimaryDatacenterWitnessServer>现在应在辅助数据中心中卸除主数据中心中要重新激活的数据库。运行以下命令。
Get-MailboxDatabase | Dismount-Database卸除数据库之后，应将客户端访问服务器 URL 从辅助数据中心移动到主数据中心中。为此，请将 URL 的 DNS 记录更改为指向主数据中心中的客户端访问服务器或阵列。
.gif "重要")
重要说明：在客户端访问服务器的 URL 移动且 DNS TTL 和缓存条目过期之后，再继续执行下一步骤。将客户端访问服务器 URL 移动到主数据中心之前激活主数据中心中的数据库会导致配置无效（例如，已装入的数据库的 Active Directory 站点中无客户端访问服务器）。 若要激活数据库，请运行以下命令之一。
Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinSecondSite>或者
Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>若要装入数据库，请运行下面的命令。
Get-MailboxDatabase <insertcriteriatoselectDBs> | Mount-Database
成功条件：在主站点中的邮箱服务器上成功装入活动邮箱数据库。若要进行确认，请运行下面的命令。
Get-MailboxDatabaseCopyStatus <DatabaseName>
Exchange 2010 测试解决方案
测试设施
测试在 Microsoft 企业工程中心进行，这是位于华盛顿州雷德蒙的 Microsoft 主园区中最先进的企业解决方案验证实验室。
借助 1.25 亿美元的硬件以及与行业领先的原始设备制造商 (OEM) 之间持久牢固的合作关系，几乎可以在 EEC 中复制任何生产环境。EEC 提供的环境可在客户、合作伙伴与 Microsoft 产品工程师间形成广泛协作。这可帮助确保 Microsoft 端到端解决方案满足客户的较高期望。
Exchange 2010 测试解决方案
解决方案验证结果
下一节汇总了功能和性能验证测试的结果。
Exchange 2010 测试解决方案
功能验证结果
下表汇总了功能验证测试结果。
功能验证结果
| 测试用例 | 结果 | 注释 |
|---|---|---|
数据库切换 |
成功 |
完成，无错误 |
服务器切换 |
成功 |
完成，无错误 |
服务器故障 |
成功 |
完成，无错误 |
站点故障 |
成功 |
完成，无错误 |
Exchange 2010 测试解决方案
存储设计验证结果
针对单存储框架上每个站点的所有磁盘进行的测试显示，CX4-480 可跨八个 Exchange VM（配置有 .15 IOPS 上的 150 封邮件的用户配置文件和附加 20% 空余空间）处理刚好 8,000 多的 Exchange 2010 事务性 IOPS。性能超过了此配置所需的 5,832 IOPS 目标基线，可为峰值负载提供一些附加空余空间。根据针对 Exchange 2010 性能的 Microsoft 最佳做法，磁盘延迟全部处于可接受的参数内。
存储设计验证结果
| 数据库 I/O | 目标值 | 4 个邮箱服务器处于正常运行情况（每个邮箱服务器 2,700 个用户） | 4 个邮箱服务器处于切换情况（每个邮箱服务器 5,400 个用户） | 总计 |
|---|---|---|---|---|
实现的事务性 IOPS（I/O 数据库读取次数/秒 + I/O 数据库写入次数/秒） |
1944 / 3888 |
3576 IOPS |
4488 IOPS |
8064 IOPS |
I/O 数据库读取次数/秒 |
不适用 |
2193 |
2729 |
4922 |
I/O 数据库写入次数/秒 |
不适用 |
1439 |
1703 |
3142 |
I/O Database Reads Average Latency (msec) |
<20 msec |
14 |
18 |
16 |
I/O Database Writes Average Latency (msec) |
不适合指示客户端延迟，因为数据库写入是异步的 |
14 |
18 |
16 |
I/O Log Writes/sec |
不适用 |
1238 |
1560 |
2798 |
I/O Log Reads Average Latency (msec) |
<10 msec |
2 |
2 |
2 |
Exchange 2010 测试解决方案
服务器设计验证结果
以下各节汇总了测试用例的服务器设计验证结果。
Loadgen 验证：测试方案
| 测试 | 描述 |
|---|---|
正常运行 |
在一个站点（其中每个邮箱服务器处理 2,700 个用户）上模拟 10,800 个用户的 100% 并发负载。 |
单个服务器故障或单个服务器维护（站点中） |
模拟每个站点中单个 Hyper-V 主机服务器发生故障。针对单个 Hyper-V 主机（其中一个 VM 处理 5,400 个用户）运行 100% 并发负载。只有三个组合客户端访问和集线器传输服务器处理负载。 |
站点故障 |
模拟站点故障，激活备用邮箱服务器 VM 上的辅助映像。针对单个站点中的 21,600 个用户运行 100% 并发负载。 |
测试用例：正常运行情况
此测试用例表示正常运行情况下的峰值工作负载。正常运行情况指的是这样一种状态，即所有活动和被动数据库都驻留在其计划运行的服务器上。因为此测试用例不表示最坏情况工作负载，所以它不是重要性能验证测试。它可很好地指示此环境在服务器故障或维护事件之外应如何运行。在此测试中，目标是在正常运行情况下，使用峰值负载验证整个 Exchange 环境。所有 Exchange VM 都在正常情况下运行。Loadgen 配置为模拟峰值负载。在峰值模式中运行的 150 邮件操作配置文件预计每秒生成两倍的发送和传递邮件数。
预期负载的验证
邮件传递速率验证测试工作负载是否与目标工作负载匹配。邮件传递速率稍高于目标速率，因而产生的负载稍高于所需配置文件。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Message Delivery Rate Per Mailbox |
15.0 |
15.2 |
主邮箱服务器的验证
下表显示主邮箱服务器 VM 的验证结果。
处理器
与预期一样，处理器利用率低于 70%。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<70% |
69 |
存储
存储结果不错。所有延迟都在目标值之下。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
MSExchange Database\I/O Database Reads (Attached) Average Latency |
<20 msec |
19 |
MSExchange Database\I/O Database Writes (Attached) Average Latency |
<20 msec < 平均读取次数 |
18 |
Database\Database Page Fault Stalls/sec |
0 |
0 |
MSExchange Database\IO Log Writes Average Latency |
<20 msec |
5 |
Database\Log Record Stalls/sec |
0 |
0 |
应用程序运行状况
Exchange 十分正常，用于确定应用程序运行状况的所有计数器都在目标值之下。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
MSExchangeIS\RPC Requests |
<70 |
3.0 |
MSExchangeIS\RPC Averaged Latency |
<10 msec |
2.0 |
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission |
0 |
2.0 |
辅助邮箱服务器的验证
下表显示辅助邮箱服务器 VM 的验证结果。
处理器
与预期一样，处理器利用率低于 70%。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<70% |
26 |
存储
存储结果不错。所有延迟都在目标值之下。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
MSExchange Database\I/O Database Reads (Recovery) Average Latency |
<100 msec |
0 |
MSExchange Database\I/O Database Writes (Recovery) Average Latency |
<100 msec < 平均读取次数 |
16 |
Database\Database Page Fault Stalls/sec |
0 |
0 |
MSExchange Database\IO Log Writes Average Latency |
<20 msec |
3 |
Database\Log Record Stalls/sec |
0 |
0 |
应用程序运行状况
辅助邮箱服务器仅维护第三个被动数据库副本，因此标准 Exchange 应用程序运行状况指示器不适用于此情况。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
MSExchangeIS\RPC Requests |
<70 |
不适用 |
MSExchangeIS\RPC Averaged Latency |
<10 msec |
不适用 |
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission |
0 |
不适用 |
客户端访问和集线器传输服务器的验证
下表显示客户端访问和集线器传输服务器 VM 的验证结果。
处理器
与预期一样，处理器利用率较低。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<70% |
48 |
存储
存储结果看起来不错。极低的延迟应不会影响邮件传输。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Logical/Physical Disk(*)\Avg。Disk sec/Read |
<20 msec |
0.001 |
Logical/Physical Disk(*)\Avg。Disk sec/Write |
<20 msec |
0.005 |
应用程序运行状况
较低 RPC 平均延迟值可确认客户端访问服务器正常，不会影响客户端体验。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
MSExchange RpcClientAccess\RPC Averaged Latency |
<250 msec |
8 |
MSExchange RpcClientAccess\RPC Requests |
<40 |
3 |
传输队列计数器都在目标之下，从而可确认集线器传输服务器正常并且能够处理和传递所需邮件。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues) |
<3000 |
2.5 |
\MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length |
<250 |
0 |
\MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length |
<250 |
2.3 |
\MSExchangeTransport Queues(_total)\Submission Queue Length |
<100 |
0 |
\MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length |
<100 |
0.3 |
根服务器运行状况的验证
以下各表显示 Hyper-V 根服务器的验证结果。
处理器
与预期一样，处理器利用率非常低，在目标阈值之下。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Hyper-V Hypervisor Logical Processor(_total)\% Guest Run Time |
<75% |
66 |
Hyper-V Hypervisor Logical Processor(_total)\% Hypervisor Run Time |
<5% |
2 |
Hyper-V Hypervisor Logical Processor(_total)\% Total Run Time |
<80% |
68 |
Hyper-V Hypervisor Root Virtual Processor(_total)\% Guest Run Time |
<5% |
3 |
应用程序运行状况
虚拟机运行状况摘要计数器指示所有 VM 都处于正常状态。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Hyper-V Virtual Machine Health Summary\Health Critical |
0 |
0 |
测试用例：单个服务器故障或单个服务器维护（站点中）
在此测试中，目标是在物理 Hyper-V 根服务器故障或维护操作情况下，使用峰值负载验证整个 Exchange 环境。在站点中一个 Hyper-V 根服务器上运行的所有 VM 都会关闭，以模拟主机维护情况。这会导致数据库映像（副本）移动到其他邮箱服务器 VM，从而形成每个邮箱服务器 VM 上都有 5,400 个用户的运行情况。只有一半的组合客户端访问和集线器传输服务器处理客户端访问和邮件传递。
预期负载的验证
实际邮件传递速率符合目标。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Message Delivery Rate Per Server |
30 |
30 |
主邮箱服务器的验证
下表显示主邮箱服务器 VM 的验证结果。
处理器
处理器利用率刚刚超过目标。此测试用例表示峰值负载下的故障或维护情况，因此这会是发生次数较少的事件。您不会希望处理器利用率长时间这么高。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<80% |
83 |
存储
存储结果看起来可以接受。平均读取延迟刚刚超过目标。平均数据库写入延迟高于首选值。这是峰值负载下的最坏故障情况，是发生次数较少的事件。高延迟不会使应用程序运行状况计数器高于目标，因此用户体验应仍可接受。您不会希望延迟长时间这么高。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
MSExchange Database\I/O Database Reads (Attached) Average Latency |
<20 msec |
20.5 |
MSExchange Database\I/O Database Writes (Attached) Average Latency |
<20 msec |
23 |
Database\Database Page Fault Stalls/sec |
0 |
0 |
MSExchange Database\IO Log Writes Average Latency |
<20 msec |
8 |
Database\Log Record Stalls/sec |
0 |
0 |
应用程序运行状况
计数器显示 Exchange 仍然相当正常。峰值负载下的某些邮件排队开始出现。您不会希望这种情况长时间继续。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
MSExchangeIS\RPC Requests |
<70 |
9.0 |
MSExchangeIS\RPC Averaged Latency |
<10 msec |
2.0 |
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission |
0 |
77 |
辅助邮箱服务器的验证
下表显示辅助邮箱服务器 VM 的验证结果。
处理器
与预期一样，处理器利用率低于 70%。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<70% |
21 |
存储
存储结果不错。所有延迟都在目标值之下。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
MSExchange Database\I/O Database Reads (Recovery) Average Latency |
<100 msec |
0 |
MSExchange Database\I/O Database Writes (Recovery) Average Latency |
<100 msec < 平均读取次数 |
21 |
Database\Database Page Fault Stalls/sec |
0 |
0 |
MSExchange Database\IO Log Writes Average Latency |
<20 msec |
3 |
Database\Log Record Stalls/sec |
0 |
0 |
应用程序运行状况
辅助邮箱服务器仅维护第三个被动数据库副本，因此标准 Exchange 应用程序运行状况指示器不适用于此情况。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
MSExchangeIS\RPC Requests |
<70 |
不适用 |
MSExchangeIS\RPC Averaged Latency |
<10 msec |
不适用 |
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission |
0 |
不适用 |
客户端访问和集线器传输服务器的验证
下表显示客户端访问和集线器传输服务器 VM 的验证结果。
处理器
与预期一样，处理器利用率低于 80%。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<80% |
74 |
存储
存储结果看起来不错。极低的延迟应不会影响邮件传输。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Logical/Physical Disk(*)\Avg。Disk sec/Read |
<20 msec |
0.001 |
Logical/Physical Disk(*)\Avg。Disk sec/Write |
<20 msec |
0.008 |
应用程序运行状况
较低 RPC 平均延迟值可确认客户端访问服务器正常，不会影响客户端体验。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
MSExchange RpcClientAccess\RPC Averaged Latency |
<250 msec |
18 |
MSExchange RpcClientAccess\RPC Requests |
<40 |
14 |
传输队列计数器都在目标之下，从而可确认集线器传输服务器正常并且能够处理和传递所需邮件。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues) |
<3000 |
49 |
\MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length |
<250 |
0 |
\MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length |
<250 |
43 |
\MSExchangeTransport Queues(_total)\Submission Queue Length |
<100 |
53 |
\MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length |
<100 |
4 |
根服务器运行状况的验证
以下各表显示 Hyper-V 根服务器的验证结果。
处理器
处理器利用率接近于目标阈值，对于峰值负载下的故障或维护情况预计会出现这种现象。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Hyper-V Hypervisor Logical Processor(_total)\% Guest Run Time |
<75% |
77 |
Hyper-V Hypervisor Logical Processor(_total)\% Hypervisor Run Time |
<5% |
2 |
Hyper-V Hypervisor Logical Processor(_total)\% Total Run Time |
<80% |
79 |
Hyper-V Hypervisor Root Virtual Processor(_total)\% Guest Run Time |
<5% |
3 |
应用程序运行状况
虚拟机运行状况摘要计数器指示所有 VM 都处于正常状态。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Hyper-V Virtual Machine Health Summary\Health Critical |
0 |
0 |
测试用例：站点故障和切换
此测试用例通过将主站点中的活动数据库切换到辅助站点中的被动数据库，使一个站点中存在 21,600 个邮箱，从而模拟站点故障。仍然正常运行的站点中的四个主邮箱服务器 VM 各自运行 2,700 个活动邮箱的正常工作负载。仍然正常运行的站点中的四个辅助邮箱服务器 VM 现在各自运行 2,700 个活动邮箱。每个 Hyper-V 根服务器承载 5,400 个活动邮箱。
预期负载的验证
邮件传递速率稍高于目标速率，因而产生的负载稍高于所需配置文件。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Message Delivery Rate Per Server |
15 |
15.1 |
主邮箱服务器的验证
下表显示主邮箱服务器 VM 的验证结果。
处理器
主邮箱服务器 VM 运行正常工作负载，在处理器利用率目标之下（与预期一样）。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<70% |
63 |
存储
存储结果不错。所有延迟都在目标值之下。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
MSExchange Database\I/O Database Reads (Attached) Average Latency |
<20 msec |
12 |
MSExchange Database\I/O Database Writes (Attached) Average Latency |
<20 msec |
13 |
Database\Database Page Fault Stalls/sec |
0 |
0 |
MSExchange Database\IO Log Writes Average Latency |
<20 msec |
4 |
Database\Log Record Stalls/sec |
0 |
0 |
应用程序运行状况
Exchange 十分正常，用于确定应用程序运行状况的所有计数器都在目标值之下。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
MSExchangeIS\RPC Requests |
<70 |
3.0 |
MSExchangeIS\RPC Averaged Latency |
<10 msec |
2.0 |
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission |
0 |
3 |
辅助邮箱服务器的验证
下表显示辅助邮箱服务器 VM 的验证结果。
处理器
处理器利用率刚刚超过 80% 目标。这高于首选值，但是似乎不会影响其他 Exchange 运行状况计数器。因为此测试表示发生次数较少的站点故障事件过程中的峰值负载，所以这没什么大问题。您不会希望此级别的处理器利用率持续出现。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<80% |
84 |
存储
存储结果不错。所有延迟都在目标值之下。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
MSExchange Database\I/O Database Reads (Attached) Average Latency |
<20 msec |
17 |
MSExchange Database\I/O Database Writes (Attached) Average Latency |
<20 msec < 平均读取次数 |
12 |
Database\Database Page Fault Stalls/sec |
0 |
0 |
MSExchange Database\IO Log Writes Average Latency |
<20 msec |
3 |
Database\Log Record Stalls/sec |
0 |
0 |
应用程序运行状况
计数器显示 Exchange 正常。有少量的排队。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
MSExchangeIS\RPC Requests |
<70 |
3 |
MSExchangeIS\RPC Averaged Latency |
<10 msec |
2 |
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission |
0 |
106 |
客户端访问和集线器传输服务器的验证
下表显示客户端访问和集线器传输服务器 VM 的验证结果。
处理器
与预期一样，处理器利用率低于 80%。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Hyper-V Hypervisor Virtual Processor\% Guest Run Time |
<70% |
63 |
存储
存储结果看起来不错。极低的延迟应不会影响邮件传输。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Logical/Physical Disk(*)\Avg。Disk sec/Read |
<20 msec |
0.002 |
Logical/Physical Disk(*)\Avg。Disk sec/Write |
<20 msec |
0.003 |
应用程序运行状况
较低 RPC 平均延迟值可确认客户端访问服务器正常，不会影响客户端体验。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
MSExchange RpcClientAccess\RPC Averaged Latency |
<250 msec |
9 |
MSExchange RpcClientAccess\RPC Requests |
<40 |
7 |
传输队列计数器都在目标之下，从而可确认集线器传输服务器正常并且能够处理和传递所需邮件。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues) |
<3000 |
5 |
\MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length |
<250 |
0 |
\MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length |
<250 |
4 |
\MSExchangeTransport Queues(_total)\Submission Queue Length |
<100 |
0 |
\MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length |
<100 |
1 |
根服务器运行状况的验证
以下各表显示 Hyper-V 根服务器的验证结果。
处理器
处理器利用率超过 80% 目标。因为此测试表示发生次数较少的站点故障事件过程中的峰值负载，所以这没什么大问题。您不会希望此级别的处理器利用率持续出现。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Hyper-V Hypervisor Logical Processor(_total)\% Guest Run Time |
<75% |
85 |
Hyper-V Hypervisor Logical Processor(_total)\% Hypervisor Run Time |
<5% |
2 |
Hyper-V Hypervisor Logical Processor(_total)\% Total Run Time |
<80% |
87 |
Hyper-V Hypervisor Root Virtual Processor(_total)\% Guest Run Time |
<5% |
3 |
应用程序运行状况
虚拟机运行状况摘要计数器指示所有 VM 都处于正常状态。
| 计数器 | 目标 | 测试结果 |
|---|---|---|
Hyper-V Virtual Machine Health Summary\Health Critical |
0 |
0 |
Exchange 2010 测试解决方案
结论
本白皮书提供了一个示例，来说明对于在 Cisco 和 EMC 硬件上部署的多个站点中存在 32,400 个邮箱的客户环境，如何设计、测试和验证 Exchange 2010 解决方案。本文档中的分步方法演练了帮助解决重大挑战、同时确保满足核心业务要求的重要设计决策点。
Exchange 2010 测试解决方案
其他信息
有关完整 Exchange 2010 文档，请参阅 Exchange Server 2010。
有关与 Cisco 和 EMC 相关的其他信息，请参阅以下资源：
EMC CLARiiON CX4-480：EMC CLARiiON 虚拟资源调配
EMC CLARiiON CX4-480：产品概述
Cisco 统一计算和服务器：UCS 概述
Cisco 统一计算和服务器：B 系列刀片服务器
Cisco 统一计算和服务器：UCS Manager
本文档按“原样”提供。本文档中涉及的信息和视图（包括 URL 和其他 Internet 网站引用）可能发生更改，恕不另行通知。您自行承担使用本文档的风险。
本文档不向您授予针对任何 Microsoft 产品的任何知识产权的任何法律权利。您可以复制并使用本文档进行内部参考。
Exchange 2010 测试解决方案