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

我们用的更多是非轻核性的,把同样的一组应用尽可能的分散在不同的物理机上,不同的可用域上,最上层从应用要两地双活部署.这个时候由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是我们自己研究的,快照也不用说了,我要经常的对虚拟机进行快照和备份,出问题有恢复的地方.

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

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