NetApp Tech OnTap
     

圆桌会议:借助 VMware SRM 和 NetApp
实现 Microsoft 应用程序的灾难恢复

2010 年 2 月,Tech OnTap 发表了一篇专题文章,介绍了使用 VMware®、NetApp® 和 Cisco 技术实现 Microsoft 应用程序虚拟化。来自 VMware 的 Wen Yu 和来自 NetApp 的 Larry Touchette 接受了 Tech OnTap 的采访,接着这篇文章继续深入探讨 Microsoft® 应用程序的灾难恢复的详细内容,并解释 DR 在 VMware/NetApp 环境中采用率较高的原因。

Tech OnTap:人们对于在 Microsoft 应用程序环境中广泛采用在线灾难恢复似乎有所顾虑。您认为导致这种现象的因素有哪些?


Wen Yu (VMware):在 VMware,我们通常发现有以下三个主要原因:第一,与执行 DR 相关的成本,这也许是最大的原因。您不仅需要增添设施,还需要许多额外的服务器、网络设备和两倍的存储。无论您使用物理服务器还是虚拟服务器,这些成本都高得惊人。

第二,传统上,执行 DR 极其复杂,在物理服务器环境中尤其如此,尝试在多个应用程序中实施 DR 时更加复杂。您最终可能使用混乱的产品和技术组合完成灾难恢复。大量产品也要求您在两端具有几乎相同的配置,这会导致成本增加。

最后,对于许多企业而言,达到足够的 RPO 所需网络带宽可能有所限制。许多 Windows® 商店可能没有必要的带宽,无法进行复制,并且对购买完成复制所需的带宽可能有所顾虑。

NetApp、Cisco 和 VMware 创建的联合解决方案可以解决大量此类问题。

Larry Touchette (NetApp):我想详细阐述一下 Wen Yu 的最后一点,NetApp 和 VMware 显著降低了 DR 的成本和复杂性,因此您可以部署涵盖更多应用程序(如果需要,可以涵盖整个 VMware 环境)的解决方案。通过在 VMware 主存储上使用 NetApp 重复数据删除节省资金,某些联合客户已能够抵消甚至完全有能力购买 DR 环境的存储。经常阅读 Tech OnTap 的人都了解 NetApp 重复数据删除与 VMware 结合使用的优势。[若要详细了解 VMware DR 和重复数据删除,本文是个不错的起点。- TOT 编者]

对于带宽节省,NetApp SnapMirror® 技术与 NetApp 重复数据删除结合使用时,仅复制唯一的块,因此非常节省带宽。NetApp 最近向 Data ONTAP® 中添加了 SnapMirror 压缩功能以实现 WAN 加速,让您可以在带宽有限的环境中更高效的工作,最多可使带宽使用量减少 70%(具体取决于数据的可压缩性)。[最近发表的一篇 Tech OnTap 文章中,详细论述了 SnapMirror 压缩技术。- TOT 编者]

在联合 VMware/NetApp 环境中,DR 的采用率非常高。我认为这一较高的采用率是这些因素推动的结果。

TOT:为什么选择在 VMware/NetApp DR 配置中使用 VMware 站点恢复管理器 (SRM)?


Wen Yu:虚拟化应用程序服务器 DR 最关键的部分是执行必要步骤以在 DR 站点连接、清点、重新配置和启动虚拟机。手动执行这些任务非常复杂,并且容易出错,当 VM 具有依赖性,必须按照先后顺序启动时尤其如此。可以编写脚本,以尝试自动执行 DR 过程和解决这些问题,但是脚本通常实施成本高昂,并且难以维护。

站点恢复管理器可以简化整个 DR 过程的管理,包括调查、配置、故障转移和 DR 测试。在 SRM 配置的设置阶段制定的恢复计划允许您预配置整个计划。内置调查功能以及与 vCenter 的紧密集成可以加快此过程。

制定计划之后,可以自动执行计划,只需最少的用户介入。借助 SRM,可以执行所有必要步骤,并以正确的顺序启动虚拟机。例如,可以首先启动支持基础架构(例如 Active Directory® [AD] 和 DNS 服务器)的虚拟机,然后依次启动数据库服务器、应用程序服务器和 Web 服务器。

