实现OpenStack高可用的方法与系统与流程

本发明涉及OpenStack云计算平台领域，特别涉及一种实现OpenStack控制系统中任意一个控制节点上的数据库高可用的方法与装置、一种实现OpenStack高可用的方法与系统。

背景技术：

目前，随着物联网、移动应用的兴起，信息系统需要处理的数据量相比过去有几何级的提升，因此，企业的应用对数据库的要求已不再是简单某一时间内能够处理“增、删、改、查”等请求的效率及响应时间等性能；还需要解决的是，当数据库遇到故障时，对用户的服务不能间断，并且数据库应该具有更高的吞吐量(数据库在一定时间内成功处理更高数据量的数据)。

面对上述需要解决的问题，越来越多的企业采用OpenStack来处理企业的业务，由于OpenStack可以将其控制节点中的多台数据库，组成一个数据库集群，当任何一台数据库出现故障时，数据库集群中的其他数据库可以接替此数据库的任务来为用户提供服务，因此可以不间断的为用户提供服务；此外，当客户端应用程序负载增加时，将新的数据库添加到数据库集群，实现对数据库集群的横向扩展，使得数据库集群对数据具有更高的吞吐量，进而满足企业的应用。

现有技术中，采用Share-Disk架构来实现数据库集群，此数据库集群中数据库共享一个数据库来存储数据。此外，Share-Disk架构实现的数据库集群存在两种方式，一种方式为：集群中只有一台数据库对外提供服务，其他数据库作为冗余服务器(此种方式称为单活)，当对外提供服务的数据库出现故障时，冗余服务器对外提供服务；另一种方式为：数据库集群中所有的数据库都对外提供服务(此种方式成称双活)，典型的产品为RAC。

技术实现要素：

发明人在研究过程中发现，现有技术中Share-Disk架构提供的两种数据库集群方式都存在一定问题。在前一种数据库集群中，由于，同一时间内集群中只有一台数据库对外提供服务，从而造成硬件资源的严重浪费，无法提升数据库集群对外提供服务的性能；在后一种数据库集群中，由于RAC的技术性非常高，因此需要水平较高的人来运维系统，并且，RAC需要与其相配的客户端应用程序来使用，若RAC与客户端应用程序不匹配，导致RAC的数据库性能极剧下降；此外，这两种方式实现的数据库集群，集群共享一个数据库来存储数据，存储方面存在单点故障，即当共享数据库出现问题时，整个数据库集群无法正常工作。

有鉴于此，本发明的主要目的是克服现有技术中Share-Disk架构提供的两种数据库集群的缺点，实现符合企业应用的高可用数据库集群方案，进而实现用于企业OpenStack的高可用。

为此，本发明解决上述问题的技术方案是：

一种实现数据库高可用的方法，其特征在于，所述方法应用于基于OpenStack的控制系统的任意一个控制节点上，所述控制系统包括两个控制节点和多个计算节点；该方法包括：

接收不同客户端发送的虚拟机处理请求；

按照预设的负载均衡算法确定响应所述虚拟机处理请求的目标计算节点；

将所述虚拟机处理请求发送至所述目标计算节点，以便所述目标计算节点执行所述数据请求。

优选地，一种实现数据库高可用的方法，其特征在于，还包括：

获取所述虚拟机处理请求中的虚拟机处理信息，所述虚拟机处理信息包括：虚拟机创建信息、删除信息或修改信息；

将所述客户端和与其对应的所述虚拟机处理信息存储至数据库的计算节点表中。

优选地，一种实现数据库高可用的方法，其特征在于，还包括：

监控所述多个计算节点上的虚拟机的运行状态；

依据所述虚拟机的运行状态统计各计算节点的资源使用情况；

将所述各计算节点的资源使用情况保存在数据库的计算节点表中。

优选地，按照预设的负载均衡算法确定响应所述虚拟机处理请求的目标计算节点，包括：

将资源使用最少的计算节点确定为响应所述虚拟机处理请求的目标计算节点。

本发明提供一种实现数据库高可用的装置，其特征在于，所述装置集成于基于OpenStack的控制系统的任意一个控制节点上，所述控制系统包括两个控制节点和多个计算节点；所述装置包括：

接收请求单元，用于接收不同客户端发送的虚拟机处理请求；

确定目标计算节点单元，用于按照预设的负载均衡算法确定响应所述虚拟机处理请求的目标计算节点；

