OpenStack Liberty 高可用性概述和参考-第一部分

这篇文章由Avishay Traeger 和 Shimshom Zimmerman编写。

OpenStack设计目的是在商用硬件上运行,但是没有自身的机制处理硬件和软件故障。OpenStack成功部署的一个重要组成部分是创建一个高可用性(HA)软件架构体系。这样的架构体系的首要组件是支持高可用OpenStack服务，它们分布在不同的硬件节点；因此，如果一个硬件节点故障时OpenStack集群还可以持续提供服务功能。这样的架构体系的第二个重要组件是有能力在一个新的计算节点上重启一个虚拟机实例当一个计算节点发生故障。OpenStack不能保证独立客户实例达到99.99%可用，但是内部OpenStack服务这个目标是可以达到的。OpenStack依赖于其他组件，如消息队列、数据库和存储；为了达到高可用OpenStack所有这些组件都需要HA 。

本文简要概述最常见的方法实现OpenStack高可用在OpenStack的当前发布版本-OpenStack Liberty。这里有多个OpenStack高可用（HA）架构，你可以根据你的需求选择合适的架构。本文将介绍两个架构：第一个主要基于Corosync/Pacemaker和第二个基于Consul。

OpenStack Liberty HA基础知识

某些OpenStack服务是无状态的。无状态服务是一个不存储任何交互请求上下文在本地。任何上下文或信息相关不仅仅是单个请求在当前被处理存储全局，例如在数据库中。这些属性意味着任何请求的结果不依赖于任何其他请求的结果。这使这些服务的部署运行在“active/active”方式中（多个实例的运行在任何时候,所有的服务请求）。

无状态服务意味着拥有多个服务实例运行在不同的节点上，监控这些实例可用性和转发请求到可用实例。如果所选择的实例无法处理请求，它会重试相同的请求使用不同的实例。OpenStack无状态服务有：nova-api, nova-conductor, nova-scheduler, cinder-api, cinder-scheduler, glance-api, keystone-api,和 neutron-api。

OpenStack同样也使用有状态服务。相对于无状态服务，它存储交互请求上下文到本地；因此，在任何时候只有一个实例可能是活跃。此外，OpenStack还依赖一些服务，如数据库和消息队列为有状态服务。运行多个有状态服务实例是高可用架构的一部分。对于OpenStack服务，这些意味着可以运行在“active/passive”方式中（在任何时候只有一个实例服务于请求）。对于数据库和消息队列，我们一般选择使用内部状态共享和所有实例一致性。

授权服务

HA HTTP终端HAProxy

OpenStack服务为HTTP 提供通过RESTful APIs。最常见的方法是为OpenStack服务满足HA模式是通过外部工具提供一个虚拟IP(VIP)管理的组合，如Pacemaker和通过HAProxy为HTTP终端提供负载均衡。为了避免单点故障（SPOF），集群在不同的节点上应该包含多个HAProxy服务实例。当一个服务使用者发送一个请求到REST API，这个请求会发送到激活的控制节点（当前持有VIP）；这个请求会被活跃的HAProxy实例处理并转发到相应的服务。

通常只有一个HAProxy实例是活跃的，另一个实例是处于待机模式(active/passive配置)。OpenStack服务可以配置为active/active或active/passive模式。OpenStack无状态服务除了HAProxy通常不需要其他工具可以工作在active/active或active/passive模式下。OpenStack有状态服务只能在active/passive模式下运行。OpenStack Dashboard服务（Horizon）属于粘性会话需要HAProxy因此在active/active模式下工作。

集群资源管理Pacemaker

Pacemaker是主要推荐工具管理HAProxy实例、数据库、消息队列和OpenStack服务。Pacemaker提供其控制下服务的资源管理器。Pacemaker可以通过使用资源代理启动和停止服务。资源代理监控一个指定资源（服务）和采取相关措施如果这个资源没有运行或反馈。例如，资源代理可以转移虚拟IP从一个故障节点到一个可用节点，这是一个实现的虚拟同步协议。这个协议通常提供集群节点间可靠连接。支持基于选举的HA，Corosync/Pacemaker通常要求奇数（三个或更多）服务实例。

