云平台监控数据系统的制作方法

本发明实施例涉及互联网技术领域，尤其涉及一种云平台监控数据系统。

背景技术：

2010年7月，openstack开源云计算项目由美国国家航空航天局(nationalaeronauticsandspaceadministration,nasa)和rackspace公司共同启动。现在全球有15000多名开发者和135个国家共同参与openstack的开发。openstack是用python语言开发的，采用apache2.0许可协议，是一个自由软件和开放源代码项目。openstack通过多个相互联系的服务提供基础设施即服务(infrastructureasaservice,iaas)类型的云计算解决方法。各个服务之间通过各自的rest风格的api相互联系。根据用户的需求，可以选择安装openstack的部分或全部服务，建立公有或私有的云存储服务。

由于云平台包含规模庞大的服务器集群，结构层次又十分复杂，对于平台的用户和管理人员而言，需要进行平台监控。云平台监控的任务主要是对物理主机和虚拟主机进行关键性能的监控，以帮助云端用户和管理员能够准确把握云主机的运行情况。监控的信息一般包括cpu、内存、磁盘io、网络等性能数据。

目前，openstack云平台主要由openstack云监控平台进行监控，openstack云监控平台作为一个公共服务组件，依托于openstack云服务器集群，为虚拟机和物理机集群提供性能检测和主机控制服务。作为服务性的工具，监控系统一般会设计成独立组件，以保证不会对openstack的基础性能不受到影响。

虚拟机和物理机的监控任务集中交给监控服务器。这种设计的优点在于监控服务和openstack提供的虚拟机服务是独立的。如果监控系统出现异常，不会影响到openstack平台的核心功能。但是对于监控服务而言，由于所有的功能都集中于监控服务器，导致监控服务器压力较大，容易出现性能问题。监控服务器的性能问题源于以下两个方面：一是由于用户数量上升对服务器产生大量的并发访问，从而对服务器造成巨大的负载问题。二是由于集群规模扩大导致监控服务器采集任务不断加重，从而使数据库承受巨大的压力。由于openstack主要是提供iaas层次的服务，会产生海量虚拟主机和性能监测数据，因此对虚拟机群进行监控会对数据库造成巨大的负担。

如何解决云平台的监控服务器存在的上述问题,是目前需要解决的一个重要技术问题。

技术实现要素：

有鉴于此，本发明实施例所解决的技术问题之一在于提供一种云平台监控数据系统，用以克服现有技术中由于大量的并发访问而造成监控服务器负载过大以及由于监控数据过大而导致监控数据库负担过大的缺陷，达到改善监控平台的能效，使资源能够被合理利用的效果。

本发明实施例提供一种云平台监控数据系统。该云平台监控数据系统包括：监控数据库，用于存储云平台的监控数据；监控集群服务器，包括多个监控服务器，用于接收针对所述监控数据库的操作请求，按照所述操作请求对所述监控数据库执行相应的操作；负载均衡组件，用于接收到来自所述云平台的各个虚拟机和各个物理机的针对所述监控数据库的操作请求，按照预设的负载均衡策略，将所述操作请求发送给所述监控集群服务器中一个监控服务器；分库组件，用于对所述监控数据库进行分库处理，将所述监控数据库中部分数据分配到一个分库中。

可选地，在本发明一具体实施例中，还包括：策略组件，用于检测所述监控数据库的i/o吞吐率，在所述i/o吞吐率低于第一预设值时，启动所述分库组件。

可选地，在本发明一具体实施例中，所述分库组件包括：垂直分库组件，用于将所述监控数据库中业务紧密、标间关联密切，单于其他表联合查找和联系的概率小于第二预设值的表独立出来，分配到一个新的分库中。

可选地，在本发明一具体实施例中，所述分库组件还包括：数据检测组件，用于在所述垂直分库组件执行分库之后，检测所述新的分库中的数据量是否超过第三预设值或数据量增长的速度是否超过第四预设值，如果是，则启动水平分库组件；所述水平分库组件，用于根据业务逻辑或表间关系，将所述新的分库划切分为多个更小的分库。