发送请求单元，用于将所述虚拟机处理请求发送至所述目标计算节点，以便所述目标计算节点执行所述数据请求。

优选地，所述实现数据库高可用的装置还包括：

获取虚拟机处理信息单元，用于获取所述虚拟机处理请求中的虚拟机处理信息，所述虚拟机处理信息包括：虚拟机创建信息、删除信息或修改信息；

存储虚拟机处理信息单元，用于将所述客户端和与其对应的所述虚拟机处理信息存储至数据库的计算节点表中。

优选地，控制节点包括至少两个互相独立的数据库，所述存储虚拟机处理信息单元包括：

存储模块，用于将所述客户端与对应的虚拟机处理信息存储至任意一个数据库的计算节点表中；

复制模块，用于将所述客户端与对应的虚拟机处理信息复制至其他数据库的计算节点表中。

优选地，所述实现数据库高可用的装置还包括：

监控单元，用于监控所述多个计算节点上的虚拟机的运行状态；

统计单元，用于依据所述虚拟机的运行状态统计各计算节点的资源使用情况；

保存单元，用于将所述各计算节点的资源使用情况保存在数据库的计算节点表中。

优选地，所述一种实现数据库高可用的装置，其中，确定目标计算节点单元，具体用于将资源使用最少的计算节点确定为响应所述虚拟机处理请求的目标计算节点。

本发明还提供一种实现OpenStack高可用的方法，其特征在于，所述方法应用于基于OpenStack的控制系统，所述基于OpenStack的控制系统包括：调度器、两个配置相同的控制节点和多个计算节点，该方法包括：

所述调度器接收客户端发送的虚拟机处理请求；

所述调度器依据所述每个控制节点的负载情况，确定响应所述虚拟机处理请求的一个目标控制节点；

所述调度器将所述虚拟机处理请求发送给所述目标控制节点；

所述目标控制节点接收所述调度器发送的虚拟机处理请求，按照预设的负载均衡算法确定响应所述虚拟机处理请求的目标计算节点，并将所述虚拟机处理请求发送至所述目标计算节点；

所述目标计算节点执行所述数据请求。

优选地，所述调度器依据所述每个控制节点的负载情况，确定响应所述虚拟机处理请求的目标控制节点，包括：

所述调度器从内存中获取所述每个控制节点的负载情况，所述每个控制节点的负载情况保存在所述控制节点的各自内存中；

所述调度器依据所述每个控制节点的负载情况，将最小负载量所对应的控制节点，确定为响应所述虚拟机处理请求的目标控制节点。

本发明还提供一种实现OpenStack高可用的系统，其特征在于，所述系统集成于基于OpenStack的控制系统，所述基于OpenStack的控制系统包括：调度器、两个配置相同的控制节点和多个计算节点，所述调度器包括接收单元、确定目标控制节点单元和发送单元，所述接收单元用于接收客户端发送的虚拟机处理请求；所述确定目标控制节点单元，用于依据所述每个控制节点的负载情况，确定响应所述虚拟机处理请求的目标控制节点；所述发送单元，用于将所述虚拟机处理请求发送给所述目标控制节点；

所述控制节点上集成上述任意一种数据库高可用的装置；

所述计算节点用于执行所述数据请求。

与现有技术相比，本发明具有以下有益效果：

本发明在实现OpenStack控制节点中数据库集群高可用时，此数据库集群中有两台数据库，正常情况下，两台数据库同时对外提供服务，并且两台数据库上的数据库存储所有使用用户完整数据，当其中一台数据库出现故障时，另一台数据库接管故障服务器的任务，为使用用户提供无间断的服务，同时克服了现有技术中数据库集群在存储方面存在单点故障的缺点；并且，此数据库集群对应用程序没有要求，任何应用程序都可采用此数据库集群，克服了现有技术中，RAC产品需要适合的应用程序来使用的缺点。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1是本发明中一种实现数据库高可用的方法流程图；

图2是本发明中一种实现OpenStack高可用的方法流程图；

图3是本发明中一种实现数据库高可用的装置示意图；

