系统级别的容错措施

 

上一次修改主题： 2006-08-16

本节提供了提高 Exchange 2003 组织容错能力的系统级别的注意事项和策略。具体地说，“系统级别”是指 Exchange 2003 基础结构，以及在该基础结构中实现容错能力所建议的最佳实践。

下图说明了一个可靠的 Exchange 2003 基础结构，并列出了用于维护高级别容错能力的最佳实践。

容错的基础结构措施

本节讨论了在 Exchange 2003 基础结构中的不同级别上设计容错能力的方法。具体地说，本节提供了下列相关信息：

• 实现防火墙和外围网络
• 确保对 Active Directory 和域名系统 (DNS) 的可靠访问
• 确保对 Exchange 前端服务器的可靠访问
• 配置 Exchange 的协议虚拟服务器
• 实现可靠的后端存储解决方案
• 实现服务器群集解决方案
• 实现监视策略
• 实现灾难恢复策略

实现防火墙和外围网络

建议 Exchange 2003 拓扑包括外围网络以及前端和后端服务器体系结构。下图说明了这种拓扑，包括由高级反向代理服务器提供的附加安全性（此处为 Internet Security and Acceleration (ISA) Server 2000 Feature Pack 1）。

注意：
若要提升高级反向代理服务器的性能和可伸缩性，可以在外围网络中的服务器上实现 Windows Server 2003 的网络负载平衡 (NLB)。有关 NLB 的信息，请参阅本主题后面的“在前端服务器上使用网络负载平衡”。

在外围网络中部署 ISA Server 2000 Feature Pack 1 只是有助于保护邮件系统安全的一种方法。其他方法包括采用传输级别的安全性，例如 Internet 协议安全 (IPSec) 或安全套接字层 (SSL)。

重要提示：
无论您是否决定实现包括 Exchange 2003 前端服务器的拓扑，都建议不要允许 Internet 用户直接访问后端服务器。

有关设计安全的 Exchange 拓扑的完整信息，请参阅“Planning a Microsoft Exchange Server 2003 Messaging System”中的“Planning Your Infrastructure”（英文）。

有关将 ISA Server 2000 与 Exchange 2003 配合使用的信息，请参阅“Using ISA Server 2000 with Exchange Server 2003”（英文）。

确保对 Active Directory 和域名系统的可靠访问

Exchange 严重依赖 Active Directory 和域名系统 (DNS)。为了提供对 Active Directory 和 DNS 的可靠而有效的访问，请确保对域控制器、全局编录服务器和 DNS 服务器进行了良好保护，以防可能出现的故障。

域控制器

域控制器是一个服务器，该服务器存放域数据库，并执行客户端登录和访问 Exchange 所需的身份验证服务。（用户必须通过 Exchange 或 Windows 的身份验证。）Exchange 2003 依赖域控制器来获取系统和服务器配置信息。在 Windows Server 2003 中，域数据库是 Active Directory 数据库的一部分。在 Windows Server 2003 域林中，Active Directory 信息在域控制器之间进行复制，这些域控制器还存放了林配置和架构容器的副本。

域服务器在 Active Directory 基础结构中可承担大量角色：全局编录服务器、操作主机或简单的域控制器。

全局编录服务器

全局编录服务器是存放全局编录的域控制器。由于它包含了通用组成员的相关信息，因此登录时需要全局编录服务器。此成员身份将授权或拒绝用户对资源的访问。如果无法与全局编录服务器联系，则无法确定用户的通用成员身份，并因此拒绝登录访问。

注意：
尽管 Windows Server 2003 提供的功能不需要本地全局编录服务器，但仍然需要一个本地全局编录服务器供 Exchange 和 Outlook 使用。全局编录服务器对于 Exchange 服务（包括登录、组成员和 Microsoft Exchange Information Store 服务）以及访问全局地址列表 (GAL) 至关重要。通过将全局编录服务器以本地方式部署到服务器和用户机，可以进行更有效的地址查询。如果跨越低速连接联系全局编录服务器，会增加网络流量，给用户体验带来不利的影响。

每个包含 Exchange 服务器的域中都必须至少安装一个全局编录服务器。

域控制器和全局编录服务器的最佳实践

由于域控制器包含了必需的 Active Directory 信息，因此，请确保对组织中的域控制器进行了良好保护，以防可能出现的故障。

下面是规划和配置 Active Directory 域控制器和全局编录服务器的最佳实践：

• 除非是组织的需要，否则不要在域控制器上运行 Exchange 2003。有关在域控制器上运行 Exchange 的可能影响，请参阅本主题后面的“在域控制器上运行 Exchange 2003”。

