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

至于监视远程区域 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 员工所提供的消息服务。

（出处：清风学院）