云存储硬核技术内幕——(24) 双城记 (下)

在上一期，我们提到，我们如果期望让对象存储具备跨AZ的高可用功能，就需要让对象存储把副本存储到两个不同的AZ。但是，对于3副本的情况，总会有一个AZ里面只有单副本。这样，当另一个AZ整体不可用时，用户的数据将处于十分危险的状态。

为了避免这种情况的发生，我们需要对多副本机制做一定的修改。

我们首先想到的是，能不能在两个AZ各自建立三副本呢？

如图，主AZ和双活AZ各自建立了数据的三个副本，这样，当任意一个AZ整体故障时，另一个AZ都保存了数据的三个副本，数据的持久性和业务的可用性都不受影响。

然而，我们发现，这样的成本是很高的，我们需要为这种容灾机制提供100%的额外成本！

我们需要另一种变通的方法。

让我们回顾上一期——

当主AZ整体不可用的时候，三副本中，只有保存在双活AZ的一个副本可用，无法满足云服务的可用性需求。

那么，我们可以稍作变通——

如图，对于需要跨AZ可用的数据，我们为它创建4个副本，分别保存在2个AZ。

当任一AZ不可用时，另一个AZ依然有2个副本可用！

假设单AZ的业务可用性为99.99% (4个9)，双AZ的业务可用性就增加到了99.999999% (8个9)。

同样地，假设单块磁盘的数据持久性为99.9% (3个9)，三副本的数据持久性为99.9999999% (9个9)，四副本的数据持久性可达 99.9999999999% (12个9)。

显然2AZ，4副本这种存储方式，比起单AZ三副本而言，业务可用性和数据持久性都得到了显著的提升。那么，这种方式付出的代价呢？我们可以很容易地计算出来，4副本的存储节点成本实际上比3副本只增加了33%，但收益是很显著的。因此，对象存储跨AZ部署使用2+2的机制，也被业界广泛采用了。

当然，如果期望对象存储的服务跨AZ可用，还有两个重要的组件，需要在两个AZ都可用：

1、一致性哈希环。实际上这个并不难，在两个AZ各自建立一致性哈希环的副本，两个AZ同步信息即可；

2、Metadata和索引功能。这个组件的同步比前者还要简单。由于Metadata本质上是一个Key-Value的数据库，我们采用分布式键-值数据库就可以很容易搞定。

这样一来，我们就解决了对象存储同城双AZ数据同步的问题。

那么，如果我们期望在巴黎和伦敦的两个AZ之间同步对象存储的数据呢？

我们需要云服务商提供一个孜孜不倦的机器人来帮忙搬运：

这个“机器人”，实际上就是对象存储迁移工具。它可以对同一服务商不同region的对象存储进行数据同步，甚至还可以对跨云服务商的对象存储进行数据搬迁，如从A公司的OSS上搬迁到T公司的COS上。关于它的介绍，可以在互联网上很容易找到，如这里：https://cloud.tencent.com/product/msp

至此，我们为大家分享了云计算系统中分布式块存储、文件存储、对象存储的实现，也讲述了虚拟机如何使用块存储和文件存储。在接下来的专题中，我们将为大家介绍容器如何使用云存储——

敬请期待。