• 每个 Active Directory 站点中至少置入两个域控制器。如果站点中的一个域控制器不可用，则 Exchange 将查找另一个域控制器。当只有跨 WAN 才能访问组织中的其他域控制器时，这一点极其重要。这种情况可能导致性能问题，并有可能引起单点故障。

• 每个 Active Directory 站点中至少置入两个全局编录服务器。如果站点中的一个全局编录服务器不可用，则 Exchange 将查找另一个全局编录服务器。当只有跨 WAN 才能访问组织中的其他全局编录服务器时，这一点极其重要。这种情况可能导致性能问题，并有可能引起单点故障。

  注意：
  如果性能要求并不需要两个域控制器的带宽以及每个域中有两个全局编录服务器，请考虑将所有域控制器配置为全局编录服务器。在此方案中，每个域控制器都可用于为 Exchange 2003 组织提供全局编录服务。

• 通常，Exchange 处理器与全局编录服务器处理器的比例应该是 4:1（假设处理器的型号和速度类似）。不过，更高的全局编录服务器使用率、较大的 Active Directory 数据库或较大的通讯组列表会需要更多的全局编录服务器。

• 在接受服务的用户达到 10 个以上的分支机构中，每个包含 Exchange 服务器的位置都必须安装一个全局编录服务器。但是，为了实现冗余，理想方案是部署两个全局编录服务器。如果某个物理站点没有两个全局编录服务器，则可将现有的域控制器配置为全局编录服务器。

• 如果体系结构的每个站点包括多个子网，那么，通过确保每个子网至少拥有一个域控制器和一个全局编录服务器，可以增添附加的可用性。因此，即使路由器发生故障，仍可以访问域控制器。

• 确保指定为基础结构主机角色的服务器不是全局编录服务器。有关基础结构主机角色的信息，请参阅 Windows 2000 Server 帮助中的“全局编录和基础结构主机”主题。

• 考虑监视所有 Exchange 2003 域控制器上的 LDAP 延迟。有关监视 Exchange 的信息，请参阅“实现软件监视和错误检测工具”。

• 根据需要，考虑将 LDAP 线程从 20 增加到 40。有关优化 Exchange 的信息，请参阅“Performance and Scalability Guide for Exchange Server 2003”（英文）。

• 确保域控制器有可靠的备份计划。

在域控制器上运行 Exchange 2003

作为最佳实践，不应在充当 Windows 域控制器的服务器上运行 Exchange 2003。而应该分别配置 Exchange 服务器和 Windows 域控制器。

但是，如果组织要求在域控制器上运行 Exchange 2003，请考虑下列限制：

• 如果在域控制器上运行 Exchange 2003，则它将仅使用该域控制器。因此，如果该域控制器发生故障，则 Exchange 无法故障转移到其他域控制器。
• 如果 Exchange 服务器除了服务于 Exchange 客户端计算机之外，还要执行域控制器任务，则这些服务器在用户负载较重时会遇到性能降低。
• 如果在域控制器上运行 Exchange 2003，则 Active Directory 和 Exchange 管理员可能会遇到安全职责和灾难恢复职责的重叠。
• 同时作为域控制器的 Exchange 2003 服务器不能是 Windows 群集的一部分。具体地说，Exchange 2003 不支持与 Active Directory 服务器共存的群集 Exchange 2003 服务器。例如，由于能够登录到本地服务器的 Exchange 管理员可以对域控制器进行物理控制台访问，因此，他们可能潜在地提高自己在 Active Directory 中的权限。
• 如果服务器是邮件系统中唯一的域控制器，则它还必须是全局编录服务器。
• 如果在域控制器上运行 Exchange 2003，请避免使用 /3GB 开关。如果使用此开关，则 Exchange 缓存可能会独占系统内存。此外，由于用户连接数应该较低，所以不需要 /3GB 开关。
• 由于所有服务都在 LocalSystem 下运行，因此，如果有安全错误，则暴露的风险会更大。例如，如果正在域控制器上运行 Exchange 2003，那么，允许攻击者访问 Active Directory 的 Active Directory 错误将同样允许攻击者访问 Exchange。
• 正在运行 Exchange 2003 的域控制器需要花费相当长的时间来重新启动或关闭。（约为 10 分钟或更长时间）。这是因为在关闭 Exchange 服务前，将关闭与 Active Directory 相关的服务（例如，Lsass.exe），从而导致 Exchange 服务在搜索 Active Directory 服务时反复失败。此问题的解决方案之一是更改已失败服务的超时。解决方案之二是在关闭服务器之前，手动停止 Exchange 服务。