可选地，在本发明一具体实施例中，所述分库组件还包括：筛选合并组件，用于将业务上联系紧密，且数据增长速率相近的多个分库中的数据合并入同一个数据库中。

可选地，在本发明一具体实施例中，所述系统还包括：逻辑控制组件，用于在所述分库组件执行分库操作之后，根据所有数据表的目标分库，更新所述监控数据库的控制逻辑。

可选地，在本发明一具体实施例中，还包括：认证库，用于记录所述监控数据库中的数据的数据标识与该数据所在的目标分库的对应关系。

可选地，在本发明一具体实施例中，所述操作请求包括：监控数据读取操作请求或监控数据写入操作请求。

由以上技术方案可见，本发明实施例提供的云平台监控数据系统，通过负载均衡组件，将对监控数据库的操作请求动态均衡到监控集群服务器的各个监控服务器，从而可以解决用于并发访问量过大，而导致监控服务器负载过大的问题，并且，本发明实施例提供的云平台监控数据系统的分库组件还可以对监控数据库进行分库处理，将监控数据库中的部分数据分配到分库中，从而避免了由于监控数据量过大而导致监控数据库的压力过大的问题，改善了云监控平台的能效，使资源能够被合理利用。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1为根据本发明实施例的一种云平台监控数据系统的架构示意图；

图2为根据本发明实施例的另一种云平台监控数据系统的架构示意图；

图3为根据本发明实施例的又一种云平台监控数据系统的架构示意图；

图4为本发明实施例中分库组件执行分库流程的示意图。

具体实施方式

当然，实施本发明实施例的任一技术方案必不一定需要同时达到以上的所有优点。

为了使本领域的人员更好地理解本发明实施例中的技术方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明实施例一部分实施例，而不是全部的实施例。基于本发明实施例中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本发明实施例保护的范围。

下面结合本发明实施例附图进一步说明本发明实施例具体实现。

本发明实施例提出了一种改进的云平台监控数据系统，以至少改良现有的基于openstack云平台的监控性能。在本发明实施例提供的云平台监控数据中，可以同时部署动态均衡和数据库逻辑拆分，从而改善云监控平台的能效，合理利用资源。

图1为本发明实施例提供的一种云平台监控数据系统的架构示意图，如图1所示，本发明实施例提供的云平台监控数据系统主要包括：监控数据库100，用于存储云平台的监控数据；监控集群服务器110，包括多个监控服务器，用于接收针对所述监控数据库的操作请求，按照所述操作请求对所述监控数据库执行相应的操作；负载均衡组件120，用于接收到来自所述云平台的各个虚拟机和各个物理机的针对所述监控数据库的操作请求，按照预设的负载均衡策略，将所述操作请求发送给所述监控集群服务器中一个监控服务器；分库组件130，用于对所述监控数据库进行分库处理，将所述监控数据库中部分数据分配到一个分库中。

本发明实施例提供的上述云平台监控数据系统，提出一种基于动态数据源的弹性架构。在本发明实施例提供的云平台监控数据系统中，可以同时部署动态均衡和数据库逻辑拆分，在具体应用中也可以根据需求取消动态均衡和数据库拆分，即关闭负载均衡组件和分库组件。这种策略能够改善云监控平台的能效，使资源能够被合理利用。

在本发明实施例中，各个虚拟机和各个物理机的针对所述监控数据库的操作请求，可以是监控数据读取操作请求，例如，查询监控数据的查询请求，也可以监控数据写入操作请求，即在各个虚拟机和各个物理机产生监控数据时，将对应的监控数据发送给服务端，请求写入监控数据库。

