导出 (0) 打印
全部展开

Azure 业务连续性技术指南

更新时间: 2015年3月

作者:Patrick Wickline、Jason Roth

供稿人和审校:Luis Carlos Vargas Herring、Drew McDaniel、David Magar、Ganesh Srinivasan、Milan Gada、Nir Mashkowski、Harsh Mittal、Sasha Nosov、Selcin Turkarslan、Cephas Lin、Cheryl McGuire、Bill Mathers、Mandi Ohlinger、Sidney Higa、Michael Green、Heidi Steen、Matt Winkler、Shayne Burgess、Larry Franks、Brad Severtson、Yavor Georgiev、Glenn Gailey、Tim Ammann、Ruppert Koch、Seth Manheim、Abhinav Gupta、Steve Danielson、Corey Sanders、John Deutscher

为满足高可用性和灾难恢复要求,需要具备两方面的知识:1) 详细了解云平台功能的技术;2) 如何适当地构建分布式服务。本文提供第一方面的信息,即 Azure 平台在业务连续性方面的功能和限制。不过,本文也对体系结构和设计模式有所涉及,但这并不是重点内容。要获得设计方面的指导,读者应当阅读“其他资源”部分中提供的其他材料。

本文信息分为以下章节:

  • 1. 从本地失败恢复:物理硬件(例如驱动器、服务器和网络设备)可能全部出现故障,而负载高峰时可能会耗尽资源。本节介绍 Azure 在这些情况下为保持高可用性而提供的功能。

  • 2. 从 Azure 区域损失恢复:广泛蔓延的故障较为罕见,但也有发生的可能。整个区域可能因为网络故障而受到隔离,或由于自然灾难而受到实体损害。本节介绍如何使用 Azure 的功能创建跨越不同地理区域的应用程序。

  • 3. 从本地恢复到 Azure:云极大地改变了灾难恢复的经济体系,使组织能够利用 Azure 来建立辅助站点进行恢复。这可以通过花费一部分成本构建和维护辅助数据中心来进行。本节说明 Azure 在将本地数据中心扩展到云方面提供的功能。

  • 4. 从数据损坏或意外删除恢复:应用程序可能有导致数据损坏的 Bug,操作人员可能错误地删除了重要数据。本节说明 Azure 在备份数据和恢复到先前时间点方面提供的功能。

  • 5. 其他资源:其他介绍 Azure 可用性和灾难恢复功能的重要资源。

应用程序可用性主要面临两大威胁:设备(如驱动器和服务器)故障以及在高峰负载情况下关键资源耗尽(如计算资源)。Azure 组合提供一套资源管理、弹性、负载平衡和分区功能,可在这些情况下实现高可用性。上述某些功能会对所有云服务自动执行;但在某些情况下,应用程序开发人员必须完成额外的工作,方可从这些功能中获益。

所有由 Azure 托管的云服务都是一个或多个 Web 角色或辅助角色的集合。特定角色的一个或多个实例可以并发运行。实例的数量由配置决定。角色实例由名为结构控制器 (FC) 的组件进行监视和管理。FC 会自动检测和响应软件和硬件失败。

  • 每个角色实例都在自已的虚拟机 (VM) 中运行,并通过来宾代理 (GA) 与其 FC 通信。GA 会收集资源和节点指标,包括 VM 使用状况、状态、日志、资源使用状况、异常和失败情况。FC 将按照可配置的间隔查询 GA,并在 GA 未能响应时重启 VM。

  • 如果发生硬件失败,关联的 FC 会将所有受影响的角色实例移到新的硬件节点,并配置网络将流量路由到该节点。

要从这些功能中受益,开发人员应确保所有服务都不在角色实例上存储状态。相反,所有永久性数据都应从持久存储访问,如 Azure 存储服务或 Azure SQL Database。这样,任何角色都能对请求进行处理。这也意味着,角色实例可以随时停止,却不会造成服务暂时状态或永久状态的不一致。

将状态存储在角色外部的要求具有几个含义。例如,这意味着对 Azure 存储表的所有相关更改,如果可能,将在单一实体组事务中进行。当然,在单一事务中进行所有更改并非始终都可能。请务必多加留心,从而确保在角色实例失败中断长期运行的操作、而这种操作包括两个或多个对服务永久状态的更新时,这些失败不会产生问题。如果另一个角色尝试重新执行此类操作,它应预期并处理只有部分工作完成的情况。

例如,有一项服务将数据分区存储在多个存储中,如果辅功角色在重定位分片时关闭,则分片重定位可能不会完成,或可能由另一个辅助角色重复,而这可能引起数据孤立或数据损坏。为防止出现问题,长期运行的操作必须为幂等操作(即可重复却无副作用)和/或能以增量方式重启(即可从最近的失败点继续)。

  • 要成为幂等操作,长期���行的操作无论执行多少次都应具有相同的效果,即使在执行过程中中断也是如此。

  • 要能以增量方式重启,长期运行的操作必须由一连串小型的原子操作组成,且应当在持久存储中记录其进度,从而使每个后续调用能够从其前任停止的位置接续。

最后,所有长期运行的操作都应被重复调用,直到操作成功为止。例如,辅助角色可能会将设置操作放入 Azure 队列中,并且只有在操作成功时才能将它从队列中删除。可能有必要进行垃圾收集,来清理已中断操作创建的数据。

为每个角色运行的初始实例数量由每个角色的配置决定。管理员应根据预期负载,将每个角色初始配置为运行两个或多个实例。但是,角色实例数可以随着使用模式的更改轻松地扩大或缩减。这可以通过 Azure 门户、Windows PowerShell、服务管理 API 或第三方工具来完成。FC 会自动配置所有新实例,并将它们插入该角色的负载平衡器中。