域名系统服务和 Windows Internet 名称服务的可用性

与域控制器服务和全局编录服务器服务类似，域名系统 (DNS) 服务对于 Exchange 2003 组织的可用性至关重要。在 Windows Server 2003 网络中，用户通过使用 DNS 和 Windows Internet 名称服务 (WINS) 来查找资源。DNS 服务器发生故障会阻止用户查找邮件系统。

若要确保 Exchange 2003 拓扑包含对 DNS 的可靠访问，请考虑下列方面：

• 确保网络上存在辅助 DNS 服务器。如果主 DNS 服务器发生故障，此辅助服务器应该能够将用户导向正确的服务器。
• 将 Windows Server 2003 DNS 区域集成到 Active Directory 中。在此方案中，每个域控制器都成为潜在的 DNS 服务器。
• 使用至少两个 DNS 地址配置每个客户端计算机。
• 理想情况下，两个 DNS 服务器都应该与客户端位于同一站点。如果 DNS 服务器没有与客户端位于同一站点，那么，主 DNS 服务器应该是与该客户端位于同一站点的那个服务器。
• 确保名称解析和 DNS 功能均工作正常。有关详细信息，请参阅 Microsoft 知识库文章 322856 HOW TO：配置 DNS 以用于 Exchange Server。
• 在部署 Exchange 之前，请确保中心站点和所有分支机构上都正确配置了 DNS。
• Exchange 需要 WINS。虽然在不启用 WINS 的情况下可以运行 Exchange 2003，但是不建议这样做。使用 WINS 解析 NetBIOS 名称可获得可用性的优点。（例如，在某些配置中，使用 WINS 可以除去重复的 NetBIOS 名称所造成的潜在风险，重复的 NetBIOS 名称会导致名称解析失败。）有关详细信息，请参阅 Microsoft 知识库文章 837391 Exchange Server 2003 和 Exchange 2000 Server 需要 NetBIOS 名称解析才能实现全部功能。

有关部署 DNS 和 WINS 的信息，请参阅 Windows Server 2003 Deployment Guide 中的“Deploying DNS”和“Deploying WINS”（英文）。

确保对 Exchange 前端服务器的可靠访问

如果组织中拥有一个以上的 Exchange 服务器，则建议采用 Exchange 前端和后端服务器体系结构。前端和后端体系结构提供了几个客户端访问性能和可用性的优点。

Internet 客户端通过前端服务器访问其邮箱。但是，在默认的 Exchange 2003 配置中，MAPI 客户端无法使用前端服务器；而是直接通过后端服务器访问其邮箱。

注意：
可以配置“Exchange 2003 RPC over HTTP”，以允许 MAPI 客户端通过前端服务器访问其邮箱。有关使用 RPC over HTTP 的信息，请参阅“Introduction to Exchange Server 2003 RPC over HTTP Deployment Scenarios”（英文）。

当前端服务器使用 HTTP、POP3 和 IMAP4 时，由于前端服务器分担了后端服务器的某些负载处理任务，因此提高了性能。

如果计划支持 MAPI、HTTP、POP3 或 IMAP4，则可以通过使用 Exchange 前端和后端服务器体系结构利用下列优点：

• 前端服务器会在服务器之间平衡处理任务。例如，前端服务器执行身份验证、加密和解密过程。这就提高了 Exchange 后端服务器的性能。
• 改善了邮件系统的安全性。有关详细信息，请参阅本主题后面的“安全措施”。
• 若要在邮件系统中包含冗余和负载平衡功能，可以在 Exchange 前端服务器上使用网络负载平衡 (NLB)。

有关规划 Exchange 2003 前端和后端体系结构的信息，请参阅“Planning a Microsoft Exchange Server 2003 Messaging System”中的“Planning Your Infrastructure”（英文）。

有关部署前端和后端服务器的信息，请参阅“Using Microsoft Exchange 2000 Front-End Servers”（英文）。虽然该文档集中讨论 Exchange 2000，但其内容仍适用于 Exchange 2003。

若要在邮件系统中构建容错能力，请考虑实现使用 NLB 的 Exchange 前端服务器。同时，还应在前端服务器上配置冗余虚拟服务器。

在前端服务器上使用网络负载平衡

网络负载平衡 (NLB) 是一个 Windows Server 2003 服务，它为需要高可伸缩性和高性能的基于 IP 的应用程序及服务提供了负载平衡支持。在 Exchange 2003 前端服务器上实现 NLB 后，就可解决前端服务引起的瓶颈。

