Exchange 2003 设计与体系结构（２）

存储设计与配置

OTG 的存储配置的全部设计都是基于有效地管理高峰期的磁盘 I/O 进行的。OTG 研究了其 Exchange 2000 消息存储基础结构的使用趋势，发现高峰期的使用通常发生在星期一的上午。OTG 接受了这一使用数据并将其作为设计 Exchange 2003 SAN 解决方案的基线。OTG 计算了每个邮箱在高峰期平均每秒的磁盘 I/O 数量。他们将邮箱数量乘以 I/O 率的结果作为一个服务器的总 I/O 率。

例如，在一个支持 4,000 个邮箱的服务器上，如果高峰期的 I/O 率是每邮箱每秒 1.2 次，那么该服务器总的 I/O 率等于每秒 4,800 次 I/O。在 Exchange 中每次 I/O 传输的数据量是 4 KB，在这样的 I/O 下，约等于每秒 20 MB 的 I/O。再考虑到在总部数据中心配置中每个 SAN 模组支持两个主机，则 I/O 率倍增为大约每秒 10,000 次 I/O。

在 OTG 为满足这些要求所进行的设计中，OTG 选中的每个 SAN 模组能够支持最高每秒 12,000 次 I/O，这为不寻常的活动高峰提供了边际空间，但是预期对于正常的 I/O 活动高峰时段应该足够了。任何超过这个数字的巨大负载都有可能导致磁盘读写延迟，它将会给连接到该 SAN 的所有邮箱造成负面影响。OTG 系统设计师在综合考虑预期的情况、额外硬件的成本、以及 Microsoft Operations Manager 中的检测与报警改进之后，认为这是一个可以接受的风险。

为了确定任何企业的消息存储需求，必须测量每邮箱用户每秒的平均高峰时段 I/O、邮箱的最大容量、项目在已删除项目保留区内保留的时间长度，以及在一个组织中典型用途的电子邮件模式的流通率。这些是 OTG 在设计其 Exchange 2003 SAN 解决方案时所考虑的因素。

OTG 给每个支持邮箱存储的 LUN 分配了额外的容量，其目的是减少未来出现意外增长时对重新分配大小的需求。LUN 的大小被设置为能够支持 6.5 个“毛边因子（fluff factor）”为 1.4 的生产数据库。

OTG 使用毛边因子来指根据已删除项目保留区、数据库开销、不受限邮箱等在磁盘上为一个给定的邮箱所分配的平均容量。例如，为 Exchange 2000 的用户创建 100 MB 邮箱实际上需要为他们每人保留 140 MB 空间。1.4 这个值是多年来支持 100 MB 邮箱的 Exchange 生产服务器的趋势，并仍然是设计新的支持 200 MB 邮箱的新解决方案的基础。

OTG 的 100 MB 邮箱大小限制是在 Exchange 级上通过策略设置和施行的硬性快速磁盘配额限制，但是如果用户用完了全部 100 MB 的可用空间，这经常是因为他们在后台超过了该数量。这常常在用户从邮箱中删除电子邮件时发生。电子邮件实际上不是从服务器的邮箱数据库中立即删除。而是暂时保留在数据库中一个名为已删除项目保留区的地方。只有在三天之后被删除的电子邮件才真正从邮箱数据库中清除。OTG 在规划它的 Exchange 2003 存储需求时需要考虑该级别的使用开销。

此外，OTG 为每个数据 LUN 分配能够支持六个半数据库的容量，即时他们在生产中只需要支持五个数据库。这使得他们能够在同一个 LUN 上复制单个受损的数据库，然后对它进行完整性检查。这种使用同一个 LUN 的能力使得 OTG 能够对数据库损坏做出最快的响应。

选择一个 SAN

像许多组织一样，OTG 决定干净利落地从本地（基于主机的）直接相连的 SCSI 存储转为 SAN 相连的存储。在过去，服务器存储被认为是一个关键的服务器组件，与服务器硬件紧密相联。SAN 技术使得存储变得更像是一种公共服务；它不再与服务器紧密相关。虽然对这种方案的评价是毁誉参半，但 OTG 仍然选择了 SAN 存储，因为它满足 OTG 对未来的性能、可伸缩性和容量的需求。这些需求是无法通过本地附加存储阵列来满足的。

