「英方周末」第十四期:OpenStack的高可用性设计

时间：2016-07-31 栏目：技术前沿

wxid_laum74lcf1jn22_1470901094800_27

导语

就像积木一样，OpenStack也是由众多服务组合而成的，因此在整体架构上是可以整合出一套行之有效的高可用（High Availability）方案的，虽然在网络等方面还存在一些不足，但目前OpenStack社区也付出了相当多的努力持续进行着优化及改进，相信随着后续新版本的不断完善，OpenStack的高可用性也将不断增强。今天，我们将节选由陈熹、Ricky Sun主编的《软件定义数据中心技术与实践》（［M］.北京：机械工业出版社，2015.）一书中的部分内容，与您一起探讨OpenStack的高可用性设计的问题。

对于主要的基础设施组建服务（如Nova、Keystone等），OpenStack号称能够保证达到99.99%的高用性。然而对于运行在云计算平台的用户实例（虚拟机），OpenStack并不提供直接的高用性保障。对于OpenStack的高可用性机制来说，如何避免单点故障首先要区分一个服务是状态相关（Stateful）还是状态无关（Stateless）的。

一

状态相关（Stateful）vs状态无关（Stateless）服务

状态无关的服务提供一问一答的请求模式，且服务请求之间互不关联。为状态无关服务提供高可用性设计比较简单，只需要提供冗余实例以及相应的负载均衡机制。实例之间通常采用多活（Active-Active）模式：请求通过虚拟地址（Virtual IP）和HAProxy进行负载均衡。OpenStack中状态无关的组建服务包括nova－api、nova－conductor、glancc－api、keystone－api、neutron－api和nova－scheduler等。

状态相关的服务提供系列问答的请求模式，下一个请求（类型／内容）依赖于上一次请求的结果。这一类型服务更难管理，因为一个用户动作通畅对应一系列的请求，因此冗余实例与负载均衡并不能解决高可用性的问题。OpenStack中状态相关的组建服务，典型的例子是各个组件的数据库（MySQL）以及消息队列（RabbitMQ）。状态相关服务的高用性设计首先取决于用户需要单活还是多活的配置。

二

单活（Active－Passive）模式

在单活模式的高可用性系统中，当故障发生时，系统会将备用组件上线用来替代故障组件。举例来说，OpenStack会在主数据库之外，同时维护一个灾难恢复（Disaster Recovery）数据库。这样当主数据库失效时，备用的数据库就可以快速上线运行。OpenStack针对状态相关服务的单活模式的高可用性设计，通常需要部署一个额外的应用例如Pacemaker或Corosync来监视组件服务，并负责故障发生时将备用组件上线。

OpenStack推荐的高可用性部署依赖于Pacemaker这样的集群管理软件栈。配置OpenStack组件服务的时候，包括网络组件（Neutron DHCP Agent、L3Agent和Metadata Agent），都需要加入到Pacemaker集群中。Pacemaker是Linux平台上的一个高可用性和负载均衡软件，广泛适用于各种不同的存储和应用程序。而Pacemaker依赖于Corosync的消息层提供可靠的集群通信，包括基于Totem环状结构的排序协议以及基于UDP的消息队列、选举和集群成员管理机制等。Pacemaker通过资源代理（Resource Agent，RA）与被管理的应用程序之间进行通信，目前原生支持70多种资源代理，并提供了良好的可扩展性，支持很方面的地接入第三方资源代理。OpenStack的高可用性配置一部分基于原始的Pacemaker资源代理（例如针对MySQL数据库和虚拟IP地址），一部分基于其他第三方的资源代理（例如针对RabbitMQ），还有一些为OpenStack开放的原声资源代理（例如针对Keystone和Glance）。