下图说明了包含 NLB 的基本的前端和后端体系结构。

NLB 群集会将 IP 流量动态分布到两个或两个以上的 Exchange 前端服务器，并在前端服务器之间透明地分布客户端请求，它还允许客户端使用单一的服务器命名空间访问其邮箱。

NLB 群集是通过计算机编号来提升下列设备或组件的可伸缩性和性能的一些计算机：

• Web 服务器
• 运行 ISA Server 的计算机（用作代理服务器和防火墙服务器）
• 接收 TCP/IP 和用户数据报协议 (UDP) 通信的其他应用程序

NLB 群集节点通常具有相同的硬件配置和软件配置。这有助于确保用户获得一致的前端服务性能，而无论提供服务的是哪个 NLB 群集节点。NLB 群集中的节点全部处于活动状态。

重要提示：
NLB 群集不提供 Windows 群集服务所提供的故障转移支持。有关详细信息，请参阅下一节“网络负载平衡和可伸缩性”。

有关 NLB 的详细信息，请参阅“Windows Server 2003 Deployment Guide”中的“Designing Network Load Balancing”和“Deploying Network Load Balancing”（英文）。

网络负载平衡和可伸缩性

通过 NLB，当 Exchange 2003 前端服务器的需求增加时，可以进行向上扩展或横向扩展。通常，如果主要目标是为 Exchange 用户提供更快的服务，则向上扩展（例如，添加附加处理器和附加内存）是很好的解决方案。但是，如果要对前端服务实现某些容错措施，则横向扩展（添加附加服务器）是最佳解决方案。通过 NLB，必要时可以横向扩展至 32 个服务器。横向扩展提高了容错能力，因为 NLB 群集中的服务器越多，服务器故障影响到的用户就越少。

重要提示：
必须密切监视 NLB 群集中的服务器。当 NLB 群集中的一个服务器发生故障时，先前配置为发送到该故障服务器的客户端请求，不会自动分发到群集中的其他服务器。因此，当 NLB 群集中的一个服务器发生故障时，应使其立即退出群集，以确保为用户提供所需的服务。

配置 Exchange 协议虚拟服务器

配置 Exchange 2003 邮件系统时，请使用 Exchange 系统管理器，为特定前端服务器上要支持的每个协议创建一个协议虚拟服务器。

若要最大程度地提高前端服务器的可用性和性能，请在配置协议虚拟服务器时考虑下列建议：

• 当为 Exchange 2003 前端服务器配置 NLB 时，应确保 NLB 前端服务器上的所有协议虚拟服务器都使用相同的设置进行配置。

  重要提示：
  如果 NLB 群集中的协议虚拟服务器不相同，那么，根据电子邮件客户端被路由至的服务器，它们可能会遇到不同的行为。

• 如果前端服务器上没有使用 NLB，则不要在每个前端服务器上创建附加的协议虚拟服务器。（例如，不要同一前端服务器上创建两个相同的 HTTP 协议虚拟服务器。）附加的虚拟服务器可能显著地影响性能，只有在默认虚拟服务器无法进行充分配置时才应创建它们。

有关 Exchange 协议虚拟服务器的详细信息，请参阅“Administration Guide for Exchange Server 2003”（英文）。

有关优化 Exchange 2003 前端服务器的信息，请参阅“Performance and Scalability Guide for Exchange Server 2003”（英文）。

实现可靠的后端存储解决方案

可靠的存储策略对于实现容错的邮件系统最为重要。若要实现和配置可靠的存储解决方案，应熟悉下列内容：

• Exchange 2003 数据库技术
• 配置和维护 Exchange 数据的最佳实践
• 诸如 RAID 和存储区域网络 (SAN) 等高级存储技术
• 有关规划和实现可靠的后端存储解决方案的详细信息，请参阅“规划可靠的后端存储解决方案”。

实现服务器群集解决方案

通过允许资源的故障转移，服务器群集为 Exchange 2003 组织提供了容错能力。具体地说，使用群集服务的服务器群集维护了数据的完整性，并为后端服务器上的关键任务应用程序和服务提供了故障转移支持和高可用性，其中包括数据库服务、邮件系统服务以及文件和打印服务。

下图说明了一个四节点群集的示例，其中有三个主动节点和一个被动节点。

