微软怎么设计Exchange 2003的体系结构

背景介绍

Microsoft 的通信基础结构种类繁多，在全球 75 个地方运行着超过 100 台邮箱服务器，这些服务器使用各种不可伸缩的硬件配置。

解决方案

OTG 升级了其全球的通信基础结构，使用集群 Windows Server 2003 服务器（连接到存储区域网络（SAN）系统）上的 Exchange Server 2003。

优点

•	整合。Windows Server 2003 改进的集群技术使得 OTG 能够实施重大的邮箱服务器整合。
•	移动性的改进。Exchange 2003 将 Outlook Mobile Access 和 Exchange ActiveSync 与 Outlook Web Access 进行集成，以提高移动通信能力。
•	增强的服务等级协议（SLA）性能。SAN 的使用使得 OTG 能够增加每台服务器的邮箱数量，并增强 OTG 及时备份和恢复邮箱数据的能力。

产品与技术

•	Microsoft Windows Server 2003
•	Microsoft Exchange Server 2003
•	Microsoft Office 2003
•	Microsoft Office Outlook 2003
•	Microsoft Operations Manager
•	存储区域网络（Storage Area Networks）

概述

Microsoft 的运营技术组（OTG）最近部署了 Microsoft Exchange Server 2003 － 该公司行业领先的企业通信应用程序的最新版本。OTG 不仅通过运行 IT 应用程序为公司内的无数员工和单位服务，而且作为 Microsoft 内各种企业产品开发组的第一个、也是最好的一个客户，在 Microsoft 软件提供给外部客户之前首先在公司内进行部署。

从 Microsoft Exchange 2000 Server 到 Microsoft Exchange Server 2003 的移植给 Microsoft 的通信体系结构带来了许多重大变化。OTG 已经转移到完全集群的邮箱服务器环境之中。这些服务器集群都连接一个或多个对其数据存储封闭的存储区域网络（SAN）。使用集群技术显著增强了可靠性、提高了可用性、并改善了执行滚动升级的过程。

部署 Exchange 2003 的优点，特别是结合部署 Microsoft Windows Server 2003 和 Microsoft Office 2003 所带来的优点，使得 Microsoft 能够整合其通信基础结构。OTG 已经开始实施这一计划，将全球 75 个位置的 113 台邮箱服务器整合为 7 个位置的 38 台邮箱服务器。Exchange 2003 还能够在同一台服务器上支持所有的移动通信服务，如 Outlook Web Access（OWA）、Outlook Mobile Access（OMA）和 Exchange ActiveSync（EAS），从而使 OTG 能够进一步整合其全球前端服务器基础结构。

通信数据存储基础结构也进行了更新。数据存储从原来位于远程位置、直接连接的小型计算机系统接口（SCSI）存储阵列和位于华盛顿州雷德蒙（Redmond，Washington）总部数据中心的 SAN 解决方案组结合的方式替换为位于所有位置的 SAN 。这些变化使得 OTG 能够增加每台服务器的邮箱数量，同时显著增强备份和恢复解决方案的性能和能力。

到撰写本文时为止，OTG 已经极大地减少了 Exchange 的管理开销，提高了系统性能和服务可用性，并增强了自己履行服务等级协议（SLA）责任的能力。随着 Microsoft 逐步实现其整合目标，这些优点将更加显著。

注：因为安全方面的原因，本文中所使用的森林、域、内部资源和组织的名称不代表 Microsoft 内部使用的真实的资源名称，仅用于说明目的。

介绍

Microsoft Exchange Server 2003 代表了 Microsoft 在企业技术领域的一项重要的持续性投资。Exchange 2003 提供了企业通信和协作客户需要的改进特性。全球许多最大型公司都使用 Microsoft Exchange 运行其消息系统，其中包括 Microsoft。

本文旨在概括介绍 Microsoft 在升级到 Exchange Server 2003 的过程中所作出的体系结构和设计决策。本文重点说明项目中的硬件选择和配置问题，同时还讨论了通过升级获得的关键技术进步和最佳实践。因为 OTG 是 Microsoft 技术和产品的领先实施者，该组织引入了一套独特的要求和创新方法来满足客户的需求。本文描述了这些要求和方法，以及它们对部署设计决策的影响方式。本白皮书的计划读者包括技术决策者、系统设计师、IT 实施人员和消息系统管理人员。

OTG 以下面这些目标为基础，实施从 Exchange 2000 到 Exchange 2003 的移植：

•	在 Microsoft 将该产品提供给客户之前进行测试和改进。
•	整合全球的 Exchange 服务器站点，以减少服务器维护和管理的成本和工作量。
•	通过使用标准化服务器和存储硬件来简化通信基础结构。
•	增强 OTG 履行其数据备份和恢复服务等级协议（SLA）责任的能力。
•	显著改善终端用户使用 Microsoft 通信服务的体验。

OTG 在部署 Exchange 2003 时达到了所有这些目标。

当前网络基础结构概述

Microsoft corporate 的企业网是世界上最大的试验性计算机网络，在它的生产环境中使用了各种 beta 级和测试版的软件。该网络是众多功能主干的联合，其范围覆盖全球。每个主干根据区域边界进行定义，集中连接到位于 Puget Sound 大都市区（Puget Sound Metropolitan Area）中的主企业园区。

该网络按照多域路由模型设计。它分为四个区域网络，每个网络都是一个单一的开放最短路径优先（Open Shortest Path First，OSPF）路由和寻址域。这四个区域覆盖了以下地区：1. 西华盛顿州的 Puget Sound 大都市区；2. 欧洲、非洲和中东；3. 日本、环太平洋地区、南太平洋地区；以及 4. 北美洲和南美洲的其它地区。

每个区域网络由一个主干区域（Area 0）和多个区域组成，以确保每个区域网络的可伸缩性。外部边界网关协议（EBGP）被用来交换区域网络之间的路由以确保网络作为一个整体的可伸缩性。

Puget Sound 城域网（MAN）支持全局企业网络上的大量数据通信，在该地区内的建筑和主要的数据中心之间提供了千兆位的连接。当前的园区由 70 个单独的建筑和两个数据中心组成，其网络基础结构为园区内的任何位置提供了对企业资源、开发人员实验室网络和 Internet 连接的访问。

该网络依赖千兆以太网和同步光纤网络（SONET）分组报文，使用私有的或租借的裸光纤作为传输介质。在大都市区内，有效的利用有限的光纤资源是通过使用波分多路复用（WDM）技术实现的，它能够在一条物理链路上提供多条通信回路。

可用的网络带宽对于 Exchange Server 2003 这样的应用程序和站点到站点的连接是非常重要的。到 2003 年 6 月为止，该网络已经增长到包含：

•	3 个企业数据中心，19 个分布全球的区域数据中心
•	在 77 个国家的约 230 个城市中有 310 个站点
•	世界上最大的无线局域网（802.1x EAP-TLS）
•	超过 24,000 部无线设备
•	超过 4,000 个无线接入点
•	超过 250 个广域网（WAN）电路
•	在 70 多个国家中有超过 200 个 WAN 站点
•	超过 3,300 个 IP 子网
•	超过 2,000 台路由器
•	超过 2,600 台第二层网络交换机
•	超过 275 台 ATM 交换机
•	超过 10,000 台全球服务器
•	超过 350,000 个 LAN 端口

当前通信基础结构概述