使用 Azure 自动缩放(预览),你可以让 Azure 根据负载自动缩放角色。还可以使用自动缩放应用程序块 (WASABi) 这样的框架,以编程方式为云服务内置和配置自动缩放。

FC 使用两种分区:升级域和故障域。

  • 升级域用于以组的方式升级服务的角色实例。Azure 会将服务实例部署到多个升级域中。对于就地升级,FC 会停止一个升级域中的所有实例,升级这些实例,然后重启这些实例,接下来将它们移到新的升级域中。这种方法能够避免整个服务在升级期间无法使用。

  • 容错域定义硬件或网络的潜在失败点。对于任何角实例数超过一个的角色,FC 会确保这些实例分布在多个容错域上,从而避免个别的硬件失败打断服务。Azure 中所有服务器和群集失败的风险都由容错域管理。

根据 Azure SLA,Microsoft 保证在有两个或多个 Web 角色实例部署到不同的容错域和升级域时,它们将有至少 99.95% 的时间具有外部连接性。与更新域不同的是,没有办法控制容错域的数量。Azure 会自动分配容错域,并将角色实例分布到这些容错域中。至少应将每个角色的前两个实例放在不同的容错域和更新域中,以确保至少有两个实例的任何角色都能满足 SLA。这如同以下图表所示。

错误域隔离(简化视图)

某个 Web 角色的所有入站流量都会通过无状态负载平衡器,由负载平衡器将客户请求在角色实例间分配。单个角色实例没有公共 IP 地址,无法直接从 Internet 访问。Web 角色是无状态角色,所以可将任何客户端请求路由到任何角色实例。每隔 15 秒会引发一次 StatusCheck 事件。这可用来指示角色是否已准备好接收流量,还是仍在忙碌,应当从负载平衡器轮换中脱离。

就高可用性而言,Azure 虚拟机在许多方面与 PaaS 计算角色有所不同。在某些情况下,你必须完成额外的工作才能确保高可用性。

与 PaaS 角色实例不同,即使虚拟机位置改变,虚拟机驱动器中存储的数据仍会保存下来。Azure 虚拟机使用以 Blob 形式存在于 Azure 存储中的 VM 磁盘。由于 Azure 存储的可用性特征,存储在虚拟机驱动器上的数据也具有高度的可用性。请注意,D:驱动器是此项规则的例外情况。D:驱动器实际是承载 VM 的机架服务器的物理存储,如果回收 VM,其中的数据就会丢失。D:驱动器只能用作临时存储。

Azure 天生了解 PaaS 应用程序(Web 角色和辅助角色)中的各个层,因此能够正确地将它们分布在容错域和更新域上。相反,必须使用可用性集手动定义 IaaS 应用程序中的层。IaaS 需要使用可用性集来符合 SLA 要求。

Azure VM 的可用性集

在上面的图表中,IIS 层和 SQL 层分配给不同的可用性集。这确保将每一层的所有实例分布在各容错域上,以使所有实例都具有硬件冗余,在更新期间不会被关闭。

如果应当在各 VM 间分布流量,必须将云服务中的 VM 分组,并对特定的 TCP 或 UDP 端点进行负载平衡。有关更多信息,请参阅虚拟机负载平衡。如果 VM 接收来自其他来源(如排队机制)的输入,则不需要负载平衡器。负载平衡器使用基本运行状况检查来确定是否应将流量发送到节点。你也可以创建自己的探查,实现应用程序特定的运行状况指标,来确定 VM 是否应接收流量。

Azure 存储是 Azure 的基准持久数据服务,可提供 Blob、表、队列和 VM 磁盘存储。它组合使用复制和资源管理,在单个数据中心内提供高可用性。Azure 存储可用性 SLA 保证至少 99.9% 的时间内能够成功且正确地处理格式正确的请求,以添加、更新、读取和删除数据,而存储帐户也可连接 Internet 网关。

Azure 存储数据持久性形成的方式,是在区域内完全独立的物理存储子系统中的不同驱动器上维护所有数据的多个副本。数据会进行同步复制,然后提交所有副本,之后才会承认写入操作。Azure 存储具有坚实的一致性,保证读取会反映最新写入的内容。此外,系统会对数据副本进行连续扫描,以检测和修复位衰减,在所存储数据的完整性方面,这是一种经常会被忽略的威胁。服务只要使用 Azure 存储,便会因复制而受益。服务开发人员不需要完成任何额外工作,即可从本地失败恢复。

2012 年 6 月 7 日之后创建的存储帐户最高可以增长至 200 TB(以前的最大值为 100 TB)。如果需要额外的空间,必须将应用程序设计为利用多个存储帐户。

虚拟机的 VM 磁盘作为页 Blob 存储在 Azure 存储中,因此它与 Blob 存储具有完全相同的持续性和可伸缩性。采用这种设计,即使运行 VM 的服务器失败,必须在另一台服务器上重启该 VM,虚拟机磁盘上的数据仍会得以保存。

Microsoft Azure SQL Database 提供数据库即服务,使应用程序可以快速配置和查询关系数据库,并在数据库中插入数据。它提供许多熟悉的 SQL Server 功能,同时减少了硬件、配置、修补和复原方面的负担。

note备注
Azure SQL Database 不提供与 SQL Server 完全相同的功能,目的是为了满足一组特别适合云应用程序的不同要求(弹性缩放、可减少维护成本的数据库即服务等)。有关详细信息,请参阅数据序列:Azure 虚拟机中的 SQL Server 与 SQL Database