Exchange 2003 的部署为 OTG 提供了一个机会 － 评估自最新研究以来 SAN 技术是否成熟。OTG 开始了一项检验和测试 SAN 厂商的技术和产品的工程。OTG 要求任何在 Microsoft 实施的新的 SAN 技术标准都必须能够很方便地从远程位置进行支持。OTG 要求存储解决方案易于部署、模块化设计、并且便于远程管理。

在 OTG 使用的每个 HP StorageWorks Enterprise Virtual Array 5000（eva5000）SAN 中有 168 个磁盘。每个 SAN 模组支持大约 8,000 个 200 MB 邮箱。每个 SAN 模组在磁盘延迟不明显的前提下每秒能够处理约 12,000 次 I/O。总部数据中心的每个邮箱将支持 4,000 个邮箱并预期在高峰时段处理每秒 5,000 到 6,000 次 I/O。因此，总部数据中心的一个 SAN 模组支持两台邮箱服务器。区域邮箱服务器将只支持低于 2,700 个邮箱，因此三个区域服务器的高峰时段负载由一个 SAN 模组支持。

使用卷装入点的存储分配

OTG 在 Windows Server 2003 中对卷装入点使用了新的集群支持，从而使驱动器号不再成为阻碍在单个集群中放置多个 Exchange 实例的可伸缩性障碍。选中的设计中每个数据 LUN（每 SG 一个）使用一个驱动器分配，每个集群节点四个数据 LUN（OTG 将每个节点设置为支持一个 Exchange 虚拟服务器）。相应的日志 LUN 被设置为卷装入点集群资源，每个都依赖它的父数据 LUN。在该设计中还包括一个专用的队列 LUN，它也作为一个卷装入点集群资源，依赖于分配给 SG1 的数据 LUN。

利用卷装入点使得 OTG 能够使用四个驱动器号来维护九个物理 LUN，从而配置最佳的磁盘布局。利用这种设计，4 个 Exchange 实例只需使用 16 个驱动器号就能够映射 36 个物理 LUN。

后续的 LUN 用于支持在线备份到磁盘，每个节点每 SG 分配一个磁盘。分配给每个节点的 SG1 的磁盘支持三个额外的卷装入点 LUN 作为 SG2、SG3 和 SG4 的备份目标。备份资源是通过 16 个通过 4 个驱动器号寻址的物理 LUN 设置的。

图 1 描述了第一个节点的驱动器号分配和用于支持在线备份设备的相应分配。

图 1：每节点的驱动器号分配。

注：在图 1 中，VMP 代表一个卷装入点。

总体上，在集群设计中总共 53 个物理 LUN 可以使用 21 个驱动器号来寻址。这使得 OTG 很容易利用通过控制器和光纤信道适配器（FCA）分布的 LUN 对磁盘子系统进行优化，从而确保满足在 Microsoft 生产环境内的高峰磁盘传输要求。

使用 Secure Path 的冗余存储系统路径

OTG 的 SAN 技术部署包括一个 I/O 设计，它不仅提供冗余性而且还使用这种冗余性来优化数据流。

OTG 使用 HP StorageWorks Secure Path for Windows 在它的 SAN 基础结构内提供许多优点。Secure Path 提供了三个关键的优点：

OTG 的 Secure Path 实施在每个主机上使用两个 FCA，两个光纤信道数据交换机，以及两个存储控制器。每个 FCA、交换机和控制器组构成了一个所谓的 Fabric。Secure Path 允许每个 SAN 使用两个独立的 Fabric，而且 Fabric 的每个元素都与两条 Fabric 的从属元素互连。更精确地说，一个集群中的每个活动节点主机通过安装在每个主机上的两个 FCA 相互连接（每个交换机一个 FCA）。每个交换机接受来自每个主机的入站数据并且有两条出站数据连接，每个控制器一条。每个控制器有两条入站数据连接，每个交换机一条，并且有一条到 SAN 模组的出站数据连接。Secure Path 使得 OTG 能够在运行时容忍在一个 FCA、一条连接线缆、一个交换机、或者一个控制器中的单个组件故障。当一个组件发生故障时，服务性能会受影响，但它仍然能够继续无缝地运行。

