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

《专家观察 | 潘文杰：“OpenStack在恒丰银行的生产实践”》要点：
本文介绍了专家观察 | 潘文杰：“OpenStack在恒丰银行的生产实践”，希望对您有用。如果有疑问，可以联系我们。

由工业和信息化部指导,中国信息通信研究院主办,业界知名组织云计算开源产业联盟(OSCAR)承办的2017全球云计算开源大会于4月19日-20日在北京国家会议中心顺利召开.本文为本届大会嘉宾分享的大会演讲速记内容,敬请浏览.

嘉宾介绍:潘文杰

公司职务：恒丰银行平台与自动化部门负责人潘文杰

大会演讲速记

潘文杰：我给大家带来的是OpenStack在恒丰银行的生产实践.

今天会议的主题是我们的全球云计算开源大会,大家介绍的也都是一些开源产品,作为云计算领域最大的开源项目,OpenStack实际上最近一段时间比较火,我们给大家介绍的就不去讲一些很新很炫的东西了,因为在大会上OpenStack基金会的成员给大家介绍了OpenStack.

今天我给大家主要介绍一下我们作为一个金融的行业,金融的甲方,我们从甲方的角度来看一下OpenStack如何在生产上进行部署以及我们一些运维的实践.

演讲主要六个部分,第一个部分是我们看一下恒丰银行现在部署的情况,为什么选择OpenStack,我们如何部署管理运维它,最后是一些我们后续的发展.

现状,恒丰银行现在的OpenStack部署情况是这样,右侧是我们的规模,现在五百个以上的结算节点,因为是超融合的,所以存储节点超过五百个了,我们现在运行着一万个以上的虚拟机.

我们几乎所有的业务都跑在OpenStack上虚拟化,当然数据库和大数据结点除外,因为金融行业对于稳定性的要求比较高,大数据都是用裸机的,所以不需要使用.我们也是标准的两地三中心的架构,三个数据中心我们都部署了OpenStack集群,多个网络区包括我们的隔离网和业务网都运行着OpenStack集群,生产个测试环境,包括我们的生产环境上的网商银行,电话银行,核心的信贷等等的业务系统,现在前端除了数据库都是部署在OpenStack集群上,已经运行超过一年了,这是我们在恒丰银行在OpenStack上的使用情况.

我们强调一下我们使用了多租户隔离的,在我们恒丰银行内部为什么也要做呢?实际上我们内部也分为一个集团下的多个子公司,那么这些集团和集团之间我们都是使用多租户的方式来进行资源的隔离的.

现状,恒丰银行现在的OpenStack部署情况是这样,右侧是我们的规模,现在五百个以上的结算节点,因为是超融合的,所以存储节点超过五百个了,我们现在运行着一万个以上的虚拟机.

我们几乎所有的业务都跑在OpenStack上虚拟化,当然数据库和大数据结点除外,因为金融行业对于稳定性的要求比较高,大数据都是用裸机的,所以不需要使用.我们也是标准的两地三中心的架构,三个数据中心我们都部署了OpenStack集群,多个网络区包括我们的隔离网和业务网都运行着OpenStack集群,生产个测试环境,包括我们的生产环境上的网商银行,电话银行,核心的信贷等等的业务系统,现在前端除了数据库都是部署在OpenStack集群上,已经运行超过一年了,这是我们在恒丰银行在OpenStack上的使用情况.

我们强调一下我们使用了多租户隔离的,在我们恒丰银行内部为什么也要做呢?实际上我们内部也分为一个集团下的多个子公司,那么这些集团和集团之间我们都是使用多租户的方式来进行资源的隔离的.

我们说一下我们为什么选择OpenStack,半年前可能还有很多的顾虑,我觉得现在应该没有什么太多顾虑了.

第一个主要是自主可控,因为毕竟OpenStack是一个开源的产品,哪怕你去找一些厂商,实际上背后还是那套开源的东西.

第二个就是它还是油价格优势的,因为毕竟是开源的产品,所以厂商卖给你的时候就是服务.

第三个也是最重要的,是完全开放的状态,集合社区的力量,这也是比较旧的数据,整个社区超过六万的开发者,代码行数超过两万行.

这是两个版本以前的数据,那么到现在只会更多,那么在这么大规模,刚才也说了这个是第二大的,那么它的产品其实也已经相当成熟了,有些人担心我们的金融行业往往都求稳,为什么我们敢用?