Azure SQL Database 对节点级失败提供内置的复原功能。所有写入数据库的内容会使用仲裁提交技术自动复制到两个或多个背景节点(主要副本和至少一个辅助副本必须先确认活动写入事务日志,然后才将事务视为成功并返回)。在节点失败时,数据库会自动故障转移到其中一个辅助副本。这会造成客户端应用程序的暂时连接中断。因此,所有 Microsoft Azure SQL Database 客户端都必须实现某种形式的暂时连接处理。有关详细信息,请参阅结合使用暂时性故障处理应用程序块和 SQL Azure

每个数据库在创建时,都配置了大小上限。当前可用的最大大小为 150 GB。当数据库达到大小限制时,它会拒绝其他 INSERT 或 UPDATE 命令(仍然可以查询和删除数据)。

在数据库内,Microsoft Azure SQL Database 使用结构来管理资源。但是,它不使用结构控制器,而是使用环形拓扑来检测失败。群集中的每个副本都有两个相邻副本,并负责检测这两个副本何时停止。当某个副本停止时,它的相邻副本便会触发重新配置代理 (RA),在另一台计算机上重新创建该副本。引擎限制可确保逻辑服务器不会在一台计算机上使用过多资源,或超过计算机的物理限制。

如果应用程序需要超过 150 GB 的数据库,它必须实现扩展方法。使用 Microsoft Azure SQL Database 扩展的方法是在多个 Azure SQL Database 上手动分区(也称为分片)数据。这种扩展方法提供了实现成本随扩展呈线性增长的机会。弹性增长(或按需容量)可以根据需求随成本的增加而增长,因为数据库是根据每天实际使用的大小来进行收费,而不是根据最大的可用大小来收费。

通过在 Azure 虚拟机上安装 SQL Server 2014 (IaaS),你可以利用 SQL Server 的传统可用性功能,如 AlwaysOn 可用性组或数据库镜像。请注意,与本地的非虚拟化 IT 基础架构不同,Azure VM、存储和网络有着不同的运行特征。需要了解这些区别并设计可适应这些区别的解决方案,才能成功地在 Azure 中实现 HADR SQL Server 解决方案。

在 Azure 中实现高可用性解决方案时,通过 Azure 中的可用性集,可将高可用性节点放入单独的故障域和升级域。在此明确一下,高可用性集是 Azure 中的一个概念。应遵循的最佳实践是确保数据库确实为高度可用,无论使用 AlwaysOn 可用性组、数据库镜像还是其他方法。如果不遵循此最佳实践,则可能会错误地假设系统为高度可用,但实际上节点可能会因碰巧被放置在 Azure 数据中心内的同一故障域中而同时全部出现故障。此项建议不适用于日志传送,因为作为灾难恢复功能,你应当确保服务器在单独的 Azure 数据中心位置(区域)运行。根据定义,这些数据中心位置是不同的容错域。

若要将 Azure 虚拟机放入同一可用性集,必须将这些虚拟机部署到同一云服务中。只有同一云服务中的节点可加入同一可用性集。此外,VM 应位于同一 VNet 中,以确保它们在服务修复后仍能保持其 IP,从而避免 DNS 更新时间。

可使用 AlwaysOn 可用性组或数据库镜像,为你在 Azure 中的 SQL Server 数据库提供高可用性解决方案。

以下图表说明了 Azure 虚拟机中运行的 AlwaysOn 可用性组的体系架构。本图表摘录自 Azure 虚拟机中的 SQL Server 高可用性和灾难恢复这篇深入探讨该主题的文章。

Windows Azure 中的 AlwaysOn 可用性组

你还可以在 Microsoft Azure 门户中使用 AlwaysOn 模板在 Azure VM 上自动设置 AlwaysOn 可用性组的端到端部署。有关详细信息,请参阅 Microsoft Azure 门户库中的 SQL Server AlwaysOn 产品

以下图表说明了 Azure 虚拟机上使用数据库镜像的情况。它同样摘自 Azure 虚拟机中的 SQL Server 高可用性和灾难恢复这篇深入探讨该主题的文章。

Windows Azure 中的数据库镜像
note备注
请注意,以上两种体系结构都需要域控制器。但是,数据库镜像也可以使用服务器证书,从而不再需要域控制器。

Azure 云服务在 Azure 上构建,因此它们可以受益于前文所述的平台功能,以从本地失败中恢复。在某些情况下,你可以采取某些特定操作来增加特定情况下的可用性。

访问控制服务 (ACS) 2.0 每天备份一次所有命名空间,并将它们存储在安全的异地位置。当 ACS 操作人员确定某个 ACS 区域数据中心发生了不可恢复的数据损失时,ACS 会通过从最新备份还原来尝试恢复客户的订阅。由于备份的频率限制,数据损失量最多为 24 小时内的信息。有关详细信息,请参阅访问控制服务(灾难恢复)

要防范 Azure 服务总线的临时中断,请考虑创建一个持久的客户端队列。这会临时使用备用的本地存储机制,来存储无法添加到服务总线队列的消息。应用程序可以在还原服务后再决定如何处理临时存储的消息。有关详细信息,请参阅使服务总线应用程序免受服务总线服务中断和灾难的影响。有关详细信息,请参阅服务总线(灾难恢复)

关于 Azure 移动服务,有���项可用性注意事项。首先,请定期备份与移动服务关联的 Azure SQL Database。其次还要备份移动服务脚本。有关详细信息,请参阅在灾难发生时恢复移动服务。如果移动服务经历暂时中断,你可能必须临时使用备用 Azure 数据中心。有关详细信息,请参阅移动服务(灾难恢复)

