侧边栏壁纸
博主头像
汪洋

即使慢,驰而不息,纵会落后,纵会失败,但一定可以达到他所向的目标。 - 鲁迅

  • 累计撰写 190 篇文章
  • 累计创建 74 个标签
  • 累计收到 106 条评论

主备|弹性|多活,如何正确的选择多云架构?

汪洋
2022-06-07 / 4 评论 / 2 点赞 / 652 阅读 / 2,505 字

多云是指企业使用两个或更多的公有云 IaaS 供应商。广义来看,混合云也在其范畴。多云架构有如下优势:

  • 灾难恢复,当一家云供应商出现故障时,数据存储可以从另一家云供应商进行恢复。虽然云厂商有多地域,单地域也有多可用区,但还是存在中心化的依赖。这种依赖的故障就会导致整个云的故障。后面提到的故障主要指这种类型的故障。

  • 故障转移,当一家云供应商出现故障时,使用另一家云供应商承接服务,实现服务平稳不中断。

  • 成本优化,任意的采购只要有了两家及以上供应商,采购方就有了充分选择和议价的能力。

  • 避免供应商锁定,单一供应商,除了没有议价能力外,各种依赖也会使得变更极为困难。

  • 数据主权,企业提供服务,但产生的数据产权也是归属于服务对象。服务对象既有普通的用户(行权由国家主体代为进行),也有机构。他们对产权的需求,连带的导致企业的云基础设施选择也受其限制。

  • 特定服务访问,不同云有自己优势的服务,一般出现在 PaaS 层,如各式各样的数据库、大数据实时方案等。使用多云可以集各家之长。

多云架构有如此多的优势,那么选择怎样的架构才能达成,下面具体展开描述下。

主备多云

企业的应用服务还是在一家云厂商上,用户通过 DNS 解析过来,数据沿着网关、应用、数据存储这条链路流转。企业出于数据灾备的考虑,将数据存储同步到另一家云供应商上。亦或者企业有海量对象存储归档的需求,而另一家云在存储架构上有优势,如提供更具性价比的深度归档存储能力,或直接提供更具竞争力的价格。基于这些存储,企业还可能在备份云上开一些衍生的离线的计算,用来进行二次加工等。

在主备架构下,上述优势的表现如下,使用 3 分制进行评定。

  • 灾难备份,3 分,核心数据已经冗余存储在两家云上,任一家的故障都不会对数据造成不可恢复的影响。

  • 故障转移,0 分,主备模式更多考虑的是存储,应用服务较之前单云没有什么变化。

  • 成本优化、避免供应商锁定,1 分。企业已经在尝试第二家云供应商了,虽然只是存储方面的一小步,但在成本、避免锁定等方面逐渐有了一定的进步。

  • 数据主权,0 分,冗余的数据是用来做灾备的,本质上是一份,所以也没有数据主权一说。

  • 特定访问,1 分,企业逐步开始使用另一家云供应商差异化的对象存储服务,如更深度的归档能力、更丰富的图片处理能力等等。

弹性多云

随着合作的更进一步,第二家云供应商抛出更优厚的条件,能提供更多的弹性计算能力。企业对这家云的使用变得更多,不再仅仅满足存储备份需求,开始把一些重要的应用服务进行部署,以应对一些突增流量的弹性需求。为了确保有突发流量时第二家云可以稳定承接,所以常态下就要承接一定流量,保证服务是双活的。当流量增加时,弹性云进行快速扩容,通过 DNS 或者网关将主云上无法承载的流量转移到弹性云上。

这种模式下各维度的打分如下:

  • 灾难备份,3 分。数据灾备是基础项。

  • 故障转移、成本优化、避免锁定,2 分。较主备模式又更进一步了。故障转移的瑕疵在于弹性云仅部署了部分核心服务,对主云还是有千丝万缕的服务依赖。如果是主云出现故障,这些依赖不可访问,会不会导致弹性云不可提供服务,这个犹未可知。

  • 数据主权,0 分,同主备多云。

  • 特定访问,1 分,同主备多云。

业务切分多云

业务切分多云,这个也很好理解。公司有多个部门,或者直接是多个子公司,各自部署到钟意的云厂商上,就形成了这样切分的局面。这种多云模式往往也是最普遍的。用户访问不同业务使用不同的域名,不同域名根据 DNS 路由到不同云的不同服务上。两家云加起来才是公司完整的服务。因为业务线强势,中台无统一规划往往会出现这种情况。当然还有就是在线业务用一家云,离线业务用一家云等等。

这种模式下各维度的打分如下:

  • 灾难备份、故障转移,0 分。两家云上的服务和存储加起来才是完整的,所以灾难恢复、故障转移都无法实现。

  • 成本优化、避免供应商绑定,2 分。对企业而言,毕竟有两家云供应商可选择,两者价格、服务差距过大时,迁移也是可以操作的。

  • 数据主权,0 分,同主备多云。

  • 特定访问,3 分,该多云模式下最亮点的就是企业可以选择云上最优势的服务使用。

主权数据多云

不同用户群体,通过 DNS 路由到不同云上,在各自内部完成网关、应用、存储的数据链路,不同云之间不进行数据互通。每个云上都是完整的应用,但数据只有各自的用户数据。主要的场景有:

  • 业务出海,很多国家都限定了数据不准离境,甚至规定了专属的云供应商。企业不得不一套代码,部署在多家云上。

  • 有些私有化交付项目也是类似,企业需要按照雇主的要求部署在指定的公有云或者私有云上。这种模式下各维度的打分如下:

  • 灾难备份、故障转移、成本优化、避免供应商绑定、特定访问,0 分。

  • 数据主权,3 分。这种模式的多云仅为数据主权服务,其他维度都无能为力。

多活多云

这种也是最复杂的一种,企业将服务等量部署在两家云供应商上,通过 DNS 进行流量分配。数据存储一般采用主从模式,随着分布式数据库的逐渐兴起,也有较多的选型,这里先简单按照主从来讲。多活多云是对稳定性和成本极致要求的产物。

各维度打分如下:

  • 灾难恢复、故障转移,3 分。应用服务、存储每家云上都有完整的一份,所以灾难恢复、故障转移都是很容易的。单家云出现故障时,只需要将 DNS 路由到另一家云即可,又可以正常提供服务了。

  • 成本优化、避免供应商绑定,3 分。不同云有完整的服务,只是流量占比不同,所以迁移成本很低。

  • 数据主权,0 分,同主备多云。

  • 特定访问,0 分。多活的方案屏蔽了各家云厂商的差异,自然也不会去使用特定的服务。看上去在多数场景下多活多云是最优的选择,但这个收益也是伴随着较大代价的。从稳定性、成本、效率几方面来推演下。

  • 多活多云是用来解决稳定性问题的,但是如果做不到各自完整的闭环,彼此之间还存在千丝万缕的依赖,整体故障率不会减少,反而被增加。

  • 多云本质上也是要解决成本问题的,但两边云稳定性做的不好,业务不得不加大冗余,这样会带来巨大的浪费。

  • 多活多云对效率的影响主要体现在几个方面,一是抹平各家云厂商的差异,就需要一层胶水层。虽然 K8S 屏蔽掉了部分,但细节的差异还是广泛存在。再有,不能使用云厂商的优势功能,不得不去寻找其他替代方案。另外,商务沟通等事情也被放大了多倍。没有最好的架构,只有最适合企业的架构。

0

评论区