2012 R2 新增功能：云集成的灾难恢复

Article
10/27/2013

9 篇博客 系列文章的第 7 篇。今天发布的博文是两块内容中的第 2 部分；要阅读前半部分，请单击此处。

过去、现在和未来，我们都在灾难恢复 (DR) 和高可用性 (HA) 解决方案领域不懈努力，并且已经取得了一些成绩。不过，有一个问题始终摆在我们的面前，对于那些真正建立了可靠 DR 解决方案的所有企业而言，这个成本高得令人难以置信。事实上，太高的成本一直令人望而却步；可以这么说，完整的 DR 解决方案属于仅为大型企业而打造的奢侈品。

通过不懈地努力应对挑战、解决问题，为各行各业提供方便易用、经济实惠的解决方案 — 在加入之前，Microsoft 的卓越成即令我敬佩，在此工作之后，这种敬佩有增无减。

借助 Windows Server 2012 R2、Hyper-V 副本和 System Center 2012 R2，我们已经提供面向大众的 DR 解决方案。

这种 DR 解决方案完美地例证了云改变一切。

由于 Windows Azure 提供全局性的高可用性云平台以及一个可以充分利用 HA 功能的应用程序体系结构 – 您可以基于随时、随地可用的 Azure 构建应用。这种功能正是我们决定在 Azure 上为 DR 解决方案构建控制面板或管理控制台的原因。始终可以获取执行测试、计划内或计划外恢复所需的控制面板和所有元数据。这意味着您不必进行巨大的投资，而在过去，要构建高可用性平台以承载 DR 解决方案，则必须进行巨大的投资 – 现在Azure 可以自动提供所需的一切。

（顺带说明一下，以后您准备构建的所有新应用程序都应依赖 Azure －我们将在下周的 R2 博文中开始讲述这个具体的主题。）

借助这一 R2 系列的产品，世界各地的各种规模和成熟程度的组织，现在都可以从简单而经济高效的 DR 解决方案受益。

我为之特别自豪的还有另外一点：与大多数组织一样，我们经常比照竞争对手而调整我们自身的基准。我们采用了各种指标，比如：“我们是否更易于部署和运营？”以及“我们是否以更低的价格带来了更多价值？”类似这些的衡量指标提供了非常明确的答案：就 DR 而言，我们已经把竞争对手远远地抛在了身后。

在 R2 开发过程中，我注意到了一项并列比较，为 500 台虚拟机设置 DR 所需内容，将我们的解决方案与竞争对手的产品进行比较，对比结果令人震惊。各项设置的简单性和所需的总时间量的差异非常显著。在 DR 应用场景中，一个有趣的衡量单位是总鼠标点击量。执行点击量计算非常简单（呵呵，我们毕竟都是工程师！）。在并列比较中，差异为 10 数量级的鼠标点击量与 100 数量级的鼠标点击量。从字面意思上说，这是分钟数与天数的差别。

您可以在此处阅读我已分享的有关 DR 的一些其他观点。

在昨天的博文中，我们了解了 R2 中新的混合网络功能（如果尚未看到，请务必阅读），在本篇博文中，Vijay Tewari（Windows Server 和 System Center 首席程序经理）将深入介绍此 DR 解决方案的体系结构，以及这种解决方案的部署和工作原理。

与本 2012 R2 系列中的其他博文一样，您可以在本博文结尾处“后续步骤”下查看指向各种工程内容的链接，其中包含本博文中所介绍概念的深度技术概述。

* * *

灾难恢复 (DR) 解决方案的部署历来非常昂贵且复杂。它们需要广泛的配置，而且不能在云级别正常进行。由于当前的解决方案因成本和复杂性而无法解决许多 DR 需要，需要保护的工作负荷容易遭受攻击，这使企业面临各种合规和审计违规问题。而且，由于其中的许多解决方案使用来自多个供应商的组件而构建，通过单一管理窗格提供简单性的尝试几无可能。

为了满足这种需求，Microsoft 通过提供 Hyper-V 副本 (HVR) 作为 Windows Server 2012 中的一项标准功能，着手开始解决这些问题。从进入市场之时起，业内评论专家和客户见证了 HVR 的价值，并且一致将其排在整个版本的“10 大功能”之列。

在 R2 版本中，我们通过提供针对 DR 的云集成解决方案，延续了这一成功。这种解决方案实现了可变的复制频率，并且支持几近同步和扩展复制，打造了 Windows Server 2012 R2 HVR 中的一些关键增强功能。从管理的角度，我们通过与 System Center Virtual Machine Manager (VMM) 相集成的 Windows Azure Hyper-V Recovery Manager(HRM) 提供 DR 解决方案。HRM 目前处于限制预览阶段，在不久的将来将会广泛发布。