与 HDInsight 关联的数据默认存储在 Azure Blob 存储中,这种存储具有 Azure 存储的高可用性和持久性特点。与 Hadoop MapReduce 作业关联的多节点处理是在 HDInsight 根据需要设置的暂时性 Hadoop 分布式文件系统 (HDFS) 上完成。MapReduce 作业产生的结果默认也存储在 Azure Blob 存储中,所以在取消 Hadoop 群集的设置后处理过的数据仍具有持久性且仍然高度可用。有关详细信息,请参阅HDInsight(灾难恢复)

 

服务/领域 清单

计算 (PaaS)

  • 为每个角色至少配置两个实例。

  • 将状态保存在持久存储中,而不是角色实例上。

  • 正确处理 StatusCheck 事件。

  • 尽可能将相关更改包装在事务中。

  • 确认辅助角色任务具有幂等性且可重新开始。

  • 持续调用操作,直到操作成功为止。

  • 考虑采用自动缩放策略。

虚拟机 (IaaS)

  • 切勿使用 D:驱动器作为永久存储。

  • 将服务层的计算机分组为可用性集。

  • 配置负载平衡和可选探查。

存储

  • 在数据或带宽超过配额时,使用多个存储帐户。

SQL Database

  • 实现重试策略以处理暂时错误。

  • 使用分区/分片作为扩展策略。

虚拟机上的 SQL Server 2014 (IaaS)

  • 按照上述有关虚拟机的建议操作。

  • 使用 SQL Server 高可用性功能,如 AlwaysOn。

访问控制服务(可用性)

  • 对于本地失败无需采取其他可用性步骤。

服务总线(可用性)

  • 考虑创建持久客户端队列作为备份。

移动服务(可用性)

  • 定期备份与移动服务关联的 Azure SQL Database。

  • 备份移动服务脚本。

HDInsight(可用性)

  • 对于本地失败无需采取其他可用性步骤。

Azure 在实际上逻辑地划分为称为区域的单位。区域由一个或多个相近的数据中心组成。在撰写本文时,Azure 共有八个区域(北美洲有 4 个,亚洲有 2 个,欧洲有 2 个)。

只有在极少数情况下,才会出现整个区域的设施都无法访问的情况,例如,网络故障或自然灾害等造成的完全失去联系。本节说明可用于创建在各区域间分布的应用程序的 Azure 功能。设计区域的目地是降低一个区域的失败影响到其他区域的可能性。

要将计算实例分布在多个区域上,可在每个目标区域中创建单独的云服务,然后将部署包发布到每个云服务上。但请注意,必须由应用程序开发人员或使用流量管理服务在不同区域的云服务间分布流量。

在容量规则方面,事先确定为实现灾难恢复而部署的备用角色实例数目是其中的重要一环。具有规模完整的辅助部署可确保容量在需要时始终可用,但是,这实际上也会使成本加倍。常见的模式是准备小型的辅助部署,规模足以满足运行关键服务即可。我们建议你至少要建立一个小型辅助部署,同时用于保留容量和测试辅助环境的配置。

note备注
订阅配额并非容量保证。配额只是信用限制。要保证容量,必须在服务模型中定义所需数量的角色,且必须部署这些角色。

要实现各地区流量的负载平衡,需要使用流量管理解决方案。Azure 提供 Azure Traffic Manager。你也可以利用提供类似流理管理功能的第三方服务。

可使用多种备用策略在地区间实现分布式计算。这些策略必须根据特定业务要求和应用程序的情况量身定制。大体而言,方法可分为 3 类:

  • 灾难发生时重新部署:如果采用这种方法,则会在灾难发生时重新部署应用程序。这种方法适合不需要保证恢复时间的非关键应用程序。

  • 暖备份(主动/被动):在备用区域创建辅助托管服务,并部署角色以保证最低容量;但是,角色不会接收生产流量。对于未设计为在区域间分布流量的应用程序来说,这种方法很有用。

  • 热备份(主动/主动):应用程序设计为接收多个区域的生产负载。为每个区域中云服务所配置的容量可能高于 DR 用途所需的容量。或者,云服务可在灾难或故障转移时进行扩展。这种方法需要在应用程序设计中进行大量的投资,但是也具有显著的好处,包括恢复时间更短且更有保证、连续测试所有恢复位置和对容量的有效使用

关于分布式设计的完整讨论不在本文的讨论范围内。以下文章提供了这些场景的详细指导。

IaaS VM 的恢复在许多方面与 PaaS 计算恢复相似,但是,由于 IaaS VM 包含 VM 和 VM 磁盘,所以两者之间也存在一些重要的差异。

  • 使用 Blob 复制 API 复制 VM 磁盘:为了在多个区域创建 VM,必须将 VM 磁盘复制到备用区域。因为 VM 磁盘就是 Blob,所以使用标准 Blob 复制 API 即可进行复制。

  • 将数据磁盘与 OS 磁盘分开:有关 IaaS VM 的一项重要注意事项是:如果你不重新创建 VM,就不能更改 OS 磁盘。如果你的恢复策略是在灾难后部署的,这便不是问题。但是,如果你使用暖备份方法来保留容量,则它可能会成为问题。要正确实现这一点,必须将正确的 OS 磁盘部署到主要位置和辅助位置,而将应用程序数据存储在单独的驱动器上。如果可能,请使用这两个位置均可以提供标准的 OS 配置。在故障转移后,你必须将数据驱动器连接到辅助 DC 中的现有 IaaS VM。可使用 CopyBlob API 将数据磁盘的快照复制到远程站点上。

  • 多个 VM 磁盘地理故障转移后的潜在一致性问题:VM 磁盘是作为 Azure 存储 Blob 实现的,具有相同的地理复制特征(请参阅下文)。可以保证 VM 磁盘在地理故障转移后处于一种崩溃一致的状态,但是,不能保证磁盘间的一致性,因为地理复制是异步进行的,并且是独立复制的。在某些情况下(如在使用磁盘条带化时)可能会产生问题。在这类情况下,需要在地理故障转移后完成额外的工作,以恢复一致性。为确保备份的正确性,应使用 Data Protection Manager 这样的备份产品来进行应用程序数据备份和还原。