在服务器群集中，节点共享对数据的访问。节点可以是主动节点，也可以是被动节点，并且每个节点的配置取决于操作模式（主动或被动），以及如何配置故障转移。必须调整指定用于处理故障转移的服务器的大小，以处理故障节点的工作负载。

注意：
在 Windows Server 2003 企业版和 Windows Server 2003 Datacenter Edition 中，服务器群集可包括多达八个节点。每个节点都连接至一个或多个群集存储设备，这些设备允许不同服务器共享相同的数据。由于服务器群集中的节点共享对数据的访问，因此，服务器群集中的存储类型和方法非常重要。

有关规划 Exchange 服务器群集的信息，请参阅“规划 Exchange 群集”。

群集的优点

服务器群集为组织提供了两个主要优点：故障转移和可伸缩性。

故障转移

故障转移是服务器群集最显著的优点之一。如果群集中的一个服务器停止运行，那么，该故障服务器的工作负载会故障转移到群集中的另一个服务器。故障转移确保了应用程序和数据的持续可用性。Windows 群集技术可帮助您防止三种特定的故障类型：

• 应用程序和服务故障。这些故障会影响应用程序软件和必需的服务。
• 系统和硬件故障。这些故障会影响诸如 CPU、驱动器、内存、网络适配器和电源等硬件组件。
• 多站点组织中的站点故障。这些故障可能由自然灾害、电源中断或连接中断引起。为了防止此类型的故障，必须实现高级的地理位置群集解决方案。有关详细信息，请参阅本主题后面的“使用多个物理站点”。

通过帮助您防止这些故障类型，服务器群集为邮件环境提供了下列两个优点：

• 高可用性 向最终用户提供可依赖的访问服务同时减少非计划中断的能力。
• 高可靠性 降低系统故障频率的能力。

可伸缩性

可伸缩性是服务器群集的另一个优点。由于可以向群集添加节点，因此 Windows 服务器群集极具可伸缩性。

群集的限制

服务器群集在应用程序级别提供容错能力，而不是在数据级别提供容错能力。实现服务器群集解决方案时，还必须实现可靠的数据保护和数据恢复解决方案，以防御病毒、损坏以及其他对数据的威胁。群集技术无法防止病毒、软件损坏或人为错误导致的故障。

群集与容错硬件

群集和容错硬件都可防止系统出现组件故障（如 CPU、内存、风扇或 PCI 总线等故障）。虽然可将群集和容错硬件一起用作端到端解决方案，但是，须注意这两种方法以不同方式提供高可用性：

• 群集可防御应用程序或操作系统故障。但是，使用容错硬件的独立（非群集）服务器（即使用可热交换硬件的服务器，它允许在服务器运行时添加设备）无法防止这些故障类型。
• 群集允许在群集中的一个节点上执行升级或安装操作，同时维护 Exchange 服务对用户的完全可用性。对于独立（非群集）服务器，则必须经常停止 Exchange 服务，以执行这些升级或安装操作。有关在执行升级或安装时，如何维护 Exchange 服务可用性的特定信息，请参阅“Administration Guide for Exchange Server 2003”中的“Taking Exchange Virtual Servers or Exchange Resources Offline”（英文）。

实现监视策略

持续监视网络、应用程序、数据和硬件对于获取高可用性来说必不可少。通过软件监视工具和技术，可以确定系统状态是否良好，并在出现错误之前识别潜在问题。

若要最大程度地提高可用性，必须始终对服务器和应用程序进行管理、监视和故障排除。如果发生问题，则必须能够迅速反应，以便尽快恢复数据，使数据可用。为了帮助您监视 Exchange 2003 组织，可以使用 Microsoft Operations Manager 的 Exchange 2003 管理包。

有关 Exchange 2003 管理包、Microsoft Operations Manager 以及其他监视工具的完整信息，请参阅“实现软件监视和错误检测工具”。

实现灾难恢复解决方案

若要提高组织中的容错能力，需要制定并实现计划周密的备份和恢复策略。如果精心准备，则应该可以从大多数故障中恢复。

其他系统级别的最佳实践

在考虑了提高 Exchange 2003 基础结构的容错能力的措施后，请考虑下列其他系统级别的最佳实践：

• 维护服务器物理环境的安全 采取预防措施，确保物理环境受到保护。
• 安全措施 实施权限实践、安全修补程序、物理计算机安全、防病毒保护以及防垃圾邮件解决方案。
• 邮件路由 使用容错的网络硬件，并正确配置路由组和连接器。
• 使用多个物理站点 通过将数据镜像到一个或多个远程站点，或通过实现地理位置群集，以便在发生站点故障时能够进行故障转移，可以保护数据免受站点故障影响。
• 操作过程 维护和监视服务器，采取标准化过程，并测试灾难恢复过程。
• 实验室测试和实验性部署 在生产环境中部署邮件系统之前，在实验室和实验性环境中测试性能和可伸缩性。

