OpenStack高可用分布式存储方案设计与实现

姚 捃，严 南

(成都理工大学 工程技术学院，四川 乐山 614000)

1 概 述

云计算作为互联网+时代重要的技术支撑，得到了飞速发展，而OpenStack是云计算最重要，同时也是市场占有率最高的开源技术。利用OpenStack建立的分布式存储系统服务在企业、高校与科研领域得到了广泛应用[1-2]。与NTFS、EXT等目的不同，分布式存储具有良好扩展性，能极大地提高数据可用性和完整性。同时分布式存储的性能和容量能同时拓展，系统规模具有很强伸缩性；将OpenStack与Ceph分布式存储相结合，在多种分布式存储方案中具有松耦合、高弹性、可伸缩、高扩展、高性能等优点[3-6]。同时由于OpenStack和Ceph都是开源项目，具有极度清晰功能模块和丰富的API接口功能，可对企业二次开发。

OpenStack和多数分布式系统相似，由控制、计算两大节点组成。控制节点不提供nova-compute的计算服务。组件与服务分布于各个节点，在安装了基本服务后可根据需求部署更多组件。计算节点主要运行nova-compute，由于nova-Scheduler的调度特性，使得虚拟实例可以在几个计算节点间切换，或者使用备份机制实现故障转移。由此，解决控制节点的高可用性成为了整个系统高可用的基础。控制节点所提供的基础服务在系统出错后，所面临的管理和控制故障，称之为单点故障(SPoF)[7]。对于单点故障，可以采用设备的冗余、热备，维护和升级相关节点，甚至暂停节点等方式来解决，因此必须有高可用架构来支撑这些技术方案，并且多数需要的是自动运行的方案。 高可用性(high-availability，HA)是针对大规模集群系统、分布式系统、云平台等项目提出的技术手段，尽量减少因维护、故障、高并发等引起的服务暂停或崩溃，以提高系统的稳定性和可用性，是目前企业、数据中心、高校实验室防止单点故障，意外停止服务的有效手段[8]。

目前各大主流公司的高可用部署模式有：网易的OpenStack云的HA方案、Mirantis的Active-active双主动模式、Hp Helion的Active-active双主动模式、Oracel的Active-passive主备模式等等。

为了实现OpenStack和Ceph结合的高可用分布式存储方案，在比较了多家公司具有可行性的高可用方案[9-10]，结合Mirantis提出的Keepalived+HAProxy的双活Active+actice模式和Oracle提出的Active+passive主备模式的各自优点，并且规避了如可靠性不足、容易产生集群脑裂等问题之后[11]，提出以三控制节点为核心，多计算/网络/存储节点为扩展，在部署过程中采用Keepalived+HAProxy的双活模式以实现负载均衡和IP漂移，为OpenStack各个组件提供高可用；利用RabbitMQ Clustering实现消息队列的集群；利用MariaDB Galera实现数据库集群；利用vrrp实现路由冗余的高可用[12]；利用Cinder和Ceph结合的方式实现存储和虚拟机实例的高可用。整个平台将Active-active的双活模式、Active+passive的主备模式、分布式集群技术等高可用技术加以融合，通过软硬件的冗余、IP漂移、故障转移、热备份、热迁移等方式实现了在OpenStack平台上的高效、高可用分布式存储，实现了高性能计算模式下性能与稳定的一种平衡。

2 模型设计

该方案采用三控制节点+多计算/网络/存储节点的形式，如图1所示。

将HAProxy+Keepalived形成的双活模式部署在三个控制节点，形成三主动模式，实现以下高可用：

(1)外部高并发连接时，实现有效的负载均衡；

(2)在三个主动节点之一意外宕机，访问可由另两个主动节点瞬间接管；

(3)利用Neutron高可用实现主备式的虚拟路由器冗余；

图1 模型架构

(4)利用Ceph+Cinder实施虚拟机的热备份、热迁移。