Secure Path 还能够帮助消除节点和连接到的 SAN 存储之间的许多单点故障。当发生一个组件故障只影响到组成 SAN Fabric 的每个主机上的单个 FCA、多条光纤线缆、光纤信道交换机、或单个存储控制器时，OTG 能够维持服务。该组件故障通过 Secure Path 探测，它将 LUN 从故障路径移动到一条可用的路径，从而确保 I/O 得以维持。此过程称为故障转移，它在维持 LUN 可用性的同时不会造成任何资源停机时间。一旦故障组件被替换，就能够使用 HP 的 Secure Path Manager 对故障转移 LUN 进行故障恢复以恢复最佳的 I/O。

图 2 展示了使用 Secure Path 连接一个 16,000 邮箱 SAN 的总部数据中心集群实施。

图 2：连接一个数据中心集群与一对 SAN 的 Secure Path
浏览全尺寸图像。

备份和恢复

通过实施集群服务器环境中的 Exchange 2003，OTG 设计了一个两段式备份过程（磁盘到磁盘和磁盘到磁带）以更好地满足它的 SLA。此过程防止了磁带备份过程影响生产服务器的性能，并且在管理数据恢复过程方面提供了更大的灵活性。此解决方案基于下面的组合：

过去，在直接相连 SCSI 存储服务器实施上维持一小时备份恢复 SLA 是非常具有挑战性的。这些服务器设计使用一步的备份过程（磁盘到磁带），其中备份通过千兆 LAN 传输到磁带库。OTG 的经验显示它们能够以大约每秒 36-37 MB 的速率移动数据，即大约每小时 33+ GB。备份被限制在非商务时间内进行，以尽量避免对（在这些服务器上有邮箱的）客户产生影响。但是，如果备份在上午 7 点以前还未完成，就必须取消。否则，继续进行的备份过程将会对客户的通信基础结构的系统性能造成极大的负面影响。

在 Exchange 2000 中恢复一个受损的邮箱存储意味着 1,000 个邮箱在恢复操作期间暂停服务长达六个小时或更长时间。这代表每个用户每小时因丧失生产效率而损失 60 到 80 美元。单邮箱恢复操作需要有专用的恢复服务器。图 3 显示了这一配置。

图 3：以前的区域消息备份环境
浏览全尺寸图像。

两段式备份解决方案

为了解决这些问题并支持服务器整合，OTG 设计了一个灵活的、两段式过程用于在多节点的集群配置中备份数据 － 磁盘到磁盘（阶段 1）和磁盘到磁带（阶段 2）。

OTG 充分利用了这样一个事实：在一个集群资源组中的资源能够在该资源组内移动而不依赖于其它的资源组。例如，一个集群 Exchange 服务器的一个活动节点除了连接到用于恢复生产数据的资源组外，还被连接到一个独立的专用备份 LUN 集群资源组。

在第一阶段，备份在集群内的所有活动节点上运行以完成在线的、磁盘到磁盘的备份，数据通过直接相连的光纤信道从生产数据资源组内的 LUN 到达备份资源组内的 LUN。备份资源组具有支持两条的在线保留的容量。一旦该过程完成，备份资源组中的 LUN 的控制被转移到一个备用的非活动节点。此时，非活动节点启动第二阶段，磁盘到磁带的备份，数据通过一个直接相连的光纤信道从备份资源组到达磁带库。这一过程将活动阶段从等待磁盘到磁带传输的时间中解放出来，从而将活动阶段用于处理数据备份操作的时间最小化。此过程如图 4 所示。

图 4：两段式备份过程
浏览全尺寸图像。