维护服务器物理环境的安全

若要维护服务器的可用性，对于服务器运行时必须处于的环境，应该维护其高标准。若要延长服务器硬件的寿命并提高其可靠性，请考虑以下几点：

• 温度和湿度 将关键任务服务器安装在专门为其建立的房间中 — 具体地说，可以严格控制温度和湿度的房间。温度约为 70 华氏度（约为 21 摄氏度）时，计算机的性能最佳。在办公室环境中，温度通常不是问题。但是，请考虑夏季较长的周末期间，关闭空调后的影响。
• 灰尘或污染物 如有可能，请保护服务器和其他设备不受灰尘和污染物侵害，并定期检查灰尘。灰尘和其他污染物可能导致组件短路或过热，这会引起间歇性故障。只要打开服务器机箱，就迅速检查以确定此设备是否需要清洁。如果需要清洁，则检查此区域中的所有其他设备。
• 电源 与任何灾难恢复规划一样，在预计发生中断之前，尽早对电源中断进行详细规划，这需要识别业务运营最重要的资源。如有可能，至少从两条线路为机房供电，并在这些电源之间划分冗余电源。理想情况下，线路应该来自于建筑物外部的两个电源。请注意每个位置所能提供的最大电量。有可能一个位置拥有如此多的服务器，以至于没有足够的电源以支持任何附加的服务器。考虑备用电源，以供计算机中心发生电源故障时使用。也许需要向此区域中的其他大楼，或地理位置远离计算机中心的区域继续提供计算机服务。可以使用不间断电源 (UPS) 装置处理短时间中断，而使用备用发电机处理较长时间的中断。当复查在中断期间需要备份电源的设备时，请将网络设备（如路由器）包括在内。
• 电缆维护 为了保护电缆不受物理损坏，请使用电缆管理系统或电缆扎带，确保电缆整洁有序。电缆决不要松散地放在机箱中，否则可能被错误地断开连接。如有可能，请确保所有电缆的两端都已安全连接。同时，还要确保拔出式、机架式安装设备的电缆具有足够的空隙，确保缆线没有绑在一起，没有相互挤压或摩擦。为冗余电缆集设置良好的路径。如果使用了多个电源或网络通信来源，请尽量从不同点将电缆引至机箱。这样，如果一条电缆断开，另一条电缆仍可继续工作。不要将双电源插入到同一个电源板。如有可能，请使用独立的电源插座或 UPS 装置（理想情况下，连接到独立的电路），以避免出现单点故障。

安全措施

安全性是实现高可用性邮件系统的关键组件。虽然要考虑的安全措施很多，但下面是一些较重要的措施：

• 权限实践
• 安全修补程序
• 物理安全
• 防病毒保护
• 防垃圾邮件解决方案

有关上述安全措施以及其他安全措施的详细信息，请参阅“Exchange Server Security Hardening Guide”（英文）。

邮件路由注意事项

路由拓扑是邮件系统的基础。因此，规划路由拓扑时，必须牢记网络、带宽和地理位置的注意事项。

路由描述了 Exchange 如何将邮件从一个服务器传输到另一个服务器。规划路由拓扑时，必须理解邮件是如何在 Exchange 内传输的，然后规划一个能够最有效地传输邮件的拓扑。还必须规划与 Exchange 组织外部的邮件系统进行连接的连接器的位置。精心的规划可以减少网络流量，并优化 Exchange 和 Windows 服务。

若要确保邮件路由具有可靠性和可用性，请考虑下列高级别的建议：

• 确保物理网络具有内置冗余。有关详细信息，请参阅本主题前面的“网络硬件”。
• 确保正确配置了连接器和路由组。例如，在某些方案中，使用 Exchange 系统管理器配置冗余连接器路径可以限制出现单点故障。
• 配置连接器以确保有多条路径可访问所有桥头服务器。
• 如果适用，确保简单邮件传输协议 (SMTP) 网关服务器是冗余的。在大型数据中心中，通常建议使用特定的 Exchange 2003 服务器来专门处理入站和出站 SMTP 通信。通常将这些服务器称为 SMTP 网关服务器或 SMTP 集线器。这些服务器负责在客户端和 Exchange 2003 邮箱服务器（后端服务器）之间移动 SMTP 电子邮件。

