专栏名称: 高效运维
高效运维公众号由萧田国及朋友们维护,经常发布各种广为传播的优秀原创技术文章,关注运维转型,陪伴您的运维职业生涯,一起愉快滴发展。
目录
相关文章推荐
运维  ·  阿里云核心域名被劫持 ·  昨天  
51好读  ›  专栏  ›  高效运维

​OpenStack在恒丰银行的生产实践

高效运维  · 公众号  · 运维  · 2017-02-13 07:20

正文

请到「今天看啥」查看全文


我们看下他的产品,第一社区好,产品稳定不稳定,但是 OpenStack 客观来说这六个核心的项目,已经是在五年以上的时间,就是发布到现在。

可以看到 NOVA 已经是六年,就是从第一个版本到现在已经六年,我们平时用到的功能,不特殊的新功能以外这些功能都运行很长的时间,该修复的漏洞都修复完了,因为在运行过程中,使用量还是很大的。

这几个核心模块可以说也经历过很多的考验,我们在使用他一年的时间,我们用的是L版本。

在L版本里面对我们的使用是几乎没有漏洞的,真正对我们造成影响就只是在 nova 有一个 BUG,在其它地方还没有看到,所以他的产品的成熟度已经达到了我们可以选择的程度,即使在金融行业我们认为也是可以选择的这样的一个程度。

其次他的架构优势,看这个图比较乱,但是我们 OpenStack 架构是值得我们做软件开发值得学习的,它的所有的服务化,他的结构,全部都是用 API 调用,还有,比如他的 Plugin,都可以自己拓展,他有非常强大的拓展性,非常方便和灵活。

以至于这几个百个甚至是六百个公司贡献了两千个代码都可以在这样的架构下良好的运行。其实大家都可以换,这个时候就是简单的替换掉这个 plugin。

所以实际上可能不会用到两千行代码但是良好的架构想作拓展和想替换一些功能的时候是非常方便的,这个也是我们选择他一个很大的点。

其次对厂商的支持就不说了,因特尔还构建了做一些虚拟化地层的技术和能力。这些都是在这里面。这些厂商对 OpenStack 社区贡献了很多一些硬件上面的对接和能力,因为企业应用很难说用纯软件实现,这个可能更不适了,你说互联网所有都是用软的来做了。

这些硬件怎么和这些 OpenStack 对接,其实靠的都是这些厂商自己贡献的代码,这里可以看到像 CISCO 这些公司,他们是要把自己的产品跟 OpenStack 适配起来。

各种各样的厂商都对 OpenStack 有比较好的兼容的方案,我们想换硬件的供应商我还不用换 OpenStack 还都可以对接上。这个也是很大的原因,所以我们最终选择了 OpenStack。

3、部署OpenStack

3.1 恒丰如何部署OpenStack

我们有两个节点,一个是控制节点,一个是计算节点,我们这里可以一些虚机把每一个都是放在虚机里面跑,有人是会用一个物理机跑,有的是使用容器这都可以,我们是把 API 等等东西都四在再一个独立的虚机上,我们做三个节点,我们还放了 DHCP Agent 和 Ceph Mon。

这两个为什么放在这里,因为本来是应该在控制节点的,因为我们控制节点和计算节点之前是三层的,二层是不通,这时候 DHCP 我们就不想让我们的控制节点的的二层延伸过去,所以我们在计算节点上放这个 DHCPAgent 的模式。Ceph Mon 是一样的道理,因为计算节点就是控制节点。

这个是我们的 OpenStack 部署架构,我们刚才说了,我们在多个网络区域里面,我们就可以看到一个数据中心,有两个机房,说白了这个都是为高可用考虑的,两个完全对对称的机房,我们这个还可以正常的提供服务,这个所有的都是双份的。我们有业务网和隔离网。我们是怎么摆放的。

首先我们业务网我们是一套 Openstack。我们用三个控制器,因为我们是三核结构,要选举必须是奇数,我们就不能放两个,一般是2和1,那最后就出现脑裂情况,所以就是需要有一个仲裁的节点。

我们找到一个网络机房放两个控制器,这个机器实际上他是三核节点中的一个,他也负责投票和仲裁。所有的计算节点,是对称的。这个要说一下,我们认证权限是一套 Keystone 管理。这样我们这里可以扩充更多的机房,但是原则上就是集群放在三个网络机房,这样来做的。

3.2 高可用应用

我们专门讲一下控制节点高可用。我们说银行不能像做实验一样,就是有一个单节点的节点这个如果坏了就事就大了,我们做的是三活的方案。

第一个,我们在三个控制节点里面都装 HA Proxy,我们选择一个主的,然后 VIP 选择一个主的来做,这个是我们所有的入口,这个是调用进来会分发给比如说我们的 NOVA 这样的 API 这些都是三个的结构,平均分发就可以了,这个数据库是一组两倍的,我们用了这个 Galera 方式来做这个三活,我们一个集群有三个DB节点,我们把它做成三活,但是我们真的用他们的了吗?这个还是有特殊的处理的。

我们在 HAProxy 中配的是一主两备。我们把它做成三活,起码保证在任何终端的时候不需要人工去切换。但是我们为什么不分到三台数据库?

因为我们有担心就是一致性的问题,我们现在这个方案,好处就在于当我晚上某一个数据库故障的时候,HA proxy 会自动把这个流量倒换到另外一个备机,这个时候是不需要人工干预的。如果主备是需要你起来去切换,我们目前的方案就是 HA proxy 切就可以了。

Memcache 都是主备,但是他有应用级的切换,这个都是三节点,就是我们能做三活都做三活,数据库做了一个特殊的处理,真正背后是三活,这样的一个高可用的架构,我们能够保证他在任何一个时间故障都是有自动切换的能力。







请到「今天看啥」查看全文