优化 Exchange Server 2003 的存储.doc

优化 ExchangeServer2003 的存储终审日期：产品版本：审阅者：最新动态：作者：2004 年 8 月Exchange Server 2003Exchange 产品开发组/exchange/libraryJanice Howd优化 ExchangeServer2003 的存储Janice Howd发布日期：2004 年 8 月终审日期：2004 年 8 月适用产品：Exchange Server 2003版权所有本文档中的信息（包括引用的 URL 和其他 Internet 网站）如有变更，恕不另行通知。除非特别声明，本文档中提及的示例公司、组织、产品、域名、电子邮件地址、徽标、人物、地点和事件纯属虚构，无意与任何真实的公司、组织、产品、域名、电子邮件地址、徽标、人物、地点或事件有任何关联，也不应进行这方面的推断。遵守所有适用的版权法是用户的责任。 Microsoft 的专利、专利申请、商标、版权或其他知识产权可能涉及本文档中的版权问题。除非 Microsoft 的书面许可协议做出了明确规定，提供本文档并不意味着赋予您这些专利、专利申请、商标、版权或其他知识产权的任何许可。 2004 Microsoft Corporation. 保留所有权利。Microsoft、Outlook、Windows 和 Windows Server 是 Microsoft Corporation 在美国和/或其他国家/地区的注册商标或商标。本文档中提到的真实公司和产品名称可能是其各自所有者的商标。感谢项目编辑：Brendon Bennett参与编写：Jon Hoerlein技术审核：Robert Quimbey、Greg Thiel、Ross Smith、Robert Gillies、Matt Gossage图形设计：Kristie Smith制作：Joe Orzech、Sean Pohtilla优化 ExchangeServer2003 的存储21目录简介2本指南面向的读者3开始之前3导致 Exchange 磁盘 I/O 的原因3Exchange 数据组件4影响 I/O 的其他活动5优化 Exchange 磁盘 I/O 的最佳做法6如何计算磁盘 I/O 要求7使用理论数据计算 I/O7使用实际环境数据计算 I/O8优化存储体系结构11多种体系结构通用的最佳做法11适合具体体系结构的最佳做法14优化 DAS16优化 SAN16优化网络附加存储16优化 iSCSI18其他设计考虑因素18使用 Jetstress 验证存储系统性能20小结21资源21技术指南21网站22Microsoft 知识库文章22简介您是否正在规划部署 Microsoft Exchange Server2003？您是否关注可用性、容错能力和性能？如果是这样，那么无论组织规模多大或多小，了解如何优化 Exchange Server2003 的存储系统都很关键。磁盘子系统瓶颈所产生的性能问题超过了服务器端 CPU 或 RAM 不足所产生的性能问题，而且设计不佳的磁盘子系统使组织容易受到硬件故障的影响。具体地说，如果磁盘子系统出现下列情况，则说明磁盘子系统性能欠佳： 平均读取和写入延迟超过 20 毫秒。 超过 50 毫秒的高峰延迟持续数秒。“严重磁盘延迟”与“低性能”同义。为了减少代价昂贵的磁盘延迟问题，至少应该： 投资高性能磁盘和心轴：与容量大而心轴较少的磁盘相比，容量较小但能够利用每个心轴性能的磁盘是更好的选择。具有足够心轴的快速存储是最重要的邮件基础结构投资之一。 在考虑容量之前先考虑性能：将容量作为主要的存储大小度量标准，经常导致磁盘子系统性能不佳。例如，大多数选择 RAID-5 解决方案的管理员这样做是为了最大程度提高存储使用率。但在很多情况下，为了完全发挥心轴的性能，RAID-5 解决方案所需的物理磁盘比 RAID-0+1 多。 对齐磁盘：使用 DiskPar 可以验证磁盘磁道是否按扇区对齐。与使用磁盘管理器创建的未对齐的分区比较，使用 DiskPar 创建的对齐分区可以使磁盘性能提高 20%。本指南后面的内容将详细讨论所有这些主题。通常，要优化存储系统并避免严重的磁盘延迟问题，需要了解： Exchange 磁盘 I/O 的原因。 如何计算磁盘 I/O 要求。 如何优化具体的存储体系结构。 如何验证存储系统的性能。本指南面向的读者本指南适用于负责规划和设计 Exchange 邮件系统的信息技术 (IT) 专业人员。表 1 列出了这些专业人员的具体角色和责任：表 1读者的角色和责任角色责任存储体系结构设计师 设计存储基础结构 制定存储部署战略和策略 参与网络连接存储设计系统体系结构设计师 设计总体服务器基础结构 制定服务器部署战略和策略 参与网络连接设计系统管理员 规划和部署运行 Microsoft Windows Server2003 或 Windows2000 Server 的服务器所采用的技术 评估和推荐新的技术解决方案邮件管理员 实现和管理组织的邮件系统开始之前本指南包括一些高级存储信息，仅适用于具备磁盘子系统组件方面的工作经验的人员。因此，如果没有这方面的知识，应该首先熟悉一下 Windows 存储概念。有关 Windows 存储概念的信息，请参阅“Disk Subsystem Performance Analysis for Windows”(/fwlink/?LinkId=34146)（英文）。本文包括基本 Exchange 体系结构元素（例如，存储、存储组和事务日志）的参考。如果您还不熟悉这些元素以及它们在 Exchange 中是如何实现的，请参阅“Exchange Server 2003 管理指南”中的“管理邮箱存储和公用文件夹存储”(/fwlink/?LinkId=21769)。导致 Exchange 磁盘 I/O 的原因每次从 Exchange 读取数据或将数据写入 Exchange 时，都将生成磁盘 I/O。了解 Exchange 磁盘 I/O 的来源，可以帮助您在规划和配置磁盘子系统时采用性能最佳的方式。考虑 Exchange 磁盘 I/O 来源时，请主要集中于访问日志文件和数据库文件期间所生成的 I/O 行为。Exchange 数据组件所有 Exchange 数据都存储在 Exchange 存储中，Exchange 存储由三个主要组件构成。表 2 列出了 Exchange 存储的三个主要组件以及它们对磁盘 I/O 的影响。表 2Exchange 存储组件及其对磁盘 I/O 的相应影响组件为什么它会影响磁盘 I/OJet 数据库（.edb 文件）Jet 数据库用来存储从 MAPI 客户端提交的所有数据。由 MAPI 客户端生成的所有客户端活动都会导致 Jet 数据库的更新。流式数据库（.stm 文件）存储从 IMAP4、NNTP、Microsoft Outlook Web Access 或 SMTP 提交的附件和数据。指针将保存在 Jet 数据库中，以便可以将数据根据请求传递到 MAPI 客户端。存储传入的 SMTP 邮件。如果数据包含 MAPI 信息，那么 SMTP 邮件然后会传输到 Jet 数据库。所有 Internet 协议客户端活动都会导致流式数据库的更新。事务日志文件（.log 文件）对数据库进行的所有更改都将首先提交到事务日志文件。这意味着，任何时候只要用户发送或读取邮件，以及修改其邮箱中存储的数据，该更改就将写入事务日志文件。更改将立即提交到位于 RAM 中的数据库缓存，然后在系统负载允许的时候复制回磁盘。装入数据库时也会读取事务。因为写入每个 Exchange 存储组件的方式不同，所以，如果将一个存储组的 .edb 文件和相应的 .stm 文件放在一个卷上，并将事务日志文件放在独立的卷上，您将体验到更好的性能。表 3 列出了每个 Exchange 存储组件的磁盘读/写是如何执行的。表 3每个 Exchange 存储组件的磁盘读/写组件I/O 模式Jet 数据库（.edb 文件） 随机读取和写入 4 KB 页大小流式数据库（.stm 文件） 按顺序正常读取和写入 可变页大小注意由于有大量的寻道操作，所以，该 I/O 模式既不是完全随机的，也不是完全有序的。事务日志文件（.log 文件） 正常操作期间，100% 按顺序写入 恢复操作期间，100% 按顺序读取 写入的大小各不相同 - 从 512 字节到日志缓冲区大小注意如果公用文件夹驻留在服务器上，则会导致额外的 I/O 负载。但是，如果该服务器上不存在文件夹内容的副本，那么，相对于用户邮箱访问所生成的 I/O 来说，从公用文件夹数据库生成的 I/O 是非顺序的。影响 I/O 的其他活动除了数据库文件访问，还有一些其他活动会导致磁盘 I/O。表 4 列出了这些活动和它们对磁盘 I/O 的影响。表 4影响磁盘 I/O 的其他活动活动为什么它会影响磁盘 I/O将已删除的数据库页清零如果把服务器配置为将已删除的数据库页清零，则每次从数据库删除项目时，将会删除多个页。然后，Exchange 将用零覆盖已删除的页。与不启用该功能相比，这将导致更多的磁盘 I/O（可能是前者的两倍）。内容索引扫描数据库是否有索引更新时，将发生额外的分页操作。这还会导致对内容索引文件执行过多的写入，从而在容纳内容索引文件的磁盘上生成的磁盘 I/O 达到高峰。SMTP 邮件传输在系统间传递时，入站和出站 SMTP 通信将写入磁盘。如果与用户数据库或日志文件共享该磁盘，则写入磁盘或从磁盘读取的 SMTP 邮件将与数据库和/或日志文件争用 I/O。当 SMTP 邮件通过后台处理从队列移动到第一个 Exchange 数据库时，它们将从 MIME 转换为 IMail。这将导致在该数据库所使用的日志文件和数据库卷上生成附加 I/O。分页当 Exchange 需要的内存超过可用物理内存时，Windows 将把信息分页到位于硬盘上的页面文件。过多的分页操作将导致过多的磁盘 I/O，这会降低 Exchange 服务器的性能。MTA 邮件处理在 Exchange 2000 和 Exchange 2003 中，在移动邮箱操作期间所接收的邮件，或从 Exchange 5.5 服务器、基于 X.400 的服务器或跨 EDK 连接器接收的邮件，将写入事务日志文件。这将导致存储系统的磁盘 I/O 负载。优化 Exchange 磁盘 I/O 的最佳做法熟悉生成磁盘 I/O 的 Exchange 活动之后，就应该以能够发挥最佳性能的方式组织存储系统。表 5 列出了放置每个数据文件的最佳做法。表 5优化磁盘 I/O 的最佳做法Exchange I/O 来源发挥最佳性能的最佳做法数据库文件应该将存储组内的所有数据库文件（.edb 和 .stm）放在专供这些数据库使用的单个卷上。容纳数据库文件的磁盘应该具有快速的随机访问速度。内容索引文件绝对不要将内容索引文件放在页面文件所在的同一个磁盘上（尽管这是默认位置）。因为内容索引文件是随机访问文件，您可以将其放在数据库所在的同一个卷上（只要磁盘子系统可以处理这些负载）。事务日志文件由于所有事务会首先写入事务日志，因此事务日志应该在可能的写入延迟最低的存储设备上。为了获得最佳可恢复性，应该单独将每个存储组的事务日志放在专用的 RAID-1 或 RAID-0+1 逻辑单元号码 (LUN) 阵列上。如果硬件 RAID 控制器具有镜像的、电池供电的回写缓存，并且它允许调整读/写缓存比率，请将该比率设置为 100% 写入。SMTP 队列应该让 SMTP 队列卷使用具有多个磁盘心轴的 RAID-0+1 阵列。磁盘心轴的数量和写入缓存的大小应该根据服务器的预计 SMTP 邮件吞吐量得出。SMTP 队列绝对不要位于执行另一项功能（例如，事务日志、数据库文件、页面文件或系统文件）的任何心轴上。无论邮件是发往同一台服务器上的邮箱还是远程服务器上的邮箱，都几乎不会影响与 SMTP 队列相关的磁盘 I/O。页面文件要获得最佳性能，应该将页面文件放在独立的心轴上，并且它至少应位于 RAID-1 设备上。如果丢失存放页面文件的磁盘，服务器将遇到停止错误。MTA 队列邮件传输代理 (MTA) 队列绝对不要驻留在日志或数据库卷上。如果服务器需要处理大量的 SMTP 和/或 MTA 通信，则应为 SMTP 和 MTA 队列提供一组独立的心轴。例如，如果运行 Exchange 2003 的计算机包含一个具有五个数据库的存储组，则应配置以下独立的物理 RAID 阵列： C: - 系统卷、操作系统、Exchange 系统文件 - RAID-0（直接附加存储，不是 SAN） D: - 页面文件 - RAID-1（直接附加存储，不是 SAN） E: - SMTP 和 MTA 队列 - RAID-0+1 (SAN) F: - 存储组 1 的日志文件 - RAID-1 (SAN) G: - 存储组 1 的数据库 - RAID-0+1 (SAN)如何计算磁盘 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 邮箱的常规使用模式。表 6 列出了可以作为 Exchange 邮箱服务器容量规划的准则使用的邮箱配置文件。这些配置文件代表了组织中“平均用户”的 Outlook（或基于 MAPI）客户端的邮箱访问情况。表 6邮箱配置文件和相应的使用模式邮箱配置文件数据库卷 IOPS每天的发送/接收量邮箱大小轻量级.18发送 10 次/接收 50 次 50MB平均级.4发送 20 次/接收 100 次50 MB重量级.75发送 30 次/接收 100 次100 MB每个配置文件代表 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 请求将写入数据库。这些估计的配置文件针对的是除基本操作系统以外没有安装其他组件的 Exchange 服务器。如果有其他变化，例如，在高峰使用时段使用第三方个人信息管理 (PIM) 软件、基于 MAPI 的病毒扫描（服务器和客户端）、管理和监视软件或者备份软件，那么，这些配置文件将不足以体现组织中的 I/O 配置文件。这些情况下，还必须考虑这些应用程序所请求的其他读取和写入操作。使用实际环境数据计算 I/O如果已经部署 Exchange，则应使用现有的生产环境来确定 I/O 要求。监视生产环境的好处是，您的数据可以包括所有应用程序（包括第三方应用程序）上发生的所有 I/O。在计算每个邮箱的 IOPS 时，应使用该服务器上当前的邮箱数。如果服务器中包含许多不使用的邮箱，或者正在运行的其他应用程序在两个小时的高峰时段内不会增加许多负载，则结果可能无法代表典型的用户负载。应选择一台具有典型用户邮箱的服务器来进行度量，或者在计算中不考虑那些不使用的邮箱。注意，星期几不同，使用负载也会略有不同。因为这种情况变化幅度很大，因此应该在较长的一段时间内监视环境（理想情况下是一个月），确定什么时候可能会遇到高峰。计算 I/O1. 确定三台供您收集基准性能数据的 Exchange 邮箱服务器。这些服务器应是为大多数经常使用电子邮件的用户提供服务的高端服务器。在该示例中，这些服务器被称为 ex2003base。通常，不同的站点有不同类型的用户。有时，这样做很有用：获取每个站点的邮箱配置文件数据，并为每个站点分配一个不同的标准邮箱配置文件。2. 在通常会遇到高峰负载的那天（很多公司是星期一）连续 24 小时监视 ex2003base 服务器。在出现高峰负载的那天，于 4:00 A.M 在每个服务器上启动 Perfmon 日志，并让它连续运行 24 小时。3. 以 15 秒为间隔记录以下 Perfmon 对象（所有计数器，所有实例）： Logical Disk MSExchangeIS Physical Disk Processor4. 编译从 ex2003base 服务器得到的以下数据： 确定三个 ex2003base 服务器的平均邮箱大小。为了帮助确定未来的存储性能需求，将使用平均邮箱大小。注意必须有邮箱大小限制，以便适当调整指定用户的存储大小/性能。 确定每台 ex2003base 服务器上有多少邮箱。在该过程随后的步骤中，您需要此数据来准确计算每台服务器上每个邮箱的平均 I/O 值。 确定每种 Exchange 功能（例如，事务日志、数据库和 MTA 队列）使用哪个 ex2003base 服务器卷。5. 逐个分析在步骤 3 中收集的三个 Perfmon 日志。对每个日志执行以下步骤。a. 在 Perfmon 中，打开 Perfmon 日志。b. 添加以下计数器：* MSExchangeIS RPC Operations/sec* Logical Disk Disk Transfers/sec 实例 = 容纳 Exchange 存储数据库的驱动器号。（添加包含 Exchange 数据库文件的所有驱动器号）。* Processor %Processor 实例 = Totalc. 设置合适的比例，以便所有计数器值都落在 0-100 x 轴上（这样可以查看所有计数器在 1 分钟内的变化情况）。显示图表视图。d. 分析 Perfmon 数据并确定一个长为一小时的时段，在此时段中三个计数器值（RPC Operations/sec、Disk Transfers/sec 和 Processor utilization）都达到最高。应会看见使用率在较长的一段时间内稳定在较高水平。e. 确定这个跨一小时的窗口之后，缩短 Perfmon 日志的时间线，让其符合该窗口。6. 从这个跨一小时的窗口，记录每台 ex2003base 服务器的以下度量数据（平均值）： RPC Operations/sec： Disk Transfers/sec： % Processor Time：7. 使用此数据填写下载的本指南所附带的 Server_Sizing.xls 电子表格。8. 识别出遇到最高负载的 ex2003base 服务器。使用从具有最高负载的服务器所收集的数据作为服务器/处理器/存储基准。使用以下最佳做法： 设计系统时，让其使用率始终比预计的高峰值高出 20%。这样，存储和处理器就有能力在高峰时段处理高峰数据量。 每个邮箱的兆周数和每个邮箱的 IOPS 可以随服务器配置的更改而发生变化。下面列出了可以更改每个邮箱的兆周数和每个邮箱的 IOPS 的可能因素。* 邮箱大小发生重大变化* 最大邮件大小发生重大变化* 添加或删除了第三方应用程序* 添加或删除了 Exchange 功能* 用户变化平均并发发生（在任意指定时间，或多或少的用户联机使用系统）9. 填写本指南附带的电子表格并确定邮箱配置文件之后，可以设计存储解决方案。例如，如果分析结果指出标准邮箱配置文件转换为每个邮箱 .70 IOPS 和每个邮箱 1.25 兆周，则可以确定 4,000 邮箱服务器的要求如下： 邮箱数：4,000 高峰数据库 IOPS：(4,000 .70) = 2,800 高峰日志 IOPS：(DB IOPS/10) = 280 高峰兆周数：(4,000 1.25) = 5,000 兆周要处理高峰数据量，应在处理器和存储设计上增加 20% 的缓冲。在增加该缓冲后，该示例的最低硬件要求是： 邮箱数：4,000 高峰数据库 IOPS ：(2800 + 20%) = 3,360 高峰日志 IOPS ：(280 + 20%) = 336 高峰兆周数：(5000 + 20%) = 6,000 兆周要支持这些要求，每个邮箱服务器的最低硬件应是双 3,000 mhz 处理器、4 GB RAM 以及能够容纳 3,360 随机数据库 IOPS 和 336 顺序事务日志写入 IOPS 的存储。注意该计算中未包括内存和网络要求。对于企业应用程序，建议为 Exchange 邮箱服务器配置 4 GB 内存。同时建议为 Exchange 邮箱服务器配置 100 mbt 或更高的全双工网络。每个邮箱的此 IOPS 值是您将在操作系统级别遇到的值。如果有适当的硬件 RAID 解决方案，那么在磁盘级别还存在无法用 Perfmon 度量的不同 IOPS 数。RAID-5 中存在的限制与 RAID-0+1 中存在的限制有所不同。有关计算每种类型的 RAID 解决方案的 IOPS 的详细信息，请参阅“Disk Subsystem Performance Analysis for Windows”(/fwlink/?LinkId=34146)（英文）。优化存储体系结构计算每个邮箱 IOPS 值并了解 I/O 要求之后，应使用该信息来优化存储体系结构。不管您正在使用的是直接附加存储 (DAS)、存储区域网络 (SAN)、网络附加存储还是 Internet SCSI (iSCSI) 存储体系结构，都有几个可以实现的最佳做法。而且，由于每个存储体系结构解决方案都是独特的，因此必须执行特有的步骤，以便基于公司的解决方案来对性能和可靠性进行优化。这一节重点介绍的最佳做法是将不同工作负荷分隔到独立物理心轴的重要性。这意味着，生成顺序读/写的事务日志文件不应与生成随机读/写的数据库文件共享相同的物理心轴。同样，生成随机读/写的 Exchange 数据库绝对不要与另一个应用程序（如 SQL Server）共享相同的物理心轴。多种体系结构通用的最佳做法在集中介绍适用于具体存储体系结构的最佳做法之前，应先熟悉一下多种体系结构都适用的最佳做法。不管公司的存储体系结构如何，都必须考虑以下组件： 硬盘 内存缓存 存储控制器 心轴 RAID 总线 SCSI 适配器 电源与其他组件相比，更多时候会涉及硬盘优化，因此首先讨论该主题。通常，以下最佳做法适用于硬盘优化： 容量规划是存储规划的重要方面。为了优化 Exchange 服务器性能，应该购买很多快速硬盘（更高的磁盘访问速度）。有关规划存储容量的详细信息，请参阅 Windows Server2003 部署工具包中的“Planning Storage for Each Server Configuration”(/fwlink/?LinkId=34172)（英文）。 对于事务日志卷（顺序磁盘访问），请使用转速更快的磁盘。对于数据库驱动器（随机磁盘访问），请使用寻道更快的磁盘。 使用能够检测即将出现的故障以及可以抢救或重定位受影响数据的磁盘系统。大多数磁盘驱动器都具备此功能。 根据所使用的具体硬件 RAID 配置，对 I/O 限制进行规划。通常，对于每个写入请求，硬件 RAID 生成以下 I/O： RAID-0 = 1 次写入 RAID-1 或 RAID-10 = 2 次写入 RAID-5 = 4 次写入使用以下公式计算 I/O 限制：(IOPS/邮箱 读取比率) + (IOPS/邮箱 写入比率) RAID 限制)例如，如果每个邮箱有 1,500 IOPS（使用本指南前面介绍的步骤计算得到），读取比率是 66%/33%（每三个请求中有两个是读取请求，另一个是写入请求），并且使用 RAID-1 或 RAID-10 阵列，则实际硬件 IOPS 是：(1,500 2/3) + (1,500 1/3) 2) = 2,000 对 RAID-5 阵列应用相同情形，实际硬件 IOPS 是：(1,500 2/3) + (1,500 1/3) 4) = 3,000如果所有驱动器都是 10,000 RPM，则至少需要 30 个驱动器才能在 RAID-5 配置中获得必需的 IOPS。如果实现 RAID-1 或 RAID-10，则需要至少 20 个驱动器（在 RAID-1 或 RAID-10 解决方案中，磁盘数不能为奇数）。 大多数情况下，应使用 DiskPar 来使硬盘磁道与物理磁盘分区对齐。由于 Windows 2000 和 Windows Server 2003 将最大隐藏扇区数限制为 63，因此，对于每个磁道具有 63 个以上扇区的磁盘，其默认启动扇区是第 64 个扇区。Windows 2000 和 Windows Server 2003 所创建的所有分区都从第 64 个扇区开始，这使得写入磁盘的每八个数据块中有一个数据块会跨越两个磁道。要使用 DiskPar 来对齐硬盘，请执行以下步骤。a. 备份硬盘上的所有数据，然后删除所有分区。b. 在命令提示符处，键入 diskpar -s ，然后确认您要对磁盘分区。c. 键入该硬盘的新起始偏移量和分区大小。由于 Exchange 以 4 KB 数据块为单位写入数据，因此所键入的起始偏移量的值必须是 4 KB 的倍数。d. DiskPar 对齐磁盘之后，在命令提示符处，键入 diskpar -i ，以验证磁盘已正确对齐。e. 使用磁盘管理器对硬盘进行分区。将分区配置为使用 NTFS，并使用 4096 (4 KB) 作为分配单位大小。f. 使用 DiskPar 提高磁盘性能并格式化磁盘分区。使用 DiskPar 之前，务必备份想要保留的所有数据。DiskPar 是 Windows 2000 资源工具包的一部分。有关使用 Diskpar.exe 的详细信息，请参阅 Microsoft Windows 2000 资源工具包的帮助。表 7 总结了其余每个存储组件的最佳做法表 7优化常见存储组件的最佳做法组件最佳做法内存缓存由于物理内存变得有限时内存会缓存到磁盘中，因此请确保有足够的可用内存。内存不足时，将有更多页被写入磁盘，从而导致磁盘活动增加。有关调整虚拟内存的详细信息，请参阅 Microsoft 知识库文章 815372“How to Optimize Memory Usage in Exchange Server2003”(/fwlink/?LinkId=3052&kbid=815372)（英文）。而且，请确保对页面文件大小的设置合理。有关如何设置页面文件的信息，请参阅 Microsoft Windows 2000 资源工具包中的“Evaluating Memory and Cache Usage”(/fwlink/?LinkId=34175)（英文）。较多的缓存有助于使磁盘 I/O 请求高峰发生偏移。但应注意的是，更多的缓存很少能解决心轴不足的问题，而心轴足够多时却可以不用大型的缓存。存储控制器如果有电池供电的缓存，请启用写入缓存，以提高事务日志文件卷和数据库卷上的磁盘写入性能。写入缓存对于写入 I/O 请求提供的响应时间是 2 ms，而不是 10 到 20 ms。启用写入缓存可以大大改善响应客户端执行的任何提交操作的能力。读取缓存不能提高性能，因为它只在顺序磁盘读取中有用，而顺序磁盘读取只发生在事务日志文件中。只有当回放事务日志文件时（例如，在数据库还原后或服务器没有正确关机时），才会读取事务日志文件。缓存越大，就能缓冲越多的数据，这意味着可以提供的饱和时段就会越长。如果控制器允许配置缓存页面大小，则应设置为 4 KB。更大的大小（例如 8 KB）会导致缓存浪费，因为 4 KB I/O 请求会占用整个 8 KB 的缓存页，因此将导致可用缓存减少一半。心轴心轴比容量更重要，如果心轴支持较高的随机 I/O 请求数，则可以使 Exchange 性能得到改善。如果使用 Raid-1+0，可以使用以下公式并将结果取整到下一个偶数来计算心轴数：1.25 (邮箱数 每个邮箱 IOPS / 每个心轴 IOPS ) + 读取 I/O 比率 / 读取 I/O 比率+ (写入 I/O 比率/ 2) = 心轴数该公式考虑到如下的规划：不超过总使用率的 80%，并确保即使在心轴出现故障的情况下也有足够的可用 I/O。RAID应该根据公司的成本与性能权衡来选择应使用的 RAID 解决方案。因此，在很多情况下，可能建议您根据特定的数据存储要求而采用多种类型的 RAID 解决方案。一般的建议是： 事务日志文件卷、数据库卷和 SMTP 队列使用 Raid-1+0。 事务日志文件卷、SMTP 队列和 MTA 队列使用 Raid-1。 通常，Raid-5 不能很好地顾及到可靠性/可用性与性能之间的权衡。 建议绝不要采用 Raid-0。总线吞吐速度越高，所提供的性能越好。通常，与 IDE 或 ATA 总线相比，SCSI 总线能够提供更快的吞吐速度和更好的可伸缩性。可以使用以下公式来计算总线的理论吞吐量限制值：(总线速度（位） / 每字节 8 位) 操作速度 (MHz) = 吞吐量 (MB/s)通过将多个驱动器分散放在独立的 I/O 总线上，也可以提高性能。SCSI 适配器吞吐速度越高，所提供的性能越好。使用制造商的规格可以确定适配器能够处理的 I/O 数量。请记住，适配器执行的某些处理专门将 I/O 请求引向正确的设备。适合具体体系结构的最佳做法除了实现适用于所有存储体系结构的最佳做法，还应熟悉每种类型的存储体系结构所特有的优点、缺点以及最佳做法。表 8 列出了这些体系结构类型以及每种类型的优缺点。表 8存储体系结构以及每种类型的优点和缺点存储体系结构优点缺点直接附加存储 (DAS) 便宜 适合于中小型配置 在 PCI 总线或 Ultra-3 SCSI 上使用 RAID 控制器时，可提供高性能 管理成本较高 可伸缩性不是很好存储区域网络 (SAN) 可以动态添加存储 用于群集时效果较好 可提供高性能，适合于大型基础结构和数据中心 支持快照、克隆和快照式克隆，从而可以对甚至是非常大型的数据库进行管理 可以将数据镜像到便宜的 JBOD（只是一批磁盘） 可以将多个供应商存储组合在一起，形成一个单元设备 可以将存储放在可以共享且易于供应的网络上 可以根据需要将资源转移到服务器 昂贵，尽管价格正在降低 复杂 - 要求有具备特定 SAN 知识的存储专家 必须正确配置，否则会遇到可靠性问题网络附加存储便宜 要求使用用于 Exchange 2000 的块模式驱动程序，这种驱动程序很少可用。 Windows Server 目录可能不支持。 必须与存储提供商协作，这在恢复时将很耗时。 可伸缩性不是很好 每个设备只支持 1,500 个用户 每个网络附加设备只允许使用两台 Exchange 服务器，因此只能实现双节点群集 要求在 Windows Server 2003 上运行 Exchange 2003 不支持卷影复制服务框架来实现快照Internet SCSI (iSCSI) 比 SAN 便宜 可以通过 LAN、WAN 和 Internet 将数据传输到远程存储位置 iSCSI 硬盘似乎直接连接到服务器建议通过专用 iSCSI Gigabit 网络将网络通信与存储通信分开。对于每种类型的存储体系结构，必须使用前面计算的每个邮箱 IOPS 值，以便： 优化性能。 优化可靠性。优化 DAS在较小型的 Exchange 部署中，直接附加存储 (DAS) 是常见情形。大多数适用于 DAS 的最佳做法在其他情形下也是适用的，因此在本指南前面的“多种体系结构通用的最佳做法”中已进行了讨论。对于 DAS，唯一增加的最佳做法是为所有存储组件和电源实现冗余，这是为了防止可能会出现的单点故障。优化 SAN存储区域网络 (SAN) 是用于 Exchange 的非常好的存储体系结构。即使如此，为了优化可靠性和性能，还是有许多最佳做法应该实现。要优化 SAN 的可靠性，应该： 配置冗余控制器、SAN 交换机和心轴。要优化 SAN 的性能，应该： 将 SAN 中的物理心轴专用于 Exchange 数据库。理想情况下，应将整个 SAN 专用于大型 Exchange 部署。 出于规划目的，忽略所有冗余组件。应该规划出甚至是在故障转移情况下的性能。 通过规划，让预计的高峰使用率不超过系统饱和量的 80%。 配置存储，以便存储单元上的控制器能够支持在本指南前面计算得到的预计 IOPS 值。在该通道上所支持的 IOPS 是带宽/块大小。如果有多个通道，并且计划其中一个作为冗余通道，则计算时不要包括该冗余通道。 验证 SAN 交换机可以支持 IOPS 要求，即便是在故障转移情况下也是如此。SAN 交换机必须处理传入 I/O 请求并将它转发给合适的端口，因此限制了可以处理的 I/O 数量。 验证服务器中安装的主机总线适配器 (HBA) 可以支持 IOPS 要求，即便是在故障转移情况下也是如此。为了避免发生遏制，请确保按照存储供应商的建议来设置队列深度。优化网络附加存储网络附加存储是新增的、Exchange 2003 支持的存储体系结构。但是，对于 Exchange 2003 组织，建议在采用网络附加存储解决方案的基础上再实现存储区域网络 (SAN) 解决方案。如果决定实现网络附加存储，请务必先熟悉一下本指南前面的“多种体系结构通用的最佳做法”中介绍的常规最佳做法。然后，要优化网络附加存储解决方案的性能，可以实现本节介绍的具体最佳做法。注意如果不能正确地将 Exchange 2003 与网络附加存储产品配合使用，可能会遇到数据丢失，包括 Exchange 数据库文件的总体丢失。很关键的一点是对 Exchange 实现的 NAS 解决方案应位于 Windows Server 目录上。另一个关键点是，在部署用于 Exchange 2003 数据库的任何存储解决方案之前，需要获得存储供应商的担保，即该端到端解决方案是专用于 Exchange 2003 的。由于很多供应商都提供有针对 Exchange 2003 的“最佳做法”指南，因此，您应该规划采用供应商的最佳做法。有关 Microsoft 对随 Exchange Server2003 使用网络附加存储设备的支持策略的详细信息，请参阅 Microsoft 知识库文章 839687“Microsoft support policy on the use of network-attached storage devices with Exchange Server2003”(/fwlink/?linkid=3052&kbid=839687)（英文）。要优化网络附加存储性能，应该： 使用 Gigabit 网络连接来连接到网络附加存储系统。 验证执行单个 I/O 操作的 I/O 带宽、I/O 延迟和 CPU 成本，了解在本指南前面计算的 IOPS 要求。 验证可用网络带宽能够支持用户的 IOPS 要求。您应知道，与使用本地附加存储相比，您可能会遇到更长的延迟和更多的 CPU 处理请求。 Exchange 2003 数据库和日志文件的存储所使用的驱动器号不会作为物理或逻辑磁盘出现，而是作为与网络文件共享关联的驱动器号出现。要度量网络附加存储系统的性能，应该启用在 Exchange 2003 Service Pack1 (SP1) 和更高版本中包括的一些附加性能监视器计数器。该任务要求按如下说明编辑注册表。警告错误地编辑注册表可能导致严重的问题，甚至可能需要重新安装操作系统。因注册表编辑不当而导致的问题可能没有办法解决。在编辑注册表之前，请备份所有重要数据。a. 启动注册表编辑器 (Regedit.exe)。b. 找到以下注册表项：HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesESEPerformancec. 在“编辑”菜单上，单击“添加值”，然后添加下列注册表值：值名称：显示高级计数器数据类型：REG_DWORD值：0x1d. 退出注册表编辑器，然后重新启动 Perfmon，以便开始使用新显示的计数器。优化 iSCSIInternet SCSI (iSCSI) 是相对较新的技术，使您能够以对操作系统无缝的方式远程地存储数据。下面是用于优化 iSCSI 存储解决方案中的可靠性和性能的最佳做法。要优化 iSCSI 可靠性，应该： 配置冗余控制器、SAN 交换机、存储单元和心轴。 使用独立的专用 Gigabit 网络处理 iSCSI 通信。要优化 iSCSI 性能，应该： 与 SAN 存储供应商联系，了解任何特殊的性能和配置建议。 通过测试来验证在服务器满负载（每个 IOPS 要求）时所观察到的 iSCSI 通信延迟能够满足需要。 使用 Gigabit 以太网。通过使用 Gigabit 以太网线缆和交换机，以及用于减轻 TCP/IP 处理开销的 iSCSI 芯片或 HBA，可以改善 iSCSI 性能。 使用 iSCSI 命令行界面 (ISCSICLI) 命令可以配置持久的登录目标，或使用 iSCSI 发起方控制面板工具来使卷持久存在。 使用 ISCSICLI 命令绑定持久卷，或使用 iSCSI 发起方控制面板工具来允许 iSCSI 服务配置持久卷列表。其他设计考虑因素除了预计的与 Exchange 相关的 I/O 以外，在您的环境中可能还存在几种可能会影响存储要求的情况。这些情况包括： 数据复制 群集 分散在不同地理位置的群集 备份和还原表 9 列出了针对所有这些情况的考虑因素表 9影响存储要求的情况情况考虑因素数据复制由于数据被复制到远程位置，因此存储规划必须包括位于远程位置的通信链路和存储需要。要使用复制的数据进行灾难恢复，必须复制事务日志文件、检查点文件和数据库卷，并且必须在所有驱动器集之间保持同步。对于同步复制，数据只有已在远程位置提交以后才会被提交到硬盘。因此，远程位置的通信链路和存储系统的性能是关键。如果跨越您的链路的同步很缓慢，而服务器在处理用户请求之前需要优先满足同步需求，因此这会极大地减缓用户响应时间。对于异步复制，每个副本通常是不同步的。与同步复制一样，当异步复制滞后太多时，必须将优先权给予复制而不是应用程序性能，从而导致用户响应时间变慢。要点尽管支持异步复制，但复制解决方案以及由此引起的问题必须由解决方案供应商而不是由 Micros