【问题标题】:How to write to Azure storage when the primary region down?主要区域关闭时如何写入 Azure 存储?
【发布时间】:2021-04-09 16:37:28
【问题描述】:

我们的应用程序使用 RA-GZRS 进行存储,当主服务器关闭时,它可以从辅助服务器读取数据,但无法写入。

是否有一种解决方案可以让应用程序在 Azure 区域出现故障时对存储进行读取和写入?

【问题讨论】:

  • 如果您需要真正的双活存储解决方案(您可以在其中写入多个区域),那么 CosmosDB 将是您唯一的解决方案

标签: azure azure-storage redundancy


【解决方案1】:

在 Azure 存储中,只能有一个区域(主)可供您写入。其他区域(次要)将始终为只读。

一种可能的解决方案是进行手动故障转移,以便您帐户的次要区域成为主要区域,然后您应该能够对其进行写入。但是,请注意手动故障转移有很多注意事项,请确保您理解这些。

您可以在此处阅读有关这些内容的更多信息:https://docs.microsoft.com/en-us/azure/storage/common/storage-initiate-account-failover?tabs=azure-portal#important-implications-of-account-failover

【讨论】:

  • 为了保持业务继续,应该有一些架构设计来克服只写主要的限制,这样我们即使在主要的关闭时也能继续写入存储。你知道这样的事吗?
  • AFAIK,不幸的是,Azure 原生没有这种类型的东西。您需要推出自己的解决方案 IMO。
  • 文档here 说“在只读模式下运行时有很多方法可以处理更新请求。”这么多方法是什么?
【解决方案2】:

请转至this。引用文章:

如果主要区域不可用,您可以选择故障转移 到次要区域。故障转移完成后, 次要区域成为主要区域,您可以再次阅读 并写入数据。有关灾难恢复和学习的更多信息 如何故障转移到次要区域,请参阅灾难恢复和 存储帐户故障转移。

教程here 告诉您如何构建一个高可用性应用程序,该应用程序在发生故障时自动 在端点之间切换。它使用断路器模式。

【讨论】:

  • 根据link ,“启动后的故障转移可能会有所不同,但通常不到一小时”。考虑到故障转移过程所涉及的持续时间,在主要区域关闭时选择故障转移到次要区域以克服 RA-GZRS 的写入限制不适合生产工作负载。
  • 一般来说,为了避免这种情况下的数据丢失,存储并不是唯一使用的持久性机制。您可以将数据放在队列中(服务总线),并让一个进程将其拾取并将其写入存储。所有这些都需要在事务中完成。如果存储数据有任何问题,在队列中仍然是安全的。
猜你喜欢
  • 2018-12-11
  • 1970-01-01
  • 2014-10-16
  • 1970-01-01
  • 1970-01-01
  • 2011-08-31
  • 1970-01-01
  • 2017-08-12
  • 1970-01-01
相关资源
最近更新 更多