管理 Microsoft 内复杂的通信基础结构是一项团队任务，涉及 OTG 内许多不同的小组。从组织结构上看，OTG 由超过 2,500 名工作人员组成，他们负责跨越全球 400 多个 IT 位置的操作。除了为公司提供 IT 工具之外，OTG 在帮助 Microsoft 满足软件开发和市场营销的主要商业目标方面也扮演着重要的角色。作为 Microsoft 的第一个也是最好的一个客户，OTG 是 Microsoft 新软件的早期采用者，例如 Windows Server 2003、Microsoft Office 2003 和 Exchange Server 2003。这个过程的结果就是业内广为人知的“eating your own dog food（吃你自己的狗食）。”

在 OTG 的 “dog food” 通信环境中，服务器经常接受软件补丁、操作系统测试版本和升级、Exchange 服务器测试版本和升级等等。每个月 OTG 平均要给每一台 Exchange 服务器进行两次这样的软件升级。对软件实施更改的目的是为了测试新方案，满足特殊要求，以及通过在实际环境中进行企业级测试来持续运行最新的应用程序概念。在 OTG 中，变化的速度是非常高的。

Microsoft 的员工给予通信基础结构极重的负载。Microsoft 的普通员工拥有 3 台计算机，通常全部都用于与 Exchange 同步。此外，还有相当一部分员工携有 Pocket PC 和 Smartphone 设备，这些设备也要与 Exchange 同步。在 Microsoft，平均每秒的远程过程调用（RPC）操作（一种对工作的测量方式）远高于 OTG 已知的任何其他公司。Microsoft 经常和客户以及合作伙伴一起测试他们的通信基础结构。在 Microsoft，Exchange 服务器所处理的工作负载通常比在这些公司所测量到的负载高出不止两倍。

在撰写此文时，Microsoft 的通信环境由全球 75 个位置的超过 200 台服务器组成，包括 190 台 Exchange 2003 服务器（其中 113 台是邮箱服务器），包括在额外的交叉目录林测试环境中的服务器。此环境支持：

•	全球邮件流每天有 6,000,000 份邮件，平均每天有 2,500,000 份 Internet 电子邮件，其中的 70％ 都是惹人厌烦的垃圾邮件、被病毒感染的、或者是发给无效电子邮件地址的邮件。比较线路上的字节就会发现，在 Microsoft，被阻止的邮件内容与被接收邮件内容的大小比例是 40:1。典型的电子邮件平均大小为 44 KB。
•	大约 85,000 个邮箱，每个从 100 MB 容量限制增长到 200 MB。普通的 100 MB 邮箱大小只有 44 MB。
•	超过 85,500 个分布组。
•	公用文件夹服务器管理超过 230,000 个唯一的公用文件夹。

OTG 服务器基础结构包括：

•

企业标准客户端配置由 Windows XP Professional 和 Microsoft Office Outlook 2003 组成。

•

旧式的、独立的邮箱服务器在独立服务器上配置有 500、1,000 或 1,500 个邮箱。在全球范围内，独立服务器正在被集群 SAN 解决方案替代，并且扩展为在区域位置每服务器支持 2,700 个用户邮箱、在总部数据中心每服务器支持 4,000 个用户邮箱。

•

在总部内的一个中心支持组织支持全球所有的 Exchange 服务器。

•

除了主企业 Exchange Active Directory 目录林之外，还有三个额外的目录林用于为 Microsoft 的 Exchange 邮箱服务器提供宿主服务：

•	一个专用的 Level A Test 目录林运行 Exchange 的开发和测试代码，在一个经常变化的服务器软件环境中操作。
•	一个专用的 Level B Test 目录林，作为一个有限使用的生产环境供一个产品分类使用，为有限数量的用户邮箱提供宿主服务。可以在此环境中运行特定的硬件配置和测试方案。Level B Test 使用一个二节点服务器集群连接到一个可支持 5,000 个用户邮箱的 SAN。
•	一个旧式测试环境目录林，用于测试比当前发行版本旧一个版本的 Windows 服务器操作系统（特别是 Windows 2000 Service Pack 专用测试）与 Exchange。

注：OTG 同时使用 Level A Test 和 Level B Test 目录林来测试交叉目录林行为并支持主 Microsoft corporate 生产目录林。

OTG 服务水平包括：

•	在主企业目录林中的全局服务可用性服务水平协议（SLA）目标，按每分钟邮箱数据库的可用性（包括计划和非计划停机）计算，对于独立服务器设计是 99.9％。使用 Exchange 2003 的新集群服务器设计将其提高到 99.99％。
•	在 95％ 的时间中，全球电子邮件能够在 90 秒内交付。
•	备份与恢复操作 SLA 少于每数据库 1 小时。

注：因为安全方面的原因，本白皮书中使用的目录林、域、内部资源和组织的名称是虚构的。它们不代表 Microsoft 内部使用的真实资源名称，并且它们在本文档中只用于演示目的。

站点与位置

跟随 Exchange 2000 部署的引导，OTG 继续执行按专用角色部署 Exchange 服务器的策略。表 1 根据服务器角色显示了 Exchange 2003 服务器的分布。OTG 将 Exchange 2003 服务器分组为 37 个 Exchange 路由组，它们与 79 个站点连接器互连。

表 1 Microsoft 内根据服务器角色的 Exchange 2003 Server 分布

服务器角色	Exchange 2000	Exchange 2003（整合后的目标*）
邮箱	113	38
公用文件夹	20	11
通信集线器	12	7 **
即时消息	4	0 ***
Internet 网关	22	18
专用忙/闲服务器	6	0 ****
前端*****	14	12
防病毒	9	7

* 邮箱服务器整合项目定于 2003 年末之前完成。

** OTG 将建立 7 个通信集线器和 4 个额外的双用途服务器，后者也将提供通信集线器服务。

*** Exchange Instant Messaging 服务器将被移除，因为消息服务被移植到 Windows Real Time Communications（WinRTC）服务器中。

**** 所有的忙/闲服务器服务将由现有的公用文件夹服务器提供。OTG 将不会在 Microsoft 建立任何专用的忙/闲服务器。

***** 前端服务器被整合到 Exchange 2003 的部署中，因为从前包含在 Mobile Information Server（MIS）2002 产品中的技术被添加到 Exchange 2003 中。为了提高系统可用性，每个 Exchange 2003 前端服务器部署站点都配置了一对负载平衡服务器。

路由组和管理组结构

在 Exchange 2000 之前的所有 Exchange 部署中（包括版本 4.0、5.0 和 5.5），OTG 根据网络拓扑将 Exchange 服务器分组到站点中。对于 Exchange 5.5，由于目录和公用文件夹复制和消息路由流量，OTG 设计了环境以在对大型站点的需求和这些站点间的网络带宽限制之间获取平衡。

自从 Windows 2000 平台上的 Exchange 2000 发布以来，Exchange 5.5 模型带来的限制和局限不复存在。无需管理组员身份就可以在路由组中放置服务器的能力使得 OTG 能够在不失去大型管理组优势的前提下优化路由拓扑。

目录复制现在是 Active Directory 的一个功能，并且是一个操作系统级的问题，而不再是 Exchange 部署的一个关键问题。因为路由组和管理组不必相同（像 Exchange 5.5 和更早版本中的情况），OTG 消息操作员工能够自由地将 Exchange 2003 服务器放置到与它们的管理和操作结构相匹配的组中，以及放置到与 WAN 拓扑相匹配的组中。这就将目录复制问题交给了另一个专注于该领域的 OTG 团队。到撰写本文时为止，OTG 维护着 31 个 Exchange Server 2003 路由组和 11 个管理组。

Exchange 2000 旧式体系结构