HRM 的唯一关注重点是通过在任意位置可供任何人使用来实现灾难恢复的大众化。HRM 建立在世界一流的 Windows Server、System Center 和 Windows Azure 的软件基础之上，用户可以通过 Windows Azure 管理门户获得。RM 与提供数据保护或备份的 Windows Azure Backup (WAB) 相结合，完善了 Windows Azure 中的“恢复服务”产品。欲了解有关 WAB 的更多内容，请阅读本篇博文。

我们希望解决的关键应用场景是提供简单的、易于部署的和便于操作的 DR 解决方案，这种解决方案提供以下优势：

将来自不同站点的“VMM 云”配对以便进行灾难恢复。
为通过 VMM 部署的虚拟机提供 DR。
在主站点和辅助站点之间建立关系。
客户能够标记他们想要复制的虚拟机。
提供适合数据复制的箱内功能 (HVR)。
提供业务流程引擎，这种引擎便于创建 DR 计划，该计划可以指示关机序列，并在测试、计划内或计划外调用 DR 计划的情况下启动虚拟机的 DR 计划。
提供基于云的服务，为操作 DR 提供业务流程和管理体验。

DR 解决方案有五大关键宗旨：

1) 简化部署和操作

DR 软件自身容易受到灾难的攻击，可能会导致数据中心瘫痪。我们需要确保提供 DR 的核心功能本身具有高度可用性、灵活性，而且不会因导致客户工作负荷出现故障的相同原因而自身出现故障。本着这些原则，我们的解决方案 (HRM) 的控制面板以我们称之为 DRaaS（灾难恢复即服务）的云服务的形式提供。HRM 一直作为一项在 Windows Azure 上运行的高度可用的服务。

从操作的角度而言，不论您管理哪个站点，只有在单独的位置（例如 HRM 门户）才需要采取恢复操作。由于业务流程所需的元数据驻留在云中，可以确保防止丢失至关重要的 DR 业务流程指令（即使主站点受到影响），从而解决监控系统监控自身时发生的常见错误。

通过在任意位置可以安全地访问 DR 计划，HRM 显著减少了企业在启动灾难恢复时通常损失的时间。客户 DR 计划可能涉及多个站点。HRM 管理多个站点，以及复杂的站点间关系，从而使客户能够创建综合的 DR 计划。在部署方面，HRM 只需要每个 VMM 服务器安装一个提供程序（单个 VMM 服务器可以管理 1,000 个虚拟主机），从而解决了曾经存在的复杂性问题（当今 DR 部署的一个最重要障碍）。

2) 借助 VMM 大放异彩

HRM 建立在 Virtual Machine Manager (VMM) 的基础之上，充分利用了构造管理员在拓扑和管理配置方面进行的现有投资。通过利用现有的数据中心智能，HRM 是支持/创建冗余配置或管理多个工具方面的强有力信心保证。通过深入的 VMM 集成，HRM 监控数据中心的环境变化，并对变化作出适当的反应。

3) 在云级别面向所有云工作

HRM 在 VMM 的逻辑抽象层工作，使其成为真正云级别的解决方案。该解决方案从开始之初即建立在云点设计基础之上，它富有弹性，而且可以轻松扩展到大规模的部署。

HRM 全天候可用，原因在于，坦率地说，您并不希望因 DR 解决方案而投资 DR 解决方案。现实是客户具有不同的目标云－私有云、托管云或公有云。设计 HRM 解决方案的目的是在所有云之间提供一致的体验，同时降低为每项新的部署/拓扑而重新培训人员的成本。

4) 应用程序级故障转移

通过脚本支持，HRM 安排应用程序的故障转移，即便在不同应用程序层由异类复制技术进行保护的情况下仍然如此。

例如，您通过 HRM 保护的典型的应用可以具有虚拟化前端，该前端与通过 SQL AlwaysOn 保护的 SQL 中的后端相配对。只需单击一次，HRM 业务流程中的功能便可以无缝地转移这些应用程序的故障。

5) 采用可扩展体系架构的服务方法

精心设计的 HRM 解决方案可以提供可扩展的体系架构，这样，它可以在未来实现其他应用场景，并且确保合作伙伴可以丰富、扩展或增加这些应用场景（例如更新的存储类型、更多恢复目标等）。随着部署复杂性的不断增加，以及系统灾难逐渐变得司空见惯，DR 解决方案必须能够及时应对这种新的局面。服务方式可以确保我们可以让这些创新以前所未有更快的速度惠及客户。

