专家观察 | 潘文杰：“OpenStack在恒丰银行的生产实践”(2)

厂商就不说了,这都已经洗牌过一次了,中国的厂商也不断的加入,华为也是白金的会员,这么多厂商的参与下你可以看到它的解决方案也是非常成熟的.比如你想找一个跟EMC我们商业存储的,或者跟思科对接的方案这里面几乎都有现成的解决方案,现在很多东西都是非常成熟了,你几乎都能找得到,所以他已经有这么多的厂商支持他,这么多的能力扩展,你对接不上的厂商给他提需求.比如国内厂商他们现在也基本上全部都认为要对

接到OpenStack上,如果你不是用他标准的OpenStack方案反而它就不支持了,我们找厂商谈的时候他说我现在就支持OpenStack的,你自己搞一套还不好对接.

我们讲一下我们如何部署的,刚才说了金融行业往往要求的是可靠性,可用性,连续性等等,都有很高的要求,社区上最开始给的标准的部署方案单节点的,可以变成多节点的部署,这里面还是有很多功夫要下的.

首先我们把它分为控制节点和计算节点两种,因为我是超融合的,所以我的计算节点里放的是多个角色.比如我的API的角色,MQ的角色等等,VTS控制器以及我HAProxy,这些我都做成虚机跑到三个物理机上.

这个图我讲控制节点如何分布,因为我们刚才说了都要尽量的做到三活的结构,因为三台选组的时候容易脑裂,所以我要尽量的让三台控制器分布在三个故障域里,不要再一个里面,这样故障率会导致它一次就坏两个的可能.

所以我们建议是说你至少要做大于二的基数,这是因为它要选组,你要尽量的把它分散在不同的故障率里,我们的做法是把控制器分布在我们的AB两个机房模块挨着的防火隔离,我们把另外一个放到楼下的网络机房.

这样至少能保证两个以上的或者快速的协商出来一个新的,我们在上面还有一些公共的节点,比如说我们的很多节点是统一布放的,不需要放在三个节点上的.

我们看一下控制节点高可用的方案,首先刚才说了都是要能做到多活的都做到多活,能做到准备的要尽量的准备,多活都是三节点部署,我们在最外面是做一层负载均衡,所有中间的API的节点实际上都是三活的,数据库这一层我们用了三活的集群,我们来说一下为什么.

我们要把这个做成三活,实际上已经支持三个数据库的节点全部三活,我们怎么做?我们让它做成三个节点复制的集群,但是我只选中一组将所有的数据库请求留给这一个组,因为我们认为实际上你不需要用三个,它之间的沟通还会有大的麻烦,如果我不用这个方案的话如果我夜里出现故障还得爬吸收修,或者要做主备切换,这个时候我只需要检查三个的状态,如果主的坏了切换到一个备机就可以.

对于数据库来说已经自动的完成切换了,我们说为了可用连续性,我的数据库还在同城机房摆了一台备机,三活加一倍,实际使用的时候数据库是一组在用,另外两个活的不跑业务,也不做查询,这是我们OpenStack控制节点高可用的方案.我们多套的OpenStack集群都是这样的.

这是讲我们如何部署了整个OpenStack,我们讲一下我们怎么管它,这些都是一些比较基本的办法,很简单.

第一个我们说银行担心的是出现整体性的故障和风险,我们会搞很多的隔离区,业务区等等这些东西,我用OpenStack也一样,如果我们整个都跑在一个集群上集群坏了怎么办?如果我的存储集群坏了怎么办?

我上面的虚机会触发整体性的风险,之前也不是没有遇到过,之前扩容的时候整个集群宕一下,上面跑了这么多集群谁能受得了?所以我们使用一个数据中心多套OpenStack方案做的,一个数据中心多套OpenStack,但是它的帐户体系是一套,我就装了一套,大家都对上了,然后我的一个OpenStack里面是有两个ceph集群的,如果网银要十台机器,我会根据调度算法把它切分在两个ceph集群,这样任何一个ceph的故障不会导致我整个宕机.

有人说这就是矛盾,你要做资源池,实际上我们的意思是故障率要小,但是资源还是会很大,就是说我们在一个集群下也要跑所有的业务,整个的容量也是很大的.

这是刚才我们说到的故障率要尽可能的小,我们资源怎么调度?

刚才也说了,我们都是为业务服务的,我们上面跑着很多的业务,这些业务我们邀请的其实是银行还是保险都是一样的,要求的是业务的高可用,不是需要我云平台的高可用,最终的价值是要完成业务的高可用,这些业务的高可用只能说我要尽可能的把鸡蛋不放在一个篮子里,所以我们就搞出了好多的非轻核性的调度,有一些就是轻的,为了更方便.

（编辑：ASP站长网）