在 Exchange 2003 仍然处于早期 beta 版本时，OTG 就开始进行部署了。为了完全掌握本项目的范畴，让我们回顾一下早期 Exchange 2000 的通信基础结构、OTG 必须升级到 Exchange 2003 的最根本原因、以及 OTG 是如何做到成功升级的。文中还包括了 OTG 在这次经验中所遇到的各种挑战和发现，以便为您计划自己的 Exchange 2003 部署提供一些指导和注意事项。

Exchange 2000 基础结构概述

Microsoft Exchange Server 平台是历史上销售最快的 Microsoft 服务器产品。自从 1996 年发布 Exchange 4.0 以来，已经售出了超过 5,000 万套 Exchange Server。表 2 提供了自 1996 年 Microsoft 首次发布 Exchange Server 以来 Microsoft 内部的 Exchange Server 部署发展概况。

表 2 Microsoft 的 Exchange Server 部署发展

	Exchange 4.0	Exchange 5.0	Exchange 5.5	Exchange 2000	Exchange 2003
邮箱/服务器	305	305	1,024	3,000	4,000
邮箱大小/用户	50 MB	50 MB	50 MB	100 MB	200 MB
恢复时间/数据库	~12 小时	~12 小时	~8 小时	~1 小时	~25 分钟*
邮箱总数	~32,000	~40,000	~50,000	~71,000	~85,000

* 从备份磁盘恢复一个数据库需要 25 分钟。

旧式服务器和存储设计

OTG 在总部数据中心和所有区域部署中都使用独立服务器。这些服务器被分类为四种基本邮箱服务器配置，如表 3 所示。

Table 3 Microsoft OTG Exchange 2000 服务器配置

Exchange 2000 服务器配置	邮箱
小型配置区域邮箱服务器	500
中型配置区域邮箱服务器	1,000
大型配置区域邮箱服务器	1,500
数据中心配置邮箱服务器	3,000

根据每种服务器配置的需求，存储设计各不相同。所有 Exchange 2000 邮箱服务器都支持 100 MB 邮箱。区域服务器配置使用直接相连的 SCSI 存储磁盘阵列，通过 100 Mbps LAN 进行备份。数据中心配置服务器使用三个 SAN 阵列，每个包含一个 SG。它们通过千兆位 LAN 进行备份。

OTG 在设计其初始 Exchange 服务器时以最大化服务器和存储硬件两者的系统性能和可用性为宗旨，使用了最佳实践指导原则。为了优化磁盘的输入/输出（I/O），SG 的每一卷都被指派了一个逻辑单元号（LUN）。因为每个 LUN 都分配了一个驱动器号，所以每个服务器（包含三个 SG，每个由三个 LUN 组成）使用九个驱动器号。

OTG 将每个 SG 配置为维护三个独立的 LUN。使用 24 个 18-GB 磁盘的邮箱数据 LUN 和使用 6 个 18-GB 磁盘的日志 LUN 都被设置为使用带状镜像配置，即通常所说的独立磁盘冗余阵列（RAID）-10。SAN 还维护一个使用 12 个 36-GB 磁盘的 RAID-5 配置的备份 LUN。此 LUN 用于支持两天的在线、磁盘到磁盘的备份保留时间。

每个 SG 支持五个数据库，每个数据库支持 200 个邮箱，这意味着它们最多能够支持每 SG 1,000 个邮箱和每服务器 3,000 个邮箱。

性能、可伸缩性和可支持性的挑战

Exchange 2000 是对前一版本的 Exchange 的一次重大升级。然而，即使 Exchange 2000 非常强大，OTG 仍必须解决某些限制。

需要管理的服务器数量太多

由于不具备有效地整合服务器和站点的能力，服务器站点数量的增长使得支持成本变得极高而且给消息环境增加了复杂性。一些与分布式环境相关的更常见的成本因素包括：

•	更多系统需要备份
•	额外维护大量站点上的备份系统
•	向管理备份过程中添加更多员工
•	额外站点需要更强劲的电力和冷却资源
•	更多现场支持员工用于多个站点的硬件维护

从复杂性的角度来看，更大数量的系统意味着在一个复杂机器中有更多移动部件；即，即使只要求同样的成功率，也需要更多的备份任务，这意味着有更多数量的故障需要检查和解决。计划减少 90％ 的服务器站点数量极大地降低了通信机器中移动部件的数量，从而减少了许多前端的故障率。

在服务等级协议（SLA）时间内恢复数据库的困难

即使是很小的整合工作也能够导致许多站点上的服务器获得的更高的可伸缩性。随着产品可伸缩性的提高，服务器上的邮箱数目也不断增加，而数据库大小也同样持续增长。更重要的是，由于倡导将最大邮箱容量从 100 MB 增加到 200 MB，数据库大小立即翻了一番。

因为 Exchange 2000 没有提供对新的恢复选项，如恢复存储组（RSG）功能或卷影复制服务（VSS）的支持，所以由 Exchange 2000 Server 的损坏所造成的数据库停机意味着数据库恢复过程将导致更长时间的停机。在许多站点中，备份是通过数据中心内的多台计算机处理的，这就导致备份和恢复需要通过 100 MB LAN 来进行，这种恢复的平均时间在最佳状态下也只有每小时 16 GB。初始的恢复 SLA 是在一小时内完全恢复数据库，这一目标很快就变得难以达到。

集群可伸缩性限制

Windows 2000 Advanced Server 支持两节点集群，而 Windows 2000 Datacenter Server 支持四节点集群。对于在 Windows 2000 Advanced Server 上运行的 Exchange 2000，在最佳配置下，OTG 需要有多个与每个 SG 相关联的驱动器号卷。还有其它的驱动器号用于服务器配置，例如简单邮件传输协议（SMTP）驱动器（一个专用的入站/出站队列设备）。结果，集群内的每个虚拟 Exchange server（在计算了全体SG 和 SMTP 驱动器后）使用十个扩展驱动器号。这其中没有将服务器节点自身使用的必需的、保留的驱动器号计算在内，例如用于软盘、操作系统卷、以及 CD 驱动器的驱动器号。在耗尽可以分配给磁盘卷的可用驱动器号之前，OTG 在一个集群内只能使用两个服务器。可用驱动器号的缺乏阻碍了 OTG 向集群环境中添加额外的 Exchange 服务器实例。

备份基础结构不灵活

OTG 对区域服务器使用一段式备份。区域服务器使用 100 Mbps LAN 执行直接的、磁盘到磁带的备份。在 Redmond，服务器执行两段式备份过程： 首先是 SAN 内的磁盘到磁盘备份，然后是磁盘到磁带备份。为了确保备份过程在非业务时间内完成，OTG 需要在每台 Exchange 服务器上部署千兆以太网络适配器，以确保它们能够获得将数据通过 LAN 传输到磁带上所必需的吞吐量。

数据恢复需要创建一个临时性的恢复服务器作为分段服务器从磁带中获取数据。OTG 了解，在此过程能够开始之前，除了恢复数据的时间之外，磁带驱动器还必须先读取并寻找特定数据库在磁带上的起始点。此过程在所有数据都确实传输到磁盘之前需要等待 90 分钟左右。在 OTG 100 Mbps 网络上，用于数据恢复的典型吞吐量（从数据开始流动算起）大约是每分钟 300-350 MB。对于一个 15 GB 的示例数据库的选择性恢复，完成恢复工作所需的总时间常常超过两小时 － 大大超过 SLA。

最后，OTG 将在分配的 SLA 时间窗口内满足备份和恢复工作的技术需求作为它构造整个 Exchange 2000 体系结构的基础。

OTG 进行升级的原因

