Exchange 2003 设计与体系结构（十一）

　　作为 Exchange 2003 的最早部署者之一，OTG 学到了许多经验，并且发现和建立了一些最佳实践来增强和优化 Exchange 所提供的服务。

　　拓扑结构最佳实践

　　OTG 在部署 Exchange 2003 期间获得了许多发现并克服了许多障碍。其中一些与网络的拓扑结构有关。

　　Windows Server 2003 要求

　　当将一个 Exchange 2000 集群拓扑升级到 Exchange 2003 时，OTG 发现必须在它的集群组中升级每一个 Exchange 虚拟服务器和集群节点，一次一个，只有这样服务器集群才能成功联机。此外，计划升级到 Exchange 2003 的服务器必须首先运行 Exchange 2000 SP3。

　　Exchange 2003 可以在 Windows 2000 Server 或 Windows Server 2003 计算机上运行并且所有 Active Directory 环境都支持，包括 Windows 2000 混合、Windows 2000 本地，以及 Windows 2003 域和目录林功能级。当在一个具有 Windows 2000 域控制器和全局目录服务器的环境中运行时，Exchange 2003 使用的域控制器和全局目录服务器必须全都运行 Windows 2000 SP3 或更新版本。此要求不仅影响 Exchange 2003 server，还影响 Exchange 2003 版本的 Active Directory Connector(ADC)。ADC 不能与运行低于 SP3 版本的 Windows 2000 Server 的域控制器或全局目录服务器一起工作。

　　邮箱移动

　　Outlook 2003 新的 Exchange 缓存模式使邮箱在整合中的移动过程更易于管理。从客户的观点来看，Exchange 缓存模式减缓了因为以下原因导致的任何重大的性能影响：从使用许多小型 Exchange 服务器向使用数量较少但更大型的 Exchange 服务器转变。

　　在邮箱服务器整合工作中，OTG 在将邮箱从本地移动到区域服务之前和之后都进行了性能基准测试。OTG 这样做是为了确保移植之后的客户端性能等于或高于移植前的性能。

　　此性能数据还对客户扮演了公共关系角色。许多人对于变化犹豫不决，一旦发生了变化，他们常常觉得变化对客户端性能有负面的影响。通过在移动前后进行基准测试，OTG 不仅展示了它关注于维持良好的服务，而且它还出示了实验测量数据来证明不存在性能的下降。

　　离线通讯簿(OAB)

　　当 Exchange 缓存模式被广泛使用时，OTG 遇到了一个与 OAB(Exchange 提供的全局通讯簿的一个离线版本)有关的性能挑战。过去，每个单独的 Exchange Server 创建其自己版本的 OAB。虽然这些版本的基本内容都一样，但 OAB 与创建它的服务器唯一关联。当移动邮箱时(即使是暂时的)这就成了一个问题，因为新服务器无法辨别出先前服务器版本的 OAB，并被迫完全下载另一个 OAB，从而不必要地消耗了网络带宽。OTG 吃一堑长一智。在 Exchange 2003 中，OTG 不再将 OAB 与特定的站点和服务器唯一关联，而是在区域的基础上关联它们。OAB 由每个区域中的一个主要服务器创建，然后通过公用文件夹复制将将其复制到此区域中的其他服务器上。

　　通过将 OAB 与区域服务器相关联，OTG 能够避免客户端计算机重复完全下载 OAB。此外，Exchange 2003 还对来自 OAB 的证书数据进行过滤，将其大小由 100 MB(未压缩时 300 MB)压缩为大约 43 MB(未压缩时大约 150 MB)。在完全下载成功之后用于更新 OAB 的差异 OAB 更新也被缩减为原始大小的 50% 左右。

　　公用文件夹访问

　　在 Exchange 缓存模式中，90% 的常用 Outlook 用户任务(如创建邮箱和执行日历查找)都发生在后台。但是一些特殊任务仍然需要实时访问，包括：

　　•访问公用文件夹。

　　•代理邮箱访问(用于那些可以使用他人邮箱的人，例如为经理安排约会的行政助理)。

　　•检查其他用户的闲/忙状态(用于检查预期会议请求接收者的时间表是否有空)

