导出 (0) 打印
全部展开

Azure 应用程序的灾难恢复和高可用性

更新时间: 2014年4月

主要作者: Michael McKeown,云解决方案架构师 (Aditi);Hanu Kommalapati,首席技术作者 (Microsoft)

供稿作者:Jason Roth

审阅者:Patrick Wickline、Dennis Mulder、Steve Howard、Tim Wieman、James Podgorski、Ryan Berry、Shweta Gupta、Harry Chen、Jim Blanchard、Andy Roberts、Christian Els

本文重点介绍在 Azure 中运行的应用程序的高可用性。高可用性的总体策略也包括灾难恢复 (DR) 区域。针对云中的故障和灾难进行规划要求迅速识别故障,然后实施适当的策略,该策略应符合你可以承受的应用程序停机时间。此外,还必须考虑在恢复应用程序时不产生不利的业务后果的情况下,应用程序可承受的数据丢失的程度。

当我们询问客户是否准备好应对临时和大规模故障时,大部分客户都表示他们准备妥当。但是,在你自己回答这个问题之前,贵公司是否演练遇到这些故障的情况?是否测试数据库的恢复以确保过程正确无误?很有可能并非如此。这是因为成功的 DR 首先要规划和设计以实现这些过程。如同安全性等许多其他非功能性要求那样,灾难恢复很少需要预先分析和分配时间。此外,大多数客户没有预算用于分散在各地并具有冗余容量的数据中心。因此,即使是任务关键型应用程序,也经常被排除在正常的 DR 规划之外。

Azure 等云平台在全世界提供分散在各地的数据中心。通过这些平台,还可以提供支持可用性以及各种 DR 方案的功能。现在,可为每个任务关键型云应用程序适当考虑系统防灾功能。Azure 具有复原功能,其中许多服务均内置 DR。你必须认真研究这些平台功能,并通过应用程序策略对这些功能加以补充。

本白皮书概述了对 Azure 部署进行灾难预防必须采取的必要体系结构步骤,以便可以实现更大规模的业务连续性过程。业务连续性计划是一个发展方向,目标是在不利的条件下持续运转。其中涵盖技术故障(如中断服务)或自然灾害(如暴风雨或断电)。应用程序在灾难下复原只是更大规模 DR 过程的一部分,如以下 NIST 文档中所述:Contingency Planning Guide for Information Technology Systems(信息技术系统应急措施规划指南)。

以下各节定义不同级别的故障、应对这些故障的方法以及支持这些方法的体系结构。此信息将对 DR 过程和程序形成影响,以确保 DR 策略正确而高效地实施。

经过精心设计的应用程序可承受小规模的功能故障,也可在数据中心级别承受大规模的系统范围故障。以下各节定义一些术语,本文通篇引用这些术语以说明可复原的云服务的各个方面。

高度可用的云应用程序实施一些策略以消减依赖项(如云平台提供的托管服务)的中断。尽管云平台功能可能会发生故障,但此方法使应用程序可继续展现应有的功能性和非功能性系统特征。这一点在防故障:弹性云体系结构的指南

实现应用程序时,必须将功能中断的可能性考虑在内。此外还需要从业务角度考虑该中断对应用程序产生的影响,然后再深入探讨实施策略。如果未适当地考虑业务影响以及发生危险情况的可能性,则实现可能成本高昂,还可能实属多余。

对于高可用性,请考虑用汽车作为类比。即使拥有优质的部件和一流的设计,也无法阻止偶尔发生故障。例如,当汽车轮胎漏气时,汽车仍可行驶,但开动时功能减弱。如果已针对这种可能发生的情况安排了对策,则可暂时使用其中一个薄边备胎,直到抵达修理厂。尽管备胎不能快速行驶,但仍可开动车辆直到更换轮胎。同样,针对可能丧失功能进行规划的云服务可防止相对较小的问题使整个应用程序停止运行。即使必须在功能减弱的情况下运行云服务也是如此。

高度可用的云服务有几个重要特征:可用性、可伸缩性和容错。虽然这些特征相互关联,但了解其中每个特征及其对解决方案的可用性发挥什么作用也很重要。

可用的应用程序将其底层基础结构和依赖服务的可用性考虑在内。可用的应用程序通过冗余和复原的设计,消除单独故障。在 Azure 中谈论可用性时,了解平台的有效可用性这一概念很重要。有效可用性考虑每种依赖服务的服务级别协议 (SLA) 以及这些协议对于总体系统可用性的累积影响。

系统可用性衡量系统可运转的时间范围所占的百分比。例如,Azure 中的 Web 或辅助角色至少有两个实例的可用性 SLA 为 99.95%(总比例为 100%)。它不衡量在这些角色上运行的服务的性能或功能。但是,其他依赖服务的各种 SLA 也会影响云服务的有效可用性。系统中移动部件越多,越要小心操作以确保应用程序能够灵活满足其最终用户的可用性要求。

考虑使用 Azure 服务的一项 Azure 服务的以下 SLA:计算、Azure SQL Database 和 Azure 存储。

 

Azure 服务 SLA 每月(30天)可能发生的停机时间的分钟数

计算

99.95%

21.6

SQL Database

99.90%

43.2

存储

99.90%

43.2

必须为所有服务有可能在不同时间中断安排对策。在这个简化的示例中,应用程序每月可中断的总分钟数为 108 分钟。一个月 30 天共有 43200 分钟。108 分钟占一个月 30 天的总分钟数(43200 分钟)的 0.25%。这样,云服务的有效可用性为 99.75%。

但是,使用本章中介绍的可用性方法可提高这个数字。例如,如果将应用程序设计为在 SQL Database 不可用时继续运行,则可从等式中删去那一行。这可能意味着应用程序运行时功能减少,因此还要考虑业务要求。有关 Azure SLA 的完整列表,请参阅服务级别协议

可伸缩性直接影响可用性 - 在增加负载的情况下发生故障的应用程序不再可用。可伸缩的应用程序可满足提高的需求,并在可接受的时间范围内获得相同结果。当系统可伸缩时,它进行水平或垂直伸缩以承受负载提高,同时保持性能一致。简而言之,水平伸缩会添加更多相同大小(处理器、内存、带宽)的计算机,而垂直伸缩则增加现有计算机的大小。就 Azure 而言,具有选择不同计算机大小以供计算的垂直伸缩选项。但更改计算机大小需要重新部署。因此,大多数灵活的解决方案都适合水平伸缩。计算尤为如此,因为你可以轻松增加任何 Web 或辅助角色的运行实例数量。这些附加实例可通过 Azure Web 门户、PowerShell 脚本或代码来处理增多的流量。应在所监视的特定指标增大时作出此决策。在此方案中,负载增加不会造成用户性能或指标大幅下降。Web 角色和辅助角色通常将任何状态存储在外部,以便灵活进行负载平衡以及正确处理实例数量的任何更改。水平伸缩也适用于不提供垂直伸缩分层选项的服务,如 Azure 存储。