OTG 有许多升级到 Exchange 2003 的重要理由。当然，由于它作为运行 Microsoft 产品组“dog food”软件的角色，OTG 必然要部署 Exchange 2003。此部署是远在任何客户接受该产品之前，利用现实世界、企业经验和反馈来改进产品的一个努力。

此外，Exchange 2003 解决了前面所述的 Exchange 2000 给 OTG 所带来的难题。Exchange 2003 的部署使得 OTG 能够改善为客户提供的服务并降低操作需求。Microsoft 实现了下列业务优势：

•	减少了服务器数量
•	提高了服务器可用性、可靠性和可管理性
•	改进了集群支持
•	增强了安全性
•	改善了数据备份和恢复
•	改善了移动用户支持
•	改进了与 Office 2003 的集成

站点和服务器整合

在撰写本文时，随着 Exchange 2003 的部署完成，OTG 正在实施整合区域邮箱服务器和位置的一个长期规划。OTG 在全球 75 个位置有 113 台邮箱服务器。整合计划的最终目标是将位置数量减少 90％，降为全球 7 个位置，使用 38台集群 Exchange 虚拟邮箱服务器。这种级别的服务器缩减将极大的降低 OTG 中的通信基础结构所需要的管理工作负载。

通常每服务器的邮箱数量的增加和每 SG 有更大数量的数据代表着出故障的风险增加。事实上，OTG 用停机时间乘以受影响的数据库数量来测量数据库服务的可用性。例如，一个为时一分钟的停电事件影响了一个服务器（包含三个 SG，每个 SG 有五个数据库，共包含 15 个数据库）的一个 SG，那么停机时间为五分钟。此外，OTG 对它的停机事件进行了研究，发现它的计划停机时间大大超过非计划停机时间，其比例是 6:1。

虽然每服务器的邮箱数量在增长，而且邮箱大小翻了一番，但是站点和服务器整合工程预计将会提高 OTG 的总体可用性及其备份和恢复性能 SLA。它还将极大地降低 OTG 服务器管理工作量，从而降低成本。

可用性/可靠性/可管理性增强

Exchange 2003 提供的各种增强功能，使它成为有吸引力的升级。

虚拟内存管理

Exchange 2003 虚拟内存的改善减少了内存碎片，并提高了服务器可用性。特别是，Exchange 重用虚拟内存块的方式效率非常高。这些设计改良减少了碎片并提高了拥有大量邮箱的高端服务器的可用性。

集群 Exchange 服务器的虚拟内存管理也得到改善。在 Exchange 2003 中，当一个 Exchange 虚拟服务器被手动移动或被故障转移到另一个节点时，该节点上的 MSExchangeIS 服务被停止。然后，当 Exchange 虚拟服务器被移动或故障回复到该节点时，一个新的 MSExchangeIS 服务被启动，因而一个新的虚拟内存块被分配给该服务。

Exchange 系统管理器（ESM）

Exchange 2003 利用下面的关键更新增强了使用 ESM 的管理员功能：

•

改进的移动邮箱的方法。Exchange Task Wizard 现在允许您选择任意多个邮箱，然后使用任务计划程序将移动任务安排在未来的某个时间进行。您也能够使用计划程序来取消任何被选中时间内未完成的移动任务。使用向导的多线程功能，您最多可以同时移动四个邮箱。

•

改良的公用文件夹接口。为了使公用文件夹更易于管理，Exchange 2003 以选项卡的形式包括了一些新的公用文件夹接口。

•	“Content（内容）”选项卡显示了 Exchange System Manager 中的公用文件夹的内容。
•	“Find（查找）”选项卡支持在选中的公用文件夹或公用文件夹层次结构中进行搜索。可以指定各种搜索标准，例如文件夹名称或时间。此选项卡在顶级和文件夹级的层次结构中都可用。
•	“Status（状态）”选项卡显示了公用文件夹的状态，包括有关具有该文件夹副本的服务器的信息和该文件夹中的项目数量。
•	“Replication（复制）”选项卡显示了有关该文件夹的复制信息。

•

新的 Mailbox Recovery Center。使用新的 Mailbox Recovery Center，您能够在多个不相连的邮箱上同时执行恢复或导出操作。

•

增强的 Queue Viewer。Queue Viewer 改善了对消息队列的监视。增强包括：

•	X.400 和 STMP 队列在 Queue Viewer 中显示，而不是在它们各自的协议节点上显示。
•	“Disable Outbound Mail（禁用出站邮件）” 选项允许您禁止所有 SMTP 队列的出站邮件。
•	可以使用“Settings（设置）”选项设置队列的刷新率。
•	使用“Find Messages（查找邮件）”， 可以根据发送者、接受者和邮件状态搜索邮件。
•	可以点击队列来显示有关该队列的额外信息。
•	原来隐藏的队列，“DSN messages pending submission”、“Failed message retry queue” 和 “Messages queued for deferred delivery” 已经显示出来。

•

对消息跟踪日志文件的增强控制。 在使用 Exchange System Manager 时，您对消息跟踪日志文件拥有更强的控制。Exchange 2003 自动为消息跟踪日志创建一个共享目录并允许您改变消息跟踪日志的位置。

•

改良的错误报告。错误报告允许服务器管理员更容易地将错误报告给 Microsoft。虽然 Exchange 2000 SP2 和 SP3 中也包含了错误报告，但它在 Exchange 2003 中的实施得到了改进。例如，如果用户不想查看标准错误报告对话框，他们可以将 Exchange 配置为自动向 Microsoft 发送与服务相关的错误报告。

改良的集群支持

Windows Server 2003 对集群进行了许多改进，允许 OTG 充分利用此项技术提供一个稳定的集群服务器标准来支持其全球 Exchange 邮箱服务器整合计划。新的标准与 Microsoft 企业 Exchange 部署以前所使用过的任何部署方法相比，提供了更好的可伸缩性和可用性。

最高支持 8 个节点

在使用 Windows Server 2003 Enterprise Edition 或 Windows Server 2003 Datacenter Edition 时，Exchange 增加了对最多 8 节点主动/被动集群的支持。这使得 OTG 能够增加 Exchange Server 2003 集群中的服务器数量，从而在减少管理 Microsoft 企业消息环境所必需的 Exchange 部署数量的同时，在实质上提高服务器可用性和可靠性。

支持卷装入点

当使用 Windows Server 2003 Enterprise Edition 或 Windows Server 2003 Datacenter Edition 时，Exchange 现在支持使用卷装入点。

卷装入点是 NTFS 文件系统的一个特性，它允许将多个磁盘卷链接到一个森林中，与一个服务器的分布式文件系统（DFS）链接远程网络共享的方式相似。管理员能够将许多磁盘卷同时链接到一个指向根卷的驱动器号上。NTFS 连接与卷装入点的结合能够用来将多个卷映射到一个主 NTFS 卷的名字空间中。

改良的故障转移性能

Exchange 通过减少服务器故障转移到新节点所花费的时间提高了集群性能。Exchange 对关闭活动（正在运行的）节点上的服务的进程进行了特殊的优化，加快了故障转移和在备用节点上启动服务的速度，从而提高了系统的总体性能。

增强的安全性

当 Microsoft 将安全性确定为它最优先的事务时，Exchange 2003 实现了许多优点：

Kerberos

Exchange 2003 在 Exchange 前端服务器和 Exchange 后端服务器之间发送用户证书时使用 Kerberos 授权。在以前版本的 Exchange 中，当用户打开诸如 Outlook Web Access（OWA）这样的应用程序时，Exchange 使用基本身份验证在 Exchange 前端服务器和 Exchange 后端服务器之间发送用户证书。因此，公司不得不使用诸如 IPSec 这样的安全性机制来加密信息。

