在 Microsoft Azure 上规划灾难恢复策略 – 定义恢复要求

介绍

欢迎来到微软设计灾难恢复策略系列。Azure 和初始模块确定这些先决条件。了解如何确定恢复要求。例如，我们将讨论如何部署弹性策略。之后，我们将研究如何在 Azure 云上进行数据备份。然后，对于 Azure 应用程序，我们将看到更多的故障分析。然后我们将专注于创建Andrea的复制计划，最后我们将结束整个课程。我们将在本模块中讨论为 Azure 应用程序设计和实现灾难恢复。RTO、RPO 和 RLO 是我们将要讨论的一些术语。我们还将研究灾难恢复如何适用于一些最流行的 Azure PaaS 服务，例如 Azure 应用服务、Azure SQL、Cosmos DB 和存储帐户（Azure Storage Account）。

定义恢复要求

特定 azure 服务的弹性检查表

我们将重点关注弹性和灾难恢复等术语，并探索几种流行的 Azure 服务。我们将首先解释两个关键术语灾难恢复和弹性。

灾难恢复

中断后，灾难恢复会详细说明用于恢复解决方案可用性的过程。它是指在自然或技术事件导致部分或完全故障后，将系统和数据恢复到先前可接受状态的过程。考虑有人删除了数据库中的表或我们的 Web API 无缘无故停止工作的可能性。从这里开始，我们必须尽一切可能恢复解决方案的可用性。因此，我们不仅必须确定发生了什么，而且还要向最终用户提供此解决方案。

弹性

它是系统从故障中恢复并在故障发生后继续运行的能力。重要的是要记住，在创建和部署应用程序解决方案时，每种技术都有自己的一组故障模式。

有一些与弹性和灾难恢复相关的重要问题需要问：

• 我们投资多少来使我们的应用程序高度可用？
• 潜在的停机时间会给我们的业务带来多少损失？
• 我们客户的可用性要求是什么？

如何实现弹性？

确定订阅和服务要求

确定订阅和服务要求的过程涉及许多关键过程。某些资源（例如资源组、课程和存储帐户的数量）在每个 Azure 订阅中都有限制。如果我们的应用程序要求超出其他订阅限制，我们可以选择创建新的 Azure 订阅并在那里预配足够的资源。

应用弹性策略

正在实施复原力战略。重试瞬态故障是这些解决方案之一。Transcend 失败可能是由于暂时缺乏网络连接、数据库连接断开或服务繁忙期间造成的，通常通过重试请求来修复。另一种选择是尽可能多地使用同步操作。当颜色等待进程完成时，同步进程可能会独占资源并阻碍其他操作。在可行的情况下，设计程序的每个部分以遵循同步过程。

规划使用模式

确定关键和非关键时期的需求差异。是否有任何时候系统必须启动并运行？例如，报税申请可能会在报税截止日期期间失败，而视频流服务在直播活动期间不应滞后。在这种情况下，权衡成本与风险。

识别不同的工作负载

在各种工作负载下确定。多个应用程序工作负载在云解决方案中很常见。在业务逻辑和数据存储要求方面，工作负载是与其他任务在逻辑上分离的独特能力或任务。例如，电子商务应用程序可能具有以下工作负载：浏览和搜索产品目录、创建和跟踪订单、查看推荐。每个工作负载对可用性、可扩展性、数据一致性和灾难恢复都有不同的要求。通过平衡每个工作负载的风险原因来做出业务决策。

多区域运营

跨区域运行，在你的应用部署到一个区域的特殊情况下，整个区域变得不可用。此外，您的应用程序将无法访问。这可能违反了您的申请条款。如果是这种情况，请考虑跨多个位置部署您的软件及其服务。

监控第三方服务

如果您的应用程序依赖于第三方服务，请定义服务可能失败的位置和方式，以及失败对您的应用程序的影响。

应用负载均衡

需要像 Azure 流量管理器这样的流量管理系统来应用负载均衡来负载均衡区域之间的流量。通过移除运行状况不佳的实例以进行额外轮换，负载平衡将您的应用程序请求分配给运行状况良好的服务实例。

识别可能的故障点

识别系统的潜在故障点。确定应用程序上发生的故障类型、我的经验以及程序如何响应这些故障。

Azure 配对区域

Azure 配对区域是包含一个或多个数据中心的地理区域内的一个位置。每个 Azure 区域都与同一地理区域内的另一个区域链接以形成区域对。例如，我们可以在北欧和西欧地区的两个不同地区部署我们的 Azure 资源。

Azure 区域对

多个区域法利赛人可以在天蓝色中访问。这里还有一些例子。华北、华东、法国中部、法国南部、德国、德国中部、德国东北部我们可以在左侧看到两个区域的自负区域，我们已经看到这些区域存在Azure数据中心。有关更多详细信息，请访问：https://docs.microsoft.com/en-us/azure/best-practices-availability-paired-regions

Azure 可用区