OTG 选择了这种两段式过程而没有选择使用直接光纤连接到磁盘库的、一段式的、磁盘到磁带的备份。虽然一段式过程不需要在 SAN 配置备份 LUN，从而可以在 SAN 中腾出更多额外存储用于更多的邮箱，但 OTG 认识到它无法承受当集群中的节点发生从磁带库断开连接的故障时损失宝贵的生产时间的风险。当发生这种故障时，节点服务器必须重启才能重新将服务器连接到磁带库。如果活动节点是执行此项工作的服务器，OTG 需要对该节点进行故障转移，以便使它能够重启并重新连接到磁带库。OTG 认为这对系统可用性是一个无法接受的风险。相反，通过在一个不支持用户的非活动节点上执行备份到磁带的工作，当该非活动节点需要重启以恢复服务器到库的连接时，不会造成生产服务的损失。

每数据库的在线备份被定期安排在晚上 8:00 到凌晨 1:30 之间，让 OTG 对每个服务器进行完全备份。数据库按每个 SG 同时备份。这里有一个重要的特性，Exchange 2003 允许在每 SG 的基础上进行并行备份与恢复操作。因此，对每个数据库的备份操作可以交替进行。

恢复解决方案

利用 OTG 的新集群解决方案，一个服务器硬件故障只是一次自动集群节点故障转移；服务几乎不受影响。如果发生磁盘故障，则需要根据故障范围和故障发生于一天中的哪个时段来实施不同的恢复方案。

方法不再依赖于方案

在过去，部署什么样的恢复方案取决于故障的类型和范围以及商务优先级。在 Exchange 2000 中，组织可以在下面两种方案中任选其一：快速恢复消息服务但放弃对旧的邮箱数据的立即访问，或者恢复对他们的服务的完全访问但需要花费更多的时间。

例如，如果一个数据库被丢失，最多可能会影响 200 个用户。因为磁盘上有最多达两天的备份数据，而且可以在一个小时内在线恢复（恢复速率最高为每分钟 2 GB），所以使用常规 Exchange 恢复过程来快速地在线恢复用户的邮箱数据。

注：每个 Exchange 数据库由两个文件组成： Exchange Database（EDB）文件和 Streaming Media（STM）文件。

在 Exchange 2000 中，如果整个 SG 丢失，那么故障在一天中哪个时段发生往往是决定如何处理的关键因素。如果故障在工作时间发生，那么恢复服务常常优先于恢复数据，后者可以在以后恢复。在该方案中，损坏的数据库被删除并重建（一个称为“清除数据库”的过程）。

如果故障发生在较晚的非工作时间，OTG 优先选择更快速地恢复所有丢失的数据，而牺牲立即恢复服务。在这种情况下，他们选择执行恢复而不清除受影响的数据库。

图 5 展示了 OTG 用于决定是先恢复服务后恢复数据还是同时恢复数据和服务的决策树。

图 5：OTG 生产恢复决策树
浏览全尺寸图像。

使用恢复存储组（RSG）

在 Exchange 2003 中，通常都能快速恢复服务而不管数据库故障发生于一天中的哪个时间段。从前一夜的磁盘到磁盘备份恢复数据的过程不是等到非工作时间进行，而是立即开始。

为了尽可能快地恢复数据，OTG 可以使用一种称为 RSG 新的 Exchange 2003 特性，这是一个特殊的离线 SG，专门用于从备份重建一个丢失的 SG。虽然 Exchange 2003 在生产中只为用户支持四个 SG，它现在支持 RSG 作为一个额外的离线 SG － 一个不支持生产用户访问的 SG。

OTG 创建一个临时 RSG 并将受损的数据库从备份源恢复到临时 RSG 中。一旦从备份的恢复完成了，从故障点到备份完成这段时间内产生的数据通过重播事务日志进行恢复。这一过程大大加快了恢复用户消息服务和从受损数据库恢复他们的数据的速度。当事务日志的重演完成后，已恢复的数据库在 RSG 和新的已清除的 SG 数据库之间交换。然后在电子邮件服务的恢复时刻和数据恢复完成时刻之间产生的所有新数据从被清除数据中导出并使用 Microsoft Exchange Mailbox Merge Wizard（也叫做 ExMerge）导入到已恢复的数据库中。RSG 随后被删除。因为数据库恢复速度受限于基于 LAN 的磁带，此方法也可以用于旧式的非集群服务器，当前它们正处于整合过程中。在大型的存储故障中，必须恢复大量的数据，而且许多邮箱在数据恢复之前可能要等待很长时间。