考虑到这些优点，您应推广该解决方案，并且能够在数小时内保护您的首个虚拟机！

下面的部分分析如何实现这些宗旨。

体系架构

HRM 服务托管于 Windows Azure 中，并且安排在构建于 Windows Server 和 System Center 的 Microsoft 云堆栈之上的私有云之间。HRM 支持 Windows Server 2012/Windows Server 2012 R2 以及 System Center 2012 SP1、System Center 2012 2012 R2 VMM。

下图描述了该服务的高级体系架构。服务本身托管在 Windows Azure 中，安装在 VMM 服务器上的提供程序向服务发送私有云的元数据，然后使用它来安排私有云中资产的保护和恢复。这种体系架构可以确保防止 DR 软件蒙受灾难。

由于此 DR 解决方案的关键目标是扩展性，因此，发送数据的复制通道具有高度灵活性。如今，复制通道支持 Hyper-V 副本。

在这种体系架构中，重要的是要注意为实现安全性而进行的大量投资：

应用程序数据始终在通道上传输。对某些客户而言，监管合规需要应用程序数据驻留在数据中心的范围内，并且为了适应这些情况，DR 解决方案的设计使应用程序数据不会进入 Windows Azure。只有业务流程需要的元数据（比如逻辑云、虚拟机、网络等的名称）才被发送至 Azure。然后，甚至向 Azure 发送或发送自 Azure 的所有流量均被加密。应用程序数据直接从主站点发送至辅助站点。
标准 HTTPS 规则：安装在 VMM 服务器上的 HRM 提供程序与 Azure 通信，而不是相反，从而去除了防火墙的任何自定义配置。
不存在 Hyper-V 主机风险。相反，该体系架构仅要求 VMM Server 与 Azure 进行通信。因此，Hyper-V 主机不需要连接互联网。
支持代理。本着以上要点，逻辑问题是 VMM Server 是否必须直接连接到互联网？答案是否。VMM Server 可以位于代理后面，从而实现更高的安全性，而 HRM 将在您选择正确的注册选项之后，继续无缝地工作。
选择性地发布元数据。如果您不想向 VMM 中的某些云提供保护，该体系结构支持不向 Azure 发送这些元数据。这可以通过取消选中单复选框来完成。

解决方案概述

HRM 解决方案的目标是在数小时内对您的工作负荷实现保护。您可以在此处查看此操作的“如何操作”步骤。现在我们了解一下如何规划、推广和使用 HRM。

在开始设置 HRM 之前，您应首先从容量、拓扑和安全性的角度来规划部署。在早期配置阶段，您应映射主站点和辅助站点的资源，从而在故障转移期间，辅助站点可以提供实现业务连续性所需的资源。之后，您应保护虚拟机，然后创建用于故障转移的业务流程单元。最后，测试并进行故障转移。

在了解这些阶段之前，我们介绍一些注意事项

衡量 DR 解决方案有两个重要因素
1. 恢复点对象 (RPO)，例如能够容忍的数据损失数量。
2. 恢复时间目标 (RTO)，在发生灾难的情况下工作负荷重新正常运行所花费的时间数量。
为了进行说明，我们来看以下示例：

- VMM-NewYork 管理位于纽约的一个拥有金牌云的站点
- VMM-Chicago 管理位于芝加哥的一个拥有金牌云恢复的站点
- NewYork（主站点）的虚拟机被复制到 Chicago（辅助站点），从而受到保护。

以上面的为例，下面介绍如何规划 HRM 部署：

部署

要部署该解决方案，需要下载单独的提供程序，并完成 NewYork 和 Chicago 中的 VMM Server 的小型向导。从 Windows Azure 门户的“恢复服务”选项卡下载提供程序。

然后，服务可以为 Hyper-V 在主站点上托管的工作负荷安排 DR。在 VMM 环境中运行的提供程序与 HRM 服务进行通信。不需要其他代理、软件和复杂的配置。

计算和内存

要映射计算和内存的资源，您应对表示 VMM 的逻辑云的“受保护项目”进行配置。例如，要通过 VMM-Chicago 的金牌恢复保护位于 VMM-NewYork 的金牌云云，您应选择简单配置的值，比如复制频率。您需要确保金牌恢复云的容量应满足在金牌云中保护的虚拟机的 DR 要求。

