Exchange 2003设计和体系结构（16）

存储设计与配置

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 生产环境内的高峰磁盘传输要求。