请嘉宾讲解下Power平台上的双活解决方案之集群文件系统双活方案?


请嘉宾讲解下Power平台上的双活解决方案之集群文件系统双活方案(Oracle RAC+GPFS A-A)

1回答

lnasmanlnasman  行业架构师 , 浪潮商用机器企业云创新中心
tyrandeZTCknight2020赞同了此回答
谈到双活就必须要从IT业务连续性管理这个话题谈起。只有从根上我们知道这个需求以及技术方案是怎么生长出来的,我们才能够彻底搞清楚,用户在什么情况下适合什么样的解决方案,以及未来技术解决方案的走向。为了保证IT系统对业务支撑的连续性,在HA高可靠方案的基础上,生长出来了...显示全部

谈到双活就必须要从IT业务连续性管理这个话题谈起。只有从根上我们知道这个需求以及技术方案是怎么生长出来的,我们才能够彻底搞清楚,用户在什么情况下适合什么样的解决方案,以及未来技术解决方案的走向。
为了保证IT系统对业务支撑的连续性,在HA高可靠方案的基础上,生长出来了DR的概念。即如果由于某些不可抗力原因,如火灾、地震、公共卫生安全事件、或其他原因,导致单数据中心整个出现问题,如何能够保证IT能够继续有效运行。在这个概念下提出了RTO以及RPO的概念。所谓的双活方案就是在这样的概念下生长出来的。及如果RTO和RPO都双双等于零,那就是所谓的双活方案。
针对应用服务器场景,由于Load balance解决方案(这里又分为有状态和无状态两种)已经非常成熟了。因此一直以来应用服务的双活方方面面的都问题不大( 老旧应用改造除外 )。核心需要解决的问题一直是数据库层面上的双活问题。

目前针对数据库双活的解决方案有很多种。总的来说分为两大类:原生数据库双活(多活)方案以及传统数据库的双活方案。
1.原生数据库双活(多活)方案
目前新型的分布式NewSQL数据库,在系统设计方面就充分考虑到了双活/多活的需求。因此原生满足。目前对于这类数据库典型的实现方式有两种:
方法1:在数据库底层建立统一的分布式存储系统,数据库实例写下来的数据同时写多副本。这些副本可以分布在多个数据中心上。在数据库实例端,可以做多个集群多实例方案,或者也可以做快速服务切换方案。因此任何一个数据中心出现问题,都不会影响。这里典型的方案如巨杉数据库。


方法2:在数据库底层建立统一的KV数据库集群(目前用RockDB的居多)来解决数据文件跨节点,跨数据中心存储的问题,并通过Raft机制来实现数据同步和跨数据中心切换。数据库实例层的设计方式和方法一类似。这里典型方案如TiDB。

综上所述的两种方法来看,其实原生的数据库双活解决方案也没有太多神秘,基本的解题思路依然是在分布式存储层来解决问题。只是实现的技术路径不同而已。

2. 传统数据库的双活方案:
这里讲的传统数据库如Oracle, DB2,Informix等。由于这些数据库本身并没有在原生状态下考虑双活问题。因此双活方案都是在原生体系外面通过附加解决方案来构建的。这类解决方案基本上也都是在解决一个问题:就是如何将多块部署在不同数据中心上的数据盘(数据块)逻辑上merge成一个。
从接替思路上基本上有两种:
方法1:通过存储设备层实现。如EMC的vplex解决方案,IBM的SVC解决方案,IBM的HyperSwap解决方案,浪潮存储双活方案等。都是通过存储层来实现的。

方法2:通过分布式文件系统实现。例如题主在问题里讲到的GPFS解决方案,就是属于这一类。通过GPFS分布式文件系统的Failure Group功能,将另一份双活数据同步地写到另一个数据中心去。

以上是对目前市面上的一些双活方案的技术总结。下面再来谈谈双活方案的优缺点:
先来谈谈优点:
数据中心切换时间短:这个优点是必然的,虽然在技术上无法实现完全的RTO=0,但是基本上可以控制在秒级。这已经非常不错了,无论是在银行、证券。还是在社保、公安户政、交警、这个级别的可靠性保证妥妥地没问题。
数据中心故障切换自动化:自动化切换是切换时间短的技术性保证。没有自动化切换是不可能做到这么短的切换时间的。

再来谈谈缺点:
建设代价高:为了保证RTO和RPO同时为0,需要满足的条件是非常苛刻的。
1) 是两个数据中心的距离必须要短,最好在5公里以内。否则的话数据在两个数据中心间的同步会拖慢整合业务系统。让用户感知下降,这个是我们最不希望看到的。
2) 网络链路要求高:网络链路延迟必须要低,并且不能有网络抖动现象。最好是有单独独立的光纤。
3) 建设费用高:即使是只有上述两点要求,这个建设的费用也是相当不低了。

运维代价高:
如果从应用系统级别就要实现双活的话,那么就设计到应用服务器集群双活、数据库双活、网络双活的多个方案集成。这个集成的复杂度,光想想看心里基本上就有点数了。因此对运维团队的考验是相当大的。

最后的建议:
双活虽好,是不是和每个客户的场景,这个问题就见仁见智了。个人认为,适合自己的才是最好的,不一定非要追求指标。即使是追求双活,也可以从一个层面上去考虑,简化技术架构,做好高可用,减少低级错误,有的时候比双活对用户更有意义。

码字不易,如果对您有用,欢迎点赞、收藏。

收起
 2020-08-05

提问者

lovenetwork其它, 城商行

核心数据库服务器选型优先顺序调查

发表您的选型观点,参与即得50金币。

问题状态

  • 发布时间:2020-08-04
  • 关注会员:2 人
  • 问题浏览:2678
  • 最近回答:2020-08-05