在上一期,我们提到,我们如果期望让对象存储具备跨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
至此,我们为大家分享了云计算系统中分布式块存储、文件存储、对象存储的实现,也讲述了虚拟机如何使用块存储和文件存储。在接下来的专题中,我们将为大家介绍容器如何使用云存储——
敬请期待。