Exchange 2003 在验证 Microsoft Office Outlook 2003 用户的身份时也使用 Kerberos。

在 OWA 中基于表单的身份验证

Exchange 2003 为 OWA 提供了一种新的登录页面，它将将用户名和密码存储在 cookie 中而非浏览器中。当用户关闭浏览器时，cookie 会被清除。此外，在经过预定义的非活动时期之后，cookie 会被自动清除。新的登录页面要求用户输入他们的域和网络用户名以及密码或其完整用户主要名称（UPN）、电子邮件地址，以及密码来访问其电子邮件。此特性也称为 cookie 身份验证。

OWA 中的用户可选安全性选项

OWA 登录页面允许用户选择最适合其需要的安全性选项。以 cookie 身份验证技术为基础，“Public or shared computer” 选项（默认为选中）提供了一个较短的 15 分钟的超时选项。作为选择，在办公室或家里独自操作一台计算机的 OWA 用户可以选择 “Private computer” 选项。“Private computer” 选项被选中时，允许在自动结束会话之前有更长的非活动时期。它的内部默认值是 24 小时。为了满足企业安全性需要，Exchange 2003 管理员可以自定义这两种选项的非活动超时值。

在 OWA 中阻止附件

与 Microsoft Outlook 2002 以及更新版本中已有的功能相似，Exchange 2003 的 OWA 特性能够被设置为阻止用户访问某些文件类型的附件。此特性有助于防止不可靠的附件对企业安全性造成潜在的破坏。

OWA 中的安全/多用途 Internet 邮件扩展（S/MIME）支持

S/MIME 通过同时支持邮件的数字签名和邮件加密提高了 Internet 电子邮件的安全性。数字签名提供了身份验证、不可否认性以及数据完整性。邮件加密提供了机密性和数据完整性。在 OTG 的配置里，当设置为使用 S/MIME时，私钥被存储在一个漫游配置文件中，后者在用户登录到一台连接到企业网络的计算机时变为可用。所有 S/MIME 加密、解密、以及消息传递签名操作都是在本地计算机上使用私钥执行的。所有的公钥由于不可否认性和解密的需要，都存储在 Active Directory 中。用户的私钥在任何时候都不会以任何形式在用户的计算机与 Exchange 服务器之间传递。

受限制的通讯组（Restricted Distribution Lists）

在 Exchange 2003 中，您可以对那些能够发送电子邮件消息给个人用户或通讯组的人设置限制。提交操作可以被限制为特定的用户、组，或所有已验证的用户。在一个通讯组上限制提交操作能够防止不可靠的发送者，例如未经身份验证的 Internet 用户向一个仅供内部使用的通讯组发送邮件。

增强的集群安全性

当在 Windows Server 2003 上运行时，Exchange 2003 包含下面的安全性特性：

许可改进意味着 Windows Cluster Service 不再要求具有 Exchange Full Administrator 权限才能创建、删除，或修改 Exchange 虚拟服务器。

•	Kerberos 身份验证协议在默认状态下是启用的
•	前端和后端服务器的 Internet 协议安全性（IPSec）支持
•	在创建虚拟服务器时，默认设置不再包含 Internet Message Access Protocol 4（IMAP4）和 Post Office Protocol 3（POP3）服务

改进的可恢复性技术更好地满足 SLA 要求

即时使用最快的网络连接，备份和恢复大型数据库或 SG 仍然需要很长的时间。但是，Exchange 2003 与 Windows Server 2003 的结合，通过在备份和恢复中使用磁带介质方法提供了另一种解决方案。此时，所需时间比原来所需时间要少得多。

卷影复制服务（VSS）集成框架

VSS 是 Windows Server 2003 的一个特性，它为 OTG 提供了在数据库中执行在线快照和复制的功能。这使得 OTG 能够拥有数据在单个时间点的镜像副本。VSS 使 OTG 能够获得生产数据的镜像副本或快照副本。根据故障类型，不论是邮箱存储、一个 SG 或多个 SG 受到损坏数据的影响，还是发生了丢失整个数据结构的重大主轴故障，OTG 都能在几分钟内恢复高达 800 GB 的数据，而相比之下标准的恢复方法需要花费数小时来恢复同样数量的数据。

恢复存储组（RSG）

新的 RSG 是一个专用的离线 SG，可以在 Exchange 中生产服务器上的标准 SG 旁创建它。RSG 为快速恢复邮箱和数据库提供了额外的灵活性。使用这一新特性，受损的 Exchange 数据库能够在离线模式下快速恢复到一台离线状态的生产服务器。一旦数据库被恢复到 RSG，就可以使用 Exchange 工具 ExMerge 将一个或多个邮箱中的内容导回到生产系统中。RSG 消除了用于单个邮箱恢复操作的专用恢复服务器，从而减少了服务器停机时间。

邮箱恢复中心（Mailbox Recovery Center）

新的 Mailbox Recovery Center 简化了在多个不相连的邮箱上同时执行恢复或导出操作。这是对 Exchange 2000 的一项重要改进，在 Exchange 2000 中，这样的操作必须在每个不相连的邮箱上单独执行。使用这个新特性，您能够快速恢复 Exchange 邮箱，从而减少停机时间。

移动特性/增强

Exchange 2003 中对移动客户端体验进行了重大的增强。所有原先在 Mobile Information Server 2002（MIS）（Exchange 2000 的一个独立的附属解决方案）中能够找到的移动特性现在都集成到了 Exchange 2003 中。

Outlook Web Access（OWA）

Exchange Server 2003 中新版本的 OWA 是对 Exchange 2000 中 OWA 的一次重大升级。这个新的版本是一个全特性的电子邮件客户端，支持规则、拼写检查程序、签名和加密的电子邮件，以及其它许多改进。重新设计的界面提供了与 Outlook 2003 类似的增强的用户体验，包括一个新的阅读窗格（以前在 Outlook 中称为预览窗格）和一个改良的导航窗格。

对于通过拨号上网、低带宽无线网络，或使用安全套接层（SSL）连接到网络的 OWA 用户来说，Exchange 2003 所使用的新的数据压缩技术与使用早先版本的 Exchange Server 相比能够带来根本性的总体性能提升。在连接到 Exchange 2003 的客户端计算机上使用 OWA 不再需要任何 ActiveX 控件，这也带来了额外的性能提升。当使用较早版本的 Exchange Server 时，如果在客户端计算机的 Internet Explorer 缓存中找不到这些控件，每次运行 OWA 时都必须下载它们。

Outlook Mobile Access（OMA）

Exchange 2003 现在包含了原来在 MIS 中提供的 OMA 应用程序。OMA 允许使用基于浏览器的移动设备的用户使用移动设备访问他们的电子邮件、联系人、日历、任务、以及搜索全球地址列表。用户还可以通过带有移动浏览器的移动设备使用 OMA。

MIS 必须在所有需要这些服务的网络域中安装。由于 Exchange 2003 带有内置的移动服务，所以不再需要在网络域中进行安装。

此外，Exchange 2000 用户只能使用位于其本地域内的 MIS server。如果用户来自 Microsoft 企业网络内的一个域，但该域的 MIS 服务器是离线的，那么该用户无法使用其它子域中的 MIS 服务器来访问这些服务。