应将云部署视为一组缩放单位,它使应用程序可灵活地满足最终用户的吞吐量需求。缩放单位在 Web 和应用程序服务器级别更容易可视化,这是因为 Azure 已通过 Web 角色和辅助角色提供了无状态计算节点。向部署中添加更多计算缩放单位不会产生任何应用程序状态管理方面的副作用,因为计算缩放单位是无状态的。存储缩放单位负责管理(结构化或非结构化)数据分区。存储伸缩单位的示例包括 Azure 表分区、Blob 容器和 SQL Database。即便是使用多个 Azure 存储帐户,也会直接影响应用程序可伸缩性。必须设计一个高度可扩展的云服务来整合多个存储缩放单位。例如,如果应用程序使用关系数据,则在多个 SQL Database 之间对数据进行分区,以便存储可以匹配灵活的计算缩放单位模型。同样地,通过 Azure 存储,可制定需要谨慎设计以满足计算层吞吐量需要的数据分区方案。有关设计可伸缩的云服务的最佳实践,请参阅在 Azure 云服务上设计大规模服务的最佳实践

应用程序需要假定每项依赖的云功能可能并将在某个时间点中断。容错应用程序可检测到发生故障的元素,设法使其继续运行并在特定期限内返回正确结果。对于暂时性的错误情况,容错系统将采用某种重试策略。对于更严重的故障,应用程序可检测问题,并故障转移到备选的硬件或采用应急计划,直到故障解除。可靠的应用程序能够正确处理一个或多个部件故障,同时继续正常运行。容错应用程序可使用一种或多种设计策略,如冗余、复制或性能减弱。

云部署可能因依赖服务或底层基础结构发生系统性中断而停止运转。在此类条件下,业务连续性计划将触发灾难恢复 (DR) 过程。此过程通常涉及操作人员和自动化过程,以便在正常运转的数据中心内重新激活应用程序。其中要求将应用程序用户、数据和服务转移到新的数据中心。它还涉及使用备份介质或持续复制。

考虑前面的类比,其中将高可用性比作可通过使用备件从轮胎漏气的情况下复原。相比之下,灾难恢复涉及在发生汽车无法再行驶的车祸事故后采取的步骤。在这种情况下,最佳解决方案是找到一种高效的换车方法,即通过致电旅行社或好友换车。在此方案中,重新上路行驶可能会耽搁更长时间。而且,修复然后重新使用原有车辆的情况可能会更加复杂。同样地,灾难恢复到另一数据中心是一项复杂的任务,通常会产生一些停机时间,并有可能丢失数据。为了更好地理解和评估灾难恢复策略,必须定义两个术语:恢复时间目标 (RTO) 和恢复点目标 (RPO)。

恢复时间目标 (RTO) 是为恢复应用程序功能而分配的最长时间。这取决于业务要求,并与应用程序的重要程度相关。重要的业务应用程序要求 RTO 较低。

恢复点目标 (RPO) 是恢复过程导致丢失数据的可接受时间范围。例如,如果 RPO 为一小时,则必须至少每小时将数据完全备份或复制一次。在备用数据中心内激活应用程序后,备份数据中最多缺少一小时的数据。如同 RTO 一样,重要的应用目标要求 RPO 越小越好。

高度可用的应用程序可消减依赖的服务和硬件在可用性、负载和临时故障方面的波动。应用程序以可接受的用户和系统响应级别继续运行,如业务要求或应用程序服务级别协议所定义。

Azure 在平台中内置了多种功能,用于支持高度可用的应用程序。本节介绍其中一些重要功能。有关该平台的更全面分析,请参阅 Azure 业务连续性技术指南

Azure 结构控制器 (FC) 负责设置和监视 Azure 计算实例的运行状况。结构控制器检查主机和来宾计算机实例的硬件和软件的状态。检测到故障后,它通过自动重新定位 VM 实例来履行 SLA。容错域和升级域的概念进一步为计算 SLA 提供支持。

部署多个角色实例时,Azure 将这些实例部署到不同的容错域。容错域边界基本上就是同一数据中心内的其他硬件机架。容错域可降低局部硬件故障将中断应用程序服务的可能性。无法管理分配给辅助或 Web 角色的容错域的数量。结构控制器采用与 Azure 托管的应用程序分离的专用资源,由于它充当 Azure 系统的核心,因此其正常运行时间为 100%。它监视和管理各个容错域中的角色实例。以下关系图显示 FC 在各个容错域中部署和管理的 Azure 共享资源。

图 1:容错域隔离(简化视图)

升级域在功能上与容错域类似,但支持升级而非故障。升级域是实例分离的逻辑单位,它决定将在某个时间点升级特定服务中的哪些实例。默认情况下会为托管服务部署定义五个升级域。不过,你可以在服务定义文件中更改该值。例如,你拥有八个 Web 角色实例。三个升级域中各有两个实例,一个升级域中有两个实例。Azure 定义了更新顺序,但它以升级域的数量为基础。有关升级域的详细信息,请参阅更新 Azure 服务

除了这些支持高计算可用性的平台功能之外,Azure 还将高可用性功能嵌入到它的其他服务中。例如,Azure 存储保留所有 Blob、表和队列数据的 3 个副本。它还允许使用异地复制选项,将 Blob 和表的备份存储在辅助数据中心内。通过内容传送网络 (CDN),可在世界各地缓存 Blob 以实现冗余和可伸缩性。Azure SQL Database 还保留多个副本。除 Azure 业务连续性技术指南一文之外,另请参阅在 Azure 云服务上设计大规模服务的最佳实践一文。这些文章全面介绍了平台可用性功能。

尽管 Azure 提供多项支持高可用性的功能,但了解其限制也很重要。对于计算,Azure 保证你的角色可用并处于运行状态,但它不了解你的应用程序是否运行或过载。对于 Azure SQL Database,在数据中心内同步复制数据。这些数据库副本不是时间点备份。对于 Azure 存储,默认情况下会将表和 Blob 数据复制到备用数据中心。但是,直到 Microsoft 选择将故障转移到备用站点,你才能访问这些副本。通常仅在整个数据中心长时间中断时进行数据中心故障转移,并且异地故障转移时间没有 SLA。任何数据损坏将迅速传播到副本,注意到这一点也很重要。出于这些原因,必须使用应用程序特定的可用性功能对平台可用性功能加以补充。这些应用程序可用性功能包括用于创建 Blob 数据的时间点备份的 Blob 快照功能。

本文的大部分内容重点介绍云服务,其中使用平台即服务 (PaaS) 模型。但 Azure 虚拟机也有一些特定的可用性功能,它们使用基础结构即服务 (IaaS) 模型。若要使虚拟机实现高可用性,必须使用可用性集。可用性集的功能与容错域和升级域类似。在可用性集中,Azure 会以某种方式定位虚拟机,避免局部硬件故障和维护活动导致该组的所有虚拟机停机。可用性集必须达到针对虚拟机可用性的 Azure SLA。有关详细信息,请参阅管理虚拟机的可用性。下图展示两个可用性集,其中分别集中了 Web 和 SQL Server 虚拟机。

图 2:Azure 虚拟机的可用性集

注意,在上图中,SQL Server 安装并运行在虚拟机上。这与以前讨论的 Azure SQL Database 不同,后者提供数据库作为托管服务。

高可用性的大多数应用程序策略均涉及冗余或消除应用程序组件之间的硬性依赖。应用程序设计应在 Azure 或第三方服务偶发的停机时间内支持容错。以下各节介绍几种用于提高云服务可用性的应用程序模式。