执行测试的功能是另一个巨大的优势。大多数 DR 解决方案都几乎不可能在不中断正常生产操作和持续复制的情况下执行测试。借助 SRM 和 NetApp,可以轻松高效地执行 DR 测试。例如,您必须创建隔离的测试网络,以避免因疏忽导致每台 VM 在企业网络中存在两个活动实例。SRM 可以自动执行此过程,以便测试保持隔离。

Larry Touchette:如果将 NetApp FlexClone® 技术与 SRM DR 测试结合使用,您可以启动 DR 站点并在该站点执行测试,而无需使用大量额外存储,也不会中断站点之间的持续复制或主站点上的操作。这为您提供了一种简单的方法来执行测试以验证 DR,而不会影响生产站点或已达成共识的 SLA。

某些复制解决方案需要两倍的容量,以在 DR 站点创建存储的副本,以便在执行测试的同时能够继续复制。这样会浪费大量时间,并且会缩短测试环境正常运行的时间或降低执行测试的频率。借助 FlexClone,可以显著减少所需存储量,并加快此过程。

 

图 1) 借助 FlexClone 执行 DR 测试的增量存储要求。

TOT:那么,如果要使用 VMware SRM 和 NetApp 存储部署 DR 解决方案,主要考虑因素有哪些?


Wen Yu:从 SRM 的角度来讲,有许多考虑因素。首先,必须在每个站点上配备 VMware vCenter Server 以及 Microsoft SQL Server(用于存储 SRM 数据库)和运行受支持版本的 ESX 的服务器。

主站点和恢复站点必须通过可靠的 IP 网络进行连接,并且恢复站点有权访问的公共网络和专用网络也应该与主站点相同。最后同样重要的是,恢复站点应配备最新的 Active Directory 和 DNS 服务器。

对于站点之间的实际复制,在这种情况下,SRM 依靠 NetApp 存储实现。运行第 1 层应用程序的客户可以通过将 SnapMirror 配置为同步复制达到零 RPO。除复制之外,在操作系统和应用程序级别保持一致性也非常关键。

Larry Touchette:NetApp 使用许多组件为 VM 本身和 Microsoft 应用程序(Exchange、SQL Server 和 SharePoint Server)提供一致的复制。VM 和应用程序的关键考虑因素是:简单地定期复制数据远远不够,必须处于应用程序一致的状态,以便可以从此状态重新启动每个组件。在最近的一份技术报告中,比较详细地介绍了完整的方法。Wen Yu 审阅了此 TR,以确保我们的 VMware 信息正确无误。

VM 位于共享数据存储库(VMFS [FC 或 iSCSI LUN] 或 NFS)中。NetApp SnapManager for Virtual Infrastructure 可为 VM 数据提供一致的 Snapshot™ 副本和复制。

关键设计要素是通过将应用程序数据存储在物理模式 RDM LUN(iSCSI 或 FC)中,使其与 VM 数据存储库保持分离。这样,我们就可以使用 NetApp SnapManager 产品套件为每个应用程序创建一致的恢复点,也可以为每个应用程序制定不同的复制计划,以通过创建不同数量的恢复点适应不同的 RPO。

 

图 2) 复制架构。

TOT:为了实现从多个恢复点重新启动应用程序,我们做了大量工作。对于此问题,您能为读者再多讲一些吗?


Larry Touchette:适用于 SQL Server、Exchange 和 SharePoint 的 NetApp SnapManager 产品能够创建和验证复制到恢复站点的多个恢复点,从而提高了灵活性。SnapManager 应用程序可以创建完整备份(要验证其是否属于应用程序一致的备份)以及更加频繁的备份(仅包括在完整备份之间发生的更改的增量日志)。这些增量备份称为频繁的恢复点(或 FRP)备份。通过调整 FRP 备份的间隔时间,可以灵活地为每个应用程序单独设置所需 RPO。

如果在恢复站点检测到恢复的应用程序数据存在任何问题,可以将单个应用程序恢复到之前的任何恢复点。如果将应用程序恢复到之前的恢复点,SnapManager 可以前滚任何未提交的数据库日志,以防止丢失执行故障转移之后在恢复站点写入的任何新数据。

