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

　　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 生产恢复决策树

　　浏览全尺寸图像。

查看本文来源