完成此操作之后，系统接管任务并执行大量的提升。系统采用所需的证书和防火墙规则配置金牌云和金牌恢复云中的所有主机－并为群集和独立主机配置 Hyper-V 副本设置。

下图说明了相同的流程，其中主机已配置。

请注意，门户中的“受保护项目”选项卡中显示了属于计算和内存资源的云。

网络

一经将云配置为受保护之后，接下来的任务是网络映射。作为初始 VMM 部署的一部分，您已经在主站点上创建了网络，并在恢复站点上创建了相应的网络，现在可以在服务站点上映射这些网络。

可以采用多种方法使用这些映射：

通过增加 VMM 放置逻辑在辅助站点上执行虚拟机的智能放置。例如，当在辅助站点上创建副本虚拟机时，虚拟机副本将放置在对所有所需网络具有必要访问权限的主机上。
故障转移期间，虚拟机被连接至正确的网络，然后启动。这可以确保真正意义上的业务连续性，因为工作负荷不但启动和运行，而且客户端也可以访问这些工作负荷。
如果您使用的是静态 IP（而且很有可能属于这种情况），服务将保留虚拟机的 IP 地址，并在故障转移时将相同的 IP 地址注入虚拟机。因此，不需要手动步骤即可将 IP 地址注入每个虚拟机。

网络映射适合整个网络 – VLAN 或 Hyper-V 网络虚拟化。它甚至适合异类部署，在此情况下，主站点上的网络站点和恢复站点上的网络属于不同的类型。

下图说明了多租户金牌云的租户网络，该网络与多租户的金牌恢复云的租户网络相映射– 副本虚拟机因这种映射关系而附加于相应的网络。例如，营销的副本虚拟机附加于网络营销恢复，原因在于 (a) 主虚拟机连接至网络营销，(b) 网络营销反过来与网络营销恢复相映射。

恢复计划 (RP)

自动恢复具有恢复计划，这种业务流程构造支持依赖性组和自定义操作。如今，组织会创建详细描述灾难恢复步骤的文档。这些文档难以维护，即使有人努力确保更新这些文档，但容易出现因执行这些计划的人员的人为错误而造成的风险。

RP 彰显了我们“简化业务流程”的目标。对于 RP，数据显示在恢复计划视图中，以便帮助客户符合合规/审计要求。例如，在快速概览中，客户可以确定计划的最后一次测试故障转移，或者多久以前执行了恢复计划的计划内故障转移。

恢复计划适合所有 3 种类型的故障转移，即测试故障转移、计划内故障转移和计划外故障转移。在恢复计划中，组中的所有虚拟机一起进行故障转移，从而提高 RTO。在各个组之间，故障转移按顺序进行，从而保留依赖关系－组 1 后面是组 2，依次类推。

在恢复时，根据客户需要和专业知识而呈现连续性（如下面的时间表中所示）。

第 1 天：客户执行虚拟机的测试故障转移。
第 5 天：完成之后开始创建应用程序的恢复计划，并定义 RP 中的虚拟机；单击将放弃整个列表。
第 7 天：将虚拟机迁移到具有依赖关系的组中。
在虚拟机的故障转移之前、期间或之后的各个阶段，您的应用需要某些额外的步骤。
第 10 天：到此时， 您应增加手动操作，例如更新 DNS 条目。当您按照这些手动步骤转移故障时，由作业所提供的详细的RTO分析报告将会显示某些任务（比如手动操作）进行的时间过长，从而无法满足您的合规要求规定。
第 15 天：用脚本代替某些手动步骤。现在，您更加接近 DR 业务流程的精髓。

DR 演练

组织出于各种目的而使用 DR 演练（在解决方案中称为测试故障转移），例如合规原因、按角色通过模拟运作来培训员工、验证系统补丁等。

HRM 利用 HVR 和 VMM 中的网络支持来简化 DR 演练。在大部分 DR 解决方案中，演练既会影响生产工作负荷，又影响工作负荷保护，使得测试难以进行下去。HRM 对二者均没有影响，使常规测试成为可能。

为了自动提高测试的质量，并且帮助客户真正注重测试应用程序，系统关注许多背景任务。DR 演练采用正确的模式创建所需的测试虚拟机。

从网络的角度而言，运行测试故障转移可以采用以下选项：

无网络： 当您仅想测试复制通道时，可以选择此选项。
现有虚拟机网络： 如果已经创建了测试虚拟机网络，则可以使用此选项。
逻辑网络： 如果您想让 HRM 创建测试虚拟机网络，可以使用此选项。根据虚拟机参与情况，HRM 服务确定所需的虚拟机网络、创建虚拟机网络，并将虚拟机附加到正确的虚拟机网络。在采用 Windows 网络虚拟化的情况下，网络设置将从副本网络转移到测试网络。

