《OpenStack高可用集群（上册）：原理与架构》—2.5.2　HPE OpenStack高可用部署方案

2.5.2　HPE OpenStack高可用部署方案

HP在企业拆分之前便投入大量资源进行OpenStack的开发和部署，并推出了基于OpenStack的Helion公有云服务，拆分后的HPE仍然致力于OpenStack社区的发展和部署实践，目前的Helion便是由HPE进行运营维护。目前HPE的Helion高可用集群架构与Redhat的三节点高可用架构类似，高可用部分的软件栈也主要由HAProxy和Keepalived构成，客户端对OpenStack服务的访问首先抵达处于Active状态的控制节点，然后被HAProxy捕获并终止，之后HAProxy再将访问请求转发到对应的OpenStack服务后端进行处理，而Helion外部VIP的高可用主要通过基于三节点的Keepalived集群实现。图2-35是HPE的Helion高可用集群架构图，在图2-35中，用户客户端对OpenStack服务的访问请求被发送到服务VIP及其端口，如访问Nova的服务，则请求被发送到192.0.26:8447，HAProxy随时在监听VIP及其端口上的请求访问，一旦发现有访问请求，HAProxy便选择一个恰当的后端控制节点进行处理。

图2-35　Helion OpenStack集群高可用架构

在HPE的Helion中，OpenStack的大多数API和MySQL均通过HAproxy实现了高可用，虽然RabbitMQ也实现了高可用，但是RabbitMQ的高可用并不是通过HAProxy实现，Helion认为RabbitMQ的高可用应该通过客户端配置来实现，即在客户端配置文件中写入全部RabbitMQ服务器主机名称，由客户端自行选择可用RabbitMQ服务器。如果Helion的某个控制节点发生故障，Keepalived将会迅速将VIP迁移到其他节点，并且接受客户端访问请求，如图2-36所示，而整个过程对于客户端而言是透明的，即客户端对OpenStack的访问方式没有任何变化。如果之前的故障节点恢复并加入集群，则Keepalived会将该节点置为Standby/Slave状态，即当前活动并接受访问请求的控制节点并不会发生变化，如图2-37所示。

图2-36　Helion控制节点故障后集群状态

从目前Helion的高可用配置来看，Cinder-volume、Nova-consoleauth仍然运行在单点模式，整个集群只提供一个对外服务VIP，RabbitMQ的高可用不通过HAProxy进行负载均衡，同时计算节点上的VM没有实现HA，而是要求应用自身应该具备HA特性，可以说Helion实现了大多数OpenStack服务的高可用性，但是相比Redhat和Mirantis的方案，还不能算是比较理想和彻底的高可用方案。