Windows Azure 存储之本地冗余存储介绍
我们很荣幸地为 Windows Azure 提供冗余存储的两种类型：本地冗余存储和地理位置冗余存储。
本地冗余存储（ LRS ） 在一个位置（子区域）内提供了高耐用性和可用性存储。和我们的SOSP Paper中所述一样，我们维护一个相当于在您主位置数据的3份拷贝（副本）的对等物。这将确保我们可以从常见故障（磁盘、节点、机架）中恢复而不会影响您的存储帐户可用性和耐久性。在成功返回到客户端之前，所有存储都要同步写入三个单独的故障域中的三个副本中。如果有主要数据中心灾难，数据中心的一部分丢失了，我们会通过使用客户的订阅联系信息联系客户关于潜在的本地冗余存储数据丢失。
地理位置冗余存储 (GRS) 为我们提供了最高水准的耐用性，通过在远离主位置区域数百英里的第二位置（子区域）另外再存储您的数据。所有Windows Azure Blob和表数据都是在不同地理位置上进行备份（geo-replicated），但此时队列数据不是geo-replicated。通过地理位置冗余存储我们维护您的数据在主位置和辅助位置3份拷贝（副本）。这将确保每个数据中心可以从常见故障中恢复，还提供了数据的geo-replicated以防重大灾难。在LRS中，成功返回到客户端之前，数据更新会被提交到主位置上。一旦完成，通过GRS 这些更新将异步geo-replicated到辅助位置。当您关闭跨地域冗余时，将从辅助位置删除数据。如果您在关闭跨地域冗余之后决定再次将其打开，系统会将您现有的数据从主要位置复制到辅助位置, 这需要使用输出带宽, 我们会对其进行收费（基于数据传输率）。仅当您关闭跨地域冗余后再将其打开时才会收费。初始复制完成后将不会对跨地域冗余的继续使用收取额外费用。当前，所有的存储帐户都已引导并处于主要存储位置和辅助存储位置之间的跨地域冗余模式。
- 跨地域冗余的工作原理
当您创建、更新或删除存储帐户的数据时，这些事务将跨主要位置内的三个故障域和升级域在三个不同的存储节点上进行完全复制，然后向客户端返回成功的信息。之后在后台，主要位置将异步复制最近提交的事务到辅助位置。之后在辅助位置的不同故障域和升级域中的三个不同存储节点完全复制该事务，它将变得持久。由于更新是进行异步跨地域冗余的，因此，您的存储帐户的现有性能不会发生变化。
我们的目标是保持数据在主要位置和辅助位置的持久性。这意味着我们同时在两个位置保持足够多的副本以确保每个位置都可以从常见的故障（例如，磁盘、节点、机架、TOR 故障）自行恢复，而无需与其他位置进行通话。这两个位置仅在将最近的更新跨地域冗余复制到存储帐户时才需要相互通话。它们无需因为常见的故障而相互通话以恢复数据。这一点很重要，因为它意味着，如果我们需要将存储帐户从主要位置故障转移到辅助位置，则所有已通过跨地域冗余提交到辅助位置的数据将变得持久。
尽管在主要位置提交事务后，通常在几分钟之内对其进行跨地域冗余复制，但是有了此首个跨地域冗余版本，我们将不针对异步对数据进行跨地域冗余复制所花费的时间提供 SLA。
- 跨地域故障转移的工作原理
如果发生了影响主要位置的重大灾难，我们将首先尝试恢复主要位置。 根据灾难性质及其影响，在某些罕见的情况下，我们可能无法恢复主要位置，那就需要执行跨地域故障转移。当发生这种情况时，我们将通过订阅时提供的联系信息通知受影响的客户（我们正在研究发送此通知的更有计划性的方式）。作为故障转移的一部分，客户的“account.service.core.chinacloudapi.cn”DNS
条目将从主要位置更新到辅助位置。在此 DNS 更改被广播之后，现有的 Blob 和表 URI 将继续工作。这意味着您无需更改应用程序的 URI - 所有现有的 URI 在跨地域故障转移前后都将以相同方式运行。
例如，如果存储帐户“myaccount”的主要位置在中国北部，则myaccount.<service>.core.chinacloudapi.cn 的 DNS 条目将直接与中国北部进行通信。如果需要执行跨地域故障转移，系统会自动更新
myaccount.<service>.core.chinacloudapi.cn 的 DNS 条目以将其指向中国东部的所有存储帐户进行直接通信。
在发生故障转移后，接受通信的位置将视为存储帐户的新的主要位置。在发生下次跨地域故障转移前，此位置将保留为主要位置。在设置新的主要位置并接受通信后，我们将启动新的辅助位置，该位置也位于相同的区域，用于故障转移的存储帐户。未来我们计划为客户提供选择辅助位置的功能（当我们在给定区域中具有两个以上的数据中心时），以及交换其存储帐户主要位置和辅助位置的功能。
- 跨地域冗余顺序和事务一致性
跨地域冗余可以确保 PartitionKey 中的所有数据在辅助位置中具有与主要位置相同的顺序。需要注意的是，不保证分区间的跨地域冗余排序。这意味着不同的分区可以不同的速度执行跨地域冗余。但是，在对所有更新执行跨地域冗余复制并在辅助位置提交后，辅助位置将具有与主要位置完全相同的状态。但是，由于跨地域冗余是异步的，因此在发生重大灾难时，最近的更新可能会丢失。
例如，假设在我们的存储帐户中具有两个 blob，foo 和 bar（blob 的全名作为 PartitionKey）。现在假设我们在 blob foo 上执行事务 A 和 B，然后在 blob bar 上执行事务 X 和 Y。我们可以保证在事务 B 前先对事务 A 执行跨地域冗余，在事务 Y 前先对事务 X 执行跨地域冗余。但是，无法保证 foo 和 bar 事务各自执行跨地域冗余的具体时间。如果发生了灾难并导致未对最近事务执行跨地域冗余，则有可能是事务 A 和 X 已经执行跨地域冗余，但丢失了事务 B 和 Y。也有可能是事务 A 和 B 已执行跨地域冗余，但 X 和 Y 未执行。这对于涉及表的操作也适用，区别是, 由应用程序定义实体的PartitionKey。
因此，要最大程度地利用跨地域冗余，一种最佳实践是尽可能避免跨 PartitionKey 关系。这意味着您应尝试将表关系限制在具有相同 PartitionKey 值的实体中。由于单个分区中的所有事务会按顺序执行跨地域冗余，因此这将保证这些关系在辅助位置也按相同的顺序提交。
Windows Azure 存储支持的唯一多对象事务是 Windows Azure 表的实体组事务，该事务可允许��户端使用单个原子事务一次性提交一批实体。跨地域冗余同样将此批次视为原子操作。因此，整个批事务可在辅助位置以原子方式提交。
目前生产过程中的所有现有存储帐户默认情况下都启用地理位置冗余存储。您可以选择禁用它通过关闭Windows Azure portal的geo-replication。您还可以配置冗余存储选项当您通过 Windows Azure Portal创建一个新的帐户。
一些客户可选择本地冗余存储来存储那些不需要额外的地理位置冗余存储耐久性并且想从折扣价格中受益。此数据通常分为: (a)非关键或临时数据（例如日志），(b)如果是从存储来源别处丢失，可以重新创建的数据。后者的一个示例是已编码媒体文件，可以从golden bits——存储在使用地理位置冗余存储的另一个Windows Azure存储账户，中重新创建。此外，一些公司有地域限制，哪些国家他们的数据可以存储其中，选择本地冗余存储可以确保数据仅存储在从存储账户中选出来的位置。
Monilee
Atkinson 和 Brad Calder
本文翻译自：