图4是本发明中一种实现OpenStack高可用的装置示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明提供一种实现数据库高可用的方法，此方法应用在OpenStack控制系统的任意一个控制节点上，其中，OpenStack控制系统包括两个控制节点与多个计算节点。在每个控制节点内至少包括两个独立的数据库，并且控制节点中的数据库保存的数据相同，当一个数据库出现故障后，无论此故障是业务流程、物理设施，还是IT软/硬件故障，控制节点中的其他数据库继续为控制节点提供服务，以实现控制节点中数据库的高可用。根据不同客户端对虚拟机的不同处理请求，控制节点可以在计算节点上创建虚拟机，也可对计算节点上的虚拟机进行删除和修改，以满足客户端需求。

本发明在OpenStack控制系统的任意一个控制节点上实现数据库高可用的过程为：首先，控制节点接收来自不同客户端发送的虚拟机处理请求(创建虚拟机、删除虚拟机或者修改虚拟机)；然后，根据预设的负载均衡算法确定响应客户端发送的虚拟机处理请求的目标计算节点；最后，将虚拟机的处理请求发送给目标计算节点，以便目标计算节点响应此虚拟机处理请求。

本发明在OpenStack控制系统的任意一个控制节点上实现数据库高可用的基础上，还实现了一种实现OpenStack高可用的方法，其中，OpenStack高可用是基于OpenStack的控制系统，OpenStack控制系统包括调度器、两个配置相同的控制节点和多个计算节点。本发明实现OpenStack高可用的过程为：首先，调度器接收来自不同客户端的虚拟机处理请求；然后，调度器根据控制系统中每个控制节点的负载情况，确定一个目标控制节点，来响应此时接收的虚拟机处理请求，并将此虚拟机处理请求发送给确定的目标控制节点；最后，目标控制节点按照本发明在OpenStack控制系统的任意一个控制节点上实现数据库高可用的方法，目标控制节点确定响应此时的虚拟机处理请求的目标计算节点，以便此目标计算节点按照虚拟机处理请求来执行。

为了使本领域的人员更好地理解本发明方案，下面结合附图和具体实施方式对本发明作进一步详细的说明。

实施例1

为了使本领域的人员更好地理解本发明的一种实现OpenStack高可用方法，下面先对本发明在OpenStack控制系统中任意一个控制节点上，实现数据库高可用的步骤进行详细介绍，在执行数据库高可用步骤之前，需要做以下准备工作。

使用SaltStack工具在OpenStack平台部署两台控制节点与多台计算节点，每台控制节点中至少包括两个数据库，每个数据库的配置相同，使用负载均衡服务器(HAProxy)来为每个客户端的虚拟机处理请求分配计算节点。具体分为以下几步：

(1)系统初始化、在控制节点安装各种API服务和内部工作组件并准备yum源；

(2)在控制节点安装数据库和相关软件包；

(3)数据库集群设置，具体包括：配置每个数据库binglog格式为ROW；配置数据库集群名字；配置数据库集群中各数据库主机名和IP地址信息；先使用“wsrep-new-cluster”参数启动一台数据库，启动成功后启动剩余的数据库；

(4)在控制节点安装和配置负载均衡服务器(HAProxy)；

(5)测试连接数据库并检查数据库集群状态。

图1，是本发明实施例提供的一种实现数据库高可用的方法流程图，具体步骤可以包括：

步骤S100：不同客户端将虚拟机处理请求发送给控制节点。

在本步骤中，不同的客户端中的任意一个客户端根据业务需求，都需要在计算节点上处理关于虚拟机的业务，例如，在计算节点上创建虚拟机、删除虚拟机或者修改虚拟机等业务。在OpenStack云平台中，计算节点有多个，因此，响应每个客户端发出的虚拟机处理请求的计算节点，都需要由OpenStack控制系统中的控制节点来选取。

控制节点首先接收不同客户端发送的虚拟机处理请求，然后选取一个响应此虚拟机处理请求的计算节点，最后被选取的计算节点执行虚拟机的数据请求。

步骤S101：控制节点接收不同客户端发送的虚拟机处理请求。

按照不同客户端发送的虚拟机处理请求的先后顺序，控制节点中的负载均衡服务器按照先后顺序，依次接收所有客户端的虚拟机处理请求，并按照此顺序为每个客户端选取一个响应此虚拟机处理请求的目标计算节点。

步骤S102：控制节点按照预设的负载均衡算法确定响应所述虚拟机处理请求的目标计算节点。

