在云平台中高可用性数据库MySQL 的设计与实现∗

王素丽

（华南理工大学广州学院计算机工程学院 广州 510800）

1 引言

近些年来随着移动互联网、物联网及各种社交软件的迅猛发展，各种不同环境下产生的数据量获得了飞速地发展。因此，本人所在的华南理工大学广州学院计算机学院也通过OpenStack云平台向社会各界提供数据、信息等多方面的服务。然而，在本人参与搭建的OpenStack 云平台系统中，通过对系统数据量的长时间分析，发现数据库在存储方面的主要压力来自于以指数级别急速增长的数据存储量及并发访问量的急剧增大两个方面［1］。因此，如何有效地解决这两方面问题已经成为该Open-Stack云平台稳定运行的首要问题。

本文主要解决的问题可简述为当OpenStack云平台的单节点中MySQL 数据库由于各种复杂原因而出现问题后导致云平台无法扩展系统的存储数据容量，进而导致无法保证对外业务的流畅性及准确性。针对此问题，本文提出了如下解决方案：

1）设计一个MySQL 数据库集群，使得节点由于各种原因导致出现故障时为了能够继续为客户提供服务而对故障节点实现迅速切换。

2）为了增加云平台数据存储的可靠性并提高其扩展性，对数据库集群的底层数据存储方面进行修改［2］。该解决方案能够使得云平台的存储节点达到万级以上，并很容易将数据量的存储扩展至PB级。

3）为了解决数据库集群切换时间方面的问题，本文提出了一种优化模型，并针对于该优化模型提出了一种切换算法，从而使得切换时间问题获得了较为完善的解决。

本人通过多次试验验证了上述的解决方案能够使得云平台的数据扩展能力得到大幅度地提高，并在单节点出现故障时仍能对客户提供数据访问、查询等诸多服务，同时采用的优化模型还降低了数据库集群切换时间。

2 基于MySQL 的高可用技术发展现状及分析

OpenStack 是一个开源的云计算管理平台项目，其具体工作的实现主要是由几个重要组件协作来完成的，而这些组件都是在MySQL 数据库的基础上才能运行的。通过论文检索，本人将MySQL数据库在国内外的高可用技术方面总结为下面几种。

1）MySQL 拷贝技术。该技术采取的方法是将主节点处存储的数据复制到备用节点处，且备用节点的数目为一个或多个。这样就能保证当主节点由于某种原因发生故障时备用节点仍然能够继续为客户提供数据查询等方面的服务［3］。该技术又有同步和异步两种不同的复制方法，但是二者在实际实现时又存在着各自的不足：前者实现时会在增加节点的同时使得锁竞争现象大量的出现并极易导致死锁情况发生，进而使得系统的响应时间骤增；后者在实现过程中虽然不会出现节点增加、死锁等情况的发生，但是由于采用异步复制的方法，节点间数据不同的情况时有发生。

2）MySQL Cluster 集群技术。该技术是MySQL官方很早以前推出了一种分布式的多主机架构的集群技术，主要由存储、SQL 及管理三种不同的组件构成，三者的硬盘及内存等硬件设备均为独立的，不会出现单点在运行过程中的发生故障的情况［4］。而且，在数据存储方面采用NDB这种全新的数据存储方式来保存节点处的数据。同时，为了保证数据复制过程中的一致性，该技术还在同步复制的两个阶段都采用了协议提交的方法。但是，该技术的维护成本要远高于其它高可用技术，且其配置过程过于复杂，因此，其在实际工作环境中很难得到推广。

3）DRBD 技术。该技术使用内核模块的方法来实现MySQL 数据库的数据同步复制，同时由于该技术是由相关脚本及内核模块组成的，所以其可以构建出高可用性的集群，这一技术特点较容易实现高可用性的MySQL数据库［5］。但是，该技术由于极易造成资源浪费、存储方式等原因使得其在实际应用中受到很大的限制。

3 基于MySQL的高可用性设计方法

基于上述问题的分析，本人在设计中对于节点的创建主要是通过红帽的附加组件并通过集群的形式向客户提供服务，而数据存储方面主要是通过Ceph 文件系统来实现的。在集群建成以后，在故障切换方面我们可以使用集群中的组件来完成，也就是说即使集群中的N 个节点由于各种原因而同时出现故障时，只要有一个节点处于正常运行状态，整个集群的运行仍是正常的，还能够为客户提供各种数据服务，进而真正体现了MySQL 数据库的高可用性［6］。其整体结构示意图如图1所示。

图1 集群整体框架图

3.1 Ceph文件系统简介

在分布式文件系统中，Ceph 以其规模大、可靠性高、扩展性强等诸多优点而著称。其架构主要由元数据服务器、集群监控、客户端、集群四部分组成，结构示意图如图2所示。