可用区是 Azure 区域内唯一的物理位置。为确保弹性，所有启用的区域中至少有三个独立的区域。我们可以看到左侧有一个 Azure 区域。有三个不同的可用性区域。如果一个区域不可用，我们仍然可以使用其中的两个区域。

Azure PaaS 服务

Azure Web 应用服务、Azure SQL 数据库、Azure Cosmos DB 和 Azure 存储帐户都提供 PaaS 服务。我们不会详细介绍每个服务提供的功能。我们将讨论这些服务以及如何使它们更具弹性和可用性。

Azure Web 应用（应用服务）

Azure Web 应用服务、Web 应用程序、Rest API 和移动后端都可以使用此基于 HTTP 的服务进行托管。它支持多种语言和框架，包括

• ASP.NET
• Java
• PHP

我们可以通过在全球范围内以高可用性为某些资源（例如内存或 CPU）增加功率，从而使用大量实例水平扩展 Azure Web 应用服务。

Azure SQL 数据库

Azure SQL 数据库是一个可用于任何事情的关系数据库。它是一项 Azure 托管服务，允许您处理关系和非关系结构，例如

• Jason
• XML

它还具有高级监控和故障排除功能。

Azure Cosmos 数据库

Cosmos DB 是 Azure 提供的全球分布式多模型数据库服务。它通过各种 API 提供数据访问，例如

• Mongo DB
• SQL

它允许在全球各个 Azure 区域之间弹性和独立地扩展吞吐量和存储。

Azure Storage Account

Microsoft Azure 存储帐户是一种用于存储当前数据的云存储解决方案。这些数据服务的场景包含在 Azure 存储中。

• Azure blobs
• Azure files
• Azure Queues
• Azure tables

Azure 应用服务的弹性清单

现在，每个服务都有一个特定的弹性检查表。例如，我们应该为 Azure Web App 服务选择标准或高级层。该层支持暂存槽和自动备份。因此，如果部署过程中出现问题，我们可以恢复到应用程序的先前版本。

避免按比例放大或缩小也是一个好主意。相反，我们应该选择与我们在通常负载下的性能需求相匹配的层和即时大小，然后扩展实例以应对流量的变化。向上和向下扩展可能会导致应用程序挂起，这对最终用户来说可能是个问题。

分别创建生产和测试应用服务计划。不应使用我们生产部署上的插槽来测试同一应用服务计划中的所有应用。如果我们将相同的虚拟机实例用于生产和测试部署，则会对生产部署产生不利影响。例如，将测试部署转移到单独的计划中会缩短生产端的生命周期。它们在生产版本中很容易访问。

诊断记录是我们弹性检查表的另一个重要方面。我们已启用日志记录。我们可以简单地跟踪程序中的错误，当然，还可以快速提供补丁。关于弹性还有一些额外的要点。请仔细检查 azure 应用程序服务；然而，这里有一些关键的例子。

Azure SQL 数据库的弹性清单

当涉及到 Azure SQL 数据库的弹性清单时，需要考虑几个关键问题，例如是使用标准层还是高级层。45 天后，这些层的时间点恢复持续时间更长。

还应启用 SQL 数据库审计。审计对于检测恶意攻击和人为错误很有用。还应使用主动异地复制在单独的区域中构建可读的辅助节点。如果我们的主数据库出现故障或需要离线，我们可以手动故障转移到我们的辅助数据库。在我们进行故障转移之前，辅助数据库保持只读状态。

还应使用时间点还原来从人为错误中恢复。恢复将我们的数据库恢复到以前的状态。这些元素至关重要，因为如果没有足够的数据库访问权限，我们的应用程序将变得毫无价值。

Azure Cosmos DB 的弹性清单

谈到弹性，Cosmos DB 的清单。使用 Azure Cosmos DB 时应考虑两个关键因素。应该在区域之间复制数据库。因此，即使一个区域不可用，我们仍然可以从另一个区域访问和读取数据。如果需要，我们还应该在另一个区域允许多主。在这种情况下，我们可以写入许多 Azure 区域。这意味着即使一个区域不可用，数据仍然可以写入另一个区域。

Azure 存储帐户的弹性清单

Azure 存储帐户的弹性清单也有一些有趣的点。我们应该为应用程序数据使用重新访问地理冗余存储。此存储将数据复制到次要区域并允许从该位置进行只读访问。如果主区域的存储出现故障，程序可以从次区域的虚拟机磁盘中读取数据。

我们应该使用它，因为磁盘彼此正确分离，这为可用性集中的虚拟机提供了更高的可靠性。到。避免在队列存储方面出现单点故障。对于 Queue 存储，我们应该在另一个区域构建一个备份 Queue。我们应该改为建立一个备份队列。在不同区域的存储帐户中。如果出现存储中断，程序可以使用备份队列。直到主要区域可用。

确定并记录 RTO、RPO 和 RLO 恢复要求

恢复时间目标 RTO

让我们从 RTO（恢复时间目标）开始。这是我们的业务流程必须在灾难后恢复的时间和服务水平，以避免不可接受的负面影响。与事件流的中断相关联。