在上步骤中，控制节点中的负载均衡服务器，按照先后顺序依次接收了不同客户端的虚拟机处理请求，负载均衡服务器中的负载均衡算法，按照所述的先后顺序，根据此时控制系统中的每个计算节点的负载量，为每一个客户端分配一个响应此虚拟机处理请求的目标计算节点。以一个客户端为例，控制节点为此客户端确定一个目标计算节点来响应此客户端的虚拟机处理请求的具体步骤包括：步骤A1～步骤A3。

步骤A1：控制节点中的pacemaker监控此时控制系统中的多个计算节点中虚拟机的运行状态。

在实际生产环境中，控制系统中的计算节点可能遇到硬件故障或者软件故障，其中，硬件故障，例如掉电、内存以及CPU故障等；软件故障主要是操作系统方面的故障，例如，Kernel panic服务异常与Neutron-ovs-agent服务异常等。为了确定响应客户端的虚拟机处理请求的目标计算节点，需要控制节点监控各计算节点中虚拟机的运行状态。

通常，在OpenStack控制系统中的控制节点和各计算节点中都安装pacemaker和corosync，OpenStack控制系统的控制节点通过pacemaker和corosync来监控各计算节点中虚拟机的运行状态，但是，控制系统的corosync最多只能监控16个计算节点，而在一般的OpenStack私有云中，计算节点的数目都会超过16个。为了克服计算节点数量受限的缺点，本发明实施例在各计算节点中安装pacemaker-remote来代替pacemaker和corosync，此时，控制节点可以通过pacemaker来监控各计算节点中的pacemaker-remote来监控计算节点中虚拟机是否在正常运行。

控制系统的控制节点监控各计算节点中虚拟机是否正常运行的方式有多种，除了通过上述的控制节点中的pacemaker来监控各计算节点中的pacemaker-remote来判断各计算节点中虚拟机是否正常运行之外，控制节点中的pacemaker还可以通过监控各计算节点中的nova-compute、neurton-ovs-agent以及libvirt等进程，甚至可以通过在各计算节点上启动虚拟机来，进而得到各计算节点中虚拟机是否正常运行。

本发明实施例中，通过控制节点中的pacemaker，实时地向各计算节点中的pacemaker-remote发送虚拟机是否正常运行信息，如果规定的时间内，控制节点中的pacemaker收到计算节点中pacemaker-remote的反馈信息，表示此计算节点中虚拟机在正常运行，如果规定的时间内，控制节点中的pacemaker没有收到计算节点中pacemaker-remote的反馈信息，表示此计算节点中虚拟机出现了故障。

在规定的时间内，Pacemaker对没有收到反馈信息的计算节点要进行隔离和恢复。隔离就是将故障的计算节点中虚拟机移除OpenStack；恢复是指将此故障计算节点的虚拟机迁移到其他正常运行的计算节点上；隔离的具体操作为:Pacemaker采用其内的fence-ipmilan来关闭出现故障的计算节点中虚拟机，接着，Pacemaker中的fence-compute一直监控此故障的计算节点中虚拟机是否down了，当Pacemaker中的fence-compute确定此故障的计算节点中虚拟机down后，执行恢复的操作：控制节点中的nava执行host-evacuate将down的计算节点中的虚拟机迁移到其他正常运行的计算节点，上述迁移故障计算节点中的虚拟机需要的时间可能较长，为了更快的迁移故障计算节点的虚拟机，本发明实施例调用Liberty版本的force-down API直接将故障的计算节点中虚拟机标记为down，以便更快的迁移此故障计算节点上的虚拟机。

此时，计算节点故障的中虚拟机已被隔离，此计算节点上故障的虚拟机已被转移到其他正常运行的计算节点上，接着，pacemaker分别向每个正常运行的计算节点，发送一个当前资源使用情况信息，所述资源使用情况信息指在各计算节点上当前正在运行虚拟机的数量，以及每台虚拟机所运行的内容，各计算节点将资源使用情况的信息发送给pacemaker，pacemaker将统计各计算节点回复的资源使用情况信息，并在任意一个数据库的计算节点表(compute_nodes表)中，保存各计算节点与其对应的负载量，以便负载均衡服务器根据计算节点表(compute_nodes表)所保存的信息，从这些计算节点中确定响应客户端虚拟机处理请求的一个目标计算节点。

步骤A2：负载均衡服务器依据各个计算节点中虚拟机的运行状态，分别统计每个计算节点的资源使用情况。