将Mariadb和RabbitMQ部署于三个控制节点，利用Galera实现Mariadb集群，提供较小延迟、读写到任意节点、自动节点加入、同步复制、自动成员控制等；RabbitMQ提供了OpenStack的消息队列，由RabbitMQ Clustering、RabbitMQ Mirrored Queue实现高可用，同步集群内由任意节点产生的消息，并且利用同步节点随时接管由于源节点故障而产生的消息同步任务。

Memcached默认支持双活高可用模式，将所有节点的名称加入OpenStack配置即可。

Keystone、Glance部署于三个控制节点，采用HAProxy+Keepalived形成三主的HA模式。

Ceph部署是基于RADOS的Ceph对象存储集群，本模型使用一个监视器+五个OSD。Ceph文件系统、Ceph对象存储和Ceph块设备从Ceph存储集群读出和写入数据以实现高可用。

模型采用三网络管理，将192.168.2.0网段用于OpenStack六个节点的外部访问，如远程登录和虚拟机的外部访问等；将10.0.0.0网段用于节点间信息管理，如数据库，控制信息，另外Ceph流量也会走10.0.0.0网络；将10.0.1.0用于数据通信，包括neutron的服务和vxlan的数据等。实践结果表明，三个独立且分工的网络是实现整个模型高可用必不可少的条件。

整个模型架构基于OpenStack+Ceph的高可用平台，具体的方案规划如图2所示。

3 环境安装

实现方案所使用的硬件如表1所示。

所有节点使用DELL PowerEdge R710服务器，是DELL双路2U机架式服务器，使得控制节点和计算节点都拥有双路8核心CPU、12 G内存、548 GB硬盘、4个千兆网卡。优点是CPU和内存性能佳，在高可用环境下，为虚拟机高负载时提供不错的计算能力；缺点是硬盘空间小，分布式存储使用范围受限，同时网络带宽只有千兆，仅能初步满足Ceph对于网络性能的要求。

图2 可用方案

名称数量机型指标用途Manager1Dell R7102U机架式管理节点Controller2Dell R7102U机架式控制节点Compute3Dell R7102U机架式计算节点Network3Dell R7102U机架式网络节点Ceph5Dell R7102U机架式存储节点Vlan3Cisco-C3560机架式隔离网段

验证环境为了尽可能发挥高可用的优势，采用了三网段策略，利用Cisco 3560交换机将三个网段使用VLAN隔离。其中，端口F0/1～6、24属于VLAN 2，连接OpenStack外部网络适配器，24号端口连接NAT网关所提供的外部网络；F0/7～12属于VLAN 3，连接OpenStack管理网络适配器；F0/13～18属于VLAN 4，连接OpenStack隧道网络适配器。由于使用的是本地的YUM源，不需要设置10.0.0.0和10.0.1.0网段网关，只需指定各个网卡IP即可，网络安装如图3所示。

图3 网络安装方案

要把Ceph块设备用于OpenStack，必须先安装QEMU、libvirt和OpenStack。其中物理主机安装OpenStack最少需要8 GB内存和4核CPU。

OpenStack里有三个地方可以和Ceph块设备结合形成分布式存储：images、Volumes和Guest Disks。

验证方案使用Cinder(Volumes)和Ceph结合的方式，具体的OpenStack/Ceph技术栈如图4所示。

4 高可用实现

下面从三个方面来阐述整个OpenStack+Ceph平台的高可用性的实现。

(1)控制节点的高可用性，表现在一些基础服务(如MariaDB、RabbitMQ、Memcached等)的高可用性；

(2)计算节点的高可用性，主要是虚拟机和存储的高可用性；

图4 OpenStack/Ceph技术栈

(3)网络节点的高可用性，最重要的是L3-Agent和DHCP-Agent的高可用性。

4.1 控制节点的高可用

控制节点主要利用了HAProxy+Keepalived形成三控制节点的三主模式集群，其中HAProxy自身实现为Active-passive模式的高可用，在任何时刻只有一个HAProxy处于Active状态并提供服务；Keepalived通过请求一个VIP来请求真实IP地址，而VIP能够在一个控制节点发生故障时，自动漂移到另外一个控制节点上，从而实现高可用。