从上图可知，Ceph 系统可以通过客户端与集群监控或者集群进行互访而获得整个集群的映射图。同时，为了对数据进行各种操作，必须获取数据的存储位置，Ceph系统对于这一问题是通过Map图并结合CRUSH 算法而实现的。Ceph 系统的元数据服务器采用POSIX 标准，能够执行诸如cp、ls等指令。该服务器的主要功能是将文件名映射为元数据，这是由于其内部能够对索引节点进行管理，从而将文件名转换为索引节点，文件I/O所使用的数据也是由其转换而来的［7］。系统中的集群主要功能之一是完成数据的存储、复制、回填等事宜，并能监测其它集群的运行情况，当出现运行异常时能够向集群监控发出警报并提交监测报告。从其功能上可以看出，该系统的OSD集群智能化程度较高，因此，其拥有独立的CPU、存储系统、网络等硬件设施。Ceph 系统的集群监控主要功能为集群映射、CRUSH映射等方面的监控。

图2 Ceph集群的理论架构图

图3 集群高可用性架构图

3.2 系统的附加组件概述

系统在集群方面的设计时采用的是x86 系统的普通服务器通过附加组件连接而成的，并在此基础上使用MySQL 数据库及其它资源共同组成系统资源，以此为客户提供各种服务。在整个系统架构中，组件的主要功能为节点出现故障时实现切换、数据管理、节点监控等诸多功能，其结构示意图如图3所示。

由上述示意图可知，整个系统的集群结构可以分为如下几部分。

1）集群管理组件。该组件的主要功能是对集群进行多方面的管理，并对集群间的交互进行仲裁。当集群中的节点发生故障而导致数据传输出现问题时，该组件能够向其它组件发出信息，使得其它组件能够采取相应的动作以保证数据的正常化运行。在仲裁方面，如果集群中的活跃节点的数目大于半数时，该组件就能保证集群的仲裁功能，反之则不行，组件此时就会停止集群的各种活动，以使得集群不会发生“脑裂”［8］。

2）锁管理组件。该组件位于集群中的各个节点内，其提供了一种有效地访问机制，该机制能够高效地管理集群中的其它组件与共享资源的数据交互。共享资源中的全局文件系统（GFS2）和集群逻辑卷（CLVM）都是通过该组件来实现数据同步及卷组更新的。

3）保护组件。该组件的主要功能是隔离集群中出现故障的节点，使得数据交互过程中的完整性能够得到保证。同时，该组件所使用的保护策略是在系统设计过程中配置的。当集群管理组件发现集群中的某一节点出现故障时，将立即向保护组件发送信息，保护组件根据发送信息的内容将对应的故障节点进行隔离［9］。在保护组件对故障节点进行隔离时，共享资源将停止正在进行的所有线程，当隔离完成后，线程将会得到恢复。

4）高可用服务管理器。该管理器提供了一种对集群服务的管理能力，当一个节点的服务失败时，其可以将服务从这个故障节点转移到集群中其它正常节点上来，从而保证了交互数据的完整性。故障切换服务是自动、透明的，切换到的正常节点的优先级既可以由用户自身决定，也可以由系统随机决定。

5）全局文件系统。该文件系统是由RedHat 在GFS1 文件系统的基础上加以完善而得到的，其改进之处主要体现在如下几方面：集群中的多个节点可以同一时刻与共享资源中的某些文件系统进行交互；在与Linux 内核进行数据交互时，GFS2 可以直接作为普通的文件系统来实现；在优化集群方面，该文件系统使用多个日志来实现［10］。

4 系统的架构设计及优化

当集群中出现故障节点时，如何尽快地恢复数据传输业务将是衡量系统性能的重要指标。但是，集群中的各个节点由于硬件设备、分布距离、运行环境等原因而使得故障切换时间大不相同。为了解决这一问题，我们在对系统的架构进行优化时，对节点性能采用动态的方式进行排序，并将此结果作为节点切换的参考标准。因此，对系统的优化分为节点负载的计算、最优节点的选择、优先级的调整等三部分。其流程示意图如图4所示。

1）节点负载的计算。为了获得集群中节点的负载情况，每个节点在运行时都会同时使用一些程序获得本节点的内存使用率、中央处理器的使用率及数据传输方面的信息，并将这些信息带入下面的式（1）以计算出节点的负载值，并将此值传递给控制端。

2）最优节点的选择

如1）所述，当节点将自身的负载发送给控制端后，控制端将通过如下的算法来获取最优节点，该算法如下所示。

3）优先级的调整

利用2）中的算法将节点进行排序后组成集合M，所谓的动态方式指的是当集合M 中节点的优先级没有发生变化的时候，配置文件将不会被改写，反之，系统则会使用附加组件将M中的排序值写入配置文件，并将此配置文件发送到集群中的各个节点，使得节点中的配置文件得到同步更新，并将更新成功的信息返回。