负载均衡服务器从控制节点的任意一个数据库中调用计算节点表(compute_nodes表)，从此表中得到此控制系统中各个计算节点的当前资源使用情况，即各计算节点中正在运行的虚拟机的数量，以便根据各计算节点上运行的虚拟机的数量的多少，来确定响应客户端虚拟机处理请求的一个目标计算节点。

步骤A3：根据步骤A2中统计得到的各计算节点的资源使用情况，将资源使用最少的计算节点确定为响应此客户端的虚拟机处理请求的计算节点。

根据步骤A2中统计得到的各计算节点的资源使用情况，即当前各计算节点上运行的虚拟机数量，从此信息中找到资源使用最少所对应的计算节点，将此资源使用最少所对应的计算节点确定为响应此客户端虚拟机处理请求的目标计算节点。

步骤A1～步骤A3，详细介绍以一个客户端发送的虚拟机处理请求为例，通过控制节点中的pacemaker监控此时控制系统中的各计算节点中虚拟机是否正常运行，接着，负载均衡服务器为此客户端分配一个计算节点的过程。对于负载均衡服务器接收的其他客户端的虚拟处理请求，同样按照步骤A1～步骤A3的过程，依次为每个客户端确定一个响应此客户端虚拟处理请求的目标计算节点。

当负载均衡服务器为一个客户端确定一个响应此客户端虚拟机处理请求的目标计算节点后，负载均衡服务器将此客户端、此客户端的虚拟机处理请求与响应此虚拟机处理请求的目标计算节点，对应的保存在此控制节点中的任意一个数据库的计算节点表(compute_nodes表)中。例如，对于1号客户端，向负载均衡服务器发送一个需要在计算节点上创建一个虚拟机的请求，并且负载均衡服务器为其确定了2号计算节点响应此客户端的请求，此时，负载均衡服务器将“1号客户端-创建虚拟机-2号计算节点”的信息保存在控制节点中的任意一个数据库的计算节点表(compute_nodes表)中，以方便对用户权限的管理，比如，1号客户端向控制节点发送，删除2号计算节点创建的虚拟机的请求，此时控制节点根据数据库中保存的信息，得到1号客户端没有在2号节点上创建过此虚拟机，因此控制节点不会响应1号客户端的删除此虚拟机的请求。

一般的，为实现数据库的高可用，在控制节点中至少有两个数据库，当向一个数据库计算节点表(compute_nodes表)中保存信息后，将此信息复制到此控制节点的其他数据库计算节点表(compute_nodes表)中，以保证控制节点中的所有数据库保存的数据相同。例如，上面已将“1号客户端-创建虚拟机-2号计算节点”的信息保存在控制节点中的一个数据库的计算节点表(compute_nodes表)中，当保存完成后，将此信息复制到控制节点中的其他数据库的计算节点表(compute_nodes表)中，以保证控制节点中的所有数据库都保存有客户端相同的完整数据。即使当其中一个数据库出现故障，其他的数据库可以接管故障的数据库的任务，正常对外提供服务，实现数据库的高可用，进而使得控制节点正常对外提供服务。

通过步骤S102，客户端被确定一个目标计算节点来响应其虚拟机处理请求，接着进入步骤S103。

步骤S103：将所述虚拟机处理请求发送至所述目标计算节点，以便所述目标计算节点执行所述数据请求。

在步骤S102中，负载均衡服务器为客户端确定了目标计算节点来响应此客户端的虚拟机处理请求后，负载均衡服务器将此客户端的虚拟机处理请求发送至控制节点中的nova-scheduler，nova-scheduler将此客户端的虚拟机处理请求发送至目标计算节点，目标计算节点执行相应的数据请求，例如在计算节点创建一个实例、修改一个实例或者删除一个实例等。

需要说明的是，若上述步骤S101中的控制节点同时接收到不同客户端发送的虚拟机处理请求时，一方面，控制节点可以按照接收虚拟机处理请求的先后顺序，首先，按照步骤S102分别对每个客户端的虚拟机处理请求，确定一个目标计算节点；然后，按照顺序，分别将客户端的虚拟机处理请求发送至与每个客户端对应的目标计算节点；最后，目标计算节点按照客户端的虚拟机处理请求执行相应的动作。另一方面，控制节点可以首先，对第一个客户端确定目标计算节点，接着将此客户端的虚拟机处理请求发送到对应的目标计算节点；然后，对第二个客户端确定目标计算节点，并将此客户端的虚拟机处理请求发送到对应的目标计算节点上；最后，按照接收虚拟机处理请求的先后顺序，依次循环，直到为最后一个客户端确定目标计算节点，并将此客户端的虚拟机处理请求发送到对应的目标计算节点上。