服务发现和HA的Consul

另一个工具可以帮助在OpenStack集群实现HA是Consul。Consul是一个开源服务发现工具，使用分布式键值对存储。Consul还没有广泛用于OpenStack部署，需要一些工作被集成在一个OpenStack集群。

Consul在集群中运行一个守护进程在所有节点上（一些是服务模式，一些是代理模式），利用Raft一致算法和底层的Serf gossip协议。

在集群节点上Consul 代理可以配置监控在本地运行的服务。这些代理发布这些监控服务的健康状态到整个Consul集群。此外，Consul在每个节点上运行本地DNS服务，它允许由名称解析以及各种集群服务的负责均衡。例如，如果我们使用数据库的Galera 集群HA（见下文），有三个Galera实例运行在集群中，Consul将通过一个可配置的健康检查脚本不断监测它们的健康。任何服务想要访问数据库可以通过名称galera.service.consul访问，这将本地解决集群中Galera实例的健康问题。

运行运行一个集群管理服务可以很简单监测服务的健康和集群节点，可以在节点间进行迁移如果有需要。一旦Consul监测启动，这里不需要主动通知这些服务的客户端-这是由DNS服务器自动完成。

集群的分布式键值存储允许方便的存储配置参数。此外,它有订阅机制在注册表键/值的变化,和整个集群范围的锁。

Learn everything you need to know about OpenStack Deployment Tools.

共享服务

MySQL/MariaDB 使用Galera

MySQL/MariaDB的Galera集群为OpenStack数据库提供了高可用性。它支持同步复制和主/主多主机拓扑结构。Galera集群需要一个奇数实例运行（三个或更多）。OpenStack支持多节点写入Galera节点还没有准备好进行生产，所以推荐的方法是配置HAProxy只使用一个激活的Galera节点，虽然Galera内部支持主/主拓扑结构和写入到任何集群节点。在这样的配置中，只有一个节点是活动的，其余的节点是standby节点。Galera使用同步复制并确保每个集群节点是相同的。如果任何节点的状态降得远远落后与Galera缓存，整个副本分发到该节点。这将导致主切换到捐赠者角色，运行进行不同步的节点迎头赶上。

MongoDB

OpenStack 计量服务可以使用MongoDB存储它的数据。MongoDB可以配置为HA模式通过HAProxt和Corosync/Pacemaker。

RabbitMQ 镜像队列

RabbitMQ提供active/active HA使用镜像队列。这不是一个理想的解决方案，因为即使镜像队列消息仍有可能丢失。无论如何，RabbitMQ仍然是一个事实上的标准OpenStack的消息队列。OpenStack服务使用Oslo消息库为RabbitMQ连接而不需要HAProxy的HA模式。

Learn more about the benefits and challenges of OpenStack

HA 技巧和窍门

Compute 节点(Nova 服务)与控制节点和共享服务之间通信是通过消息队列和数据库。Compute节点应该使用VIP和HAProxy去连接控制节点上的服务终端。

卷存储，Cinder管理。必须高可用。默认Cinder后端创建逻辑卷使用LVM在一个节点上的一个或多个磁盘，通过iSCSI出口。因为存储驻留在单个节点上,它不适应节点故障。Cinder支持管理卷在大多数存储设备,以及几个开源软件选项。一个流行开源选项是Ceph，内部支持HA。Ceph需要多个Ceph监控实例形成法定人数。此外，运行Ceph OSD的数量取决于所需的复制因子和集群能力。

Swift API依赖于控制器节点上相同的HAProxy设置VIP其他RESTful API。用于生产环境需要专用的节点,至少有两个Swift代理和至少三个Swift存储。

可以开始尝试OpenStack在单个节点上的服务配置为高可用性,并添加更多的节点迁移到生产之前。所有的服务描述支持这个,可以添加额外的节点没有停机时间。

如果RESTful API端点安全通过SSL,您应该在所有节点有相同的SSL证书。

原文：http://www.stratoscale.com/blog/openstack/openstack-liberty-high-availability-overview-and-guidelines-part-1/