OpenStack高可用集群(上册):原理与架构》—2.4 Mirantis OpenStack高可用部署架构

网友投稿 784 2022-05-30

2.4 Mirantis OpenStack高可用部署架构

Mirantis是OpenStack最为成功的创业公司之一,其在2013年10月开始发布自己的OpenStack版本Fuel,Fuel也是基于OpenStack社区的发行版本。也许在开源社区或者IT业界,Mirantis的影响力不及Redhat,但是在基于OpenStack的产品发布和社区影响力上,Mirantis丝毫不亚于Redhat。Mirantis的Fuel系列产品以其简易可靠的特性在OpenStack用户群中占有很大市场,而且从OpenStack的第十三个发行版本Mitaka的代码贡献来看,Mirantis已经领先于Redhat成为代码贡献量最大的公司,并且在OpenStack下一版本Newton的代码贡献中,Mirantis以24%的代码贡献率占据第一的位置(截至2016年4月),此外,Mirantis还是OpenStack社区的黄金会员,其与VMware、Citrix、Ericsson、Oracle、Dell等传统IT巨头和国内的UCloud等公有云初创公司都有良好的合作,并且Mirantis的产品支持在众多操作系统上进行部署,可以说,Mirantis作为一家“纯净”地聚焦在OpenStack上的创业公司,其在OpenStack推广部署方面做出了极大贡献,同时其Fuel系列产品和技术实力也得到了广大OpenStack用户群的认可。在OpenStack社区的“大帐篷”模式下,以Mirantis贡献代码为主的项目包括Fuel、Murano、Sahara、Rally等。

2.4.1 Mirantis OpenStack高可用集群部署架构

使用Mirantis的Fuel部署工具,用户可以将OpenStack部署为高可用模式或者非高可用模式,此外,用户还可以在初期将OpenStack部署在非高可用环境中,随后再添加另外的节点并实现OpenStack集群的高可用。这一部署模式非常适合很多OpenStack初级用户在私有云上的递进部署,因为很多用户在初期更多的是功能测试与验证,在各个所需功能得到验证后,用户通过Fuel工具可以快速转入具备高可用的生产环境。在OpenStack的生产环境中,Mirantis强烈建议使用高可用部署架构,由于OpenStack服务众多,每个服务的单点故障都有可能导致整个OpenStack集群无法正常工作。为了能够提供冗余的服务器以防止单点故障,Mirantis推荐的高可用部署架构至少需要三台控制器才能保证OpenStack服务的冗余。同时,为了减少部署环境对硬件的需求,在Mirantis的高可用架构中,用户也可以将计算、存储和网络节点混合部署,尽管这样会降低集群性能和高可用环境的稳健性,图2-23为Mirantis提供的OpenStack高可用集群多节点部署拓扑。

OpenStack服务之间的交互主要基于两种方式实现,即基于HTTP协议的REST API和基于RPC的消息队列,所以在Mirantis的OpenStack高可用集群部署中,无状态(Stateless)服务如OpenStack API服务,其高可用的实现主要借助Pacemaker管理的虚拟IP和负载均衡器HAProxy以实现客户端服务请求的负载均衡。而对于有状态的OpenStack服务组件,诸如数据库和消息队列服务,其高可用性则是通过这些组件自身的Active/Active或Active/Passive高可用模式来实现,例如消息队列服务RabbitMQ使用其内置的集群机制实现消息队列的镜像高可用,而数据库则使用MySQL/Galera复制机制来实现高可用,图2-24为Mirantis提供的OpenStack高可用集群组件之间的交互与调用关系拓扑。

图2-23 Mirantis OpenStack高可用集群多节点部署拓扑

图2-24 Mirantis OpenStack高可用集群服务组件交互调用关系

Mirantis多节点高可用OpenStack环境涉及三种类型的节点,分别是控制节点、计算节点、存储节点。业务系统高可用性设计的首要考虑便是物理设备的冗余,因此作为运行OpenStack服务最多的控制节点,必须实现服务器节点的冗余。由于MySql数据库运行在控制节点上,并通过Galera来实现高可用,而Galera是一个基于Quorum的系统,因此作为高可用OpenStack集群的控制节点理论上至少需要3台服务器组成,而Mirantis的部署文档认为,除了集群服务可用性有所降低之外,两个控制节点也是可行的,而且控制节点和服务都可以通过Scale-out的方式进行扩容,因此后期也可以将控制节点增加到5个或者7个(考虑Quorum机制,如果想要通过增加控制节点数目来负载均衡访问请求,只需将控制节点数目增加到奇数个即可)。在OpenStack高可用集群中,每个控制节点上均运行HAProxy程序,HAProxy负责向外部客户端提供单一高可用的服务访问IP地址(VIP),并将客户端对该IP地址的访问以负载均衡的形式转发到后端对应的OpenStack API、数据库、消息队列等服务上进行最终的处理,图2-25为Mirantis OpenStack高可用架构下控制节点上的服务部署和高可用情况。