本发明实施例1，通过控制节点中的负载均衡服务器接收不同客户端的虚拟机处理请求，负载均衡服务器依据pacemaker监控得到的正常运行计算节点的资源使用情况，为每个客户端分配响应其虚拟机处理请求的目标计算节点，并通过nova-scheduler将此客户端的虚拟机处理请求发送至目标计算节点，使得目标计算节点执行此客户端的虚拟机处理请求。

在此过程中，通过pacemaker监控控制系统中的各计算节点中虚拟机的运行状态，将计算节点中故障的虚拟机进行隔离，并且将计算节点上隔离的的虚拟机转移到其他正常运行的计算节点上，实现了OpenStack控制系统中计算节点的高可用，进而保证了对使用用户的服务不间断。此外，pacemaker将实时监控得到的各正常运行的计算节点上，正在运行的虚拟机的数量以及虚拟机运行的内容，来更新任意一个数据库的计算节点表(compute_nodes表)，以便实现对客户端权限的管理。此外，负载均衡服务器将每个客户端、每个客户端的虚拟机处理请求以及为每个客户端分配的目标计算节点，都一一对应的保存在控制节点的任意一个数据库的计算节点表(compute_nodes表)中，通常在控制节点中至少存在两个独立的数据库，将信息保存在一个数据库计算节点表(compute_nodes表)中后，将此信息复制到其他的数据库计算节点表(compute_nodes表)中，进而保证控制节点中的各数据库都保存有相同的数据，当一个数据库出现故障时，其他的数据库可以继续工作，使得控制节点不间断地为客户端服务，从而实现了在一个控制节点中数据库的高可用。

上述实施例1介绍了，在OpenStack控制系统中的任意一个控制节点上实现数据库高可用的方法，并且在一个控制节点上实现数据库高可用的同时，实现了OpenStack控制系统中计算节点的高可用，本发明的最终目的在于，在OpenStack控制系统上实现OpenStack的高可用，OpenStack的高可用包括OpenStack控制系统中控制节点的高可用和计算节点的高可用，在实施例1中已经实现了OpenStack控制系统中计算节点的高可用，对于控制节点的高可用，即当OpenStack控制系统中的控制节点出现故障时，OpenStack控制系统的其他控制节点，接管此时故障的控制节点的任务，使得OpenStack控制系统不间断地响应客户端发出的虚拟机处理请求。控制节点的高可用实现过程通过实施例2进行详细介绍。

实施例2

本发明实施例详细介绍一种实现OpenStack控制系统中控制节点高可用的方法，此方法应用于基于OpenStack的控制系统，在本实施例中OpenStack控制系统包括调度器、两台相同配置的控制节点和多台计算节点。

图2，是本发明实施例提供的一种实现OpenStack高可用的方法流程图，具体步骤包括：

步骤S200：客户端发送虚拟机处理请求给调度器。

本发明实施例，在实现OpenStack控制系统中控制节点的高可用的过程中，OpenStack控制系统中的两台控制节点都可以为客户端发送的虚拟机处理请求，分配目标计算节点，对于客户端发送的虚拟机处理请求由哪一台控制节点来分配目标计算节点，由控制节点中的负载均衡服务器来负责，在两台控制节点中都分别存在一台负载均衡服务器，其中用来负责为客户端分配目标控制节点的负载均衡服务器，称之为调度器。所以，调度器，在物理位置上，是位于控制节点中，在逻辑功能上，与控制节点以及计算节点是同一级的。因此，客户端将其虚拟机处理请求发送给调度器，使得调度器为其分配目标控制节点，进而使得目标控制节点为其分配响应其请求的目标计算节点。

步骤S201：调度器接收客户端发送的虚拟机处理请求。

调度器接收来自客户端的虚拟机处理请求，来为此请求分配目标控制节点。

步骤S202：调度器依据所述每个控制节点的负载情况，确定响应所述虚拟机处理请求的一个目标控制节点。

本步骤中，调度器从OpenStack控制系统的每个控制节点的内存中获取，各控制节点在控制系统的各计算节点上的负载情况，将最小负载量所对应的控制节点确定为目标控制节点，具体包括步骤B1～步骤B2。