有关规划路由设计和配置（包括创建路由组和连接器的建议）的信息，请参阅“Planning a Microsoft Exchange Server 2003 Messaging System”（英文）。

有关如何配置邮件路由的信息，请参阅“Exchange Server Transport and Routing Guide”（英文）。

使用多个物理站点

为了改进灾难恢复能力并提高可用性，某些组织使用多个物理站点。大部分多站点设计都包括一个主站点以及镜像该主站点的一个或多个远程站点。各站点间的组件和数据的镜像级别取决于 SLA 和业务需求。另一个选择是实现地理位置分散的群集。通过地理位置分散的群集，一旦发生灾难，一个站点上的应用程序可以故障转移到另一站点。

以下各节提供了有关站点镜像和地理位置群集的详细信息。

站点镜像

站点镜像涉及到使用同步复制或异步复制，将数据（例如，Exchange 2003 数据库和事务日志数据）从主站点镜像到一个或多个远程站点。

如果主站点上出现完全的站点故障，那么，将 Exchange 服务在镜像站点上联机所需的时间取决于 Exchange 组织的复杂程度、已有的预先配置的备用硬件数量，以及管理支持的水平。例如，组织可能会按照预先规划的一组灾难恢复过程进行操作，并在 24 小时内将其 Exchange 邮件系统联机。虽然 24 小时可能看起来是相当长的停机时间，但是，您也许可以在接近故障点的时间恢复数据。有关同步复制和异步复制 Exchange 数据的信息，请参阅“存储技术概述”中的“Exchange 数据复制技术”。

地理位置分散的群集

实现站点级容错的一个更先进的方法是实现地理位置分散的群集。若要部署 Windows Server 2003 的地理位置分散的群集，请使用虚拟 LAN (VLAN) 远程连接到 SAN。

配置地理位置分散的群集可能很复杂，并且群集服务器必须只能使用 Microsoft 所支持的组件。应该只与可提供合格配置的供应商一起，部署地理位置分散的群集。

有关 Exchange 2003 地理位置分散的群集解决方案的详细信息，请参阅“规划 Exchange 群集”。

有关 Windows Server 2003 和地理位置分散的群集的信息，请参阅 Geographically Dispersed Clusters in Windows Server 2003（英文）。

操作最佳实践

运行和管理 Exchange 2003 邮件系统时，IT 人员应使用标准 IP 最佳实践，这一点很重要。本节提供了最大程度地提高应用程序和计算机的可用性的最佳实践。（此信息适用于群集环境和非群集环境。）

• 最大程度地减少或彻底消除对操作系统、Service Pack 和过时应用程序的多个版本的支持
  在单个系统中（或在网络上进行交互的多个系统中），不同软件和硬件版本的多种组合一起使用时，很难提供可靠的支持。当过时的软件、协议和驱动器（以及相关的硬件）不支持新技术时，使用它们就不切实际。应为规划、测试和安装新的操作系统、应用程序和硬件预留出资源和时间。规划软件升级时，请与用户协同工作，以识别用户所需的功能。提供培训，使用户更方便地进行软件转换。在软件和支持预算中，为将来升级应用程序和操作系统提供基金。

• 隔离不可靠的应用程序
  不可靠的应用程序是指业务运行必不可少，但却不符合相应可靠性标准的应用程序。如果必须使用这样的应用程序，有两种基本方法可供采用：

  • 将这些不可靠的应用程序从对企业最关键的服务器上删除。如果已知某一应用程序不可靠，则应采取措施将其隔离，并且不要在关键任务服务器上运行此应用程序。
  • 提供足够的监视，并在适当位置使用自动重新启动选项。执行足够的监视要求定期对重要的系统性能度量标准拍摄快照。通过使用服务管理单元，可以设置应用程序或服务的自动重新启动。有关 Windows 服务的详细信息，请参阅 Windows Server 2003 帮助中的“服务概述”。

• 使用当前的标准化硬件
  硬件不兼容可能导致性能问题和数据丢失。维护并遵循新系统、备件和替换部件的硬件标准。

• 规划将来的容量要求
  容量规划对于成功实现高可用性系统至关重要。若要了解系统中当前存在多少额外容量，请在高峰负载时研究和监视系统。

• 维护操作步骤的更新列表
  修复根系统问题后，确保从操作和支持日程安排中删除了任何过时步骤。例如，更换或升级软件后，某些步骤可能不必要或不再有效。应特别注意可能已成为例行过程的步骤。确保所有的步骤都是必需的，而不是针对未找到根本原因的问题的临时修补程序。

