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

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

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

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

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

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

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

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

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

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

（编辑：开发网_开封站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!