《OpenStack高可用集群（上册）：原理与架构》—2.4.2　Mirantis OpenStack自定义高可用集群架构

2.4.2　Mirantis OpenStack自定义高可用集群架构

在Mirantis看来，OpenStack生产环境部署最重要的两个方面是服务的高可用性和可扩展性，在满足这两个必要条件的前提下，OpenStack服务在节点上的分布可以灵活多变。传统的OpenStack生产环境部署认为高可用环境就应该存在服务集中的控制节点（OpenStack APIs、MySQL/MariaDB和RabbitMQ均部署在控制节点），而Mirantis认为这些OpenStack相关的服务均可以部署在控制节点或计算节点上，并将控制节点与计算节点在“胖节点”（部署大量服务）与“瘦节点”（部署少量服务）之间权衡，如果将控制节点上的服务移到计算节点，则控制节点甚至可以消失。图2-28中，计算节点作为“胖节点”部署了Nova-api、Nova-scheduler、Glance-api等服务，而控制节点作为“瘦节点”仅部署数据库和消息队列服务，同时使用物理负载均衡器来作为OpenStack服务的访问入口（Endpoint），将来自Horzion和REST API的访问请求进行均衡高可用。在这种部署模式下，控制节点仅部署平台服务（数据库和消息队列），其他属于OpenStack的内部服务全部部署在计算节点，因此用户可以将数据库独立出来交由专门的DBA团队负责，而消息队列也可独立到特定的消息集群中。通过这种方式，最终的OpenStack集群只剩下部署有“纯净”OpenStack服务的计算节点，中心化的控制节点已经消失，不仅减轻了云管理的复杂性，同时可以对集群实现几乎是水平线性的伸缩扩展。

作为OpenStack高可用集群的另外一种部署方式，Mirantis使用HAProxy软件替换物理负载均衡器，并将其部署在冗余节点系统上实现高可用，集群通过HAProxy实现访问请求的负载均衡和OpenStack服务的高可用性，如图2-29所示。图2-29与图2-28架构上最大的不同除了负载均衡器之外，还有就是图2-29中OpenStack的APIs服务被部署到控制节点，而不是计算节点，因此控制节点变得“更胖”，而计算节点变得“更瘦”，两个控制节点运行在Active/Standby模式，控制节点服务之间的故障转移通过Pacemaker和Corosync/Heartbeat实现。

图2-28　基于物理负载均衡器的OpenStack高可用服务部署

用户不仅可以通过物理负载均衡器和独立节点系统上的HAProxy软件实现OpenStack服务的负载均衡和高可用，还可以将HAProxy集成到控制节点，并将除了计算服务之外的OpenStack服务和基础平台服务全部部署在控制节点上，同时控制节点可以通过添加节点和重新配置HAProxy的形式实现伸缩扩展，如图2-30所示。在这种模式下，至少需要两个HAProxy实例以Active/Standby模式运行在控制节点上，HAProxy的故障检测和某个Standby状态的HAProxy实例变为Active状态则通过Pacemaker和Corosync/Heartbeat实现。图2-30的高可用部署模式也是Mirantis官方文档中推荐的OpenStack高可用服务部署模式，即图2-30中的OpenStack高可用部署架构与图2-25的部署架构是一致的，这种部署模式的优点是将集群服务集中部署到控制节点并使用集群管理软件Pacemaker统一管理，同时集群所需物理设备和服务器节点数目也有所减少，其与Redhat的官方OpenStack高可用部署架构比较相似，但是Mirantis的架构并没有实现多个服务VIP在控制节点集群上的均衡分布，而是采用单一的VIP对外提供服务。

图2-29　基于特定负载均衡器节点的OpenStack高可用服务部署

图2-30　基于集成负载均衡器的OpenStack高可用服务部署