• 执行足够的监视实践
  如果不充分监视邮件系统，那么，在问题变得严重并导致系统故障前，可能无法识别这些问题。如果不进行监视，则应用程序或服务器故障可能是出现问题的唯一通知。

• 作出反应前先确定问题的本质
  如果操作人员未经培训或指导，以在作出反应前仔细分析问题，那么，工作人员可能会花费大量时间对问题作出不适当的反应。他们还可能在问题的第一批迹象和实际发生故障之间的关键时间内，不能有效地使用监视工具。

• 处理问题的根本原因而不是处理问题的现象
  发生意外故障或执行短期预防性维护时，故障现象处理是还原服务的有效策略。但是，添加到标准操作步骤中的故障现象可以变得难以控制。支持人员可能忙于处理故障现象，而不能对新故障作出正确反应。

• 避免采用停止和重新启动服务和服务器来结束错误情况
  有时停止和重新启动服务器可能是必需的。但是，如果此过程只是暂时修复了问题，而没有解决根本原因，则可能导致其他问题。

实验室测试和实验性部署

在部署任何新解决方案之前，无论它是容错硬件或网络硬件、软件监视工具，还是 Windows 群集解决方案，都应该对解决方案进行彻底测试，然后才能在生产环境中进行部署。在隔离的实验室中测试后，请在只有一些用户会受到影响的实验性部署中测试该解决方案，然后对设计进行任何必要的调整。在对实验性部署感到满意之后，请在生产环境中执行全面部署。

根据 Exchange 组织中的用户数目，可能需要分阶段执行全面部署。每一阶段后，请在部署下一组用户前，验证系统是否能够容纳来自附加用户的处理负载增加。有关设置测试环境和实验性环境的完整信息，请参阅“Windows Server 2003 Deployment Guide”中的“Designing a Test Environment”和“Designing a Pilot Project”（英文）。

Exchange 容量规划工具

若要确定管理用户负载所需的 Exchange 服务器数目，请使用下列容量规划工具：

• Exchange Server Load Simulator 2003 (LoadSim)
• Exchange Server 压力和性能 (ESP) 工具
• Jetstress

重要提示：
由于其中某些工具创建的帐户具有不安全的密码，因此这些工具专用于测试环境，而不用于生产环境。

Exchange Server Load Simulator 2003

利用 Exchange Server Load Simulator 2003 (LoadSim)，可以模拟对 Exchange 施加的 MAPI 客户端负载。通过在客户端计算机上运行 LoadSim 测试，可以模拟这种负载。这些测试将向 Exchange 服务器发送邮件请求，从而在服务器上产生负载。

请按照下列方式使用这些测试的输出：

• 计算在客户端负载下，该服务器配置的客户端计算机响应时间
• 估计每个服务器的用户数
• 识别服务器上的瓶颈

可从“Downloads for Exchange Server 2003”网站上（英文）下载 LoadSim 2003。

Exchange Server 压力和性能工具

Exchange Server 压力和性能 (ESP) 2003 工具是用于 Exchange 的、具有高度可伸缩性的压力和性能工具。它通过同时访问一个或多个协议服务来模拟大量客户端会话。使用脚本来控制每个模拟用户所执行的操作。这些脚本包含与服务器进行通信的逻辑。然后，测试模块 (DLL) 运行这些脚本。测试模块通过 Internet 协议、调用应用程序编程接口 (API) 或通过诸如 OLE DB 等接口来连接服务器。

ESP 是模块化的并且可以扩展，目前提供了大多数 Internet 协议的模块，这些模块包括：

• WebDAV
• Internet 邮件访问协议版本 4 修订版 1 (IMAP4)
• 轻型目录访问协议 (LDAP)
• OLE DB
• 邮局协议版本 3 (POP3)
• 简单邮件传输协议 (SMTP)

可以在 https://go.microsoft.com/fwlink/?linkid=27881（英文）下载 ESP 2003。

Jetstress

Exchange 2003 是一种对磁盘空间需求量很大的应用程序。要正常运行它，Exchange 需要一个快速、可靠的磁盘子系统。Jetstress (Jetstress.exe) 是一个 Exchange 工具，用于将 Exchange 服务器部署到生产环境之前，帮助管理员验证磁盘子系统的性能和稳定性。有关 Jetstress 和 Exchange 后端存储的详细信息，请参阅“规划可靠的后端存储解决方案”。

可在 https://go.microsoft.com/fwlink/?linkid=27883（英文）上下载 Jetstress。