步骤B1：调度器从内存中获取所述每个控制节点的负载情况，所述每个控制节点的负载情况表示，每个控制节点的正在响应客户端虚拟机处理请求的数量。

在OpenStack控制系统中每个控制节点中，对于当前正在响应的客户端虚拟机处理请求，都以一种临时存储的方式保存在各控制节点的内存中，所述临时存储的方式是指，当客户端的虚拟机处理请求被响应后，此部分被响应的客户端虚拟机处理所占用的内存空间被释放，被释放的内存空间用来存储后来客户端所发送的虚拟机处理请求，依次循环，使得各控制节点的内存空间所存储的都是各控制节点正在响应的客户端虚拟机处理请求，这种临时存储的方式可以提高各控制节点的内存运行速度。

首先，调度器从各控制节点的内存中获取各控制节点当前正在响应的客户端虚拟机处理请求；然后，统计各控制节点正在响应的客户端虚拟机处理请求，得到各控制节点的负载情况。

例如，OpenStack控制系统的控制节点分别为A控制节点和B控制节点，A控制节点中的负载均衡服务器为调度器，调度器分别从A和B控制节点的内存中获取，A控制节点和B控制节点的当前客户端虚拟机处理请求，并统计得到A控制节点和B控制节点的当前客户端虚拟机处理请求量。比如，调度器统计得到在A控制节点中有7个正在响应的客户端虚拟机处理请求，B控制节点中有5个正在响应的客户端虚拟机处理请求，因此，A控制节点的当前负载量为7，B控制节点当前的负载量为5。

步骤B2：调度器依据所述各控制节点的负载情况，将最小负载量所对应的控制节点，确定为响应所述虚拟机处理请求的目标控制节点。

在步骤B1中调度器已得到每个控制节点的负载情况，调度器将最小负载量所对应的控制节点确定为目标控制节点，此目标控制节点为此客户端分配响应此客户端发送的虚拟机处理请求的目标计算节点。对于步骤B1中的例子，调度器得到了A控制节点的负载量为7，B控制节点的负载量为5，由于B控制节点的负载量小，所以，调度器将B控制节点确定为目标控制节点。

步骤S203：调度器将所述虚拟机处理请求发送给所述目标控制节点。

在调度器确定目标控制节点后，将接收的客户端虚拟机处理请求发送给目标控制节点，以方便目标控制节点分配响应此请求的目标计算节点。对于步骤S202的例子，调度器已确定B控制节点为目标控制节点，在本步骤中，调度器将虚拟机处理请求发送给B控制节点。

步骤S204：目标控制节点接收所述调度器转发的虚拟机处理请求，按照预设的负载均衡算法确定响应所述虚拟机处理请求的目标计算节点，并将所述虚拟机处理请求发送至所述目标计算节点。

在本步骤中，首先，目标控制节点接收调度器转发的虚拟机处理请求；然后，目标控制节点中的负载均衡服务器根据实施例1中步骤S102所述的方法，确定响应所述虚拟机处理请求的目标计算节点。

对于步骤S203中的例子，调度器已经将虚拟机处理请求发送给B控制节点，在本步骤中，B控制节点按照实施例1中步骤S102所述的方法，假设此时，3号计算节点的资源使用最少，则B控制节点将3号计算节点确定为目标计算节点，并且通过nova-scheduler将虚拟机处理请求发送给3号计算节点。

需要说明的是，在执行本步骤后，目标控制节点将此时“客户端-客户端具体的虚拟机处理请求-目标计算节点”信息保存在目标控制节点的任意一个数据库的计算节点表(compute_nodes表)中，并且将此信息复制到OpenStack控制系统中控制节点的其他数据库的计算节点表(compute_nodes表)中，使得OpenStack控制系统的所有数据库所保存的数据都相同。

步骤S205：目标计算节点执行所述数据请求。

目标计算节点接收到目标控制节点中nova-scheduler发送的虚拟机处理请求后，首先识别此请求，并为执行此请求做准备，待准备完成后，执行此数据请求。