考虑在松散耦合的服务之间进行异步通信以提高 Azure 应用程序的可用性。在此模式下,会将消息写入存储队列或 Service Bus 队列供以后处理。将消息写入队列后,立即将控制权归还给消息的发送者。消息由通常作为辅助角色实现的另一层应用程序负责处理。如果辅助角色失灵,则消息累积在队列中,直到处理服务恢复。只要队列可用,前端发送者与消息处理程序之间即不存在直接的依赖关系。这样就不必进行同步服务调用,此类调用可能在分布式应用程序中形成吞吐量瓶颈。

上述情况的一种变化形式使用 Azure 存储(Blob、表,队列)或 Service Bus 队列作为调用数据库失败后的故障转移位置。例如,如果在应用程序中同步调用另一个服务(如 Azure SQL Database)多次失败,则可以将这些数据序列化为持久存储。以后在服务或数据库恢复联机时,应用程序可重新提交来自存储的请求。此模型中的区别在于中间位置不是应用程序工作流的固定部分。此模型仅用于故障情况下。

在两种方案中,异步通信和中间存储均可防止后端服务中断导致整个应用程序停止运行。队列充当逻辑意义上的中介。有关选择正确队列服务的更多指导,请参阅 Azure 队列和 Azure Service Bus 队列 - 比较与对照

高度可用的应用程序设计的一个关键点,是利用代码中的重试逻辑正常处理临时中断的服务。Microsoft 模式和实践团队开发的暂时性故障处理应用程序块可协助应用程序开发人员完成此过程。“暂时性”一词表示仅持续相对较短时间的临时条件。在本文的背景下,处理暂时性故障是开发高度可用的应用程序的一部分。暂时性情况的示例包括间歇性网络错误和丢失数据库连接。

暂时性故障处理应用程序块是一种正常处理代码中故障的简化方式。此方式可通过添加可靠的暂时性故障处理逻辑,提高应用程序的可用性。大多数情况下,将由重试逻辑处理短暂中断,并在一次或多次尝试失败后重新连接发送者和接收者。应用程序用户通常注意不到成功的重试尝试。

开发人员有三个选项可用于管理其重试逻辑:增量、固定间隔和指数。增量是指在每次重试前等待更长时间,等待时间以线性方式增长(例如 1、2、3 和 4 秒)。固定间隔是指在每次重试之间等待相同长度的时间(例如 2 秒)。作为一个更随机的选项,指数补偿是指在重试之间等待更长时间,但等待时间以指数方式增长(例如 2、4、8 和 16 秒)。

代码中的策略大致包括:

  1. 定义重试策略

  2. 尝试可能导致暂时性故障的操作

  3. 如果发生暂时性故障,则调用重试策略

  4. 如果所有重试均失败,则捕获一个最终异常

将在模拟故障中测试重试逻辑,以确保连续的重试操作不会导致难以预料的长时间延迟。请在决定放弃整个任务之前进行此测试。

引用数据是应用程序的只读数据,该数据提供一个业务上下文,应用程序将于业务运行期间在其中生成事务数据。事务数据是引用数据的时间点函数,因此其完整性取决于引用数据在事务期间的快照。这个定义不太准确,但应该可以满足我们在此的用途。

应用程序上下文中必须有引用数据,否则应用程序将无法运行。各个应用程序将创建和维护引用数据;主数据管理系统通常负责执行此功能。这些系统对引用数据的整个生命周期负责。引用数据的示例包括产品目录、雇员主数据、部件主数据和设备主数据。引用数据也可来自组织以外,如邮政编码或税率。提高引用数据可用性的策略之外通常要比提高事务数据可用性的策略简单。引用数据具有最为持久的优点。

通过将引用数据连同应用程序一起部署,使用引用数据的 Azure Web 角色和辅助角色可在运行时变为自治。如果本地存储的大小允许此类部署,则这是理想状态。部署到本地文件系统的嵌入式数据库(SQL、NOSQL)或 XML 文件有助于实现 Azure 计算缩放单位的自治。但是,应该制定一种机制,以便无需重新部署即可更新每个角色中的数据。为此,请将对引用数据的任何更新放置到云存储终结点(例如,Azure Blob 存储或 SQL Database)。向每个角色添加在角色启动时将数据更新下载到计算节点中的代码。或者添加使管理员可在角色实例中执行强制下载的代码。若要提高可用性,角色还应包含一组引用数据以防存储失灵。这样使角色可先使用一组基本的引用数据,直到有存储资源可供更新使用。

图 3:通过自治计算节点使应用程序获得高可用性

此模式的一个注意事项是角色的部署和启动速度。如果在启动时部署或下载大量引用数据,则这样会增加使新部署或角色实例运转所需的时间。要在每个角色上立即有引用数据可用而不依赖于外部存储服务,这可能是一个可接受的折衷。

事务数据是应用程序在某种业务上下文中生成的数据,由应用程序实现的一组业务流程与支持这些流程的引用数据组合而成。事务数据的示例包括订单、预先发货通知、发票和 CRM 机会。这样生成的事务数据将送入外部系统,用于保存记录或进一步处理。

请牢记,引用数据在负责这些数据的系统中可发生更改。出于此原因,事务数据必须保存时间点引用数据上下文,以使其对外部的依赖程度降至最低,保持其语义一致性。例如,设想在履行订单几个月后从目录中删除某件产品。最佳实践是将尽可能多的引用数据上下文嵌入到事务中。这样可保留与事务相关的语义,即使要在捕获事务之后更改引用数据也是如此。

如前面所提及,使用松散耦合和异步通信的体系结构可提高自身的可用性。这一点对于事务数据也属实,但实现起来更为复杂。传统的事务概念通常依靠数据库确保事务的正常进行。引入中间层后,应用程序代码必须在各层正确处理数据,以确保足够的一致性和持久性。

以下顺序介绍一个工作流,其中将事务数据的捕获与其处理相分离:

  1. Web 计算节点:提供引用数据。

  2. 外部存储:保存中间事务数据。

  3. Web 计算节点:完成最终用户事务。

  4. Web 计算节点:将完成的事务数据与引用数据上下文一起发送到保证做出可预测响应的临时持久存储。

  5. Web 计算节点:通知最终用户事务已完成。

  6. 后台计算节点:提取事务数据,如有必要,则后处理这些数据,然后将其发送到它在当前系统中的最终存储位置。

下图展示在 Azure 云服务中实现这种设计的一种可行方式。

图 4:通过松散耦合使应用程序获得高可用性

上图中的虚线箭头表示异步处理。前端 Web 角色不了解这种异步处理。这样导致将事务存储在其最终目标,并引用当前系统。由于此异步模型会导致延迟,因此无法立即查询事务数据;所以,需要将事务数据的每个单位保存在缓存或用户会话中,以满足即时 UI 的需要。

结果,Web 角色将脱离基础结构的其余部分进行自治,其可用性配置文件是 Web 角色与 Azure 队列而非整个基础结构的结合。除了高可用性之外,这种方法还使 Web 角色可独立于后端存储进行水平伸缩。这种高可用性模型可能会影响运营的经济状况,因为 Azure 队列和辅助角色等其他组件可能影响到每月的使用成本。

注意,上图展示了针对事务数据的这种去耦方法的一种实现。还有许多其他实现可用。以下列表提供一些备选的变化形式。

  • 可能在 Web 角色与队列存储之间放置辅助角色。

  • 可使用 Service Bus 队列代替 Azure 存储队列。

  • 最终目标可能是 Azure 存储或其他数据库提供商。

  • 可在 Web 层使用 Azure Caching 满足完成事务后的立即缓存要求。