在 Azure 中,默认情况下,Blob、表、队列和 VM 磁盘都会进行地理复制。这称为地理冗余存储 (GRS)。GRS 会将存储数据复制到几百英里之外特定地理区域中的配对数据中心。GRS ���于在发生重大数据中心灾难时提供额外的数据耐用性。Microsoft 可以控制何时进行故障转移,并且故障转移仅限于其认为在合理时间内原始主位置无法进行恢复的重大灾难。在某些情况下,这可能需要几天时间。尽管同步间隔在 SLA 中并未提及,但是数据通常在几分钟内完成复制。

在地理故障转移时,不会对访问帐户的方式进行更改(URL 和帐户密钥不会更改),但是,在故障转移后存储帐户将位于另一个区域,这可能会影响需要与存储帐户保持区域关系的应用程序。即使服务和应用程序不要求存储帐户位于相同的数据中心,跨数据中心的延迟性和带宽费用也使暂时将流量移到故障转移区域成为一种明智之举。整体的灾难恢复策略可以考虑此项因素。

除了 GRS 提供的自动故障转移之外,Azure 还推出了一种服务,让你能够对位于辅助存储位置的数据副本进行读取访问。这称为读取访问 - 地域冗余存储 (RA-GRS)。

有关 GRS 和 RA-GRS 预览版的详细信息,请参阅 Azure 存储冗余选项和读取访问地域冗余存储

必须了解地理复制会将数据复制到哪里,这样才能知道,对于要求与存储保持区域关系的数据,应将其实例部署到哪里。下表显示了配对的主要位置和辅助位置:

 

主要 辅助

美国中北部

美国中南部

美国中南部

美国中北部

美国东部

美国西部

美国西部

美国东部

欧洲北部

欧洲西部

欧洲西部

欧洲北部

亚洲东南部

亚洲东部

亚洲东部

亚洲东南部

中国东部

中国北部

中国北部

中国东部

巴西南部

美国中南部

地理复制包括在 Azure 存储的当前定价中,称为地理冗余存储。如果你不想对数据进行地域复制,可以为帐户禁用地域复制。这称为本地冗余存储,将按照地理复制存储的折扣价格收费。

如果发生了地理故障转移,信息会发布到 Azure 服务运行状况仪表板。但是,应用程序可以通过监视其存储帐户的地理区域,来实施自动的检测方法。这可以用来触发其他恢复操作,如激活存储移往的地理区域中的计算资源。可使用获取存储帐户属性从服务管理 API来进行查询。相关的属性包括:

<GeoPrimaryRegion>primary-region</GeoPrimaryRegion>
<StatusOfPrimary>[Available|Unavailable]</StatusOfPrimary>
<LastGeoFailoverTime>DateTime</LastGeoFailoverTime
<GeoSecondaryRegion>secondary-region</GeoSecondaryRegion
<StatusOfSecondary>[Available|Unavailable]</StatusOfSecondary>

  • 如 VM 磁盘一节所述,无法在故障转移后保证各 VM 磁盘之间的数据一致性。为确保备份的正确性,应使用 Data Protection Manager 这样的备份产品来进行应用程序数据备份和还原。

可以利用基本、标准或高级层中的时间点还原实现 Azure Azure SQL Database 的恢复。有关详细信息,请参阅 Azure SQL Database 备份和还原

除了使用时间点还原以外,还可以使用 Azure Azure SQL Database 导入/导出服务手动将数据库导出到 Azure 存储 Blob。可以通过三种方式来实施此复制:

  • 使用不同数据中心中的存储帐户导出到 Blob

  • 使用同一数据中心中的存储帐户导出到某一 blob,并且依赖于 Azure 存储的地理复制功能复制到单独的数据中心。

  • 导入到你的内部 SQL Server。

有关实施详细信息,请参阅 MSDN 文章 Azure SQL Database 中的业务连续性

要将 IaaS 上运行的 SQL Server 数据库恢复到备用 Azure 数据中心,可以使用两个建议的选项:跨区域 AlwaysOn 可用性组,或使用存储 Blob 进行备份和还原。

此外,还可以使用数据库镜像,但 SQL Server 的将来版本中将删除此功能。使用数据库镜像进行灾难恢复时,你必须有在不同 Azure 数据中心运行的主要服务器和镜像服务器。这意味着,你必须使用服务器证书进行部署,因为 Active Directory 域不能横跨多个 Azure 数据中心,除非通过本地网络路由流量。以下图表展示了这种设置。

Windows Azure 中的数据库镜像 (DR)

下图演示了使用 Azure 存储 Blob 进行标准备份和还原。

Windows Azure 中的备份到博客

有关详细信息,请参阅 Azure 虚拟机中的 SQL Server 高可用性和灾难恢复