　　将 Exchange 服务器与主要的区域站点整合要求 OTG 应用更高容量的公用文件夹服务器，从而向所有用户提供相同的、一致的性能水平。OTG 期待这些服务器的使用率会大大提高，因为每个服务器有更多的人使用闲/忙发布、检索 Outlook 2003 安全性设置，以及访问通用公用文件夹。为了冗余性和负载共享，每个整合站点使用两个非集群的公用文件夹服务器。

　　服务器配置最佳实践

　　OTG 有关服务器配置的主要成果与障碍有以下方面：

　　服务器优化

　　OTG 的服务器配置了 4 GB 的 RAM。这些服务器运行 Windows Server 2003, Enterprise Edition 和 Exchange Server 2003，并进行了如下修改：

　　•在 Boot.ini 文件中设置了 /3GB 开关;

　　•在 Boot.ini 文件中设置了 /USERVA=3030 参数。

　　Windows Server 2003, Enterprise Edition，最高支持 32 GB 的 RAM。但是，默认状态下，4 GB RAM 的安装分为 2 GB 供应用程序使用，2 GB 供操作系统使用。因为 Windows Server 2003 支持 RAM 调整，OTG 使用 /3GB 开关将通常供操作系统使用的 1 GB 的 RAM 划分给了 Exchange 使用。但是，OTG 很快遇到了操作系统方面的问题，因为它的内存不足。然后 OTG 使用 /USERVA 开关进一步指定 RAM 总量中的多少将分配给 RAM 的应用程序部分。OTG 发现将 USERVA 开关设置为 3030，将 42 MB RAM 内存归还给操作系统，解决了内存不足的问题，同时又提供了最大数量的内存供 Exchange 使用。

　　使用最靠近邮箱服务器的前端服务器以获取最佳性能

　　OTG 发现，当通过 Internet 使用任何移动特性时，如果用户选择物理上距离他们的邮箱服务器最近的 Exchange 前端服务器，而不是最靠近他们当前位置的前端服务器，就能够获得最佳的性能。例如，如果一个员工从澳大利亚出差到美国，当她使用最靠近其邮箱服务器的前端服务器时，她的在线 OWA 体验是最佳的。在发现了这一点后，OTG 修改了 OWA 登录 Web 页面，在其中包含了到所有可用前端服务器的链接，并包含了关于选择使用哪一个的指导。

　　仔细考虑 Exchange 统一资源定位符(URL)名称

　　OMA 与 OWA 使用的是同一个 Exchange 前端服务器。在一台 Smartphone 设备上键入普通的 URL 可能会很耗时。一个长而复杂的 OMA URL 可能会阻止大部分用户有规律地使用该服务。

　　解决处理器利用率瓶颈

　　为了确定下一代服务器平台，OTG 进行了大量测试。和 Exchange 2000 服务器一起使用的八处理器 Xeon 550 MHz 服务器平台在高峰负载时段的利用率已经达到了约 80%。这个数字被用来充当新系统测试的基准组件。

　　在经过了大量的各种处理平台的测试之后，OTG 得出的结论是：解决内存总线的局限比解决处理器局限更能获得总体系统性能的大幅提高。OTG 测试了一个 beta 版本的四处理器 Xeon Processor MP 1.6 GHz 超线程服务器，FSB 是 400 MHz。在该系统上的性能测试证实了 OTG 的猜想：处理器利用率从没有超过 40%。基于这些测试，为了优化服务器性能，OTG 计划将 Exchange 2003 服务器移植到使用新的更快速的 FSB 技术的 Xeon 处理器系统。

　　存储设计最佳实践

　　OTG 在部署新的 SAN 解决方案时遇到并解决了一些问题。

　　在集群中使用卷装入点

　　OTG 的集群服务器配置使用 SAN 来获得最大的存储容量并提高备份和恢复性能。下面几点对于成功部署 SAN 和 Exchange 2003 很有帮助：

　　使用装入点消除驱动器号限制，支持日志、SMTP 和备份驱动器。卷装入点是在 Windows 2000 中引入的。但是，Windows 2000 不支持集群内 NTFS 卷上的卷装入点。Windows Server 2003 引入了该特性。由于缺乏可用的驱动器号不再是一个问题，因此使用在 Windows Server 2003 集群上运行的 Exchange 2003 使得 OTG 能够将四个 SG 与 Exchange 服务器相关联并保持最佳的 I/O 吞吐量。