除了在本节中讨论的模式之外,注意云服务的可伸缩性直接影响可用性这一点也很重要。如果负载增加导致你的服务无法响应,则给用户留下的印象就是应用程序故障。根据预期的应用程序负载和未来的预期,遵照可伸缩性的最佳实践进行操作。最大限度的扩展需要考虑多种因素,如使用单个还是多个存储帐户、在多个数据库之间共享以及缓存策略。若要详细探讨这些模式,请参阅在 Azure 云服务上设计大规模服务的最佳实践

高可用性与临时故障管理有关,而灾难恢复 (DR) 与应用程序功能因发生灾难而丧失有关。例如,设想有一个或多个数据中心停机的情况。在这种情况下,需要制定在数据中心之外运行应用程序或访问数据的计划。执行此计划主要关注的是人员、流程以及使系统可正常运转的支持性应用程序。定义其灾难运作模式的业务和技术所有者负责确定发生灾难期间服务的功能级别。这可能表现为各种形式:完全不可用、部分可用(功能减弱或延迟处理),或完全可用。

和可用性注意事项一样,Azure 提供了旨在支持灾难恢复的 Azure 业务连续性技术指南。Azure 灾难恢复的某些可用性功能之间还存在某种关系。例如,跨容错域管理角色可提高应用程序的可用性。但是,如果没有此项管理,则未经处理的硬件故障将会演变为“灾难”情形。因此,应将正确地应用许多可用性功能和策略视为应用程序防灾的重要部分。但是,本节不仅介绍一般的可用性问题,还涉及到严重(且罕见)的灾难事件。

Azure 在世界各地许多不同的地区均有数据中心在运转。这样即可支持多种灾难恢复方案,如系统提供的将 Azure 存储异地复制到辅助数据中心。这也意味着可以轻松而经济地将云服务部署到全球多个地点。将此与在多个地区运行自己的数据中心的成本和困难程度相比,高下立见。将数据和服务部署到多个数据中心可保护应用程序不会在一个数据中心内发生重大中断。

发生数据中心特有的故障后,必须将流量重定向到另一数据中心内的服务或部署。可手动进行此路由过程,使用自动过程更加高效。Azure Traffic Manager (WATM) 专为完成此任务而设计。通过它,可在主数据中心发生故障时管理将用户流量故障转移到其他数据中心的过程。由于流量管理是整体策略的一种重要部分,因此了解 WATM 的基本知识很重要。