在您表明完成 DR 演练之后，系统清除所创建的一切内容。

计划内故障转移 (PFO)

在下面的案例中，您需要进行计划内故障转移。组织的某些合规要求规定，工作负荷向恢复站点的故障转移每年进行两次，然后在恢复站点上运行工作负荷一周时间。典型的应用场景是主站点需要进行一些维护，以防止应用程序在该站点上运行。

为了帮助客户满足这些应用场景的要求，HRM 通过业务流程工具 RP 为计划内故障转移提供一流的支持。作为 PFO 的一部分，虚拟机将关闭，并发送最后一次更改，以确保零数据丢失，然后在恢复站点上按顺序启动虚拟机。

PFO 之后，您可以通过反向复制重新保护虚拟机，在此情况下，复制按另外的方向进行 – 从 VMM-Chicago 至 VMM-NewYork。完成维护或者满足合规目标之后，采用系统的方式执行 PFO，以便返回 VMM-NewYork。只需单击一次，即可按相反的方向执行计划内故障转移的故障回复操作。

计划外故障转移

与保险颇为相似的是，我们希望客户永远不需要使用计划外故障转移！但是，在自然灾害等偶然情况下，计划外故障转移可以确保指定的应用程序持续正常工作。在进行计划外故障转移的情况下，万一其中的一些虚拟机在灾害袭来时仍然运行，HRM 将会尝试关闭主要机器。然后，按照 RP 自动在辅助站点上执行恢复。

尽管作出了一切准备，但在灾害期间，事情仍然会变得糟糕。因此，计划外故障转移可能在首次尝试时不会取得成功，从而需要更多的反复性工作。在解决方案中，您可以重新运行相同的作业，从已经成功完成的最后一项任务重新开始。

与在 PFO 中的情况类似，在计划外故障转移之后，只需单击一次，即可按相反的方向执行计划外故障转移的故障回复。在这些操作中，涉及的是一种系统行为。

各种拓扑

拓扑随着组织的发展、部署复杂性、环境变化等因素而演变。与其他解决方案不同，HRM 使得采用统一的方式管理各种不同的拓扑成为可能。这方面的示例包括双向主动保护，在此情况下，纽约站点为芝加哥站点提供保护，反之亦然，许多站点被一种复杂的关系所保护，或者多个分公司由一个总部提供保护。当无法从主站点运行工作负荷时，这可以毫无保留地充分利用辅助站点的容量。

监控

DR 解决方案特别需要简单、可扩展的监控。HRM 通过为正确的作业提供正确的视图而实现这一目标。例如，当用户对 HRM 门户采取安装基础结构的操作时，HRM 识别该用户将会监控门户，以确保操作取得成功。因此，门户的“作业”选项卡中呈现丰富的视图，以便帮助此用户监控正在进行的作业，并对等待操作的作业采取相应的措施。另一方面，当用户没有主动监控门户且系统需要引起注意时，可以通过 Operations Manager (SCOM) 中的集成来提供监控。

下表描述了这种连续性，并且说明了如何满足用户的所有要求的监控需求。

由于所有 DR 任务都是长期性的，可以通过系统来创建工作流。我们构建了丰富的作业框架，帮助您监控作业、查询以前的作业并导出作业。您可以导出作业以保持审计账簿完全一致，并且跟踪恢复计划的 RTO，以便帮助作业报告任务级的时间粒度。

VMM 拓扑

首先，高度可用的或 HA VMM 是建议的适合 VMM 的部署，它可以防止因主站点和辅助站点上的 VMM 维护/补丁而导致的停机时间。HRM 可以在此情况下无缝地工作：您可以将 VMM 服务从一个 VMM 服务器故障转移到另一个 VMM 服务器，而且管理和业务流程也将无缝地进行故障转移。

其次，还有一种应用场景是用户使用一个 VMM 管理两个站点－主站点和辅助站点。这种应用场景的一个示例是当一名管理员管理两个站点时（而且这些站点恰好相互接近），因此，需要在一个控制台中了解两个站点的虚拟机。HRM 支持单独的 VMM 应用场景，实现同一 VMM Server 管理云的配对。

请注意，在主站点完全失灵的情况下，客户必须在辅助站点上恢复 VMM Server，然后才能继续操作。VMM 在辅助站点上启动之后，其他的工作负荷可以被故障转移。