在 Azure 存储中断时该怎么办

Microsoft 一直努力确保所提供的服务始终可用。 但有时候,各种不可控因素会导致一个或多个区域出现计划外服务中断,对我们造成影响。 为了帮助你应对这些偶发事件,我们提供了下述针对 Azure 存储服务的概述性指导。

如何准备

每个客户都应准备好自己的灾难恢复计划,这很重要。 从存储中断进行恢复时,通常需要操作人员和自动化过程的参与,目的是在正常运行状态下重新激活应用程序。 制定自己的灾难恢复计划时,请参阅以下 Azure 文档:

如何检测

若要确定 Azure 服务状态,建议订阅 Azure 服务运行状况仪表板

在存储空间中断时该怎么办

如果一个或多个区域的一个或多个存储服务临时不可用,可以考虑两种选项。 如果需要立即访问数据,请考虑“选项 2”。

选项 1:等待恢复

在此情况下,不需要采取任何操作。 我们正在努力还原 Azure 服务的可用性。 可在 Azure 服务运行状况仪表板上监视服务状态。

选项 2:从辅助数据库复制数据

如果为存储帐户选择读取访问异地冗余存储 (RA-GRS)(推荐),就可以从次要区域访问数据。 可使用 AzCopyAzure PowerShellAzure 数据移动库之类的工具将数据从次要区域复制到不受影响区域的其他存储帐户中,然后将应用程序指向该存储帐户,确保可读取和写入。

进行存储空间故障转移时会发生什么情况

如果选择异地冗余存储 (GRS)读取访问地域冗余存储 (RA-GRS)(推荐),Azure 存储会将数据持久保存在两个区域(主要区域和次要区域)中。 在这两个区域,Azure 存储始终维护你数据的多个副本。

当区域灾难影响主要区域时,我们会首先尝试还原该区域的服务。 在很少的情况下,我们可能无法还原主要区域,具体取决于灾难的性质及其影响。 在那种情况下,我们会进行异地故障转移。 跨区域数据复制是一个可能有延迟的异步过程,因此,可能会丢失尚未复制到次要区域的更改。 若要详细了解复制状态,可查询存储帐户的“上次同步时间”

有关存储空间异地故障转移体验的一些观点:

  • 只能通过 Azure 存储团队触发存储空间异地故障转移 - 不需客户操作。
  • 针对 Blob、表、队列和文件的现有存储服务终结点在故障转移后保持不变;需要更新 DNS 条目才能从主要区域切换到次要区域。
  • 在异地故障转移之前和过程中,由于灾难的影响,无法对存储帐户进行写入访问,但如果存储帐户已配置为 RA-GRS,则仍然可以从次要区域进行读取。
  • 完成异地故障转移且传播 DNS 更改以后,对存储帐户的读取和写入访问权限恢复;指向曾经是辅助终结点的位置。
  • 请注意,如果为存储帐户配置了 GRS 或 RA-GRS,则用户将具有写入访问权限。
  • 若要了解更多详细信息,可查询存储帐户的“上次异地故障转移时间”
  • 在故障转移之后,存储帐户完全可以正常使用,但处于“已降级”状态,因为实际上它是托管在独立区域中,不可能进行异地复制。 为了缓解此风险,我们需要还原原始的主要区域,并通过异地故障回复还原原始状态。 如果原始的主要区域不可恢复,我们会分配其他次要区域。 有关 Azure 存储异地复制基础结构的更多详细信息,请参阅存储团队博客中有关 冗余选项和 RA-GRS的文章。

数据保护最佳实践

可以通过一些推荐的方法定期备份存储数据。

若要深入了解如何创建充分利用 RA-GRS 功能的应用程序,请参阅使用 RA-GRS 存储设计高可用性应用程序