你看OpenStack社区里面主的项目,包括这六个是它的核心的项目,nova、neutron、swift等五年前就已经推出了,持续不断的改进都是增加新的功能,对大家最常使用的问题和bug我们认为它已经修改了很完善了,你如果不去碰它比较新的功能,有很多新的功能包括容器都在支持,在你不需要用的时候,而且变化大的是在网络的部分开发量非常大,实际上你不需要使用这些东西的情况你用到的往往是它非常稳定和成熟的代码,我们认为Open Stack已经是一个生产或者金融行业可用的系统了,当然你除了这个以外开源部分你也没有选择.

还要说一下的是整个OpenStack的架构的优势,这一点就是我不得不佩服OpenStack一开始创始人或者一开始的核心代码贡献者,整个OpenStack的架构是非常非常的标准式异构的结构,使我们增加任何我们想要的功能都非常的容易和可扩展,我们几乎不会动到它所有核心的地方,它给你留下了足够多的可以扩展的地方,不管是什么东西都是可以扒插对接的,哪怕我们对它后期进行调整也是非常容易的融合进来整个社区的,或者我从社区就可以很容易的拿到相应的,这点相较于厂商我认为优势非常大.

大家会提一个需求给厂商,厂商回去开发半年都不一定做出来,你可能提的想法和点子别人都提到过,这是一个我认为社区里架构也有优势,社区人也多,这是一个非常大的趋势.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我们用的更多是非轻核性的,把同样的一组应用尽可能的分散在不同的物理机上,不同的可用域上,最上层从应用要两地双活部署.这个时候由OpenStack再上一层的管理平台,我们叫云管理平台来调度,也就保证它同一个应用同一个节点.

比如网银的外部节点要分散在不同的OpenStack集群里,我上面挂DNS就可以,到达一个OpenStack以后我们就使用机房和机柜的非亲和性,我要让它的节点尽可能的分散在不同的模块里.

因为我们刚才看到了,我们的架构刚才是双模块的部署,所以两个模块都是防火隔离完全对等复制的,这样换一个机房模块原则讲也不会对我们的使业务产生影响,我们就使用HostAgreation来做,还不能跑同一个宿主机上.

说极端一点的情况,我还尽量的要求它不能落在同一个机柜里,因为一个柜子都会坏,所以我们要尽可能的把资源分散的调度到不同的节点上,有很多的办法,包括存储也要分散开,计算也要分散开,甚至要在同城分开等等,这是讲我们在用OpenStack的时候应该怎么样.

后面我们讲最复杂怎么运维,可能大家都很困扰,就是云化下面其实我们的运维可能有些时候会变.

第一个就是OpenStack整个集群它的可靠性和可用性就要求很高了,因为如果我的ceph可用率只有99.9%,那很难再超过99%了,因为我是基础设施,那我对整个ceph都有很多的要求,前面搞得那么变态,弄那么多节点,还要用这个那个的,还要摆在不同的网络机房模块里,因为我要防止一个机房模块断裂,也不是没有发生过,有前车之鉴所以我们要小心.

然后就是监控,服务器的故障X86的服务器,故障也是经常的,网络会抖动,各种各样的情况都会发生我们都要监控,

现在的监控手段主要是通过Zabbix完成CPU内存这些的监控以及服务器的状态,我们通过Smokeping来保证全网之间控制平面和控制节点到业务节点还有所有的存储节点之间的网络都是可达的,可靠的,因为实际上网络稍微有一个抖动,你的ceph是最先被感知的,甚至有可能就被踢掉了,这是一个很容易做的,我们也发生过很多次,整个过程中还是踩了很多的坑,这些都是总结下来的.

还有一个模拟应用,我们写了一个应用,模拟标准的BS的业务,它从LB开始,把请求发过来,我在里面处理这些业务,内部互相盯,模拟一个数据库的访问,模拟一个写盘,我在互相拼一下节点之间痛不痛,因为太多的网络区太多的租户了,我必须要排除如果我的模拟应用是好的,起码证明我的基础网络存储区,