5 系统实验及结果分析

系统实验环境的搭建由以下几部分组成：

1）分布式系统：一台客户端节点；一台监控节点；六台OSD 节点，未配置元数据服务器。Ceph 系统采用的是2015年八月份发行的0.94.4版本，并对集群进行了手动配置，配置的具体环境如表1 所示。

为了体现集群的高性能性和可靠的安全性，我们将集群分为两个网络：

表1 Ceph的集群配置

（1）公共网络：该网络的主要功能是OSD 节点与客户端节点进行数据交互；

（2）集群网络：该网络的主要功能是OSD 节点间的数据交互及节点监测。

2）节点服务器采用的是红帽公司的RHEL 6.5操作系统；

3）数据库采用的是MySQL数据库的5.7.13版。

在完成对数据库的配置工作后，我们还需要在各个节点中安装红帽公司的rgmanager 、lvm2-cluster 、gfs2-utils 三个附加组件。为了能够对这些附加组件进行管理和配置，我们需要对集群管理节点中的文件(/etc/cluster/cluster.conf)进行创建，文件中对集群的属性，包括隔离策略、故障节点ID、集群名称、故障保护资源等通过XML 语言进行描述。在集群管理节点对配置文件完成自定义后，必须将该文件同步到集群中的各个节点。在完成整个集群架构的建设后，我们还需要创建出一个块设备并将其映射到客户端节点，块设备的大小由用户自行设置。同时，MySQL节点也需要该块设备的数据，我们主要使用ISCSI 协议来完成块设备与节点映射的。随后，我们要完成磁盘的分区并将其配置为全局文件系统格式，并在系统的数据存储路径中添加该磁盘的路径。至此我们就完成了整个系统的搭建工作。

图4 集群优化的流程图

5.1 系统的扩展性试验

该项试验的目的是当集群的存储空间出现不足时是否能够在系统不重启的基础上通过对分区动态调整的方式来完成存储空间的扩容。

首先在客户端使用rbd resize 指令调整rbd 影像的大小；然后将集群中的MySQL 节点再次挂在iscsi target 上；随后使用clvm 将逻辑卷扩展；最后使用gfs2_grow 指令完成扩容。试验前后对比如图5、6所示。

图5 没扩容时存储大小图

图6 扩容后存储大小图

5.2 系统的故障切换试验

本项试验主要用于检测集群中节点出现故障时系统是否能够自动完成故障隔离、切换等功能。为了保证试验的真实性，我们在试验时令节点1 出现死机，从图7 所截取的日志不难发现，Fence 设备在收到rgmanager发出的消息后立即对这一消息进行解读，随后对节点1 成功的进行了隔离，然后，锁管理器解除了对节点1 的锁定。在对配置文件的检测中发现剩余节点中节点2 的优先级最高，因此，节点2开始提供服务，系统恢复正常状态。

图7 故障切换测试图

图8 故障切换平均时间优化前后对比图

5.3 系统的优化性试验

节点的内存和中央处理器的使用率及数据传输方面的参数在上述的负载公式的调节下达到了理论最优化，在这种情况下，我们对此优化模型进行了仿真测试。我们将两种软件相结合从而实现了局域网中出现的诸如传输延时、数据丢包、时序混乱等较为复杂的网络情况，第一种为NetEm 模块，其是建立在Linux 系统内核上的一种网络模拟模块，而第二种软件TC 则属于高级网络管理工具iproute2 中的主要组成部分，其能够调整前者的工作模式、实现流量方面的修正。

在模拟环境配置完成后，我们将系统中的节点数目进行了调整，从最初的三台调整为试验中的十一台，并在调整前后对系统的故障切换时间等参数进行了多次试验对比，进而验证了该优化模型的可靠性及安全性，实验对比结果如图8、9所示。

图9 故障切换时间优化前后样本标准差比较图

从上面的图示可以看出，在对系统进行优化后，故障切换时间等参数明显优于优化前的参数值，从而有力地证明了该优化模型的有效性及可行性。

6 结语

OpenStack 云平台的组成部分是极为复杂的，而整个OpenStack 平台的核心部分则为数据库，这是由于云平台涉及到的组件都和数据库有数据交互，如果平台运行时数据库方面出现了故障，将会导致整个云平台的业务出现问题，故障严重时还有可能导致平台的瘫痪。本文就是在此基础上对MySQL数据库集群进行了优化，使用了数据库存储与对外业务进行分别处理的方式，并在底层开辟了共享资源的文件系统，而在业务层方面，我们使用了Redhat 的附加组件对MySQL 数据库进行了集群构建，并在集群完成构建后采用了有效的优化算法减少了故障切换方面的参数，最终有力地证明了该系统架构的高可用性及存储可扩展性。