借助 SRM,您可以在恢复计划中插入自定义命令。我们使用此功能执行恢复计划中的命令,配置 SnapDrive® 以启用在 DR 站点运行的 VM,以便查看从生产站点复制的备份的完整历史记录。如果您有权访问 NetApp NOW™ (NetApp on the Web) 站点,可以参阅 KB56952,了解此过程更详细的介绍。

TOT:你们二位谁能解释一下 Active Directory 在 SRM 环境中的重要性?


Wen Yu:Microsoft 应用程序高度依赖 Active Directory 和 DNS 执行正确操作,因此在恢复站点对其进行正确配置极为重要。执行 DR 测试时,也必须确保在隔离的测试网络上提供正确配置的最新 Active Directory 服务器。从恢复站点故障恢复到主站点之后,也必须确保正确处理 Active Directory/DNS 服务器。如果不这样做,可能会遇到更新序列号 (USN) 回滚问题和 Active Directory 数据库损坏。在 Microsoft 知识库文章 875495 中,更详细地介绍了这些问题。

为了确保 Active Directory 在恢复站点上正确无误,最简单的方法是让恢复站点上至少一个 Active Directory 服务器与主站点保持同步。

对于 DR 测试,必须在执行 DR 测试之前克隆此 AD 服务器。克隆完成之后,在启动 VM 之前,要确保克隆的 AD 服务器仅连接到 DR 测试网络。在测试网络中启动 AD VM 之后,必须按照 Microsoft 知识库文章 255504 中介绍的步骤,获取 Active Directory 林中的五个 FSMO(灵活单主机操作)角色。

如果发生了真正的故障转移,则不必执行此克隆过程,但是仍然需要获取 FSMO 角色,且必须手动完成。从灾难(无论是什么灾难)中恢复之后,在故障恢复之前,必须在原始站点重建 Active Directory 服务。这可通过在此站点恢复 AD 服务器,并强制这些服务器与恢复站点上较新的 AD 服务器重新同步,或通过建立新的 AD 服务器来完成。

在 Larry Touchette 之前提到的 NetApp TR-3822 中,非常详细地介绍了所有这些操作。

TOT:最后总结一下,你们二位能否都简单讲讲故障恢复到原始站点的方法?


Wen Yu:正如我刚才的建议,原始站点启动并正常运行之后,第一步是启动 Active Directory。SRM 尚不能提供全自动反向和故障恢复,但是我们仍然建议您使用 SRM 执行故障恢复,通过重新配置软件从反方向恢复。

Larry Touchette:为了进行故障恢复,必须使恢复站点与原始站点的数据保持同步。SnapMirror 关系易于反向和重新同步。重新同步过程在某种程度上取决于发生的故障。如果原始存储并未在灾难中损毁,SnapMirror 只需复制增量 - 原始站点脱机时发生的更改。否则,必须完全重新同步。当然,无论在哪种情况下,NetApp 重复数据删除和 SnapMirror 压缩功能都可以降低对 WAN 的影响。重复数据删除通过删除由于相同来宾操作系统存在过多副本而产生的重复数据,可以减少 VMware 环境中的总数据量,而压缩功能可以确保通过 WAN 传输的所有数据都使用最少的带宽。

我们希望从圆桌会议总结的上述信息对您有所帮助,并且我们愿意听取您对本文的宝贵意见。有关所讨论主题完整的详细信息,请参阅 TR-3822

 获得关于借助 SRM 和 NetApp 实现灾难恢复的看法?

请在 NetApp 社区中在线提出问题、
交流观点、分享看法。


Wen Yu
VMware
高级技术联盟经理

Wen Yu 在 VMware 工作已经五年多了,负责持续可用性、灾难恢复和桌面虚拟化产品的支持和推广。目前,他是基础架构联盟技术团队的一名成员。



Larry Touchette
NetApp
技术营销工程师

Larry Touchette 在 NetApp 工作已经九年了,负责 NetApp 存储和灾难恢复解决方案的支持、实施和设计。目前,他是 NetApp 服务器虚拟化技术营销团队的一名成员。