一个政府机构最近开始为其Microsoft Exchange 2003服务器提供高可用性和灾难恢复(DR)。回顾可用的选项后,该机构选择SteelEye LifeKeeper保护套件交易所提供实时交换数据保护和应用程序监控和恢复,和VMware ESX Server 2.5主机DR站点中的所有服务器来帮助减少博士和管理基础设施的建设成本。
•支持物理到虚拟集群
•支持保护其现有的Exchange服务器
做出选择后，接下来的议程就是实施。一是基础设施建设。点对点45 mbps广域网初级之间建立连接2020欧洲杯预赛和灾难恢复站点。DR站点也有通过T1连接到因特网的直接连接，它作为网关发送和接收SMTP电子邮件在发生灾难的情况下，以及提供远程访问到Outlook Web Access的一种手段灾难事件。
在DR站点中，VMware ESX服务器2.5.4,aLinux基于主机的操作系统，被安装到一个IBM系统X3650与四核Intel Xeon处理器为2.66GHz，4GB的RAM和四个73GB 15K热插拔SAS驱动器。第一个虚拟机然后联机。这些虚拟机正在运行的Exchange所需的核心基础设施服务，如DNS和全局编录的Microsoft Active Directory（AD）控制器。微软自动复制AD和AD集成的DNS，所以需要采取进一步的步骤，以确保DR站点有AD控制器和DNS的保护。在发生灾难的情况下，操作步骤均有详细记载如何，如果原来的AD控制器不再可用抓住AD FSMO角色。
下一步是将Exchange服务器添加到DR站点。该SteelEye公司的LifeKeeper保护套件为Exchange是微软集群服务器（MSCS）Exchange群集完全不同。当MSCS需要集群认证和相同的硬件，共享存储和升级现有的Exchange服务器企业版的LifeKeeper只需要另一个Exchange邮箱服务器添加到现有的Exchange站点。由于LifeKeeper支持物理到虚拟群集这种新的Exchange服务器，虚拟机是在ESX服务器上创建和Exchange安装在相同的方式就好像它是在同一网站的另一个邮箱服务器。唯一的LifeKeeper要求是存储组和邮箱存储的名称是相同的主Exchange服务器。
所有的网络基础设施和硬件现在都已经就绪，可以开始实现用于交换的救生员。由于实现还将包括广泛的故障转移测试，时间被安排在周五和周六晚上来完成安装、配置和测试，以便将对用户的影响降到最低。
图1 -网络配置
星期五晚上 - 安装和配置
在安装LifeKeeper之前，要对Exchange和网络执行一个基本的运行状况检查。除了检查系统和应用现有的错误，例如公用事业Exchange最佳实践分析工具（ExBPA），原木的DCDiag，NETDIAG运行，以确保没有任何存在的问题。这是确定的ExBPA中的一件事是交易所SP1从未安装新的Exchange服务器上。一旦这个问题是固定的，我们已经准备好继续前进。
LifeKeeper的安装是非常直接的，其中包括安装和主要和次要Exchange服务器上牌LifeKeeper的保护套件。一旦软件安装和服务器重新启动后，安装完成。现在是时候的LifeKeeper的配置。
主Exchange服务器已经生产了两年多，并在惠普的Proliant DL380 2GB内存正在运行，直连SCSI磁盘。该服务器有一个30 GB的RAID 1盘为系统分区和一个160 GB的RAID 5卷日志和数据库文件。有关的LifeKeeper具有在硬件方面的唯一要求是，在辅助服务器上的复制卷的尺寸一样大或比主服务器上的卷大。因此，VM充当次级Exchange服务器必须被分配一个160 GB体积。
一旦在虚拟机创建卷，分区和格式化，我们配置了LifeKeeper集群。配置包括创建心跳，卷资源，Exchange资源，DNS资源和通用应用程序资源的通信路径集群。创建这些资源是通过LifeKeeper的GUI调用适当的向导来完成。
建立两者之间的通信路径服务器是第一个步骤。因为这些服务器是由单个WAN链路连接，只有一个通信路径已建立。为了消除脑分裂场景，其中两个服务器的所有通信链路失败的情况下变得活跃的可能性，因此决定禁止自动故障转移和严格依靠手动故障转移。今后，在两个服务器之间的VPN连接将跨越公网被创建，使得辅助通信路径可以建立和自动故障转移可以被启用。
在创建了通信路径之后，还创建了卷、DNS和Exchange资源。完成资源配置后，GUI如图2所示。
图2 -创建所有资源后的LifeKeeper GUI
每个资源都有专门的代码，给救生员提供智能来监控和恢复该资源。DNS资源还对DNS服务器进行动态更新，以便在不同子网之间迁移交换时提供客户端重定向。当您组合这些资源时，如图2所示，您为整个Exchange应用程序堆栈提供了完整的保护。
体积资源的创建包括数据镜像的创建。因为它要花费几个小时为34GB的初始复制通过WAN链接来完成，因此决定，这是一个很好的突破点在晚上。
星期六晚 - 完成配置
星期六晚上我们继续LifeKeeper的资源的配置。在这一点上，唯一剩下的配置问题是解决与Exchange交互的第三方应用程序的保护。这些应用程序包括Esker的传真，2003 PageMasterEX和Trend Micro。这些资源的保护是通过创建一个通用的LifeKeeper应用恢复工具包（GenApp）来实现的。
一个GenApp让用户没有预先包装的恢复工具包能够轻松保护第三方和定制应用程序。建立一个GenApp的基本要求包括独立的脚本，知道如何启动和停止应用程序。可选的，可以在应用程序的运行状况的脚本可以被写入。
会议决定，只要求基本的启动和停止操作。将得到的开始（Restore.ksh）和止挡（Remove.ksh）脚本如下所示。
Remove.ksh
净停止FGExchge
净停止EUQ_Monitor
净停止PageMasterEX
退出0
Restore.ksh
NET START FGExchge
NET START EUQ_Monitor
净启动PageMasterEX
退出0
一旦脚本完成，GenApp资源创建向导运行，LifeKeeper的配置就完成了。现在是测试解决方案的时候了。
星期六晚 - 测试解决方案
手动切换
第一个测试涉及到一个简单手动切换测试。客户端，包括Outlook 2003，OWA和POP3客户端的少数的推出，并连接到Exchange服务器。一些测试电子邮件的切换之前被发送出去，然后切换从LifeKeeper的GUI启动。在切换过程中，交易所是为大约1.5分钟不可用。切换完成后，客户端连接成功进行了测试。
本地恢复
救生员的功能之一是局部恢复。该特性允许LifeKeeper在发生故障转移之前尝试在本地修复问题。要测试此特性，只需通过服务控制面板手动停止Exchange Information Store服务。然后，我们验证了LifeKeeper检测到此故障，并自动重启服务，而不会导致故障转移。
硬故障转移
最后一个测试(也是最重要的一个)是模拟Exchange服务器的硬故障。测试这种类型的灾难的一种方法是拉一下服务器上的电源线。经过一番哄骗，行政部门同意了。因为之前禁用了自动故障转移，辅助服务器只是坐在那里等待我们告诉它进入服务。一旦我们通过GUI将其投入服务，辅助服务器在大约一分钟内就上线了，没有数据丢失。
SWITCHBACK
在手动切换测试和硬故障转移测试之后，我们必须能够使Exchange恢复到主服务器上的服务。这可以通过LifeKeeper GUI轻松地完成，方法是选择主服务器并让它进入服务。由于LifeKeeper的意图日志跟踪复制卷上的更改，所以在主服务器恢复联机之前，只需要同步主服务器离线时发生的更改。
检测结果
所有的测试的成功与故障转移时间总是在不到两分钟内完成。唯一需要改变的是，与EX02 20的优先点加入第二次公开DNS MX记录，所以在事件EX01是不可用的，EX02将接收所有传入的SMTP电子邮件。
结论
通过结合使用LifeKeeper for Exchange和在DR站点中使用VMware ESX，客户能够满足其Exchange灾难恢复RPO和RTO的要求，并在预算和空间限制之内。通过在DR站点安装VMware ESX服务器，客户可以考虑安装其他DR服务器，而不必购买额外的硬件。
戴维·伯明翰，MCSE，MCSA：信息，是SteelEye公司技术产品管理总监。
了解更多关于这个话题
这个故事，“高可用性为Microsoft Exchange与VMware ESX Server和SteelEye公司的LifeKeeper”最初发表LinuxWorld——(美国) 。