Exchange 2003 消除了对 OMA 的域边界限制。任何能够使用 OMA 的用户都可以在任何一个前端服务器上使用移动服务，而不管他们的网络域是什么。这给 OTG 带来一个额外的优点，如果一个区域的 Exchange 前端服务器不得不离线维修，那么用户仍然可以通过网络上剩下的服务器访问那些服务，从而几乎消除了该服务的停机时间。

Exchange ActiveSync（EAS）

Exchange ActiveSync 特性以前在 MIS 服务器中提供，它使用户能够安全地将他们的移动设备与 Exchange 服务器直接进行远程同步。EAS 现在也被集成到 Exchange 2003 中，并且在默认设置中启用。通过将移动设备与 Exchange 服务器进行同步，用户能够访问他们的 Exchange 信息，而无需持续连接到一个移动网络上。此外，用户不再受限于（与影响 MIS 中的 OMA 相同的）EAS 域边界限制。

最新通知

Exchange 2003 在 EAS 中引入了一个称为最新通知的新特性。过去，MIS 中的 push 通知特性使用无线运营商的短消息服务（SMS）发送文本消息（由转发电子邮件的头 160 个字符组成）。因为 SMS 使用非加密的文本发送它的消息，所以消息内容的安全性是一个主要的问题。最新通知不是传送实际消息的头 160 个字符，而只是向移动设备发送一条二进制命令，该命令使移动设备开始通过受 SSL 保护的 EAS 链接安全地同步电子邮件。使用这种方式，二进制命令中不会包含消息体的任何部分，但是用户仍然会接收到最新的电子邮件。

为了减少经常接收大量电子邮件的用户在一台设备上造成的通信流量，Windows Mobile 2003 设备为用户提供了两种选项：用户可以指定一个称为 Peak Time 的时间范围，同步将只在此指定时间间隔内进行，或者选择在所有时间进行持续的同步。但是，在非高峰时段里，每当有消息到达时，移动设备通过最新通知进行同步。对最新通知的支持要求使用 Windows Mobile 2003 设备，如 Pocket PC Phone Edition 设备或 Smartphone。

Office 2003 集成

Exchange 2003 比以前任何版本都更紧密地与其首要客户端应用程序 Outlook 2003 集成。这两者的结合给用户提供了许多增强特性。

Exchange 缓存模式

Exchange 缓存模式是 Microsoft Office Outlook 2003 的一个特性，它使用户能够在一个通信环境中使用 Outlook 2003 客户端和 Exchange Server 之间的已知连接。Exchange 缓存模式使客户端消除了大部分网络和服务器延迟，过去，这些延迟使得 Outlook 看起来好像停止了响应。使用 Exchange 缓存模式的 Outlook 连接到 Exchange Server，并将所有的传入内容（例如电子邮件、会议请求和任务）自动下载到一个专用的 .OST 文件中，该文件作为客户端计算机上的本地缓存使用。一旦下载完成，用户能够读取、回复、创建新邮件和删除邮件，以及发送任务和会议请求。在后台持续工作的 Outlook 将本地缓存文件连接到 Exchange Server，从而上载新的传出内容并下载所有新增加的传入内容。使用 Exchange 缓存模式时，用户不但能够摆脱低速的网络连接或低下的服务器性能所带来的烦恼，而且通常不会注意到通信性能有任何的不同。

Exchange 缓存模式（Outlook 2003 的特性之一）在 Exchange 2000 和 Exchange 2003 中都受到支持，但是当它与 Exchange 2003 结合使用时，一些专门设计的性能改进能够增强 Outlook 2003 客户端的性能。

Exchange 缓存模式是 Exchange Server 整合工作的一项关键要求。当位于区域内的用户通过 WAN 链接使用 Outlook 或连接到远程邮箱服务器时，Exchange 缓存模式将帮助他们摆脱系统延迟带来的苦恼。

数据压缩

为了减少在 Outlook 2003 客户端和 Exchange 2003 服务器之间传送的信息量，当 Exchange 2003 和 Outlook 2003 联合使用时，二者都执行数据压缩来显著减少网络流量。OTG 发现，它减少了平均达 40％ 的 Exchange 2003－Outlook 2003 相关的网络流量。Exchange 2003 也减少了在客户端和服务器之间的信息请求。

当本地服务器整合到区域服务器时，这种客户端和服务器之间的高水平数据压缩有助于 OTG 减轻产生的额外的 WAN 使用。以前所有本地 SMTP 网络通信量现在全部变为通过 WAN 传播的消息应用程序编程接口（MAPI）远程方法调用（RPC）的网络通信量，但是这种通信的数量与先前版本的 Exchange 和 Outlook 所产生的通信量相比是大幅减少了。

采用超文本传输协议（HTTP）的远程过程调用（RPC）

Exchange 2003 和 Outlook 2003，与 Windows Server 2003 结合使用，支持利用 RPC over HTTP 访问 Exchange。使用 Microsoft Windows 的 RPC over HTTP 特性，用户能够通过 Internet 安全地使用 Outlook 2003，而无需利用远程访问或使用 OWA 来建立一条虚拟专用网（VPN）隧道。Outlook 总是使用 RPC 与 Exchange 服务器通信。如果 Outlook 被设置为使用这一新特性，它在默认情况下将首先尝试使用采用传输控制协议/Internet 协议（TCP/IP）的 RPC连接到它的企业 Exchange 邮箱服务器，就像它在企业网络设置中那样。如果无法通过这种方式定位服务器，Outlook 将尝试使用采用 Internet 上的安全 HTTP 链接（使用 SSL）的 RPC 来连接到它的企业 Exchange 邮箱服务器。RPC over HTTP 使用 OWA、OMA 和 EAS 的用户所使用的相同的前端服务器。实际上，对于 Exchange 后端服务器来说，此服务与 OWA 是一样的。但它使用 Outlook 2003 而非 Internet Explorer 作为电子邮件客户端。与 OWA 类似，如果 RPC 连接是通过 Internet 建立的，用户在获准访问 Exchange Server 数据之前，需要输入他们的网络登录证书。

注： 该特性名为 RPC over HTTP，实际上使用的是 SSL 连接上的安全超文本传输协议（S-HTTP）。

使用笔记本作为其主要 Outlook 计算机的用户将发现此特性特别有用。到客户所在地出差并经常等待演示机会的用户可以使用 RPC over HTTP 与其企业 Exchange 服务器联系而无需建立 VPN 连接。RPC over HTTP 允许用户在客户地点（通常阻止 VPN 连接）通过防火墙连接到企业 Exchange Server，从而提高他们的可访问性和生产效率。

和 OWA 不同的是，用户可以在 Outlook 中通过远程连接访问本地存储的个人文件夹文件的内容，而且与他们在办公室里通过企业网络进行访问的方式完全一样。

注：与 OWA 不同，RPC over HTTP 在用户连接到 Exchange Server 时下载电子邮件信息（假设使用 Outlook 缓存模式）。因此，RPC over HTTP 只应该在用户控制的计算机上使用，例如企业笔记本，而不能在共享计算机或公共信息亭上使用。

OTG 乐观地预测 RPC over HTTP 的使用将会减少为满足公司需要所需的 VPN 服务器的数量。大部分使用 VPN 连接到企业网络的员工主要使用 Outlook。为了量化 VPN 的使用水平，OTG 正在分析如何在减少已部署的 VPN 服务器的数量而不减少所需连接服务的情况下更好地理解员工的需要。

Exchange 2003 体系结构设计决策

