Exchange 2003 设计与体系结构 （2）(3)

　　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 的性能问题。

　　从千兆以太网移植到 100 Mbps 以太网

　　在 Exchange 2000 使用的旧 SAN 上，OTG 使用千兆以太网以便在备份过程中使独立 Exchange 服务器上的网络吞吐量最大化。这些服务器中的每一个通常都包含 200 到 300 GB 的数据。一旦 OTG 开始使用集群，它就不再单纯依靠网络吞吐能力来处理磁盘到磁带的备份。相反，OTG 现在改为使用每个集群中的备用非活动节点，通过直接光纤连接将备份数据传输到磁带库中。

　　OTG 使用千兆以太网的经验显示出网络适配器性能有逐渐退化的趋势。处理和解决这种性能退化的管理工作非常耗费时间和资源。既然使用带有光纤附属库的集群消除了 OTG 对极高速网络吞吐量的依赖，OTG 就将千兆以太网络适配器替换为 100 Mbps 以太网络适配器以简化服务器维护工作。因为网络本身对于备份吞吐量不再是一个瓶颈，这些适配器提供的网络性能足以满足 Exchange 服务器的需求(普通网络利用的高峰通常大约是容量的 20%)。而且，100 Mbps 以太网络适配器所需的维护开销要少得多。

　　管理与监视最佳实践

　　OTG 在学习使用 MOM 来管理 Exchange 的经历中获得了一些宝贵的经验，这些经验对其他组织也是适用的。

　　客户端监视

　　结合使用 Outlook 2003 和 Exchange 2003 能够收集宝贵的客户端性能监视数据。Outlook 2003 收集客户端通信性能数据，包括通信系统成功、失败和延迟，并将它们报告给 Exchange 2003 邮箱服务器。Exchange 2003 服务器为其邮箱汇集客户端性能信息，并向 Performance Monitor 工具提供这些信息，同时将它们存储到服务器的事件日志中。OTG 使用 Exchange 2003 Management Pack 中的 MOM，从服务器事件日志中访问该信息以提供报告，并在出现问题时生成警报(如果需要的话)。OTG 使用 MOM 收集的数据来检查客户端停机，并报告关于客户端性能和可用性的性能规范。虽然 MOM 报告是以汇总的客户端数据为基础的，OTG 也使用 WMI 脚本来获取有关更小的组(如那些在 WAN 上远程办公室中的组，这些组从本地服务器整合到区域服务器)的通信客户端性能的更详细信息。

　　禁用集群的事件日志复制

　　当 OTG 开始在集群环境中监视 Exchange 时，他们发现，对于收集到的每个事件，他们都接收到与集群中节点数相同数量的通知。这是事件日志复制的结果。作为最佳实践，OTG 在它的 Exchange 集群节点中禁用了事件日志。

　　监视远程服务器上的备份

　　至于监视远程区域 Exchange 服务器上的备份，OTG 使用了检查事务日志日期戳的 MOM Exchange Management Pack 脚本。如果日期比现在早 24 小时以上，说明前一晚的备份没有成功完成。

　　邮件流分析

　　OTG 利用 MOM Exchange Management Pack 脚本监测一封从总部发出、由所有区域数据中心接收的测试电子邮件所花费的时间，该脚本利用一个星型结构模型来执行邮件流分析。发送时间和接收时间之间的差值决定邮件传递的速度。如果该时间超过五分钟，OTG 将 MOM 配置为生成一个警报通知。

　　自定义规则

　　使用默认的 MOM Management Pack，任一特定被监视事件的阀值粒度水平与 OTG 使用的所有不同的服务器配置不相对应。例如，位于印度孟买的一个支持 100-200 个邮箱的小型配置区域服务器，可能不会对一个问题指示器 - 为总部数据中心配置服务器(支持 4,000 个邮箱)的阀值而配置 - 发出警报。当创建自定义规则时，OTG 禁用默认的 Exchange Management Pack 中的规则，将这些规则复制到它自己的自定义管理包中，并创建多个子处理规则组。这些规则组定义不同的阀值水平以满足 OTG 通信基础结构中每个服务器配置的特定要求。这种做法保留了原始的规则以便升级。

　　操作的最佳实践

　　将 Exchange 2003 部署到 OTG 通信基础结构中是一个相对简单的转变，产生了一些值得注意的、操作方面的最佳实践。

　　备份吞吐量调整

　　OTG 发现了一种可以将磁盘到磁盘备份速率提高不止一倍的方法 - 在注册表修改过程中全程使用 Windows Backup 工具。这一修改将平均吞吐率从每 SG 每分钟 600 MB 提高到每分钟 1,200 MB。该修改位于 OTG 用来执行备份脚本的用户配置文件中(HKEY_CURRENT_USER)。

　　OTG 在每个活动的 Exchange 实例上运行两个并发的备份作业，数据吞吐率合计为每服务器每分钟大约 2.4 GB，每个 SAN 模组有两到三个服务器(取决于是总部数据中心设计还是区域设计)。在没有过多读写磁盘延迟的情况下，OTG 监测到的最大吞吐量为每 SAN 模组每分钟约 6.3 GB。吞吐量取决于跨处理器的 LUN 分配，以及每处理器所分配的每 SG 的数据、日志、和备份 LUN。

　　用于优化吞吐量的模式是：

　　•SG 1 和 2 - 在一号控制器上的数据、日志和备份

　　•SG 3 和 4 - 在二号控制器上的数据、日志和备份

　　•作业的并发性被限制为每服务器两个，SG 1 和 SG 3 并发运行，随后是 SG 2 和 SG 4。

　　•RAID：

　　•备份的目标 LUN 是 RAID-5

　　•所有的 RAID-5 LUN 都禁用写回缓存。

　　注：RAID-1 目标将会提供更高的吞吐量，OTG 当前正在考虑选择它们与 146 GB 磁盘一起用于第一阶段的备份(磁盘到磁盘)。

　　管理事务日志

　　OTG 发现增加每台服务器的邮箱数量后，每台服务器的事务日志数量也会增加。重播事务日志花费的时间对恢复服务器所需的时间影响极大。最好的实践方法是：计算重播日志的时间，监视每天的平均日志数量，然后相应调整恢复计划。

　　备份同步

　　既然集群已安排妥当，在 OTG 激活每日的备份脚本之前(晚上 8 点，本地时间)，它会检查 Exchange 的每个虚拟实例在其预定义节点上是活动的。如果任何节点被移动，OTG 必须将其移回正确的节点，或配置运行备份过程的自动脚本使其在在非活动节点上运行;否则，为每个物理活动节点服务器设置的计划备份过程对于被移动的服务器将会失败。

　　结论

　　Exchange Server 2003 平台的增强，特别是与 Windows Server 2003 和 Office 2003 的增强相结合，使得 OTG 能够在一个整合的、完全集群化的环境中在全球范围内重新部署 Exchange，在所有位置使用高级 SAN 技术，并为 Microsoft 的员工提供更好的服务。作为正在进行当中的服务器和站点整合工作的一部分，每个服务器中增加了更多的用户邮箱。高级 SAN 技术使得 OTG 能够将所有用户邮箱的空间分配增加一倍，并将允许粘贴的附件大小增加一倍，而不会影响服务可用性或备份/恢复 SLA。通过将连接到 SAN 的服务器集群化，OTG 大大提高了服务器可用性，并简化了它的备份与恢复方法。MOM 的使用提高了 OTG 监视和维护通信基础结构的能力。Exchange Server 2003 极大地改善了 OTG 为其客户、Microsoft 员工所提供的消息服务。