细说 Azure Storage 的冗余策略

当我们想要把应用搬到云端的时候，首先要关注的便是数据的安全性。当然所有的云服务厂商都会对用户数据承诺一个非常高的安全性，但万一出现意外呢？我们是不是还要有适当的应对方案？比如今年的3月8日晚间，Azure 某个区域中的存储几乎全部不能访问，持续达两个多小时。当时最担心的是：用户的数据万一丢掉怎么办？同时，我们是不是可以根据云服务提供的数据服务的特点来优化程序的性能呢？基于如此种种的原因，我们需要了解云端数据服务的一些特性的详情，这将对我们很有帮助。本文将和大家一起探讨 Azure Storage 的冗余策略。

理解 Azure Storage 冗余策略的好处

微软针对不同的应用场景提供了不同的存储冗余策略。比如对可靠性要求很高的数据可以选择多个异地的备份，而对访问速度要求高的数据则可以使用高速的存储设备。当然，不同的方案成本也是不一样的。我们可以针对应用的特点使用不同的存储策略，这样可以节省成本。还可以指定对应的容灾备份以及灾难恢复方案。

Azure Storage Account

需要注意的是，Azure Storage 存储的冗余策略是绑定在 Azure Storage Account 上的。Azure Storage 当前一共有四种数据的冗余策略，分别是：

Locally Redundant Storage(LRS)

Zone Redundant Storage(ZRS)

Geo Redundant Storage(GRS)

Read-access Geo Redundant Storage(RA-GRS)

当我们创建 Storage Account 的时候就需要指定其对应的存储的相关类型和策略：

Performance 选项目前有两种选择，分别是 "Standard" 和 "Premium"。准确的说，下面的 Replication 选项才是 Storage Account 的冗余策略。可是，冗余策略和性能选项是有关联性的。比如，当 performance 为 "Standard" 时，Replication 可以选择 ZRS, LRS, GRS, RA-GRS:

而 performance 为 "Premium" 时，Replication 则只能选择 LRS:

下面我们将详细的介绍这四种冗余策略及常见用例。

Locally Redundant Storage

本地冗余存储(LRS)，在单个数据中心里有多个同步的数据拷贝。数据在弹性存储单元中被复制三次，该弹性存储单元托管在创建存储帐户的区域中的数据中心内。 仅在写入所有三个副本后，才成功返回写入请求。 这三个副本驻留在同一弹性存储单元中的不同容错域和升级域中。

弹性存储单元是存储节点的机架的集合。 容错域 (FD) 是一组代表出错的物理单元的节点，可将其视为属于同一物理机架的节点。 升级域 (UD) 是一组在服务升级（推出）过程中一起升级的节点。 三个副本将分布在同一弹性存储单元中的 UD 和 FD 上，以确保即使在硬件故障影响单个机架时，或在推出期间升级节点时，数据也可用。

当看到这里时，相信你已经感受到了，即便是 Azure Storage 中最基础的 LRS 数据冗余策略也远高于我们自己维护的系统了！
LRS 的优点是成本最低，这里说的低是和其它类型的冗余策略相比。并且可以提高访问的性能，比如选择performance 为 “Premium” 时只能使用 LRS 策略。
但是它的缺点也很明显，就是无法应对整个数据中心都 crash 的情况(火灾、洪灾、地震、技术故障等)。

Zone Redundant Storage

区域冗余存储(ZRS)，除了存储类似于 LRS 的三个副本外，还在一个或两个区域内的数据中心之间异步复制数据，从而提供比 LRS 更高的安全性。 在这种情况下，即使主数据中心不可用或不可恢复，存储在 ZRS 中的数据也安全的。

需要注意的是，ZRS 仅能应用于 blob 类型的存储。

Geo Redundant Storage

异地冗余存储(GRS)，将数据复制到距主区域数百英里以外的辅助区域。如果 Storage Account 启用了 GRS，即使在遇到区域完全停电或导致主要区域不可恢复的灾难时，用户的数据也是安全的。

对于启用了 GRS 的 Storage Account，更新将首先提交到主要区域，并在其中复制三份。
然后，更新将异步复制到次要区域（也是在其中复制三份）。
使用 GRS 时，主要和次要区域在一个弹性存储单元内管理跨单独容错域和升级域的副本。

GRS 是一种性价比很高的选择，对数据安全要求较高的用户可以选择这种冗余策略。比如我们在一个 web 应用中保存了用户上传的数据(文档、图片、视频等)。为了保护用户的数据，我们可以把这些文件存放在设置为 GRS 的存储中。当主区域发生问题时，至少可以把用户的数据恢复回来。下面是笔者维护的一个使用了 GRS 的项目：

次区域是系统自动设置的，不支持用户自由选择。其实我们都没有必要知道它的存在，只需要知道数据是安全的就可以了。

Read-access Geo Redundant Storage

除了 GRS 所提供的在两个区域之间进行复制外，读取访问异地冗余存储 (RA-GRS) 还提供对辅助位置中的数据的只读访问权限，从而最大限度地提高了 Storage Account 的可用性。

当设置为 RA-GRS 时，除了 Storage Account 的主终结点外，还可以通过访问辅助终结点获取数据。辅助终结点与主终结点类似，但会在帐户名称后面追加后缀 –secondary。例如，如果 Blob 服务的主终结点是 myaccount.blob.core.windows.net，辅助终结点则是 myaccount-secondary.blob.core.windows.net。 Storage Account 的访问密钥对于主终结点和辅助终结点是相同的。

对于 RA-GRS, 看起来可能很高大上，但是我们却很难把这种能力加以应用。按照 Azure文档所说，这种策略主要的目的是高可用性。但是用户又不能自由的指定次区域的位置，所以十分怀疑是否可以达到真正的目的。

总结

数据的安全永远都是相对的，片面的追求数据安全肯定会为我们带来不可承受的成本压力。我们能做的就是针对不同类型的数据，寻找价格上可以接受的冗余方案。而 Azure Storage 提供的丰富选项，则给我们的选择带来了很大的灵活性。