　　OTG 实施了与 Exchange 2000 相同类型的基础结构设计。但现在每个服务器只占用四个驱动器号而不是十个，从而使得每个服务器能够关联全部四个 SG，并且在一个集群内允许有更多的服务器。在 OTG 的 Exchange 服务器上使用卷装入点实际上意味着四个驱动器号能够支持 20 个数据库，而不是 10 个驱动器号支持 15 个数据库。

　　将备份磁盘 LUN 放在一个单独的集群资源组中

　　在单独的集群资源组中维护备份磁盘，以支持在集群节点之间，在第一阶段(磁盘到磁盘备份)和第二阶段(磁盘到磁带备份)之间进行独立的 LUN 运动。

　　注：Windows 集群将资源组织成名为资源组的功能单元，它们被分配给单独的节点。如果一个节点出故障了，集群服务将该节点上的组转移到集群中的其他节点上。此转移过程称为故障转移。

　　定义高峰时段通信率的基线

　　在能够开始设计新的 SAN 实施之前，OTG 需要了解现有的 Exchange 实施的高峰 I/O 需求是什么。OTG 获取此数据的最佳途径是在连续几个星期一的上午(这是 Microsoft 用户通信行为发生的高峰期)记录通信基础结构行为。OTG 寻找高峰时段通信量的趋向并收集有关高峰时段通信量的信息，然后增加 20%，并将这个数字作为计划未来增长的基线。

　　OTG 使用实时的 Performance Monitor(PerfMon)- Windows Server 内置的性能监视工具 - 并在高峰时段，在一些最繁忙的生产 Exchange 服务器上统计 MOM 数据趋向来验证关键的性能计数器。表 7 中显示了一些特殊计数器，通过它们能够了解与读写相关的磁盘传输(每秒的磁盘操作)总量与延迟的对比。关键的目标是了解每台服务器每个邮箱的平均磁盘传输，在可接受的磁盘延迟水平下，基于 100 MB 的邮箱限制，它趋向于每秒 0.6 到 0.8 次传输。

　　表 7 OTG 用来监视 Exchange 磁盘性能的 PerfMon 计数器

　　计数器对象物理磁盘MSExchangeIS

　　计数器名称平均磁盘读/秒

　　平均磁盘写/秒

　　磁盘传输/秒

　　磁盘读/秒

　　磁盘写/秒RPC 平均延迟

　　RPC 请求

　　RPC 操作/秒

　　其他用于验证的计数器与 MSExchangeIS RPC 操作相关。OTG 担心增加每台服务器的邮箱数量可能会对用户体验造成负面影响。这些计数器被严密监视以确保 RPC 延迟和未解决的请求维持在在 Exchange 产品族的推荐范围内。RPC 延迟和未解决请求可能会受低磁盘读写性能的负面影响。

　　其他的产品验证是用于 Level B Test 目录林工程的，OTG 对 5,000 个 200 MB 的邮箱集群进行了性能分析，结果趋向于在高峰时段每个邮箱每秒 1.0 到 1.2 次磁盘传输。磁盘传输的增加导致性能的低下，表现为当服务器扩展为支持超过 2,500 个邮箱时，磁盘的读写延迟变得难以接受。SCSI miniport FCA 驱动程序中默认的队列深度参数被认为是一个瓶颈，并从默认的 32 调整为 128。参数的改变使得 OTG 能够以好于预期水平的读/写延迟达到 5,000 个邮箱的目标，并促使 OTG 决定将 200 MB 的邮箱作为所有新服务器设计的标准。

　　评估 SAN 性能

　　在评估预期的 SAN 解决方案的测试阶段，OTG 将它的邮箱大小限制从 100 MB 提高到 200 MB，并将单个 Exchange server(使用新的服务器硬件和新的存储硬件)上的邮箱数量从 3,000 提高到 5,000。OTG 希望找到这些新硬件平台可能达到的性能水平。当单个服务器上的邮箱数量超过 2,000 时，OTG 首先在数据 LUN 上遇到了非常大的读/写延迟(40 到 50 毫秒)。OTG 测试发现 SAN 上默认的 Host Bus Adapter(HBA)参数设置制约了它的性能。OTG 将默认的 Queue Depth 参数从 32 重置为 128，将高峰负载时的读延迟缩减为 12 毫秒，写延迟缩减为 2 毫秒，从而解决了 SAN 的性能问题。

查看本文来源