最近开始执行任务的一个政府机构，以提供高可用性和对他们的Microsoft Exchange 2003服务器的灾难恢复（DR）。After reviewing the available options, the agency selected SteelEye’s LifeKeeper Protection Suite for Exchange to provide real-time data protection and application monitoring and recovery of Exchange, and VMware ESX Server 2.5 to host all servers in the DR site to help reduce the cost of building and managing the DR infrastructure.
•物理到虚拟群集的支持
•保护他们现有的Exchange Server的支持
随着所做的选择，实施被提到议事日程未来。首先，基础设施成立。一个点至点45Mbps的湾主服务器之间建立了连接雷竞技电脑网站还有博士网站。博士网站也通过T1线路直接连接到互联网,担任网关发送和接收的SMTP邮件在灾难的事件提供了一种用于远程访问Outlook Web access在发生灾难。
在DR站点，在VMware ESX Server 2.5.4，一个Linux基于主机操作系统，被安装到一个IBM系统x3650配备四核Intel Xeon 2.66GHz处理器，4GB内存和4个73GB 15K的SAS热插拔驱动器。第一批虚拟机随后上线。这些虚拟机是运行Exchange所需的核心基础设施服务(如DNS和全球目录)的Microsoft Active Directory (AD)控制器。微软自动复制AD和AD集成的DNS，因此不需要进一步的步骤来确保DR站点有AD控制器和DNS的保护。在发生灾难时，记录了在原始AD控制器不再可用时如何捕获AD FSMO角色的步骤。
下一步是向DR站点添加一个Exchange服务器。SteelEye LifeKeeper Exchange保护套件完全不同于Microsoft Cluster Server (MSCS) Exchange集群。当MSCS需要集群认证的相同硬件、共享存储并将现有Exchange服务器升级到Enterprise Edition时，LifeKeeper只需要将另一个Exchange邮箱服务器添加到现有Exchange站点。因为LifeKeeper支持这个新的Exchange服务器的物理到虚拟集群，所以在ESX服务器上创建了一个虚拟机，并且以相同的方式安装Exchange，就好像它是同一个站点上的另一个邮箱服务器一样。唯一的“生命保持者”要求是存储组和邮箱存储的名称必须与主Exchange服务器相同。
所有网络基础设施和硬件已经到位开始的LifeKeeper的实施交换。因为在实现中也将包括广泛的故障转移测试，时间是为了尽量减少对用户计划上要完成安装，配置和测试一个周五和周六晚上。
图1 - 网络配置
星期五晚上-安装和配置
安装的LifeKeeper之前，进行交流的基本健康检查和网络。除了审查制度，应用程序运行针对现有错误的日志，如Exchange最佳实践分析器(ExBPA)、DCDiag、NetDiag等实用工具，以确保不存在任何问题。ExBPA发现的一件事是Exchange SP1从未安装在新的Exchange服务器上。一旦这个问题得到解决，我们就准备继续前进。
救生员的安装非常简单，包括在主服务器和次服务器上安装救生员保护套件并获得许可。一旦安装了软件并重新启动了服务器，安装就完成了。现在是配置救生员的时候了。
主Exchange服务器已经投入生产两年多了，运行在一台HP Proliant DL380上，具有2GB RAM和直接连接的SCSI磁盘。服务器有一个30 GB的RAID 1驱动器用于系统分区，一个160 GB的RAID 5卷用于日志和数据库文件。就硬件而言，LifeKeeper的唯一要求是备用服务器上复制的卷的大小与主服务器上的卷相同或更大。因此，必须为充当次要Exchange服务器的VM分配一个160gb的卷。
在VM上创建、分区和格式化卷之后，我们配置了LifeKeeper集群。集群的配置包括为心跳、卷资源、交换资源、DNS资源和通用应用程序资源创建通信路径。通过LifeKeeper GUI调用适当的向导来创建这些资源。
在两者之间创建通信路径服务器是第一步。因为这些服务器通过单一的WAN链路连接，所以只创建了一条通信路径。为了消除脑裂的可能性，即在所有通信链接失败的情况下，两个服务器都活跃起来，我们决定禁用自动故障转移，而严格依赖于手动故障转移。将来，两个服务器之间的VPN连接将通过公共网络创建，以便建立二级通信路径并启用自动故障转移。
创建的通信路径后，音量，也创造了DNS和Exchange资源。资源的配置完成后，该GUI出现如图2中。
图2 - 创建的所有资源后的LifeKeeper GUI
每个资源都有专门的代码，让LifeKeeper的情报提供监测和资源的恢复。该DNS资源也做DNS服务器的动态更新不同子网之间迁移的Exchange时提供客户端重定向。当你把这些资源，如图2所示，你为整个Exchange应用程序栈完整的保护。
卷资源的创建包括数据镜像的创建。因为通过WAN链路完成34GB的初始复制需要几个小时，所以我们决定将其作为今晚的一个很好的断点。
周六晚上-完成配置
周六晚上，我们继续配置救生员资源。此时，唯一剩下的配置问题是解决与Exchange交互的第三方应用程序的保护问题。这些应用包括Esker传真、PageMasterEX 2003和趋势科技。这些资源的保护是通过创建一个LifeKeeper通用应用程序恢复工具包(GenApp)来完成的。
GenApp让用户能够轻松地保护没有预先打包的恢复工具包的第三方和自定义应用程序。构建GenApp的基本要求包括知道如何启动和停止应用程序的独立脚本。可选地，可以编写一个可以检查应用程序运行状况的脚本。
决定只需要基本的启动和停止操作。得到的启动(Restore.ksh)和停止(Remove.ksh)脚本如下所示。
Remove.ksh
净停止FGExchge
净停止EUQ_Monitor
净停止PageMasterEX
退出0
Restore.ksh
净启动FGExchge
净启动EUQ_Monitor
NET START PageMasterEX
退出0
一旦剧本是完全的，并且GenApp资源创建向导运行的LifeKeeper的配置完成。这是一次测试解决方案。
星期六晚 - 测试解决方案
手动切换
第一个测试包括一个简单的手动切换测试。一些客户端，包括Outlook 2003、OWA和POP3客户端被启动并连接到Exchange服务器。在切换之前发送了一些测试电子邮件，然后从LifeKeeper GUI启动切换。在切换过程中，通话中断了大约1分半钟。切换完成后，成功地测试了客户端连接。
当地经济复苏
其中一个附带的LifeKeeper特点是本地恢复。此功能允许LifeKeeper的尝试故障切换发生之前本地解决问题。为了测试这个功能，我们只需通过服务控制面板手动停止Exchange信息存储服务。然后，我们验证了LifeKeeper的检测这种故障并没有引起故障自动重新启动该服务。
硬故障转移
最后的测试，另外一个是最重要的，是模拟Exchange服务器的硬故障。测试这类灾害的一种方法是，拉你的服务器上的电源线。有点哄后，管理员同意先走，并做到这一点。由于自动故障转移较早禁用，辅助服务器只是坐在那儿等着我们告诉它投入服务。一旦我们将其纳入服务通过GUI，辅助服务器在一分钟内上线了，没有数据丢失。
蜿蜒而行
手动切换测试和故障转移难这两个测试后，当务之急是我们能够将主服务器上的Exchange重新投入服务。这是通过选择主服务器，并告诉它投入服务，通过LifeKeeper的GUI轻松完成。由于LifeKeeper的意图日志，跟踪复制的卷上的变化，只有当发生了脱机所需的主要服务器要同步其被带回联机之前的变化。
测试结果
所有测试都成功完成，故障转移时间总是在不到两分钟内完成。唯一需要的更改是添加一个二级公共DNS MX记录，优先级为20指向EX02，因此在EX01不可用的情况下，EX02将接收所有传入的SMTP电子邮件。
结论
通过对Exchange结合的LifeKeeper，并在灾难恢复站点使用VMware ESX，客户能够满足他的预算和空间的限制之内他的Exchange灾难恢复的RPO和RTO要求以及住宿。通过在DR站点有到位的VMware ESX服务器，客户正在考虑把其他DR服务器到位，而无需购买额外的硬件。
David A. Bermingham, MCSE, MCSA:即时通讯，是SteelEye技术公司的产品管理总监。
了解有关此主题的更多信息
这个故事，“微软交换与VMware ESX服务器和SteelEye LifeKeeper的高可用性”最初是由LinuxWorld-（美国） 。