在尝试于多个 Azure 区域运行云服务时,你必须考虑每个依赖项的含义。下面的各章节中提供了服务特定的指南,这些指南假定你在备用 Azure 数据中心中使用相同的 Azure 服务。这同时涉及到配置和数据复制任务。

注意,在某些情况下,这些步骤有助于缓解服务特定的中断,而不是整个数据中心的中断事件。从应用程序的角度而言,服务特定的中断可能只是受到限制,需要临时将服务迁移到备用 Azure 区域。

访问控制服务 (ACS) 使用不横跨多个 Azure 区域唯一命名空间名称。ACS 2.0 每天执行一次所有命名空间的备份并在安全的站点外位置存储它们。如果灾难发生,ACS 操作人员可能会尝试使用最新的备份,在远程 Azure 区域中恢复客户的订阅。由于备份的频率限制,数据损失量最多为 24 小时内的信息。区域故障恢复没有 SLA,根据情况,恢复时间可能需要几天。

要在备用区域中使用 ACS,必须在该区域配置一个 ACS 命名空间。对于那些担心潜在数据损失的 ACS 2.0 客户,我们鼓励他们醒看 ACS 2.0 管理服务。此界面使管理员能够查看其命名空间,并导入和提取所有相关数据。通过使用此界面,ACS 客户便能够以比 ACS 目前提供的数据一致性级别更高的级别来开发自定义备份和还原解决方案。有关其他可用性注意事项,请参阅访问控制服务(可用性)

和 ACS 一样,服务总线也使用不跨越 Azure 区域的唯一命名空间。所以,首要要求是在备用区域中设置必要的服务总线命名空间。但是,对于排队消息的持久性,也有一些注意事项。有几种在 Azure 区域间复制消息的策略。有关这些复制策略和其他灾难恢复策略的详细信息,请参阅使服务总线应用程序免受服务总线服务中断和灾难的影响。有关其他可用性注意事项,请参阅服务总线(可用性)

若要将 Azure 网站迁移到辅助 Azure 区域,你必须有该网站可供发布的备份。如果中断不涉及整个 Azure 数据中心,则也许可以使用 FTP 下载网站的最新备份。然后,在备用区域创建新的网站,除非你已在该处创建了网站来保留容量。将网站发布到新区域,然后进行必要的配置更改。这些更改可能包括数据库连接字符串或其他区域特定的设置。如有必要,请添加网站的 SSL 证书,并更改 DNS CNAME 记录,以使自定义域名指向重新部署的 Azure 网站 URL。

在辅助 Azure 区域,为你的应用程序创建备份移动服务。再将 Azure SQL Database 还原到备用区域。然后使用 Azure 命令行工具,将移动服务移到备用区域。然后,将移动服务配置为使用还原的数据库。有关此过程的详细信息,请参阅在发生灾难时恢复移动服务。有关其他可用性注意事项,请参阅移动服务(可用性)

与 HDInsight 关联的数据默认存储在 Azure Blob 存储中。HDInsight 要求 Hadoop 群集处理 MapReduce 作业必须与包含所分析数据的存储帐户位于同一区域中。假如你使用可用于 Azure 存储的区域地理复制功能,则如果主要区域因为某些原因而无法使用,你可以访问复制到辅助区域的数据。你可以在数据复制到的区域中创建新的 Hadoop 群集并继续处理这些数据。有关其他可用性注意事项,请参阅HDInsight(可用性)

此时,要从 Azure 区域的损失中恢复,需要有多个位于其他 Azure 区域的 SQL Reporting 实例。这些 SQL Reporting 实例应当访问相同的数据,且该数据应当有自��的恢复计划,来处理灾难情况。你还可以为每个报表维护 RDL 文件的外部备份副本。

Azure 媒体服务对于编码和流有不同的恢复方法。通常,在区域中断期间,流更为重要。为对此做好准备,你应在两个不同的 Azure 区域中各有一个媒体服务帐户。这两个地区都应有编码的内容。在失败期间,你可以将流式流量重定向到备用区域。编码可在任意 Azure 区域执行。如果编码对时间敏感,如在现场活动处理期间,你必须准备好如何在失败期间向备用数据中心提交代码。

配置文件是在备用 Azure 区域设置虚拟网站的最快速方式。在主要 Azure 区域配置虚拟网络之后,将当前网络的虚拟网络设置导出为网络配置文件。如果主要区域发生中断,则从存储的配置文件还原虚拟网络。然后,配置其他云服务、虚拟机或跨部署设置,来使用新的虚拟网络。

 

服务/领域 清单

计算 (PaaS)

  • 创建跨区域的灾难恢复策略。

  • 了解在备用地区保留容量的利弊。

  • 使用流量路由工具,如 Azure Traffic Manager (CTP)。

虚拟机 (IaaS)

  • 将 Blob VM 磁盘资源复制到备用数据中心。

  • 对 VM 磁盘或磁盘内容执行定期备份。

存储

  • 切勿禁用存储资源的地理复制。

  • 了解地理复制在故障切换时的备用区域。

  • 为用户控制的故障转移策略创建自定义备份策略。

SQL Database(灾难恢复)

  • 使用 Azure SQL Database 时间点还原。

  • 将 Azure SQL Database 导出到 Blob 存储。

  • 根据之前存储方面的注意事项,创建灾难恢复计划。

虚拟机上的 SQL Server(灾难恢复)

  • 使用跨区域 AlwaysOn 可用性组或数据库镜像。

  • 也可以使用备份和还原到 Blob 存储。