在本发明实施例中，监控集群服务器110是由多台监控服务器以对称的方式组成一个服务器集合，每台监控服务器都具有等价的地位，可以单独对外提供服务而无须其他监控服务器的辅助。在本发明实施例中，负载均衡组件120可以采用某种负载均衡策略,将外面发送来针对监控数据库的操作请求均匀分配到对称结构中的某一台监控服务器上，而接收到操作请求的监控服务器独立地回应该操作请求。通过将系统负载分配到不同的监控服务器上处理，可以解决大量用户并发访问服务的问题，实现并行处理。

在具体应用中，可以按照负载均衡组件120可以按照现有的负载均衡策略进行负载均衡处理。具体地，负载均衡组件120可以设置在服务端，通过多监控服务器协同处理来自云平台的操作请求，从而在多个监控服务器之间分担负载，以减轻单个监控服务器处理报文的负担。或者，负载均衡组件120可以设置在客户端，在网络客户端(在云平台中，可以为虚拟机或物理机上客户端)运行特定的程序，该程序通过定期或不定期地收集监控集群服务器的运行参数：cpu占用情况、磁盘i/o、内存等动态信息，再根据某种选择策略，找到可以提供服务的最佳服务器，将本地的应用请求发向该最佳服务器。如果负载信息采集程序发现监控服务器失效，则找到其他可替代的监控服务器作为服务选择。或者，可以提供一个javaapplet在客户端浏览器中运行，applet向各个监控服务器发送请求收集服务器的负载等信息，再根据这些信息将虚拟机或物理机的操作请求发到相应的监控服务器。

在本发明实施例中，负载均衡组件120可以自动判断监控服务器的负载量，并将操作请求被分摊到不同的监控服务器。监控服务器可以采用一种被称为“黏性session”的会话方式，来保证来自同一个源端的操作请求能始终被特定某一个的监控服务器所响应，从而避免session同步的问题。由于所有监控服务器都连接同样的数据库(即监控数据库)，处理同样的业务，而操作请求之间也是相互独立的，因此，本发明实施例中增加负载均衡组件不会对现有的业务逻辑带来改变。

在具体应用中，由于载均衡的目的是根据系统中各个处理机的性能及其负载来分配任务，监控服务器的处理能力和当前的负载量是影响监控服务器负载变化的主要因素。负载量是一个动态值，确定它的参数需要首先确定一个动态调度策略，负载均衡策略的核心是负载均衡算法。因此，在本发明实施例中采用的负载均衡策略具有以下特点：1)为了保证系统在长时间运行状态下,负载不发生较大倾斜,负载均衡组件120每次选择的监控服务器,应该是监控集群服务器中负载较小的；2)为了充分利用节点的处理能力，负载均衡组件120在进行决策时，应该考虑全局的负载状态，获取的负载信息也要保证是最新的；由于操作请求的动态变化，监控集群服务器各处理节点上的负载也在不断变化，因此要求负载均衡组件120能够根据某种动态均衡策略进行监控服务器负载的均衡，为用户提供服务；3)在得到每个监控服务器的负载状态信息之后，可以在综合考虑系统结构和负载特征等因素的基础上，对一般的均衡算法进行改进或者把几种方法结合在一起使用，以更好的适应系统的变化。

对于大型系统而言，数据迁移是一个巨大的负担，不仅直接消耗大量的资源，而且容易出现数据残留或损坏，因此，在本发明实施例的一个可选实施方案中，如图2所示，该云平台监控数据系统还包括：策略组件140，用于检测所述监控数据库的i/o吞吐率，在所述i/o吞吐率低于第一预设值时，启动所述分库组件130。即在该可选实施方式中，只有在监控数据库的i/o吞吐率较低的情况下，才启动分库组件130进行数据分库，以避免不必要的分库所来的问题。在监控数据库的i/o吞吐率较低的情况下，说明当前监控服务器采集的数据较多，监控数据库承受压力较大，因此，需要集群服务器，运用数据库分库策略使其达到大型，或超大型商业数据库的效果，这样不仅节约了成本，而且提高了系统的性能。