在下图中,用户连接到为 WATM 指定的 URL (http://myATMURL.trafficmanager.net),后者将真实的站点 URL(http://app1URL.cloudapp.nethttp://app2URL.cloudapp.net)进行了抽象化。当策略发出指令时,将根据配置何时路由用户的条件,将用户发送到正确的真实站点。策略选项为循环、性能或故障转移。在本白皮书中,我们将仅涉及故障转移的选项。

图 5:使用 Azure Traffic Manager 进行路由

配置 WATM 时,将提供新的 Traffic Manager DNS 前缀。将向用户提供该 URL 前缀以访问你的服务。WATM 当前将负载平衡向上提升了一个级别,而不处于数据中心级别。对于 Traffic Manager 管理的所有部署,其 DNS 均映射到某个 CNAME。

在 WATM 内,你指定在发生故障时将用户路由到的部署的优先级。WATM 会监视部署的终结点,并注意主部署何时发生故障。如果发生故障,WATM 将分析按优先顺序排列的部署列表,然后将用户路由到列表中的下一个部署。

虽然 WATM 决定在故障转移时前往何方,但在不处于故障转移模式时,你可以决定故障转移域是处于休眠还是活动状态。该功能与 Azure Traffic Manager 无关。如果 WATM 在主站点中检测到故障,它会转移到故障转移站点。无论该站点当前是否在为用户提供服务,WATM 都会这样做。可在本文后面的部分中找到有关休眠或活动的故障转移域的详细信息。

有关 Azure Traffic Manager 工作方式的详细信息,请参阅以下链接。

以下各节涵盖多种不同类型的灾难情况。数据中心故障不是应用程序范围内发生故障的唯一原因。设计不良或管理错误也会导致中断。请在恢复计划的设计和测试阶段设想可能导致故障的原因,这样做很重要。一个好的计划可充分利用 Azure 功能,并通过应用程序特有的策略强化这些功能。由应用程序的重要性、RPO 和 RTO 规定所选的响应。

如前所述,Azure 结构控制器会自动处理因主机虚拟机中的底层硬件或操作系统软件引起的故障。Azure 会在正常运行的服务器上创建新的角色实例,然后将其添加到负载平衡器轮换中。如果角色实例数大于一,Azure 会将处理过程切换到其他正在运行的角色实例,同时替换发生故障的节点。

但是,还会发生与任何硬件或操作系统故障无关的严重应用程序错误。应用程序可能因逻辑错误或数据完整性问题导致的灾难性异常而发生故障。必须在代码中加入足够的遥测,以使监视系统可检测到故障情况并通知应用程序管理员。完全了解灾难恢复过程的管理员可决定调用故障转移过程,也可以简单接受可用性中断以解决关键性错误。

Azure 自动将你的 Azure SQL Database 和 Azure 存储数据在同一数据中心内的不同容错域中冗余地存储三次。如果使用异地复制,则再将这些数据在另一个数据中心内存储三次。但是,如果用户或应用程序损坏了主副本中的数据,则会将损坏情况迅速复制到其他副本。不幸的是,这将产生三份损坏的数据。

若要应对可能的数据损坏,将需要管理你自己的备份,以保持事务一致性。你可以将备份存储在 Azure 中或存储在本地,具体取决于你的业务需求或治理监管。有关详细信息,请参阅灾难恢复的数据策略部分。

当 Azure 网络的某些部分中断时,你可能无法访问应用程序或数据。如果一个或多个角色实例因网络问题而不可用,则 Azure 将利用应用程序剩余的可用实例。如果应用程序因 Azure 网络中断而无法访问其数据,则可以通过使用缓存数据在本地以降级模式运行,因此需要在应用程序中为在降级模式下运行制定灾难恢复策略。某些应用程序可能做不到这一点。另一个选项是将数据存储在备用位置,直到连接恢复。如果降级模式不是好办法,则剩余的选项为产生应用程序停机时间或故障转移到备用数据中心。设计在降级模式下运行应用程序多出于业务决策而非技术决策。应用程序功能降级部分深入讨论了这一问题。

Azure 提供的许多服务可能会定期停机。设想 Azure Shared Caching 为例。这项多租区服务向应用程序提供缓存功能。设想如果依赖服务不可用,应用程序中将发生什么,这样做很重要。此方案在许多方面与网络中断方案类似,但是,单独考量每一项服务有望改进整个计划。

例如,通过 Caching,多租区共享缓存模型有一个相对较新的备选项。通过角色上的 Azure Caching,可从云服务部署中缓存到应用程序。(建议今后也这样使用 Caching)。虽然它有一个限制,只能从单个部署中访问它,但有可能使灾难恢复获益。首先,服务现在运行在你的部署本地的角色上。因此,在云服务的总体管理过程中,可更好地监视和管理缓存的状态。但是,这种类型的缓存也公布了新功能。其中一个新功能是缓存数据的高可用性。此功能通过在其他节点上保留重复的副本,帮助在一个节点发生故障时保留缓存数据。请注意,高可用性会降低吞吐量并增大延迟,因为需要在写入时更新辅助副本。它还会将每项使用的内存量加倍,因此要为此做好规划。这个具体的示例表明,每项依赖服务都可能具有提高总体可用性和帮助抵御灾难性故障的能力。

通过每个依赖服务,应了解可能产生的总中断数。在 Caching 的示例中,或许可以直接从数据库访问数据,直到 Caching 功能恢复为止。在性能方面,这将是降级模式,但可提供数据方面的完整功能。

以前的故障主要还是可在同一 Azure 数据中心内应对的故障。但是,还必须为整个数据中心发生故障的可能性做好准备。当数据中心发生故障时,数据的本地冗余副本不可用。如果启用了异地复制,则在异地数据中心内另有 Blob 和表的 3 个副本。当 Microsoft 声称数据中心发生故障时,Azure 会将所有 DNS 条目将重新映射到异地复制的数据中心。注意,你对此过程无任何控制权,并且仅对整个数据中心范围的故障进行此过程。因此,还必须依靠应用程序特有的其他备份方法才能达到最高级别的可用性。有关详细信息,请参阅灾难恢复的数据策略部分。

在灾难规划中,必须考虑到所有可能发生的灾难情况。最严重的一个故障将同时涉及所有 Azure 数据中心。如同任何其他故障一样,你可能决定在这种情况下甘冒停机时间的风险。跨越多个数据中心的广泛故障应比涉及依赖服务或单个数据中心的孤立故障少见得多。但是,对某些任务关键型应用程序而言,你可能决定还必须为此方案制定备份计划。针对此事件的计划可能包括故障转移到备选云混合本地和云解决方案中的服务。

设计良好的应用程序通常使用一组模块,这些模块通过实现松散耦合的信息互换模式相互通信。适合 DR 的应用程序尤其需要在模块级别分离任务,以防止依赖服务中断导致整个应用程序停止运行。例如,以 Y 公司的电子商务应用程序为例,该应用程序可能由以下模块构成:

  • 产品目录:便于用户浏览产品

  • 购物车:便于用户在其购物车中添加/删除产品

  • 订单状态:显示用户订单的发货状态

  • 订单提交:通过提交订单并付款,完成购物过程

  • 订单处理:验证订单的数据完整性并执行数量可用性检查

当此应用程序中某个模块的依赖项停止运行时,在该部件恢复之前,此模块如何运行?设计良好的系统将通过在设计时和运行时分离任务来实施隔离边界。可以将每个故障分类为可恢复和不可恢复。不可恢复的错误会使模块停止运行,但可以通过备选项来规避可恢复错误。如高可用性一节所述,可以通过处理故障并采取备用措施,使用户察觉不到某些问题。在更严重的停运期间,应用程序可能完全不可用。但是,还有第三个选项,即在降级模式下继续为用户提供服务。

例如,如果托管订单的数据库停运,则“订单处理”模块无法处理销售事务。根据体系结构的不同,该应用程序的“订单提交”和“订单处理”部分可能难以或无法继续。如果该应用程序未设计成处理这种情况,则整个应用程序可能离线。

但是,在这同一情况下,可将产品数据存储在其他位置。在这种情况下,仍可使用“产品目录”模块查看产品。在降级模式下,用户可继续使用该应用程序的可用功能,如查看产品目录。但是,该应用程序的其他部分不可用,如下订单或库存查询。

降级方式的另一种变化形式重点在于性能而非功能。例如,设想一种情况,其中通过 Azure Caching 缓存产品目录。如果 Caching 变得不可用,该应用程序可以直接转到服务器存储以检索产品目录信息。但此访问的速度比缓存版本慢。因此,应用程序性能下降,直到 Caching 服务完全恢复为止。

对于该应用程序中有多少功能将继续在降级模式下运行,这既是一个业务决策,也是一个技术决策。该应用程序还必须决定如何向用户通知临时问题。在本例中,该应用程序可允许查看产品,甚至可将这些产品添加到购物车。但是,当用户尝试进行购买时,该应用程序向用户通知销售模块暂时停运。对于客户来说,这不是理想状态,但这样确实可防止整个应用程序停运。

正确处理数据是任何灾难恢复计划中最难以安排妥当的部分。还原数据也是恢复过程中通常占用最多时间的部分。在发生故障之后,在降级模式下做出的不同选择使数据的故障恢复和一致性面临严峻挑战。其中一个因素是需要还原或维护应用程序数据的副本。此数据将在辅助站点用于引用和事务目的。本地设置需要一个成本高昂且耗时漫长的规划过程才能实施多数据中心 DR 策略。方便的是,包括 Azure 在内的大多数云提供商均已允许将应用程序部署到多个数据中心。这些数据中心分散在各地,因此应该极少发生多个数据中心同时停运的情况。能够跨数据中心处理数据的策略是任何灾难恢复计划成功的决定性因素之一。

以下各节讨论与数据备份、引用数据和事务数据相关的灾难恢复方法。

定期备份应用程序数据可为某些灾难恢复方案提供支持。不同的存储资源需要使用不同的方法。

对于 Azure SQL Database,可使用 DATABASE COPY 命令创建数据库的副本。必须使用此命令才能获得在事务上一致的备份。还可以利用 Azure SQL Database 的导入/导出服务。这样支持将数据库导出到存储在 Azure Blob 存储中的 BACPAC 文件。Azure 存储内置的冗余性在同一数据库中创建备份文件的两个副本。但是,由运行备份过程的频率决定 RPO,即可能在灾难情况下丢失的数据量。例如,如果在整点执行备份,而灾难发生在整点的两分钟前,则会丢失在执行上次备份之后产生的 58 分钟的数据。此外,为了应对数据中心停运,应将 BACPAC 文件复制到备用数据中心。然后,可还原备用数据中心内的那些备份。有关更多详细信息,请参阅 Azure SQL Database 中的业务连续性

对于 Azure 存储,可制定你自己的自定义备份过程,也可使用许多第三方备份工具。注意,在大多数应用程序设计中,还有许多其他的复杂情况,其中存储资源互相引用对方。例如,设想一个 SQL Database,其中一列链接到 Azure 存储中的 Blob。如果未能同步进行备份,则数据库可能会提供一个指针,指向在发生故障之前未备份的 Blob。应用程序或灾难恢复计划必须实现在恢复后处理这种不一致性的过程。

如同以前提到的那样,引用数据是支持应用程序功能的只读数据。这些数据通常不经常更改。尽管备份和还原是处理数据中心停运的一种方法,但 RTO 耗时相对较长。将应用程序部署到辅助数据中心后,有一些策略可改进引用数据的 RTO。

由于引用数据不经常更改,因此可通过在辅助数据中心内保留引用数据的永久副本,缩短 RTO。这样可消除发生灾难时还原备份所需的时间。若要满足多数据中心 DR 要求,必须将应用程序和引用数据一起部署到多个数据中心。如引用数据模式(高可用性)中所述,可以将引用数据部署到角色本身、外部存储或这两者的组合。计算节点内引用数据部署模型还隐式满足了 DR 要求。将引用数据部署到 SQL Database 需要将引用数据的副本部署到每个数据中心。同样的策略也适用于 Azure 存储。你必须将存储在 Azure 存储中的任何引用数据副本部署到主数据中心和辅助数据中心。

图 6:引用数据发布到主辅数据中心

如同以前提到的那样,必须对所有数据(包括引用数据)实现你自己的应用程序特有的备份例程。仅在整个数据中心范围停运时,使用跨数据中心的异地复制副本。为了防止出现长时间的停机,应将应用程序的任务关键部分的数据部署到辅助数据中心。有关此拓扑的示例,请参阅主动/被动模型。

实施功能完备的灾难模式策略需要将事务数据异步复制到辅助数据中心。可进行复制的实际时间范围将决定应用程序的 RPO 特征。你仍然可以从主数据中心恢复在复制期间丢失的数据,以后还可以与辅助数据中心合并。

以下体系结构示例介绍在故障转移情况下处理事务数据的几种不同方式。这些示例并未尽列,注意到这一点很重要。例如,可将中间存储位置(如队列)替换为 Azure SQL Database。队列自身可以是 Azure 存储或 Service Bus 队列(请参阅 Azure 队列和 Azure Service Bus 队列 - 比较与对照)。服务器存储目标也可能有所不同,如使用 Azure 表而不是 SQL Database。此外,在不同步骤中,还可插入辅助角色作为中介。重要的不在于精确地模仿这些体系结构,而是在恢复事务数据和相关模块时考虑各种备选方法。

设想一个应用程序,其中使用 Azure 存储系统队列容纳事务数据。这允许辅助角色在去耦体系结构中处理事务数据并将其放入服务器数据库。正如讨论的那样,如果前端角色要求立即查询这些数据,则这要求事务使用某种形式的临时缓存。根据数据丢失承受程度的不同,可以选择复制队列、数据库或所有存储资源。如果只是复制数据库,则当主数据中心停机后,你仍然可以在主数据中心恢复时恢复队列中的数据。下图显示一种体系结构,其中跨数据中心同步了服务器数据库。

图 7:复制事务数据,为 DR 作准备

实现前一种体系结构的最大难题是数据中心之间的复制策略。虽然 Azure 为这种类型的复制提供了 SQL 数据同步服务,但此项服务仍为预览版,建议不要将其用于生产环境。有关详细信息,请参阅 Azure SQL Database 中的业务连续性。对于生产应用程序,必须投资购入第三方解决方案或在代码中创建自己的复制逻辑。根据体系结构的不同,可能会进行双向复制,而这也更加复杂。可能有一个实现利用上一示例中的中间队列。处理数据并将其放入最终存储目标的辅助角色可以同时在主辅数据中心内做出更改。这些任务并非不重要,而有关复制代码的完整指导超出本文的范畴。关键是应投入大量时间并重点测试如何将数据复制到辅助数据中心。应进行其他处理和测试,以确保故障转移和恢复过程正确处理任何可能发生的数据不一致情况或复制事务。

note备注
尽管本文主要关注平台即服务,但使用 Azure 虚拟机的混合应用程序仍具有其他复制和可用性选项。这些混合应用程序使用基础结构即服务 (IaaS) 在 Azure 中的虚拟机上托管 SQL Server。因此,可在 SQL Server 中使用传统的可用性方法,如 AlwaysOn 可用性组或日志传送。某些方法(如 AlwaysOn)只能在本地 SQL Server 与 Azure 虚拟机之间发挥作用。有关详细信息,请参阅 Azure 虚拟机中的 SQL Server 高可用性和灾难恢复

另外设想一个在降级模式下运行的体系结构。辅助数据中心上的应用程序会停用所有功能,如报告、BI 或清空队列。它仅接受业务要求定义的事物工作流的最重要类型。系统将捕获事务并将其写入队列。在中断的初始阶段,系统可以推迟数据处理。如果主数据中心内的系统在预期的时间范围内重新激活,则主数据中心内的辅助角色可能会清空队列。此过程不需要合并数据库。如果主数据中心的停运超出可承受的范围,则应用程序可开始处理队列。这此方案中,辅助数据中心内的数据库包含增量事务数据,一旦主数据中心重新激活,就必须合并此类数据。下图展示此策略,用于临时存储事务数据,直到还原主数据中心。

图 8:仅用于事务捕获的降级应用程序模式

有关具有复原功能的 Azure 应用程序的数据管理方法的更多讨论,请参阅防故障:弹性云体系结构的指南

任务关键型应用程序需要做好准备,以防止整个数据中心停止运行。可以通过将多数据中心部署策略合并到运营规划中来实现这一目标。多数据中心部署可能需要 IT 专业人员在经历灾难后将应用程序数据和引用数据发布到辅助数据中心。如果应用程序要求立即进行故障转移,则部署过程可能涉及主动/被动或主动/主动设置。此类部署具有在备用数据中心内运行应用程序的现有实例。如前所述,Azure Traffic Manager 等路由工具会在 DNS 级别提供负载平衡服务。此类工具可检测到停运,并在需要时将用户路由到其他数据中心。

如果从一开始就在解决方案中加入 Azure 灾难恢复,它就成功了一部分。云提供了其他可用于在灾难期间从故障中恢复的选项,而传统的托管提供商无法提供此类选项。具体来说,你可以动态而迅速地为另一数据中心分配资源,因而不必为闲置资源花费大量资金却坐等故障发生。

以下各节涵盖灾难恢复的不同部署拓扑。通常,在提高可用性时,需要在增加成本或复杂性之间取得平衡。

单区域部署实际上不是一种灾难恢复拓扑,而是旨在与其他体系结构进行对比。单区域部署对于 Azure 中的应用程序较为常见。但它不是灾难恢复计划的有力竞争对手。下图介绍在单个 Azure 数据中心内运行的应用程序。如前所述,Azure 结构控制器以及使用容错域和升级域可提高数据中心内应用程序的可用性。

图 9:单区域部署

此处,数据库显然是单点故障。即使 Azure 跨越不同的容错域将数据复制到内部副本,也都是在同一数据中心内进行。它无法承受灾难性故障。如果数据中心停运,则所有容错域均停运,其中包括所有服务实例和存储资源。

对于所有应用程序(最不重要的除外),必须制定计划以将应用程序部署到不同区域中的多个数据中心内。在考虑要使用哪种部署拓扑时,还应考虑 RTO 和成本的限制。

现在来看支持在不同数据中心内进行故障转移的特定模式。以下示例都使用两个数据中心说明该过程。

在此模式下,仅主数据中心有应用程序和数据库在运行。辅助数据中心未设置为自动故障转移。因此,在发生灾难时,必须启动新数据中心内服务的所有部分。其中包括将云服务上载到 Azure、部署云服务、还原数据和更改 DNS 以重新路由流量。

虽然这是最实惠的多区域选项,但其 RTO 特征最差。在此模型中,服务包和数据库备份存储在本地或辅助数据中心的 Blob 存储中。但必须先部署新服务并还原数据,然后才能继续操作。即使完全自动从备份存储中传输数据,使新数据库环境正常运转仍然会花费大量时间。将数据从备份磁盘存储移至辅助数据中心内的空数据库是还原过程中成本最高的部分,但必须这样做才能使新数据库进入正常运行状态,因为并未复制该数据库。

最佳方法是将服务包存储在辅助数据中心内的 Azure Blob 存储中。这样不必将包上载到 Azure,而从本地的开发计算机进行部署时就要这样做。可以使用 PowerShell 脚本,迅速将服务包从 Blob 存储部署到新云服务中。

此选项仅适用于可承受高 RTO 的非关键应用程序。例如,此选项可能适用于可关闭数小时,但应在 24 小时内再次运行的应用程序。

图 10:重新部署到辅助 Azure 数据中心

许多公司倾向于选择主动/被动模式。与重新部署模式相比,这种模式增加相对较少的成本即可提高 RTO。在此方案中,同样存在主辅 Azure 数据中心。所有流量均流向主数据中心内的主动部署。辅助数据中心为灾难恢复所做的准备更充分,因为两个数据中心内均运行有数据库。而且,它们之间还建立了同步机制。这种备用方法可能涉及两种变化形式:仅数据库方法或在辅助数据中心内进行完全部署的方法。

在主动/被动模式的第一种变化形式中,只有主数据库部署了云服务应用程序。但是,与重新部署模式不同,这两个数据中心与数据库内容进行同步(请参阅事务数据模式(灾难恢复)一节)。发生灾难时,激活要求会更低。你启动辅助数据中心内的应用程序,将连接字符串更改为新数据库,然后更改 DNS 条目以重新路由流量。

与重新部署模式一样,服务包应已存储在辅助数据中心内的 Azure Blob 存储中,以便更快进行部署。与重新部署模式不同的是,数据库还原操作所需的大部分开销并非由你产生。数据库已就绪并在运行。这样可节省大量时间,使这种模式成为最经济并因此也是最普遍的 DR 模式。

图 11:主动/被动(仅数据库)

在主动/被动模式的第二种变化形式中,主辅数据中心均为完全部署。这种部署包括云服务和同步数据库。但是,只有主数据中心在主动处理来自用户的网络请求。只有当主数据中心停机时,辅助数据中心才会激活。在这种情况下,会将所有新网络请求路由到辅助区域。Azure Traffic Manager 可自动管理此故障转移。

由于已部署相关服务,因此故障转移的速度比仅数据库变化形式更快。此模式的 RTO 非常短;在主数据中心发生故障时,辅助故障转移数据中心必须能够立即投入使用。

除了响应更快之外,此模式还具有预先分配和部署备份服务的优点。不必担心数据中心没有空间可在发生灾难时分配新实例。如果辅助 Azure 数据中心接近最大容量,则这一点很重要。无法保证 (SLA) 立即可在任何数据中心内部署大量新的云服务。

为了尽量缩短此模型的响应时间,主辅数据中心的规模(角色实例数)必须相近。尽管存在一些优点,但由于为未使用的计算实例付费的成本高昂,通常这不是最明智的财务选择。因此,更常见的做法是在辅助数据中心内使用规模略有缩减的云服务版本。因此,可在必要时迅速进行故障转移和横向扩展辅助部署。你应当自动完成故障转移过程,以便一旦主数据中心发生故障,即根据负载激活其他实例。这可能涉及某种类型的自动缩放机制,如自动缩放预览自动缩放应用程序块。下图展示一种模型,其中主辅数据中心均包含处于主动/被动模式的完全部署的云服务。

图 12:主动/被动(完整副本)

至此,你可能明白了解这些模式的演化过程 - 降低 RTO 会提高成本和复杂程度。主动/主动解决方案实际上打破在成本方面的这种倾向。在主动/主动模式下,云服务和数据库在这两个数据中心内均部署齐全。与主动/被动模型不同的是,两个数据中心都会接收用户流量。此选项产生的恢复时间最快。相关服务已经过扩展,以在每个数据中心处理一部分负载。已启用 DNS,便于使用辅助数据中心。在确定如何将用户路由到相应的数据中心的过程中,还有其他复杂因素。尽管可采用循环计划,但很可能某些用户会使用其数据的主副本所在的特定数据中心。

在故障转移时,只需禁止 DNS 访问主数据中心,即可将所有流量路由到辅助数据中心。即使在此模型中,也有一些变化形式。例如,下图展示一种模型,其中主数据中心拥有数据库的主控副本。两个数据中心内的云服务均写入该主数据库。辅助部署可从主数据库或复制的数据库进行读取。本例中的复制为单向进行。

图 13:主动/主动

上图中的主动/主动体系结构有一个缺点。第二个数据中心必须访问第一个数据中心内的数据库,因为主控副本存放在那里。从数据中心之外访问数据时,性能大幅下降。在跨数据中心调用数据库时,应考虑使用某种类型的批处理方法以提高这些调用的性能。有关详细信息,请参阅 Azure 中 SQL Database 应用程序的批处理方法。另一种备选体系结构可能要求每个数据中心直接访问其数据库。在该模型中,将需要进行某种类型的双向复制以同步每个数据中心内的数据库。

在主动/主动模式中,主数据中心内需要的实例数量可能不像主动/被动模式那么多。如果主动/被动体系结构的主数据中心内有 10 个实例,则在每个主动/主动体系结构的数据中心内可能只需要 5 个实例。现在两个区域分担负载。如果在被动数据中心内将 10 个实例保持在热备用状态以等待故障转移,则这样做可能比主动/被动模式更为节省成本。

如果直到主数据中心还原后才意识到这一点,则辅助数据中心的新用户可能会突然间猛增。如果在主数据中心发生故障时每个服务器上有 10,000 个用户,则辅助数据中心现在突然间必须处理 20,000 个用户。针对辅助数据中心的监视规则必须检测到这种增长情况,并将辅助数据中心内的实例增加一倍。有关这方面的详细信息,请参阅故障检测部分。

另一个灾难恢复策略是设计一个同时在本地和云中运行的混合应用程序。根据应用程序的不同,主数据中心可能在任一位置。以前面的体系结构为例,并假设主辅数据中心均位于本地。

这些混合体系结构中有一些难题。首先,本文大部分内容处理的是平台即服务 (PaaS) 体系结构模式。Azure 中的典型 PaaS 应用程序依赖 Azure 特有的构件,如角色、云服务和结构控制器。为此类型的 PaaS 应用程序创建本地解决方案所需的体系结构显著不同。就管理或成本角度而言,这一点可能不可行。

但是,对直接移至云中的传统体系结构来说,混合灾难恢复解决方案面临的挑战更少。对于使用基础结构即服务 (IaaS) 的体系结构就是这样。IaaS 应用程序使用云中的虚拟机,这些虚拟机在本地具有直接等效项。使用虚拟网络还可将云中的虚拟机与本地网络资源相连。这样就产生了多种仅 PaaS 应用程序所不具备的可能性。例如,SQL Server 可利用灾难恢复解决方案,如 AlwaysOn 可用性组和数据库镜像。有关详细信息,请参阅 Azure 虚拟机中 SQL Server 高可用性和灾难恢复

IaaS 解决方案还为本地应用程序使用 Azure 作为故障转移选项提供一个更方便的途径。可能在现有的本地数据中心内具有完全正常运行的应用程序。但如果缺少资源,无法维护分散在各地的数据中心以进行故障转移,该怎么办呢?可能决定使用虚拟机和虚拟网络在 Azure 中运行应用程序。定义将数据同步到云的过程。然后,Azure 部署成为用于故障转移的辅助数据中心。主数据中心仍为本地应用程序。有关 IaaS 体系结构和功能的详细信息,请参阅虚拟机虚拟网络

有时,即使 Microsoft 云这样可靠的服务也无法满足你的可用性要求。过去一年左右的时间内,各种云平台发生了几次严重的中断事件;这包括 Amazon Web Services (AWS) 和 Azure 平台。即使是最完善的准备和设计也无法在发生灾难时实施备份系统,整个云可能需要一整天时间恢复。

你需要将可用性要求与提高可用性所需的成本和复杂程度进行比较。执行风险分析,然后为解决方案定义 RTO 和 RPO。如果应用程序无法承受任何停机,则可能需要考虑使用其他云解决方案。除非整个 Internet 同时瘫痪,否则在 Azure 罕见地完全停机的情况下,其他云解决方案(如 Rackspace 或 Amazon Web Services)仍将正常运转。

和混合方案一样,其他云解决方案中也可存在以前 DR 体系结构中的故障转移部署。备选云 DR 站点应仅用于那些 RTO 只允许极短停机时间(如有)的解决方案。请注意,使用 Azure 以外 DR 站点的解决方案将需要在配置、开发、部署和维护方面做更多工作。此外,在跨云的体系结构中实施最佳实践也更加困难。尽管云平台的高级概念相似,但 API 和体系结构各有不同。如果决定将 DR 分散在不同平台上,则在解决方案的设计中加入抽象层会有一定意义。如果这样做,就不必为各种云平台开发和维护同一应用程序的两个不同版本来应对灾难。和混合方案一样,在这些情况下使用虚拟机可能比云特定的 PaaS 设计更加方便。

我们刚刚讨论的某些模式需要迅速激活离线部署以及还原系统的特定部分。通过自动化或脚本处理,可按需激活资源以及迅速部署解决方案。在本文中,与 DR 相关的自动化等同于 Azure PowerShell,但也可以选择服务管理 REST API。开发脚本可帮助管理 Azure 无法透明地处理的 DR 部分。这样做的优点是每次产生的结果均保持一致,因而使人为出错的几率降至最低。预先定义 DR 脚本还可缩短在灾难中途重建系统及其组成部分的时间。你不想尝试自己解决如何在停机时还原站点,因为分分秒秒都在损失金钱。

创建脚本后,应自始至终不断测试这些脚本。验证这些脚本的基本功能后,请确保在灾难模拟中测试它们。这样有助于揭示脚本或过程中的缺陷。

自动化的最佳实践是创建 Azure DR PowerShell 脚本的存储库。请确保清楚标注这些脚本并对它们分类,以便于查找。指派一个人管理脚本的存储库和版本控制。请通过参数解释和脚本使用示例,妥善记录这些脚本。另外请确保将此文档与 Azure 部署保持同步。这样强调让一个人管理存储库的所有部分的意图所在。

若要正确地处理可用性和灾难恢复的问题,必须可检测和诊断故障。应对服务器和部署进行高级监视,以使你可在系统或其部分突然停运时迅速了解情况。检查云服务及其依赖项的总体运行状况的监视工具可完成这其中的一部分工作。Microsoft 提供的两个工具是 MetricsHubSystem Center 2012 R2 (SCOM)。AzureWatch 等其他第三方工具也可提供监视功能。通过 AzureWatch,还可自动进行伸缩。大多数监视解决方案跟踪关键的性能计数器和服务可用性。

尽管这些工具很重要,但仍需要为云服务中的故障检测和报告进行规划。必须规划以正确使用 Azure 诊断。自定义性能计数器或事件日志条目也可成为总体策略的一部分。这样可在故障期间提供更多数据以迅速诊断问题并恢复所有功能。它还为监视工具提供其他指标,用于确定应用程序的运行状况。有关详细信息,请参阅使用 Azure 诊断收集日志记录数据。有关如何规划总体“运行状况模型”的讨论,请参阅防故障:弹性云体系结构的指南

模拟测试涉及在真实工作环境下营造小规模的真实情形,以观察团队成员的反应。模拟还会展示在恢复计划中概述的解决方案的效果。执行模拟的方式应以所营造的情景不会中断实际业务,仍感觉像“真实”情况为准。

设想在应用程序中设计某种类型的“切换面板”以手动模拟可用性问题。例如,通过软开关,使订购模块发生故障,从而触发该模块的数据库访问异常。可将类似的轻型方法用于网络接口级别的其他模块。

将在模拟期间重点关注任何未充分解决的问题。模拟的方案必须完全可控。也就是说,即便恢复计划似乎会失败,也可以使情况恢复正常,而不会导致任何重大损害。还应向高级管理人员通知将执行模拟练习的时间和方式,这一点也很重要。此计划应包括有关在运行模拟测试时可能无法用于生产的时间或资源的信息。使灾难恢复计划经受测试时,还要定义将如何衡量成功,这一点也很重要。

还有多种其他方法可用于测试灾难恢复计划。但是,其中大多数只是这些基本方法的修改版。此测试背后的主要动机是评估恢复计划的合理程度和可行程度。灾难恢复测试侧重于详细信息以发现基本还原计划中的漏洞。

下面总结本文已讨论的要点,以期给出你在自己进行可用性和灾难恢复规划时应考虑事项的清单。这些最佳实践对于寻求认真实现成功的解决方案的客户非常有用。这种类型的解决方案确有实效,可在系统发生故障时及时而成功地恢复。

  1. 对每个应用程序执行风险评估,因为每个应用程序的要求可能各有不同。某些应用程序比其他一些重要,有理由投入额外的成本为这些应用程序设计灾难恢复功能。

  2. 使用此信息定义每个应用程序的 RTO 和 RPO。

  3. 从应用程序的体系结构开始,针对故障进行设计。

  4. 实现高可用性的最佳实践,同时在成本、复杂程度和风险之间取得平衡。

  5. 实现灾难恢复计划和过程。

    1. 设想故障跨越模块级别直至云完全瘫痪。

    2. 为所有引用数据和事务数据制定备份策略。

    3. 选择多站点灾难恢复体系结构。

  6. 定义灾难恢复过程、自动化和测试的具体所有者。该所有者应管理并拥有整个过程。

  7. 记载这些过程,以使其可轻松重复。尽管只有一个所有者,但应有多人可了解这些过程并在紧急情况下按这些过程操作。

  8. 培训人员以实现进程。

  9. 定期进行灾难模拟以进行过程的培训和验证。

在 Azure 中有硬件或软件发生故障时,处理这些故障的技术和策略与在本地系统上发生故障时有所不同。这主要是因为云解决方案通常更加依赖分散在数据中心内并作为单独服务管理的基础结构,因此必须使用高可用性技术处理部分故障。若要处理更严重的故障(可能由于灾难事件导致),请使用灾难恢复策略。

Azure 可检测并处理许多故障,但有许多类型的故障需要使用应用程序特有的策略。必须主动为应用程序、服务和数据的故障做准备并应对这些故障。

制定应用程序的可用性和灾难恢复计划时,请考虑应用程序故障造成的业务后果。定义在灾难性事件后恢复关键系统的流程、策略和过程需要投入时间、规划和精力。制定计划后,并不能就此止步,还必须根据应用程序组合、业务需求和可用的技术,定期分析、测试并不断完善这些计划。对于创建可承受故障的可靠应用程序,Azure 不仅提供新功能,也产生新难题。

另请参阅

显示:
© 2014 Microsoft