更多有关 OTG 的 Exchange Server 2003 备份与恢复的信息，请参阅 http://www.microsoft.com/china/technet/itsolutions/msit/default.mspx 页面上题为“Microsoft 的消息备份与恢复”的 iT Showcase 技术案例研究。

未来的备份技术

OTG 当前正在测试将 Window Server 2003 的一个称为卷影复制服务（VSS）的新特性用于一步的 Exchange 备份。此服务允许基于本地文件系统或基于特定厂商存储的数据快照功能。

VSS 提供了克隆磁盘数据、在单个时间点创建该数据的镜像的能力。OTG 的目标是结束它对当前的两段式在线备份过程的依赖，转而使用 VSS 在午夜克隆它的服务器，然后在中午 12 点和下午 6 点对一套新的克隆 LUN 使用 VSS 差分快照。在一个事故中，OTG 将根据数据损失的范围和事故发生的时间段来决定是使用最后已知良好 VSS 克隆还是使用快照来恢复数据。例如，如果在下午 2 点后，一个数据库因为受损而离线，那么恢复该数据库数据和服务的最容易和最快速的方法是从中午的快照恢复数据。如果在深夜探测到数据库损坏，因为那时候的通信量负载很轻，所以从最后克隆恢复数据是更可取的方法。如果使用 VSS 恢复大量的数据，今天需要几小时的时间才能完成的恢复任务仅需几分钟就够了。

VSS 作为一个备份解决方案，需要依赖许多第三方工具才能使它高效工作。需要一个请求程序、一个供应程序和一个写入程序。OTG 正在测试将 VSS 作为“快照加克隆”集成的可能的解决方案的运作优点。到撰写本文时为止，VSS 还没有用于 OTG 的生产备份，仍然处于测试阶段。

使用 Microsoft Operations Manager（MOM）2000 进行管理和监视

在 Exchange 2000 中，OTG 使用一个内部开发的名为 Prospector 的工具来监视 Exchange server。Prospector 监视关键的指示器，如服务运行、安装的服务器以及磁盘使用率。Prospector 非常高效，但用处有限。

在 OTG 开始移植到 Exchange 2003 之前不久，OTG 决定从 Prospector 移植到带有 MOM Exchange Management Pack 的MOM 2000来管理它的 Exchange server。MOM 是一个企业系统管理应用程序，它使用一个客户端代理从被监视服务器的事件日志中收集预定义的事件，并存入一个中央数据库。它还会创建警告来响应预定义事件，并将其路由到受数据中心操作人员监视的中央控制台。

除了许多其它功能之外，MOM 还为 Exchange Server 提供了特殊的管理规范。受监视的关键 Exchange 2003 管理数据包括服务器状态、性能标准和消息队列状态。MOM 还提供了可自定义的“知识脚本”（KS），它使系统管理员能够为操作系统或应用程序创建特定的管理目标。Microsoft 广泛使用 MOM KS 功能来管理 Exchange 2003 环境。表 5 提供了 Microsoft 用于 Exchange 2003 的一些关键 MOM 知识脚本的概述。

表 5：用于 Microsoft Exchange 2003 部署的关键 MOM 知识脚本

MOM 使用存储转发技术来收集事件，这样即使在正常的服务器操作期间发生临时网络中断，也能够可靠地传递事件。MOM Application Management Packs 是一系列预定义的事件和阀值，用于捕获与特定服务器应用程序最相关的数据。

MOM 使用一种称为配置组的组织结构来管理被监视的服务器。一个配置组通常由一个数据库、一个或更多 DCAM（数据访问服务器 + 整合程序和代理管理器）服务器，以及一个或更多在所有被监视计算机上运行的代理组成。

一旦系统正常运行，特别是在应用了 MOM Exchange Management Pack 并针对 OTG 的需求进行了合适的调整之后，使用 MOM 通过 WAN 来监视服务器就只会造成非常少的网络流量开销。因为这种高效率，早期的计划（使用五个 MOM 配置组以更好地管理 MOM 在 WAN 上的流量）被认为不必要而被放弃了。该过程十分高效，因此 OTG 只需要一个 MOM 配置组就能够监视全球所有的 Exchange server，而部署一个 MOM 配置组服务器的成本只需 50,000 美元。