图2-25 Mirantis OpenStack高可用集群控制节点服务部署

在多节点OpenStack高可用环境下,当终端用户从Dashboard访问OpenStack云服务或者以命令行形式向Openatck服务,如Nova-api、Glance-api、Keystone-api、Neutron-api、Nova-scheduler或者MySQL服务的REST API发出访问请求时,客户端请求将会进入HAProxy活动的控制节点,因为HAProxy对外提供的服务IP地址(VIP)只会在HAProxy活动的节点上出现,同时客户端请求被HAProxy终止,即客户端请求是不会直接抵达OpenStack服务的API的,当客户端发起下一个访问请求时,HAProxy仍然会将其终止并重新转发给位于后端控制节点上的相应OpenStack服务,而这个控制节点可能与之前处理请求的控制节点相同,也可能是另外的控制节点,主要取决于用户对HAProxy负载均衡策略的设置。

Mirantis提供的OpenStack高可用集群设计模式与Redhat差异并不大,其主要思想也是将无状态服务通过HAProxy和Pacemaker实现Active/Active高可用模式,其他有状态服务则利用Pacemaker通过控制服务的OCF脚本来实现高可用,具体的服务高可用模式如下:

OpenStack无状态服务,如Nova-api、Glance-api、Keystone-api、Neutron-api、Nova-scheduler和Cinder-api 可以通过负载均衡的形式实现Active/Active高可用模式。

作为典型Web应用的Horizon,则通过在负载均衡中设置粘性会话(Stick Session)的形式实现Active/Active高可用模式。

RabbitMQ本身提供了Active/Active高可用集群,其高可用主要通过队列镜像(Mirrored Queue)的形式实现,RabbitMQ高可用集群通过Pacemaker调用客户自定义的OCF脚本(Resource Agent)来实现。

MySQL/MariaDB的高可用通过Galera集群实现,具体实现过程则通过Pacemaker调用Galera的OCF脚本(Resource Agent)进行资源高可用性的管理。Mirantis还特别强调后端MySQL/MariaDB服务应该运行在Active/Passive模式下,因为Active/Active模式在生产环境中还不具有稳定性。

Neutron的多个Agent通过Pacemaker管理OCF脚本的形式运行在Active/Passive模式下。

《OpenStack高可用集群(上册):原理与架构》—2.4 Mirantis OpenStack高可用部署架构

Mirantis推荐使用的后端存储服务是Ceph,Ceph有其自身的高可用集群机制,需要注意的是,Ceph要求运行其监控服务(Monitor)的节点必须保持时钟同步,时钟差异超过50ms则可能会影响到Ceph的Quorum机制甚至Crush算法。

在OpenStack云环境中,计算节点是整个IaaS服务的基础,用户的虚拟机(VM)和应用最终都运行在计算节点上,计算节点在运行过程中需要访问控制节点的某些服务,例如RabbitMQ和MySQL数据库等,而控制节点上的这些服务都是通过HAProxy向来自Horizon或者REST API的客户端请求提供冗余,即计算节点对控制节点服务的访问也由HAProxy代理,计算节点总是通过访问HAProxy对外提供的VIP来实现对控制节点服务的访问,

图2-26是Mirantis OpenStack高可用集群下计算节点与控制节点之间的服务访问示意图。

在Mirantis的高可用架构下,存储节点可以有多种选择,例如用户可以在存储节点上部署使用Cinder、Swift或者Ceph来作为OpenStack集群的存储服务,从集群共享存储和高可用角度考虑,Mirantis建议在存储节点上部署Ceph服务,用户需要注意的是保证足够的控制节点数目(通常为三个)以确保运行在控制节点上的Ceph监控服务Monitor能够实现Quorum机制,同时需要部署足够的OSD节点以满足Ceph数据的多份复制从而实现Ceph集群数据的冗余高可用,图2-27为Mirantis推荐的基于Ceph集群的存储节点拓扑图。

图2-27 Mirantis OpenStack高可用集群中的存储节点拓扑图

OpenStack 云计算

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:用户态网络协议栈还是内核协议栈?
下一篇:无服务器云计算
相关文章