数据库分库主要为了应对海量数据库的稳定、高效、健壮的扩展，以突破单数据库服务器的i/o吞吐、运算负载，提高数据库事务的执行效率，从而提高整个系统的性能。通过数据库分库，可将原服务器的运算、存储、i/o吞吐科学分配到一个系统的服务集群之中，这样可充分利用集群中所有的硬件资源，而且可避免单节点执行失败导致系统无法运行的问题。

在本发明实施例的一个可选实施方案中，如图3所示，分库组件130可以包括：垂直分库组件131，用于将所述监控数据库中业务紧密、标间关联密切，单于其他表联合查找和联系的概率小于第二预设值的表独立出来，分配到一个新的分库中。在具体应用中，分库组件130在执行分库时，可以先启动垂直分库组件131，将业务紧密、标间关联密切，单于其他表联合查找较少、联系较少的表独立出来，分配到一个新的库内。

在具体应用中，在垂直分库组件131执行垂直分库后，如果其数据增长速度缓慢，其当前负载上限能够维持相当一段时间的系统运行，则暂时不需要进行水平切分处理。如果分库内数据数据量大或者数据增长速度快，在预期的有限时间内可能达到当前负载上限，则需要在垂直切分的基础上执行水平切分操作。因此，可选地，如图3所示，分库组件130还可以包括：数据检测组件132，用于在所述垂直分库组件131执行分库之后，检测所述新的分库中的数据量是否超过第三预设值或数据量增长的速度是否超过第四预设值，如果是，则启动水平分库组件133；所述水平分库组件133，用于根据业务逻辑或表间关系，将所述新的分库划切分为多个更小的分库。在具体应用中，水平分库组件133切分得到的这些更小的分库中都只包含一个主表(主表的id与分库之间具有映射关系)和多个与相关联的次表。

通过上述的监控数据系统，通过水平拆分或垂直拆分使数据库呈现分布式结构，这样就能达到在数据库层面均摊读写压力的需求。

随着水平切分的完成，将产生越来越多的分库，如果某些小的分库中只有有限的几张数据表，则将浪费该分库的运算及存储资源，因此，在水平切分完成后，可根据各分库中的数据表数量进行一次筛选合并。因此在本发明实施例的一个可选实施方案中，如图3所示，分库组件130还可以包括：筛选合并组件134，用于将业务上联系紧密，且数据增长速率相近的多个分库中的数据合并入同一个数据库中。

在垂直分库组件131、水平分库组件133和筛选合并组件134执行上述操作后，确定了监控数据库中所有数据表的目标分库，则需要在系统查询還辑中打断所有跨越分库的表间关联，如在书写sql时，跨分库的join、groupby、orderby都将是不允许的，因此，为了便于联合查询，在本发明实施例的一个可选实施方案中，该系统还可以包括逻辑控制组件，用于在所述分库组件130执行分库操作之后，根据所有数据表的目标分库，更新所述监控数据库的控制逻辑。从而使得监控数据库的联合查询操作可以由由单库查询配合程序逻辑控制实现。

图4为本发明实施例中，分库组件130对监控数据库执行分库的示意图，如图4所示，主要分为以下三个步骤：

步骤1、垂直切分。将业务紧密、标间关联密切，单于其他表联合查找较少、联系较少的表独立出来，分配到一个新的库内。

步骤2、水平切分。对于垂直分库后库内的数据表进行分析，如果其数据增长速度缓慢，其当前负载上限能够维持相当一段时间的系统运行，那就暂时不需要进行水平切分处理。如果分库内数据数据量大或者数据增长速度快，在预期的有限时间内可能达到当前负载上限，则需要在垂直切分的基础上执行水平切分操作。水平切分的方法为：根据业务逻辑或表间关系，将当前库划切分为多个更小的库。通常情况下，这些更小的分库中都只包含一个主表(主表的id与分库之间具有映射关系)和多个与相关联的次表。