HAProxy可以为OpenStack Service API(如httpd，neutron-server，glance-registry，nova-novncproxy，keystone等)和MariaDB-Galera服务提供负载均衡，将请求按照一定的算法转到某个节点上，由Keepalived为此服务提供VIP。因此，OpenStack控制节点集群可配置为HAProxy的后端，实现双活模式。

MariaD Galera数据库的同步多主(Multi-Master)集群，Galera使用底层并行机制对数据库集群进行读写，实现同步复制。OpenStack支持多节点写入Galera节点，Galera内部支持主/主拓扑结构和写入到任何集群节点。在这样的配置中，只有一个节点是活动的，其余节点是standby状态。Galera使用同步复制并确保每个集群节点是相同的。

利用RabbitMQ Clustering实现消息队列的集群，同时RabbitMQ支持Mirrored Queue高可用技术，集群内任意一个节点出现故障时消息由同步节点接管。将RabbitMQ主机列表配置给OpenStack相关服务组件。

Memcached默认支持双活高可用模式，将所有节点的名称加入OpenStack配置即可。

图5列出了整个控制节点实现高可用性的思想。

图5 控制节点高可用

4.2 计算节点的高可用

计算节点，主要涉及到虚拟机的高可用和存储的高可用，而上层应用会直接决定虚拟机的高可用性(虚拟机绝对的高可用涉及到多方面，如存储、CPU、内存等)，同时生产环境中的容错设计也极大地降低了上层应用加入高可用的必要性。

方案设计通过使用Ceph结合Cinder的分布式存储方案来实现OpenStack实例的热迁移与热备份，实现计算节点在简单场景下的高可用性。Ceph-Monitor安装配置在控制节点，Ceph-Client安装配置在计算节点。

Cinder提供的存储服务是作为一个存储管理器而非硬盘，真正的硬盘是下层的LVM、Ceph、GlusterFS等，所以，OpenStack的存储高可用，几乎完全由Cinder决定，同时加入Ceph以完成数据存储的高可用性。

4.3 网络节点的高可用

OpenStack中，网络的高可用由L3-Agent、DHCP-Agent、DHCP-server、Virtual-Router等服务决定，而L2-Agent只在所在的网络或者计算节点上提供服务，不需要高可用支持。Neutron的高可用采用OpenStack原生自带的高可用模式，对不同服务采用不同的高可用实现方式。

由于DHCP协议自身对多个DHCP服务器的支持，因此利用在所有网络节点上部署Agent来实现多Server运行，从而实现DHCP-Agent服务的高可用。在私有网络中DHCP分布式地提供IP服务。

为了同时兼容高可用性、扩展性，使用VRRP的Active-active高可用性方案来实现L3-Agent服务的高可用。作为一种容错协议，VRRP可以在下一跳路由失效时，由备用路由器继续工作，保障网络的可靠、通畅。VRRP利用BFD、NQA等协议快速检测、监视敏感的上行链路，从而Master路由器可以检测到故障，并快速切换为Backup路由器代替。方案实现使用了BFD技术监视Master的状态。

5 结束语

方案从模型的设计建立到环境安装再到实现，完成了OpenStack+Ceph环境下的高可用性。在一定的压力测试下，能够有效地规避单点故障。体现为，在任一控制节点的断开下不会影响整个负载均衡系统的稳定运行；在三主动的双活模式下，三个控制节点任一的宕机不会影响MariaDB、RabbitMQ、Memcache等基础服务；在单一或少量存储节点断开的情况下，Ceph会提出警告，但不会停止集群服务，并能快速修复错误，重新连接丢失的存储节点加入集群服务；在一定频率的热备份和热迁移的基础上，能提供持续有效的计算服务。即使发生虚拟机故障，也能快速恢复，没有严重故障表现。

当然，方案在大规模分布式系统的高可用技术上，还有一定的发展空间，能进一步提升高可用的量化指标、进一步降低服务失效时间、减少服务和配置工作量和复杂度。