《OpenStack高可用集群（上册）：原理与架构》—2.4　Mirantis OpenStack高可用部署架构

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模式下。

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高可用集群中的存储节点拓扑图