本发明实施例，首先，调度器接收客户端发送的虚拟机处理请求，并获取控制节点内存中正在响应的客户端虚拟机处理请求，统计获取的各控制节点正在响应的客户端虚拟机处理请求的量，得到各控制节点的负载情况；然后，调度器根据各控制节点的负载情况，将负载量小的控制节点确定为目标控制节点，并将此虚拟机处理请求发送给此目标控制节点；最后，此目标控制节点根据各正常运行计算节点的负载量，将负载量小的计算节点确定为目标计算节点，使得目标计算节点执行此数据请求，此外，控制节点将“客户端-客户端具体的虚拟机处理请求-目标计算节点”保存在OpenStack控制系统的所有数据库的计算节点表(compute_nodes表)中，使得数据库的数据都相同，当OpenStack控制系统的一个控制节点出现故障时，另外一个控制节点可以接管故障控制节点的任务，使得为客户提供的服务不间断，从而实现OpenStack控制系统中控制节点的高可用。

实施例3

本发明实施例公开了一种实现数据高可用的装置，此装置集成于基于OpenStack的控制系统的任意一个控制节点上，所述控制系统包括两个控制节点和多个计算节点；请参见图3，所述装置包括：

接收请求单元301，用于接收不同客户端发送的虚拟机处理请求；

确定目标计算节点单元302，用于按照预设的负载均衡算法确定响应所述虚拟机处理请求的目标计算节点；

发送请求单元303，用于将所述虚拟机处理请求发送至所述目标计算节点，以便所述目标计算节点执行所述数据请求。

本发明实施例公开了一种实现数据高可用的装置，还包括：

获取虚拟机处理信息单元，用于获取所述虚拟机处理请求中的虚拟机处理信息，所述虚拟机处理信息包括：虚拟机创建信息、删除信息或修改信息；

存储虚拟机处理信息单元，用于将所述客户端和与其对应的所述虚拟机处理信息存储至数据库的计算节点表中。

监控单元，用于监控所述多个计算节点上的虚拟机的运行状态；

统计单元，用于依据所述虚拟机的运行状态统计各计算节点的资源使用情况；

保存单元，用于将所述各计算节点的资源使用情况保存在数据库的计算节点表中。

优选地，所述存储虚拟机处理信息单元，具体包括：

存储模块，用于将所述客户端与对应的虚拟机处理信息存储至任意一个数据库的计算节点表中；

复制模块，用于将所述客户端与对应的虚拟机处理信息复制至其他数据库的计算节点表中。

优选的，所述确定目标计算节点单元，具体用于将资源使用最少的计算节点确定为响应所述虚拟机处理请求的目标计算节点。

本发明实施例，首先，通过接收单元，接收不同客户端发送的虚拟机处理请求；然后，通过获取虚拟机处理信息单元、监控单元、统计单元、保存单元以及确定目标节点单元，为客户端发送的虚拟机处理请求分配目标计算节点，并通过存储虚拟机处理信息单元，将所述客户端和与其对应的所述虚拟机处理信息存储至数据库的计算节点表中；最后，通过发送请求单元，将所述虚拟机处理请求发送至所述目标计算节点，以便所述目标计算节点执行所述数据请求。

实施例4

本发明实施例公开了一种实现OpenStack高可用的系统，所述系统集成于基于OpenStack的控制系统，所述基于OpenStack的控制系统包括：调度器、两个配置相同的控制节点和多个计算节点，所述调度器包括接收单元、确定目标控制节点单元和发送单元，请参见图4，包括：

接收单元401，用于接收客户端发送的虚拟机处理请求；

确定目标控制节点单元402，用于依据所述每个控制节点的负载情况，确定响应所述虚拟机处理请求的目标控制节点；

发送单元403，用于将所述虚拟机处理请求发送给所述目标控制节点；

其中，所述控制节点上集成实施例3所述的装置；

所述计算节点用于执行所述数据请求。

优选的，所述确定目标控制节点单元，包括：

获取负载情况模块，用于从各控制节点内存中获取所述每个控制节点的负载情况；

确定目标控制节点模块，用于依据所述每个控制节点的负载情况，将最小负载量所对应的控制节点，确定为响应所述虚拟机处理请求的目标控制节点。

本发明实施例，首先，通过接收单元，接收客户端发送的虚拟机处理请求；然后，通过确定目标控制节点单元中的，获取负载表模块与确定目标控制节点模块，来确定响应所述虚拟机处理请求的目标控制节点；最后，通过发送单元，将所述虚拟机处理请求发送给所述目标控制节点。当控制系统中的一台控制节点出现故障时，其他正常工作的控制节点接管故障节点的任务，为客户端的虚拟机处理请求分配目标计算节点，进而实现OpenStack的控制系统中控制节点的高可用。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。