访问控制服务(灾难恢复)

  • 在备用区域配置 ACS 命名空间。

  • 使用 ACS 2.0 管理服务创建自定义备份解决方案。

服务总线(灾难恢复)

  • 在备用区域中配置服务总线命名空间。

  • 考虑自定义跨区域消息的复制策略。

网站(灾难恢复)

  • 在主要区域外部维护网站备份。

  • 如果发生局部中断,则尝试使用 FTP 检索当前站点。

  • 计划将网站部署到备用区域中的新网站或现有网站。

  • 计划对应用程序和 DNS CNAME 记录的配置更改。

移动服务(灾难恢复)

  • 在备用区域创建备份移动服务。

  • 管理关联 Azure SQL Database 的备份,以在故障转移间进行还原。

  • 使用 Azure 命令行工具来移动移动服务。

HDInsight(灾难恢复)

  • 使用复制的数据在区域中创建新的 Hadoop 群集。

SQL Reporting(灾难恢复)

  • 在另一个区域维护备用 SQL Reporting 实例。

  • 维护单独的计划以将目标复制到该区域。

媒体服务(灾难恢复)

  • 在备用区域创建媒体服务帐户。

  • 在两个区域对相同的内容进行编码,以支持流式故障转移。

  • 在发生中断时,将编码作业提交到备用区域。

虚拟网络(灾难恢复)

  • 使用导出的虚拟网络设置,在另一个区域重新创建该虚拟网络。

Azure 提供一整套服务,可让你将本地数据中心延伸到 Azure,用于高可用性和灾难恢复目的:

  • 网络:通过虚拟专用网络,你可以安全地将本地网络延伸到云。

  • 计算:使用本地 Hyper-V 的客户可以将现有 VM“提起并移动”到 Azure

  • 存储:StorSimple 可将你的文件系统延伸到 Azure 存储空间。Azure 备份服务提供将文件和 Azure SQL Database 备份到 Azure 存储的功能。

  • 数据库复制:通过 SQL 2014 可用性组,你可以为本地数据实现高可用性和灾难恢复

Azure 虚拟网络使你可以在 Azure 中创建逻辑上独立的网段,然后利用 IPsec 连接将该网段安全地连接到本地数据库或单个客户端计算机。虚拟网络使你可以轻松地利用 Azure 可扩展的按需使用基础架构,同时提供了连接本地数据和应用程序的能力,包括 Windows Server、大型机和 UNIX 上运行的系统。有关详细信息,请参阅此处

使用本地 Hyper-V 的客户可以将现有的 VM“提起并移动”到 Azure 和运行 Windows Server 2012 的服务提供程序,而不需要对 VM 进行更改或转换 VM 格式。有关详细信息,请参阅管理磁盘和映像

你可以使用几个选项中的一个将 Azure 用作本地数据的备份站点。

StorSimple 可安全、透明地整合本地应用程序的云存储,并提供 单一设备来实现高性能的分层本地和云存储、即时归档、基于云的数据保护和灾难恢复。有关详细信息,请参阅StorSimple -- 云集成存储 -- 说明及原因

Azure 备份服务让你可以使用 Windows Server 2012、Windows Server 2012 Essentials 和 System Center 2012 Data Protection Manager 中熟悉的备份工具进行云备份。这些工具提供了独立于备份存储位置的备份管理工作流,无论是本地磁盘还是 Azure 存储都可以使用。将数据备份到云之后,授权用户可以将备份轻松恢复到任何服务器。

使用增量备份时,只有文件更改将传输到云。这有助于有效使用存储空间、降低带宽消耗并支持多个数据版本的时间点恢复。你还可以选择使用其他功能,如数据保持策略、数据压缩和数据传送限制。使用 Azure 作为备份位置有一个明显的优点,那就是自动在“异地”备份。这样就不再需要额外对现场备份媒体进行保护了。有关详细信息,请参阅 Azure Backup 概述结合使用 DPM 与 Azure 备份

可使用 AlwaysOn 可用性组、数据库镜像、日志传送以及备份和还原与 Azure Blob 存储配合使用,在混合 IT 环境中为 SQL Server 数据库提供灾难恢复解决方案。所有这些解决方案都使用 Azure 虚拟机上运行的 SQL Server。

AlwaysOn 可用性组可在本地和云中都有数据库副本的混合 IT 环境中使用。具体如以下图表所示,此图表摘录自 Azure 虚拟机中的 SQL Server 高可用性和灾难恢复这篇深度文章。

Hybrid IT 中的 AlwaysOn 可用性组

在基于证书的设置中,数据库镜像也可以横跨本地服务器和云。以下图表展示了这一概念。

Hybrid IT 中的数据库镜像

日志传送可用于同步本地数据库和 Azure 虚拟机中的 SQL Server 数据库。

Hybrid IT 中的日志传送

最后,你可以直接将本地数据库备份到 Azure Blob 存储。

Hybrid IT 中的备份到博客

有关详细信息,请参阅 Azure 虚拟机中的 SQL Server 高可用性和灾难恢复Azure 虚拟机中的 SQL Server 备份和还原

 

服务/领域 清单

网络

  • 使用虚拟网络安全地将本地部署与云相连。

计算

  • 在 Hyper-V 和 Azure 之间重新定位 VM。

存储

  • 利用 StorSimple 服务以使用云存储。

  • 使用 Azure 备份服务。

数据库

  • 考虑使用 Azure VM 上的 SQL Server 作为备份。

  • 设置 AlwaysOn 可用性组。

  • 配置基于证书的数据库镜像。

  • 使用日志传送

  • 将本地数据库备份到 Azure Blob 存储。