我的这些连通性没有什么大的问题,我的ceph也没有问题,必须我要用我的模拟应用排除我整个OpenStack或者基础平台的问题,因为应用说的要么就是不通,要么业务中断了,我们要自证清白,模拟应用在ceph层面比较复杂的,因为如果我只是读写一下,那实际上你可能只是在检测ceph的一个OSD,相当于一块盘,那怎么样能够尽可能多的检测到足够多的不同的盘.

我们要写入的时候我们是16兆一块,可能就要先写16兆的前一段,再跳过去写下16兆,我多写几个16兆连续的读写,一有这样的情况,整个ceph没有问题,但是ceph个别节点出现问题,这个时候你看ceph的监控一切正常,但是这个时候IO已经不正常,这种经过我们都需要做,所以花在这上面的精力比较多.

还有就是刚才也说了,自动化运维,今天的话题很多的嘉宾都谈到了,确实自动化就是一切,因为我们节点也很多的,一个参数配的不一致,产生了无穷的隐患,所以我们现在全部要求一切自动化,我们能做到标准化.

按照刚才前一个嘉宾讲的,我的成熟度应该是第四级,我要求的是所有的服务器,所有的参数配置必须是用puppet推,我就会强行的改掉所有的参数,也就是我的服务器全是标准的.

刚才提到了我的代码是自动从GIT捡出的,每一台机器的扩容要自动的GIT下载社区的代码,然后直接打包.

我的Goldenimage,因为上面已经跑了一万的虚机,管理也是非常头疼的事情,我们都使用标准化的镜像,通过这种方式保证设备尽量的一致,所以我们一开始在这里做了标准化和自动化,我们坚定的认为标准化和自动化是唯一我们可以解放自己的办法.

我们就说高可用,银行的业务还是很变态的,所以我们必须要保证虚拟机是高可用的,所以做了好多的功能,比如虚拟机热迁移是OpenStack本身代的,但是他遇到了我们控制器以后也不灵了,所以要修改.

虚拟机HA是我们自己研究的,快照也不用说了,我要经常的对虚拟机进行快照和备份,出问题有恢复的地方.

我们还有一个宿主机HA,宿主机也许可能坏,坏的时候上面的虚机都有问题,我要一个独立运行的自动化流程来保证快速的把这些虚拟机先要停掉,因为有可能它的状态都不对,这个时候我要先把特都清掉以后快速的在其他的服务器上启动起来,这是一个标准的.

最后我们说一下展望,我们也已经在OpenStack社区里参与了很长时间了,所以现在我们是在用mogan解决虚拟机的编排问题,

大家也都听过nova是用在上层的,现在社区地方向是华为、因特尔还有我们一起在OpenStack社区里面做的项目,项目名字叫莫干山,这个项目主要负责配合与nova相对应的完成物理机编排,包括Ironic等等都是完成物理机部署,部署的过程我们也提出了使用Cloudboot来替换的方案,我们必须支持可拔插的driver,这个也在给社区回馈.

还有就是我们自动化扩容,因为目前我们五百个节点不是一日建成的,已经扩了几十次了,最大的一次扩了几百个节点,我们希望用一个标准化的流程,通过容量管理触发一个标准的PBU一个资源池的扩容,扩容以后我通过装机来完成这些宿主机安装,把配置全部下发再完成上线,这是自动化扩容方面努力的方向.

刚才说了莫干的项目,我们要完成X86的裸机的服务,还有就是我们的Power小机,也在想办法完成它的对接,还有存储的备份,这个备份指的是我放在对象存储上,还有异构的计算资源的租户网络,计算资源有各种各样的了.因为我一年的发展有一些老机器,不同的机器实际上新旧程度不一样,性能也不一样,这个时候我要支持各种异构的资源池了,还有就是今天上午我们谈到的运维知识库,我们要完善开源社区的玩法一样,我们要用开源的运维知识库贡献一些脚本和案例,方便大家在整个Open Stack的运维阶段有所借鉴,还有就是我们的日志和监控的分析.

我们要完成性能采集,现在的采集不能支持我们性能再大的发展,我们还要完成容器和文件存储马尼拉的服务,这些都是我们在做的事情.

最后我们说一下今天的会议主题是我们要拥抱开源,我们是紧随社区,希望大家回馈社区,我们只是从社区索取,只提了一段代码,以后会更多的,所以也希望大家不忘初心,方得始终,谢谢大家.

文章来自微信公众号：云计算开源产业联盟

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4092.html