这意味着在发生灾难（例如白色系统感染或用​​户破坏生产数据）时，RTO 是从危机中恢复并恢复数据和应用程序所需的时间。恢复时间的目标是非常关键的。考虑一下着火的银行应用程序的情况。比如删除整个数据库和用户的表好还是只删除用户数据的表好？无法登录该程序的用户无法访问重要数据。我们必须尽一切可能将系统恢复到用户可以访问的状态。

恢复点目标 (RPO)

恢复点 RPO 的目标是指在中断期间丢失的数据量超过业务需求之前可以经过的时间量。连续性计划的最大允许阈值 例如，如果中断期间可用的最后一个完好的数据副本是 18 小时前，并且该业务的 RPO 是 20 小时，我们仍处于业务连续性计划 RPO 的范围内。换句话说，这就是问题的解决方案。鉴于在此期间丢失的数据量，业务流程恢复可以标记到什么程度？

恢复水平目标 (RLO)

RLO 指定必须恢复数据的粒度级别，例如整个实例、数据库或数据库组，或整个系统中的选定表。例如，我们必须确定是否需要恢复Web 应用程序，或者是否需要恢复数据库结构，或者是否需要恢复整个系统。

Azure 应用程序的备份和灾难恢复

灾难恢复计划

许多 Azure 服务具有内置的弹性和可用性特征。如果单独评估每项服务，灾难恢复计划可能会得到改进。例如，Azure SQL 数据库支持异地复制。如果由于删除了表（例如用户表）而导致某个 Azure 区域中的数据不可用，我们仍然可以从第二个 Azure 区域访问数据。这是相当有益的。另一种选择是 Azure Cosmos DB，它允许我们启用异地复制以及写入多个区域。当悲剧发生时，一旦我们的补救措施可用，建立一个灾难恢复计划也是一个好主意。让我们看看这样一个计划的一些方面。

• 评估应用程序故障的业务影响
• 尽可能使流程自动化
• 记录过程，尤其是任何手动步骤
• 选择跨区域恢复架构
• 定期执行灾难模拟以验证和改进计划

首先，我们必须评估应用程序失败的财务影响。例如，我们应该回应一个基本的询问。如果应用程序无法运行会怎样？我们几乎肯定会赔钱。我们还应该尝试尽可能多地自动化程序。例如，我们应该有自动发布管道以允许快速恢复。我们还应该记录流程，尤其是任何手动流程，并就如何从失败中恢复向团队成员提供明确的指示。我们还应该选择适用于跨区域的恢复架构。这是我已经提到的。我们应该跨多个区域部署我们的解决方案以实现灾难恢复。我们还应该定期运行灾难模拟来测试和改进策略。

多个 Azure 区域以实现高可用性

考虑使用多个 Azure 区域来实现高可用性。在两个地区，我们有 Web 应用程序。SQL 数据库、Cosmos DB 和 Azure 存储也可用。当第一个区域中的 Web 应用程序出现故障时，流量管理器可以通过第二个区域根植 Tropic，从而为我们的解决方案提供最大的可用性。

数据损坏和恢复

在处理数据损坏和恢复时保留备份是个好主意。备份可防止应用程序组件因数据损坏或无意删除而丢失；完成备份过程的频率设置了恢复点目标 RPO。如果 Azure 存储或 SQL 数据库中的数据在主数据库中损坏或删除，Azure 会将其存储在同一区域的不同完整域中 3 次。所有修改都被复制并复制到其他副本。

让我们来看看一些高可用性特性，

Azure 应用服务是 Azure 服务之一，最多可扩展到 30 个虚拟机实例。在常规和高级级别，它还支持暂存槽和自动备份。我们可以使用他们的部署槽来保存最后一个已知的良好部署。如果有问题，稍后会发现。有一种简单的方法可以返回到最后一个已知的良好版本。

你的应用程序在所有区域都支持Azure Cosmos DB。如果来自另一个区域的数据不可用，我们仍然可以访问来自另一个区域的数据。数据在第二个区域重复。Azure Cosmos DB 还支持多个正确区域。这意味着即使我们需要的数据无法访问一个区域，我们仍然可以将其写入另一个区域。在我们的故障转移之后，客户端像违反衰减一样，向当前适当的区域提交正确的请求。

当谈到Azure SQL 数据库的高可用性时，可以使用活动异地复制，它允许您创建可读的辅助副本。每个区域中最多可以有四个可读的辅助副本。如果主库出现故障或需要下线，我们可以切换到辅助库。只读访问

对于Azure 存储帐户，异地冗余存储提供高可用性。它将数据复制到次要区域，并为次要区域提供对数据的只读访问。

如果主区存储失败，程序可以从次区读取数据。为确保持久性和高可用性，始终复制 Microsoft Azure 存储帐户中的数据。

总结

在本文中，我们讨论了以下特定 Azure 服务（如 Azure 删除服务、Azure SQL 数据库、Cosmos DB 和存储帐户）的弹性检查表。我们解释 RTO、RPO 和 RLO 等术语。在下一篇文章中，我们将详细介绍 Microsoft Azure 上的数据备份