此方案是关于应用程序错误或操作人员失误造成的数据损坏或意外删除的恢复。

请注意,尽管 Azure 存储通过自动化副本提供了数据复原功能,但这不会防止你的应用程序代码(或开发人员/用户)因为意外或无心的删除、更新等操作而造成数据损坏。在遇到应用程序或用户错误时保持数据保真需要更为先进的技术,如将数据和审核日志复制到辅助存储位置。开发人员可以利用 Blob 快照功能,创建 Blob 内容的只读时间点快照。这可以用作 Blob 数据保真解决方案的基础。

如果 blob 和表高度持久,那么它们始终代表着数据的当前状态。从意外的数据修改或删除中恢复可能需要将数据还原到以前的状态。这可以通过利用 Azure 提供的功能来存储和保留时点副本来实现。

对于 Azure Blob,你可以使用 blob 快照功能来执行时点备份。对于每个快照,你只需要支付存储自上次快照状态以来 blob 内的更改所需的存储空间费用。快照依赖于它们所基于的原始 blob 的存在,因此建议复制到另一个 blob 甚至另一个存储帐户,以确保正确保护备份数据不受意外删除的影响。对于 Azure 表,你可以将时点备份保存到另一个表或 Azure Blob。有关执行表和 blob 的应用程序级备份的更详细指南和示例,请参阅以下文章:

Azure SQL Database 有几个业务连续性(备份、还原)选项可供使用。数据库可以通过数据库复制功能或 DAC 导入/导出服务进行复制。数据库复制提供业务一致的结果,而 bacpac(通过导入/导出服务)则不会提供业务一致的结果。这两种选项都在数据中心中作为基于队列的服务运行,当前不提供完成时间 SLA。

note备注
请注意,数据库复制和导入/导出服务会对源数据库形成极大的负载,可能会触发资源争用或限制事件(如下面“共享资源和限制”一切中所述)。

Microsoft Azure SQL Database 的时间点备份是使用 Azure SQL Database 复制命令来实现的。你可以使用此命令在同一逻辑数据库服务器或不同服务器上创建数据库的事务一致副本。无论是哪种情况,数据库副本都完全独立于源数据库并发挥全部功能。你创建的每个副本表示一个时点恢复选项。你可以通过将新数据库重命名为源数据库名称,完全恢复数据库状态。或者,可以通过使用 Transact-SQL 查询从新数据库恢复数据的特定子集。有关 SQL Database 的其他详细信息,请参阅 Azure SQL Database 中的业务连续性

对于 IaaS 上的 SQL Server,有两个选项可供使用:传统备份和日志传送。使用传统备份使你可以还原到特定时间点,但恢复过程缓慢。还原传统备份首先需要从最初的完整备份开始,然后应用之后获取的所有备份。第二种选项是配置日志传送会话,延迟日志备份的还原(例如,延迟两小时)。这就为从主要数据库发生的错误恢复提供了时间窗口。

某些 Azure 平台服务将信息存储在用户控制的存储帐户或 Azure SQL Database 中。如果帐户或存储资源遭到删除或损毁,这可能会造成服务的严重错误。在此类情况下,必须维护备份,从而使你能在这些资源遭到删除或损毁的情况下重新创建它们。

对于 Azure 网站和 Azure 移动服务,你必须备份和维护关联的数据库。对于 Azure 媒体服务和虚拟机,你必须维护相关的 Azure 存储帐户和该帐户中的所有资源。例如,对于虚拟机,你必须备份和管理 Azure Blob 存储中的 VM 磁盘。

 

服务/领域 清单

存储

  • 定期备份关键存储资源。

  • 考虑使用 Blob 的快照功能。

数据库

  • 使用 SQL Database 复制命令创建时间点备份。

虚拟机上的 SQL Server 备份 (IaaS)

  • 使用传统备份和还原技术。

  • 创建延迟的日志传送会话。

网站

  • 备份和维护关联的数据库(如果有)。

移动服务

  • 备份和维护关联的数据库。

Media Services

  • 备份和维护关联的存储资源。

虚拟机

  • 备份和维护 Blob 存储中的 VM 磁盘。

防故障:弹性云体系结构的指南:提供构建可复原云体系结构的指南、采用 Microsoft 技术实现这些体系结构的指南,以及针对特定情况实现这些体系结构的方法。

Azure 应用程序的灾难恢复和高��用性:关于可用性和灾难恢复的详细概述。它涵盖了手动复制参考资料和事务数据的挑战。最后的几个章节总结了可在 Azure 数据中心中使用的几种不同类型的灾难恢复拓扑,采用这些拓扑可实现最高级别的可用性。

Azure SQL Database 中的业务连续性:专门关注 Azure Azure SQL Database 的可用性技术,主要以备份和还原策略为中心。如果你在云服务中使用 Azure SQL Database,你应当阅读该文章及相关资源。

Azure 虚拟机中 SQL Server 的高可用性和灾难恢复:讨论在使用基础架构即服务 (IaaS) 来承载数据库服务时,可以使用的可用性选项。它讨论了 AlwaysOn 可用性组、数据库镜像、日志传送和备份/还原。请注意,在示范如何使用这些技术的同一章节内,还有另外几个教程。

在 Azure 云服务上设计大规模服务的最佳实践:关注高度可扩展的云体系结构的开发。你可以利用许多技巧来帮助你提高可伸缩性和可用性。另外,如果你的应用程序不能在负载增加时扩展,则可伸缩性问题将成为可用性问题。

Azure 虚拟机中 SQL Server 的备份和还原

显示:
© 2015 Microsoft