除此之外，对于包括数据库（MySQL）和消息队列（RabbitMQ）在内的一些核心组件，高可用性的冗余实例之间需要一种基于数据复制机制等分布式块存储设备支持。EMC的RecoverPint产品就是一个很好的选择，基于高度可靠的持续数据复制（Continuous Data Replication）机制，支持在多达五个节点之间同时进行数据复制。此外，RRBD（Distributed Replicated Block Device），一个Linux平台上的分布式存储系统，也是不错的选择。DRBD提供了一个基于软件实现的、无共享的、基于复制的块存储（如下图），经常被用于高可用性集群的设计。DRBD提供了基于网络的类似于RAID－1的数据复制机制。

641977334304930845
基于复制的分布式块存储（DR:BD）

三

多活（Active－Active）模式

在双活和多活模式的高可用性系统中，所有的组件服务实例都同时上线，并发地对外提供服务。这样一来，某个实例都失效只会造成轻微的性能下降，而不会导致系统停机或数据丢失。概括来说，针对状态相关的基于多活模式的高可用性设计，需要在冗余实例之间时刻保持一致状态。比如通过一个冗余实例对数据库的更新，能够立刻同步到其他实例。多活模式的设计通常还包括一个负载均衡管理器，保证将心来的任务分配到相对空闲的服务实例上。至于如何实现上述目标，不同的系统就要“八仙过海、各显神通”了。OpenStack的高可用性指导文档描述了通常需要考虑的问题，并提供了一些常见的选择。

首先要考虑数据库管理系统的部署，作为高可用性集群的核心组件，我们需要的是多个冗余实例以及为之量身定做的实例间同步机制。一个常见的选择是使用MySQL数据库，然后通过部署Galera来实现多主节点的同步复制；也可以用MariaDB和Percona作为MySQL的替代，通过与Galera的配合实现高可用性。此外，例如Postgres这样内置复制机制等数据库产品，以及其他数据库高可用性的方案也可以作为选择。

另外一个需要考虑的核心组件是消息队列。作为OpenStack默认的AMQP服务器，RabbitMQ被许多OpenStack服务所使用。针对RabbitMQ的高可用性设计包括：通过配置RabbitMQ使其支持高可用性队列（HA queue），比如为RabbitMQ Broker配置一个包含多个RabbitMQ节点的集群；配置OpenStack服务使用RabbitMQ提供高的高可用性队列，即至少配置两个RabbitMQ。

此外，在针对OpenStack的高可用性设计中，HAProxy也得到了广泛的使用。HAProxy提供了一种快速可靠的解决方案，包含了高可用性、负载均衡、针对基于TCP和HTTP应用的代理服务等功能。HAProxy支持虚拟IP地址的配置，可以将一个虚拟IP地址映射到多个冗余实例的物理IP地址。最后考虑HAProxy本身的高可用性，通常需要部署至少两个HAProxy实例，从而有效避免单点故障。

作为OpenStack组件的一个特例，网络组件（即Neutron）在设计之初就有着高可用性的考虑。Neutron的重要组成部分是一系列的代理组件，包括：Neutron DHCP代理；Neutron二层网络（L2）代理；Neutron三层网络（L3）代理；Neutron元数据（Metadata）代理；Neutron负载均衡（LBaaS）代理。Neutron的调度器（Scheduler）原生支持多活模式的高可用性，并在多个节点上运行多份代理组件的实例。因此，除了二层网络（L2）代理之外，所有的代理组件也都原生支持高可用性部署。Neutron的二层网络（L2）代理因为设计之初就是与物理器一一对应的，与主机上的虚拟网络组件（如Open vSwitch和Linux Bridge）紧密耦合，因此天然地就不支持高可用性。最后，如果Neutron被配置为使用外置的网络控制器，例如NVP这样的软件定义网络方案来管理网络，则由外部网络控制器提供高可用性。

—end—

「英方周末」以“线上与线下相结合、倾听与分享相结合”为特色；以“解析知识、传递知识”为己责；将预见性、知识性和趣味性熔于一炉，寓技术、思想于谈天说地之中。每周末，英方周末与你不见不散。英方周末所有内容版权为上海门徒娱乐股份有限公司所有。