OTG 成功地部署 Exchange 2003 需要综合许多不同的元素。不仅需要新的 Exchange 服务器软件，而且也需要其它的许多新技术，例如来自第三方资源的服务器、存储硬件和 Microsoft Windows Server 2003 与 Microsoft Office 2003 软件，OTG 才能从部署中获得最大的优点。有关网络设计的注意事项（包括带宽需求和备份与恢复的 SLA 协议）也已考虑到。做出的设计决策所导致的变化也给 OTG 带来了操作变化。

拓扑结构

OTG 以 Windows 2000 Server 上的 Exchange 2000 拓扑结构为基础来设计 Exchange 2003 部署的拓扑结构。Active Directory 在 Exchange 2000 的组织结构和管理需求中是一个关键因素。OTG 能够将现有的 Active Directory 结构用于 Exchange 2003 部署。

当开始最初的 Exchange 2003 部署时，OTG 已经深入地参与了 Windows Server 2003 在其全球网络基础结构中的部署。这一发展非常关键，因为虽然 Exchange 2003 能够在 Windows 2000 Server 上运行，但 Exchange 2000 却不能在 Windows Server 2003 上运行。在 Windows Server 2003 上运行 Exchange 2003 能够给 Exchange 提供许多额外的优点，对此我们将在后面详细讨论。这些优点使得 OTG 能够开始计划实施整合全球通信基础结构中的服务器数量，这促进了 Exchange 2003 拓扑结构的设计。

移动性设计和配置

Microsoft 对移动性的定义已经增长到包括通常与移动技术无关的系统。使用 OTG 移动基础结构的设备不仅包括 Pocket PC 和 Smartphone。使用运行 Outlook 2003 的笔记本电脑或 Tablet PC 的 Microsoft 员工仅使用一条 Internet 连接就能够利用 RPC over HTTP 来访问 Microsoft 企业 Exchange server。任何远程的、可以访问 Internet 的计算机都可以作为 Microsoft 员工的 OWA 客户端。所有这些技术都通过同一个移动基础结构访问 Exchange 2003。

在 Exchange 2003 中的移动性增强使得 OTG 能够利用附加的服务器整合和改良的安全性修改其移动消息基础结构的设计。OTG 中的移动基础结构包括如下的一些服务：OWA、OMA、EAS、RPC over HTTP 以及最新通知。

前端服务器整合

除了邮箱服务器站点与服务器整合工程之外，Exchange 2003 还使得 OTG 能够整合它的移动服务器基础结构（也称为 Exchange 前端服务器）。OTG 不再需要在每个域中部署一个多服务器基础结构来提供移动服务。另一方面，与 Exchange 2000 一起部署 OWA 和 MIS需要一台 OWA 专用的 Exchange 前端服务器和用于 MIS 的独立服务器。使用 Exchange 2003 时，所有的移动通信特性都驻留在一台物理前端服务器上，使得 OTG 能够整合专门支持移动特性的前端服务器的数量。

OTG 将它的服务器数量从 7 台 OWA 服务器和 7 台 MIS 服务器（在 Microsoft 企业网中，每个域一套）减少为 7 个提供 OWA、OMA、EAS 和 RPC over HTTP 服务的 Exchange 前端站点。全球的每个 Exchange 前端站点支持一对非集群的、网络负载平衡的 Exchange 前端服务器。虽然 OTG 在理论上可以整合为一套 Exchange 前端服务器，但由于巨大的地理距离在 Exchange 前端服务器和区域 Exchange 邮箱服务器之间造成的网络延迟，工程团队决定保留多套前端服务器。如果 OTG 整合为一套，用户性能可能会受影响。在那些使用低速 Internet 连接或移动设备的用户中，网络延迟将显得尤其明显。

移动安全性增强

OTG 还将在 Exchange 2003 中用于 OWA 增强的安全性特性用于其前端服务器部署，例如基于时间的注销和基于表单的身份验证。和 Exchange 2000 下的 OWA 不同，当用户导航到一台前端服务器时会出现一个安全的、基于 HTML 表单的身份验证界面而不是基于 NTLM 的对话框。除了登录身份证书之外，该表单还会问两个额外的问题：

1.	用户是从一个公共信息亭/共享计算机登录还是从一台私有的家庭计算机登录？
2.	用户希望使用基础的还是高级 OWA 用户界面（UI）特性集？（答案通常依赖于连接是快速还是慢速数据链路。）

OWA 登录页面中显示的所有 UI 元素都可以自定义，从而能够包含公司图标、到区域前端服务器的特殊 URL、自定义用途的指令文本，等等。OTG 使用这些特性创建其自定义 OWA 页面。

一旦用户填满表单并单击 Log On，数据就被封装并通过 SSL 连接发送到用户指定的（在他们导航到特定服务器获取身份验证表单时指定的）前端服务器。一旦通过 Web 发出登录证书，本地客户端计算机上会创建一个特殊的超时 cookie。取决于用户是否指示客户端计算机为公用还是私有，该超时 cookie 开始倒计数一个非活动阀值。如果达到阀值时一直没有活动发生，会话连接将自动关闭，如果用户想要再次访问 Exchange 邮箱必须再次进行身份验证。OTG 将超时 cookie 设置为在公用或共享计算机上 15 分钟后关闭非活动会话，而在用户私有的家庭计算机上，非活动会话被设置为在两小时非活动时间后关闭。企业可以对会话超时时期进行自定义以满足任何安全性要求。

为了提供额外的安全性水平，OTG 选择了部署 Internet 安全性与加速（ISA）服务器作为所有 Exchange 前端服务器的反向代理。这就使得 Exchange 2003 的前端服务器能够放在防火墙后面，安全地位于企业网络之内，不用再直接与 Internet 相连。

服务器设计与配置

OTG 为其 Exchange 2003 部署设计服务器平台时，考虑了各种因素。除了一般的系统可靠性和厂家支持等硬件问题之外，关键的技术问题还包括新的处理器技术、集群实施、服务器设计，以及移动性问题。结果，OTG 将其所有的 Exchange 邮箱服务器都转移到集群环境中运行。

处理器

处理器技术不断进步，提高了处理速度，增加了板上集成缓存的数量和大小，还增加了能够并行处理的任务数量。Exchange 2000 基础结构的大部分服务器都基于 Intel Pentium II 和 Pentium III 处理器，频率从 500 到 700 MHz，前端总线（FSB）为 100 或 133 MHz。

鉴于自 OTG 部署 Exchange 2000 之后处理器技术的突飞猛进，OTG 决定在基于采用 400 MHz FSB 的 Intel Xeon Processor MP 超线程（Hyper-Threading）处理器的新系统上部署 Exchange 2003。

超线程使单个处理器能够像两个共享相同的内存总线和缓存的独立处理器那样处理信息。实际上，OTG 实施的四处理器超线程服务器在功能上就像一台虚拟的 8 处理器服务器。但是，一个具备超线程技术的处理器并不能提供与真实的双处理器系统完全相同的性能。因为超线程处理共享相同的板上集成缓存和主内存总线，OTG 测试的结果是超线程处理器与相同块速度的非超线程处理器相比，能够带来大约 25％ 的实际 Exchange 性能提升。

集群服务器设计

OTG 购买的所有用于安装 Exchange 2003 邮箱服务器的新服务器都被设置为集群，并且都装备了 Xeon Processor MP 微处理器。

利用 Exchange Server 2003、Windows Server 2003、第三方 SAN 技术、以及更快的服务器，OTG 决定创建一个提供更高的操作可靠性和更低的管理开销的集群服务器设计。他们的设计选择能够给他们带来下面的一些特殊优点：

