构建弹性存储架构

在现代云计算环境中，构建一个具有弹性的存储架构是至关重要的。本文将探讨如何设计一个能够应对各种故障情况的存储系统。首先，需要了解服务等级协议（SLA）对于存储系统的重要性。目前，如果使用的是本地冗余存储（LRS），SLA为99.9%，这对于许多应用程序来说可能不够理想。但如果使用读访问地理冗余存储（RA-GRS），SLA可以提高到99.99%。

对于刚刚接触Blob存储的人来说，了解不同类型的存储选项是必要的：

• 本地冗余存储（LRS）：这意味着存储在Blob存储中的3份数据副本都存储在同一区域。
• 区域冗余存储（ZRS）：这意味着存储在Blob存储中的3份数据副本存储在不同的可用区域。
• 地理冗余存储（GRS）：这意味着存储在Blob存储中的3份数据副本存储在多个区域，遵循Azure区域配对。
• 读访问地理冗余存储（RA-GRS）：这意味着存储在Blob存储中的3份数据副本存储在多个区域，遵循Azure区域配对。但在这种情况下，可以控制一个只读访问端点。

基于上述信息，推荐使用RA-GRS，这是Azure独有的特性。RA-GRS允许拥有一个次要端点，可以从中以只读方式访问保存在次要区域的备份副本。

根据这个建议，如果存储账户名为：

那么次要只读访问端点将是：

接下来的问题可能是：“这很好，但需要能够读写。” 为此，推荐一个架构模式：

上述架构虽然简化，但专注于存储账户配置以实现更高的可用性。在上述架构中，有一个部署在流量管理器后面的Web应用程序，它在主区域和次区域都有实例。此外，有一个AzureSQL数据库，它被异步复制到备份区域。

假设在上述情况下：

• 区域A => 美国东部
• 区域B => 美国西部

对于存储，执行以下操作：

• 存储账户A将位于美国东部，这意味着它将自动复制到美国西部。
• 存储账户B将位于美国西部，这意味着它复制到美国东部。

让看看区域A的情况：

• 新的Blob写入存储账户A（1,2,3）。
• 根据数据库条目读取Blob。
• 应用程序尝试从数据库识别的Blob存储读取，如果失败，它使用“-secondary”端点。

对于区域B的情况：

• 新的Blob写入存储账户B（4,5,6）。
• 根据数据库条目读取Blob。
• 应用程序尝试从数据库识别的Blob存储读取，如果失败，它使用“-secondary”端点。

在数据库中，建议为每个保存的Blob推荐以下字段：

• 存储账户名称
• 容器名称
• Blob名称

这允许轻松实现在需要时使用“-secondary”。

基于上述，让模拟一系列事件：

• 正在将Blob写入存储账户A（1,2,3）。
• 发生故障，故障转移到区域B。
• 开始将新的Blob写入存储账户B（4,5,6）。
• 如果想读取Blob 1，通过存储账户A的“-secondary”端点进行。
• 问题解决。
• 从存储账户A（主端点）读取Blob 1-3。
• 如果读取Blob 4-6，它将来自存储账户B的“-secondary”端点。