在调整 MOM Exchange Management Pack 时，OTG 没有采取修改默认管理包的办法，而是创建一个自定义 OTG 管理包来维护新的和已修改的规则。这包括收集默认设置没有指定的数据、改变默认的数据收集参数和阀值等。OTG 仍然使用其自定义管理包来管理其处理环境中特有的特殊备份事件。OTG 将所有这些调整与整合反馈都提交给产品开发组，让他们将其包含到发布的产品中。

更多有关 MOM 的信息，请参阅 http://www.microsoft.com/technet/itsolutions/msit/default.mspx 页面上题为“Monitoring Messaging at Microsoft”的 IT Showcase 技术解决方案摘要和题为“Monitoring Enterprise Servers at Microsoft”的 iT Showcase 技术白皮书。

应用程序管理

一旦 MOM 检测到来自一个远程服务器的警报，OTG 能够使用 Windows Server 2003 中内置的远程管理工具来访问该服务器以进一步调查和诊断问题。

远程管理桌面（Remote Desktop for Administration）与远程桌面协议（RDP）

OTG 使用 Windows Server 2003 和 Windows XP Professional 的远程管理桌面与 RDP 特性来维护远程的 Exchange 2003 server。远程管理桌面由终端服务技术启用，是为服务器管理而专门设计的。因此，远程管理桌面可用于繁忙的服务器，且不会明显影响处理器性能。这对远程管理来说是一种便利、有效的服务。实际上，远程管理桌面用于登录到远程服务器上，就像本地登录一样。

服务器管理

OTG 使用 MOM 来创建关于服务器性能的长期趋势数据。然而，MOM 能够管理的最为主动的趋势循环是每隔五分钟左右记录一个数据检查点。OTG 使用 Performance Monitor（PerfMon）－ Windows Server 2003 中提供的一个工具 － 进行更实时的性能监视。

MOM 性能数据保存在八天的时间表中（当天和之前的七天）。OTG 使用在 MOM 中捕获的趋势数据来跟踪向 Exchange 服务器添加软件补丁或硬件驱动程序的性能提示。通过留意性能数据中的趋势何时发生变化，并将其与末班员工变化中维护的 Exchange Server 环境服务器变更记录相比较，OTG 能够更加快速地将性能问题和受益情况与在特定时间所做的特定更改联系起来。鉴于 OTG 环境中极高的变化率，这是 OTG 诊断过程中的一个重要工具。

HP Insight Manager

HP Insight Manager 是第一个可用于 PC 服务器的服务器元素管理器。它在 1992 年发布。从那时起，Insight Manager 就奠定了它作为服务器平台管理应用程序的领先地位。OTG 广泛地使用 Insight Manager 来监视与 HP 硬件相关的信息。虽然 Insight Manager 没有具体的 Exchange 管理数据，系统管理器可以使用此工具将来自其他管理应用程序的事件与 OTG 的 Exchange 2003 服务器上的特定硬件情况关联起来。HP Insight Manager 还与 MOM 紧密结合，为系统管理器提供一个统一的管理平台。表 6 显示了一些 Insight Manager 为其提供管理数据的关键对象。

表 6 HP Insight Manager

存储管理

在 SAN 模组上发生的事件不会记录到服务器的事件日志中，而 MOM 正是从事件日志中获得许多警报的。相反，SAN 模组事件存储在 HP Storage Manage Appliance（SMA）中。OTG 也配置 MOM 对 SMA 上的事件进行监视，以便监视 SAN 模组事件。在总部中，一对 SAN 模组安装一个 SMA。在区域中，每个 SAN 模组安装一个 SMA。结合 SMA 一起使用 MOM 能够确保象监视 Exchange 服务器那样有效地监视 OTG 的 SAN 模组。

最佳实践和经验教训

作为 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，并进行了如下修改：

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 操作相关。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。

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

注：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 员工所提供的消服务。