•	通过将活动节点邮箱服务器自动故障转移到非活动节点服务器可以减少服务的停机时间。
•	Clustered Exchange Virtual Server（EVS）故障转移达到低于两分钟的性能，不论与 SAN 相连的故障节点内包含的邮箱数据量有多大。
•	同时增加了 EVS 的数量和集群内每 EVS 所支持的 SG 数量。每个 SG 都被设置为使用三个 LUN。这些 LUN 使用卷装入点，使所用的驱动器号数量最小化。
•	每服务器为更多邮箱提供宿主服务，从而支持了服务器整合。
•	通过将 75 个位置的 113 台邮箱服务器整合为 7 个位置的 38 个服务器，减少了管理和维护开销。
•	减少了数据库恢复对用户造成的潜在停机时间的影响（原来为每用户六小时或更多）。
•	将备份和恢复时间减少为低于一小时。
•	服务器可用性达到 99.9％，2004 财政年度的 SLA 目标为达到 99.99％。
•	支持实施滚动升级，可以加快服务器操作系统和应用程序升级和安装补丁的速度，同时将服务中断的影响最小化。
•	将用户邮箱限制提高了一倍（到 200 MB）

OTG 的设计目标是每 SAN 支持 8,000 邮箱，邮箱容量限制为 200 MB，集群服务器可用性达到 99.99％，以及备份与恢复时间低于每数据库一小时。主企业目录林中的数据中心 EVS 的设计容量达到 4,000 个邮箱。

多节点集群设计

OTG 决定采用使用多个活动（在线）和非活动（离线）节点的多节点集群设计。此设计使得一个故障的活动节点能够立即被一个相同配置的非活动节点代替，并将故障活动节点的资源，例如存储，立即转移给该非活动节点，从而确保故障转移最大限度地减少对终端用户体验的影响。

OTG 实施了两种独立的非活动节点类型： 主要非活动节点和被选非活动节点。主要非活动节点是一个与活动节点服务器配置相同硬件的服务器。这使得活动节点故障转移能够恢复完全的功能。备用非活动节点是一个配备较低性能的硬件的服务器，主要用于将磁盘数据导向磁带之类的任务。它还充当降低性能的故障转移服务器。两种类型的非活动节点都被用于软件的滚动升级。

OTG 的多节点集群设计同时使用主要和备用非活动节点。和主要非活动节点不同，备用非活动节点是一些较小的服务器，主要用于执行磁盘到磁带的备份任务。当需要对操作系统和/或 Exchange 进行滚动升级时，OTG 使用集群中所有的非活动节点。替代了将活动节点故障转移到主要非活动节点、升级离线的活动节点，然后将已升级的节点再恢复为活动状态并对每个活动节点滚动执行这一循环过程，OTG 同时部署主要非活动节点和备用非活动节点的方法加速了该过程。OTG 首先修补所有离线的非活动节点，然后将与可用的非活动节点数量相同的活动节点故障转移。然后并行地升级这些离线节点并在就绪时使它们恢复服务。此过程重复一次以升级剩下的一个活动节点服务器。

OTG 集群设计

OTG 在主企业目录林中为 Exchange 2003 部署实施了两种主要的集群设计： 一个区域设计和一个总部数据中心设计。在 Level B Test 有限使用产品目录林中还部署了一个独立的、可伸缩性的身份验证设计。全都使用多节点、活动/非活动集群设计。表 4 显示了 OTG 的集群配置。

表 4 每个部署的集群设计规格

	区域	总部	Level B Test
四处理器活动节点的数量	3	4	1
四处理器主要非活动节点的数量	1	1	1
双处理器备用非活动节点的数量	1	2	0
每活动节点的 SG 数量	4	4	4
每活动节点的邮箱数量	2,700	4,000	5,000
每活动节点的数据库数量	20	20	20
每数据库的邮箱数量	135	200	250
数据库的最大容量	27 GB	40 GB	50 GB
每集群的邮箱数量	8,000	16,000	5,000

•	区域设计。区域集群实施的服务器规格包括每集群一个 SAN 模组，带有三个活动节点、一个主要非活动节点、以及一个备用非活动节点（表示为 AAAPp）。
•	总部设计。总部集群实施在设计上是类似的。它包括两个 SAN 模组，四个活动节点，一个主要非活动节点，以及两个备用非活动节点（表示为 AAAAPpp）。
•	Level B Test 森林设计. Level B Test 服务器规格与区域集群在设计上类似，但拥有更大的邮箱容量。它包括一个 SAN 模组，一个活动节点，以及一个主要非活动节点（表示为AP）。

为了以最佳的价格获得最好的性能，OTG 将四处理器的 1.9 GHz Intel Xeon Processor MP 服务器作为它的活动和主要非活动集群节点的标准，用于区域和总部数据中心部署。对于备用非活动集群节点，OTG 使用双处理器的 2.4 GHz Intel Xeon Processor MP 服务器。得益于这个新的处理平台，OTG 的 Exchange 2003 基础结构获得了巨大的性能提升。

OTG 的集群设计有力支持了每个 Exchange 服务器的邮箱数量和容量的同时增长。它有助于消除第二阶段的备份过程对用户的性能影响，因为它将该阶段的备份过程交给了集群内的非活动服务器，从而维持了 SLA。

存储设计与配置

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 提供了三个关键的优点：

1.	消除了支持服务器和 SAN 互连的单点故障的风险。
2.	允许 LUN 分配以维持一个忙碌的 Exchange 主机所需要的最优的 I/O，减少高峰时段磁盘读/写延迟并极大地提升到磁盘的在线备份吞吐量。
3.	确保不论到主机的路径有多少条，只有一个 LUN 表示。

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。此过程防止了磁带备份过程影响生产服务器的性能，并且在管理数据恢复过程方面提供了更大的灵活性。此解决方案基于下面的组合：

•	Exchange Server 2003
•	Microsoft Windows Server 2003，Enterprise Edition
•	支持磁盘到磁盘备份的 Windows NT Backup
•	支持磁盘到磁带备份的 Veritas 存储管理解决方案

过去，在直接相连 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 知识脚本

知识脚本	目的
Service Monitor	轮询重要的 Exchange 服务，如 STORE.EXT，并在这些服务中断时产生警报。
Backup Monitor	此脚本监视备份操作和数据库以检验常规备份操作是否正在进行。此脚本列举 SG，检验日志文件和数据库头以确保它们已备份。
Disk Space Monitor	此脚本检验是否有足够的磁盘空间用于事务日志、数据库和备份卷。此脚本检验是否有至少 20％ 的可用空间。
Event Log Monitor	此脚本检查关键的 Exchange 2003 事件日志错误。它还寻找已经卸除的数据库。
Availability Monitor	此脚本通过在每个信息存储上执行测试登录来检验 Exchange 服务是否可用。
Discovery	此脚本为了配置管理目的对诸如软件版本、service pack、驱动程序等项目执行版本发现。
Active Directory Monitor	此脚本监视 Exchange 2003 服务器以发现访问 AD 方面的问题。Global Catalog 和 DS_Access 错误是此 KS 关注的关键问题。

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

对象	Insight Manager 提供的数据
磁盘子系统	Insight Manager 提供了广泛的磁盘监视与诊断信息，这些信息能够与应用程序事件（如 I/O 错误）相关联。
环境	Insight Manager 提供了有关服务器环境特征的信息，如温度、风扇状态和关键的 BIOS 错误。
版本控制	Insight Manager 的版本控制特性提供了有关固件、软件和驱动程序版本的详细信息，对于配置管理很有帮助。
利用率	Insight Manager 提供了关于处理器和 I/O 总线利用率的基于硬件的统计。

存储管理

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

•	在 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 员工所提供的消息服务。