Exchange Server 2003如何计算磁盘I/O要求

既然了解了哪些 Exchange 活动和组件会生成磁盘 I/O 以及如何配置存储来支持它们，那么，您必须为用户计算磁盘 I/O 要求。计算磁盘 I/O 要求最终将允许您优化磁盘子系统，以便为用户提供最佳支持。

您的目标是提供实现高效的 Exchange 功能所需的足够高的磁盘 I/O 性能（按每秒可以执行的 I/O 操作数 [IOPS] 进行度量），延迟应该在可接受的范围之内。

计算每个邮箱的 IOPS 是基于随机数据库读/写 I/O（该公式不考虑事务日志 I/O）来度量特定服务器的配置文件的一种简洁的方式。每个邮箱的 IOPS 越高，邮箱配置文件在磁盘使用方面的效率就越高。

有两种方式可以计算磁盘 I/O 要求：

基于理论数据确定用户需求

通过使用“性能”控制台 (Perfmon) 来计算用户活动
 

不管采用哪种方式，都应基于高峰使用时段进行规划和计算。在很多公司中，高峰使用时段发生在刚开始上班的那段时间，人们在这时到达办公室并检查他们的电子邮件。

 使用理论数据计算 I/O

如果没有安装 Exchange，但想规划一下由于 Exchange 部署而产生的即将到来的存储需要，则可以使用已经收集到的数据。该数据采用邮箱配置文件的形式，邮箱配置文件描述了 Exchange 邮箱的常规使用模式。

下表列出了可以作为 Exchange 邮箱服务器容量规划的准则使用的邮箱配置文件。这些配置文件代表了组织中“平均用户”的 Outlook（或基于 MAPI 的）客户端的邮箱访问情况。

用户配置文件和相应的使用模式

每个配置文件代表 Jet 数据库的总计 I/O，并且不包括与事务

日志文件活动相关的 I/O。为了准确地计算磁盘子系统负载，必须将该数据库 I/O 拆分为读取 I/O 和写入 I/O，因为写入操作比读取操作更耗费 I/O 资源。

为了有助于估计自己的读/写比率，请考虑具有重量级邮箱配置文件的公司的使用模式。在生产环境中，预计公司的读/写比率会达到 75%/25% 到 66%/33% 之间，具体情况还要看所评估的用户组。

对于由 2,000 个重负载邮箱所组成的邮件系统，将在数据库卷上产生总计 1,500 IOPS。其计算公式是：

用户类型对应的预计每个用户 IOPS × 用户数

在此示例中，.75 IOPS × 2,000 邮箱 = 1,500 IOPS。

使用每次写入对应两次读取的保守比率值（66% 读取对应 33% 写入），计划数据库卷每秒产生 1,000 次读取 I/O 请求和 500 次写入 I/O 请求。每个写入请求首先写入事务日志文件，然后写入数据库。在数据库卷上出现的总计 1,500 IOPS 中，大约 10% 将出现在事务日志卷上（1,500 的 10% 是 150 IOPS）；500 次写入 I/O 请求将写入数据库。 #p#page_title#e#

这些估计的配置文件针对的是除基本操作系统以外没有安装其他组件的 Exchange 服务器。如果有其他变化，例如，在高峰使用时段使用第三方个人信息管理 (PIM) 软件、基于 MAPI 的病毒扫描（服务器和客户端）、管理和监视软件或者备份软件，那么，这些配置文件将不足以体现组织中的 I/O 配置文件。这些情况下，还必须考虑这些应用程序所请求的其他读取和写入操作。

基于邮箱计数的数据库 IOPS

每 1000 个邮箱的数据库 IOPS

在 Exchange Server 上增加具有相似

配置文件的用户数时，更多用户必须竞争使用数据库缓存，这将导致数据库磁盘传输的增加。

例如：

1.0 IOPS 的 1000 个邮箱将在数据库逻辑单元号 (LUN) 上产生 1000 IOPS。如果具有相同配置文件的用户数翻倍到 2000，则公式是：1.0 IOPS x 2000 邮箱 x 1.25 = 2500 IOPS。

基于数据库计数的数据库 IOPS

在 Exchange 服务器中添加数据库会减少单实例存储的好处。影响的程度取决于用户配置文件和平均邮件大小。例如，如果在 1 个数据库上有 1000 个用户，这会消耗 1000 数据库 IOPS，如果将这些用户分散到 10 个数据库，则会使消耗的数据库 IOPS 增加 18%，即 1180 IOPS。如果有人向 20 个邮箱发送 10 MB PowerPoint 文件作为附件的邮件，那么这些邮件将全部驻留在同一个数据库中，只有 10 MB 会写入数据库。如果相同的 20 个收件人在不同数据库上，则必须将 200 MB 写入磁盘；写入活动增加到二十倍。此数据基于 MMB3 测试，该测试使用大容量的通讯组列表和较重的公司配置文件。

使用 Outlook 缓存模式，可以让很多常见的磁盘操作密集任务在客户端上执行。在 Outlook 缓存模式下的初始完整同步是磁盘操作密集活动，但它很少执行。使用 Outlook 联机模式，则会在服务器上执行搜索和排序。在完成初始索引创建之后，它将随着接收邮件而自动更新。有异常大量索引的用户可以超过此限制，这会导致重新创建某些索引。某些 Outlook 插件和外部应用程序会创建索引，并导致物理磁盘压力增加。从 500 MB 移动到 1 GB 时，数据库的物理磁盘开销将增加大约 25%，而从 1 GB 更改到 2 GB 则会使数据库物理磁盘开销增加大约 40%。

 使用实际环境数据计算 I/O

如果已经部署 Exchange，则应使用现有的生产环境来确定 I/O 要求。监视生产环境的好处是，您的数据可以包括所有应用程序（包括第三方应用程序）上发生的所有 I/O。

在计算每个邮箱的 IOPS 时，应使用该服务器上当前的邮箱数。如果服务器中包含许多不使用的邮箱，或者正在运行的其他应用程序在两个小时的高峰时段内不会增加许多负载，则计算结果可能无法代表典型的用户负载。应选择一台具有典型用户邮箱的服务器来进行度量，或者在计算中不考虑那些不使用的邮箱。

请注意，星期几不同，使用负载也会略有不同。因为这种情况变化幅度很大，因此应该在较长的一段时间内监视环境（理想情况下是一个月），以便确定什么时候可能会遇到高峰。

有关如何使用在 Exchange 生产环境中收集的数据来计算存储 I/O 要求的详细步骤，请参阅如何使用环境数据计算存储 I/O 要求。

每个邮箱的此 IOPS 值是您将在操作系统级别遇到的值。如果有适当的硬件 RAID 解决方案，那么在磁盘级别还存在无法用 Perfmon 度量的不同 IOPS 数。RAID-5 中存在的限制与 RAID-1+0 中存在的限制有所不同。有关计算每种类型 RAID 解决方案的 IOPS 的详细信息，请参阅 Disk Subsystem Performance Analysis for Windows（英文）。

在计算每个邮箱值的 IOPS 后，可以优化现有的存储体系结构。

现货：全球最快的Fusion-io SSD硬盘卡述评