步骤3、筛选合并。随着水平切分的完成，会产生越来越多的分库。如果某些小的分库中只有有限的几张数据表，那样会浪费该分库的运算及存储资源，所以，在水平切分完成后，可根据各分库中的数据表数量进行一次筛选合并。筛选合并，即为将业务上联系紧密，并且数据增长速率相近分库合并入同一个数据库之中。确定所有数据表的目标分库后，需要在系统查询還辑中打断所有跨越分库的表间关联，如在书写sql时，跨分库的join、groupby、orderby都将是不允许的，这些联合查询操作将由单库查询配合程序逻辑控制实现。

在实际操作中，上述三个步骤可能只需要其中的一步或多步。比如对于有些数据库只需要简单的垂直切分即可，有些在完成垂直切分与水平切分后并不需要筛选合并过程，所切视具体情况而定，尽量找到性能与资源的平衡点。

监控数据库在进行分库后，在上线一段时间后，数据可能会进行快速的增加，使得各分库的数据量逐步趋近负载上限，此时需要对再次对分库进行扩容，也就是引入新的分库来分担系统中的数据压力。如果分库组件130使用的是基于hash取模的水平切分规则，那么需要根据新的节点规模重新计算所有数据应处的目标分库，并将其迁移过去。如果分库组件130是按分段水平切分，这样在分库扩容时虽然可避免数据的迁移，但是却可能带来＂热点＂问题，即为新添加数据的访问要远高于历史数据，如日志数据的提取，从而影响了系统性能。

所以，＂完美＂的分库扩容应实现以下几个方面：

1.最好不迁移数据。对于海量数据的数据迁移不仅耗时、耗损硬件资源，而且极易产生一些未知的差错，导致系统缺陷。

2.可以自由的设定分库的负载能力。

3.各分库间数据操作频率相对平衡，实现负载均衡。

4.当分库数据量达到负载上限时，不再进行数据添加。

由于技术和硬件资源的限制，现实项目中可能无法全部满足以上四点，一般都是必须做到避免数据迁移的基础上尽量兼顾其他。一个可行的方法是在＂认证库＂中保存数据库配置，即维护一张记录数据id和目标分库对应关系的映射表。新添加数据时，按照一定的规则(比如按分段切分或者hash取模切分)给数据分配新的数据库，进行目标库数据添加的同时，将id和目标分库的映射添加到认证库中。在进行新数据读取时，需要先查询认证库中的映射信息，然后去目标分布再执相关查询。当发生分库扩容时，如hash取模切分的n值变化时，可按照新的规则换算新的id所映射的数据库，但是因为历史映射没有改变，所以就避免了旧数据。因此，在本发明实施例的一个可选实施方案中，如图3所示，该系统还包括认证库150，用于记录所述监控数据库中的数据的数据标识与该数据所在的目标分库的对应关系。

总之，动态均衡和分库的引入，在带来性能提升的同时，也会极大程度上增加系统本身的复杂性。这会使系统整体更加臃肿，调整空间变得更小。极端情况下也可能会遇到这种需求：需要在企业内部搭建基于openstack的私有云服务，但是企业内并没有太多服务器集群用于搭建云平台，也没有太多客户。这意味着如果在这种对性能要求较小的企业级环境中，最原始的拓扑架构已经足够满足需求，采用动态均衡和分库策略将是完全的浪费。

本发明实施例主要针对现有openstack云主机的监控性能问题，提出一种基于动态数据源的弹性架构的监控数据系统。在该系统中，可以同时部署动态均衡和数据库逻辑拆分，也可以根据需求取消动态均衡和数据库拆分。这种策略能够改善云监控平台的能效，使资源能够被合理利用合理。在云计算虚拟节点产生动态数据变化时，监控系统通过动态数据反馈进行自适应的变化，并继续保持高效稳定的运行。