CN113703917A - 一种多集群资源数据处理***与方法、非暂态存储介质 - Google Patents
一种多集群资源数据处理***与方法、非暂态存储介质 Download PDFInfo
- Publication number
- CN113703917A CN113703917A CN202110989470.5A CN202110989470A CN113703917A CN 113703917 A CN113703917 A CN 113703917A CN 202110989470 A CN202110989470 A CN 202110989470A CN 113703917 A CN113703917 A CN 113703917A
- Authority
- CN
- China
- Prior art keywords
- resource
- resource data
- cluster
- database
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45583—Memory management, e.g. access or allocation
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种多集群资源数据处理***与方法,处理***包含多个集群、资源收集器、数据库,多个集群分别与资源收集器进行数据传输,资源收集器与数据库进行数据传输,数据库内存储有资源数据。资源收集器包含资源监视器、资源对象变化队列、筛选模块、全量资源版本缓存模块、去重压力队列、数据库同步控制器。本方案基于Kubernetes平台搭建了多集群资源数据平台,对多集群的资源数据进行整合和展示,可通过资源搜索服务器搜索和查看多集群中的任何资源数据,无需分别登录每个集群即能够快速有效查看目标资源数据。
Description
技术领域
本发明涉及容器云技术领域,具体涉及一种多集群资源数据处理***与方法、非暂态存储介质。
背景技术
Kubernetes是一个开源的,用于管理云平台中多个主机上的容器化的应用,多个主机在Kubernetes的统一管理下组成一个Kubernetes集群。随着越来越多的应用部署在云平台上, 每个Kubernetes集群的工作负载资源数据数量庞大,集群管理员可以通过登录集群管理界面的方式,查看和搜索集群中工作负载及容器的资源数据。
在实际生产过程中,企业通常会部署多套Kubernetes集群, 以满足企业的使用需求,多套Kubernetes集群中的全部资源数据更是不计其数。当企业部署多套Kubernetes集群时,集群管理员要查看多个集群或全部集群中工作负载及容器的资源数据,则需要分别登录这些集群的管理界面进行查看和搜索,操作繁琐,效率低下。
因此,亟需一种将多Kubernetes集群的资源数据进行聚合,以供集群管理员进行统一查看和搜索的技术方案。
发明内容
本发明要解决的技术问题是,本发明提供一种多集群资源数据处理***,本发明还提供一种多集群资源数据处理方法,本方案基于Kubernetes平台搭建了多集群资源数据查看和搜索平台,对多集群的资源数据进行整合和展示,集群管理员可通过资源查看和搜索平台的用户使用界面,查看或者搜索多集群中的任何资源数据,无需分别登录每个集群的管理界面,即能够快速有效地查看目标资源数据,用以解决现有技术导致的缺陷。
名词解释:
资源数据变化对象:当Kubernetes集群中的工作节点上的资源产生变化时,工作节点上的kubelet组件监测到该变化,即向控制节点进行汇报,并通过API Server将变化写入Kubernetes集群中的分布式状态存储数据库ETCD,资源数据变化对象是指产生变化的资源的全部数据信息。
资源版本号:用于区分资源版本迭代的数字,只要资源产生变化,资源版本号即按照预设规则增大。
为解决上述技术问题本发明提供以下的技术方案:
第一方面,一种多集群资源数据处理***,其中,包含多个集群、资源收集器、数据库,所述多个集群分别与所述资源收集器进行数据传输,所述资源收集器与所述数据库进行数据传输,所述数据库内存储有资源数据;
所述资源收集器包含资源监视器、资源对象变化队列、筛选模块、全量资源版本缓存模块、去重压力队列、数据库同步控制器;
所述资源监视器用于获取所述多个集群中的资源数据变化对象,并存入资源对象变化队列中;
所述去重压力队列中存储有资源数据变化对象并对所述资源数据变化对象进行去重;
所述资源对象变化队列中存储有资源数据变化对象的资源版本号;
所述全量资源版本缓存模块用于访问数据库以获取资源数据,并生成键值对形式的所述资源数据的关键信息;其中,所述关键信息包括资源版本号;
所述筛选模块用于获取所述资源对象变换队列中的资源数据变化对象的资源版本号与所述全量资源版本缓存模块中相应资源数据的资源版本号,并判断所述资源对象变换队列中的资源数据变化对象的资源版本号是否比所述全量资源版本缓存模块中相应资源数据的资源版本号更新,若是,则将所述资源对象变化队列中存储的资源数据变化对象存入所述去重压力队列中,并使用所述资源数据变化队列中资源数据变化对象的关键信息更新所述全量资源版本缓存模块中相应的资源数据的关键信息;
所述数据库同步控制器用于定期读取所述去重压力队列中存储的资源数据变化对象并更新所述数据库中的资源数据。
所述去重压力队列作为所述数据库存储的缓冲区,需要与所述数据库中资源数据存储的机制保持一致,由于在所述数据库中不同类型的资源数据存储方式存在区别,因此使用不同类型的所述去重压力队列来存储不同类型的资源数据;此外,如果在所述数据库同步器两次读取所述去重压力队列期间,某资源数据发生了两次或两次以上的变化,可以对资源数据变化对象进行去重处理,以减轻所述数据库的存储负担,具体是,当所述去重压力队列收到所述筛选模块存入的资源数据变化对象后,与所述去重压力队列中已有的资源数据变化对象进行比对,如果是同一集群上的相同类型的同一个资源对象,则使用新的资源数据变化对象覆盖所述去重压力队列中已有的资源数据变化对象。
上述的一种多集群资源数据处理***,其中,所述资源监视器通过所述集群的APIServer获取所述集群中的资源数据变化对象,并与所述集群之间建立数据传输通道,以持续传输所述集群中的资源数据变化对象,所述集群为Kubernetes集群。
上述的一种多集群资源数据处理***,其中,所述资源监视器、所述资源对象变化队列、所述筛选模块、所述去重压力队列均设置有多个,每个所述资源监视器与一个所述集群中的一种资源类型对应设置;
每个所述资源对象变化队列与一个所述资源监视器对应设置;所述资源监视器用于获取所述多个集群中的每种资源类型的资源数据变化对象,并存入相应的所述资源对象变化队列中;
每个所述筛选模块与一个所述资源对象变化队列对应设置;
每个所述去重压力队列与全部所述集群中的一种资源类型对应设置;
每个所述筛选模块与所述全量资源版本缓存模块、所述去重压力队列进行数据传输;
每个所述去重压力队列与所述数据库同步控制器进行数据传输;
所述全量资源版本缓存模块、所述数据库同步控制器分别与所述数据库进行数据传输。
上述的一种多集群资源数据处理***,其中,所述***还包括资源搜索服务器,用于获取所述数据库中的资源数据,并展示在资源查看与搜索界面上。
上述的一种多集群资源数据处理***,其中,为了让多集群资源数据查看和搜索平台能够查询到资源数据的历史变化情况,所述数据库包括主数据库和副数据库,所述全量资源版本缓存模块与所述主数据库进行数据传输,所述主数据库与所述副数据库进行数据传输,所述主数据库用于存储最新资源数据,所述副数据库用于存储历史资源数据。
所述数据库同步器定期读取每个所述压力队列中存储的资源数据变化对象,将所述去重压力队列中的资源数据变化对象存入所述主数据库,定期对所述主数据库中存储的资源数据进行盘点,如果所述主数据库中存在不同版本的同一资源数据时,将旧版本的资源数据移入所述副数据库中进行存储,并建立同一资源数据新旧版本之间的关联关系;
相应地,前述所述去重压力队列将不再执行去重功能,仅作为所述数据库存储的缓冲区,也就是说,当所述去重压力队列收到所述筛选模块存入资源数据变化对象后,与所述去重压力队列中已有的资源数据变化对象进行比对,如果是同一集群上的同类资源,则将新的资源数据变化对象标记为最新资源数据,将队列中已有的资源数据变化对象标记为历史资源数据;在所述数据库同步控制器将所述去重压力队列中的资源数据变化对象存入所述主数据库时,先存入带有历史资源数据标记的资源数据变化对象,后存入带有最新资源数据标记的资源数据变化对象,从而自动将带有历史资源数据标记的资源数据变化对象移入所述副数据库中进行存储。
当集群管理员查看和搜索平台能够查询到资源数据的历史变化情况时,资源搜索服务器首先在所述主数据库中检索最新资源数据,然后通过最新资源数据在所述副数据库中检索历史资源数据,将资源数据的新旧历史版本全部展示给集群管理员。
上述的一种多集群资源数据处理***,其中,所述资源信息数据的关键信息包含以键值对(ClusterName-ResourceKind-Namespace-ResourceName:ResourceVersion)形式存储的资源数据对应的集群、资源类型、命名空间、资源名称、资源版本号。
第二方面,一种多集群资源数据处理方法,其中,包含以下步骤:
全量资源版本缓存模块访问数据库以获取资源数据,并生成键值对形式的所述资源数据的关键信息;其中,所述关键信息包括资源版本号;
资源监视器获取多个集群中的资源数据变化对象,并存入资源对象变化队列中;
筛选模块获取资源对象变化队列中的资源数据变化对象的资源版本号和所述全量资源版本缓存模块中相应资源数据的资源版本号,并判断所述资源对象变换队列中的资源数据变化对象的资源版本号是否比所述全量资源版本缓存模块中相应资源数据的资源版本号更新;
若是,则将所述资源对象变化队列中存储的资源数据变化对象存入所述去重压力队列中,并使用所述资源数据变化队列中资源数据变化对象的关键信息更新所述全量资源版本缓存模块中相应的资源数据的关键信息;
数据库同步控制器定期读取所述去重压力队列中存储的资源数据变化对象并更新所述数据库中的资源数据。
上述的一种多集群资源数据处理方法,其中,所述资源监视器获取多个集群中的资源数据变化对象,包括:所述资源监视器通过所述集群的API Server获取所述集群中的资源数据变化对象,并与所述集群之间建立数据传输通道,以持续传输所述集群中的资源数据变化对象。
上述的一种多集群资源数据处理方法,其中,所述方法还包括:资源搜索服务器获取所述数据库中的资源数据,并展示在资源查看与搜索界面上。
上述的一种多集群资源数据处理方法,其中,所述数据库包括主数据库和副数据库,所述主数据库用于存储最新资源数据,所述副数据库用于存储历史资源数据,所述资源搜索服务器获取所述数据库中的资源数据包括:
获取资源数据查看指令或搜索指令;
根据所述查看指令或搜索指令所对应的展示需求,对所述最新资源数据进行展示,或者对所述最新资源数据和所述历史资源数据一起进行展示。
上述的一种多集群资源数据处理方法,其中,每个所述集群内的每种资源均对应一个所述资源监视器,为了在数据传输通道出现故障时,所述资源监视器能够及时采取恢复措施,所述资源监视器与相对应的所述集群的API Server(心跳机制)连接获取该所述集群中指定类型的资源数据变化对象,即当所述集群的API Server超过预设时间没有向所述资源监视器发送资源数据变化对象时,需要单独发送一个心跳包,以让资源监视器确定数据传输通道是否畅通。如果所述资源监视器超过预设时间,既没有收到资源数据变化对象,又没有收到心跳包,可以确定数据传输通道出现故障,则所述资源监视器主动向集群的APIServer发送请求,恢复数据传输通道。
上述的一种多集群资源数据处理方法,其中,所述资源监视器、所述资源对象变化队列、所述筛选模块、所述去重压力队列均设置有多个,每个所述资源监视器与一个所述集群中的一种资源类型对应设置;
每个所述资源对象变化队列与一个所述资源监视器对应设置;所述资源监视器用于获取所述多个集群中的每种资源类型的资源数据变化对象,并存入相应的所述资源对象变化队列中;
每个所述筛选模块与一个所述资源对象变化队列对应设置;
每个所述去重压力队列与全部所述集群中的一种资源类型对应设置;
每个所述筛选模块与所述全量资源版本缓存模块、所述去重压力队列进行数据传输;
每个所述去重压力队列与所述数据库同步控制器进行数据传输;
所述全量资源版本缓存模块、所述数据库同步控制器分别与所述数据库进行数据传输。。
依据上述的一种多集群资源数据处理***与方法能够实现如下四种场景:
一、首次同步场景
当多集群资源数据查看和搜索平台首次获取每个所述集群上的所有资源数据时,每个所述资源收集器设置的所述资源监视器分别向相对应的所述集群上的API Server发出请求,以获取每个所述集群上每种类型的资源数据,从而建立起所述资源监视器与所述集群之间长期稳定的数据传输通道;所述数据库中没有任何资源数据,因此所述全量资源版本缓存模块、所述筛选模块无需工作,所述资源监视器获取相对应的单个所述集群上指定类型的资源数据变化对象后,存入相应的所述资源对象变化队列中,再按照资源类型的不同将资源数据变化对象存入相应的所述去重压力队列中,所述数据库同步器将所述去重压力队列中的资源数据变化对象存入所述数据库。
二、实时同步场景
当多集群资源数据查看和搜索平台实时获取每个集群上的所有资源数据时,所述全量资源版本缓存模块获取所述数据库中存储的所有资源数据的关键信息,包括资源数据对应的集群、资源类型、命名空间、资源名称、资源版本号,并以键值对(ClusterName-ResourceKind-Namespace-ResourceName:ResourceVersion)的形式进行存储;所述集群的API Server通过访问ETCD来获知当前集群上的资源数据变化对象,并通过首次同步时建立的长期稳定的数据传输通道向对应的所述资源监视器传输当前集群上指定类型的资源数据变化对象,存入相应的所述资源对象变化队列中;其中,每个资源数据变化对象具有一个属性,用于标注资源变化的类型,具体包括新增、变更、删除等。
(一)资源变化的类型为新增
与所述资源对象变化队列对应设置的所述筛选模块将直接新增的资源对象存入相应的所述去重压力队列中,并将该资源数据变化对象对应的关键信息***所述全量资源版本缓存模块。
(二)资源变化的类型为变更
与所述资源对象变化队列对应设置的所述筛选模块将其对应的所述资源对象变化队列中存储的资源数据变化对象的资源版本号,与所述全量资源版本缓存模块中存储的资源数据的关键信息中的资源版本号进行比较,以判断所述资源对象变化队列中存储的资源数据变化对象是否比所述数据库中存储的资源数据更新,如果是,则将所述资源对象变化队列中存储的资源数据变化对象存入相应的所述去重压力队列中,并使用该资源数据变化对象对应的关键信息覆盖所述全量资源版本缓存模块中相应的关键信息;所述去重压力队列将所述筛选模块存入资源数据变化对象与所述去重压力队列中已有的资源数据变化对象进行比对,如果是同一集群上的相同类型的同一个资源对象,则使用新的资源数据变化对象覆盖队列中已有的资源数据变化对象。
(三)资源变化的类型为删除
与所述资源对象变化队列对应设置的所述筛选模块将其对应的所述资源对象变化队列中存储的资源数据变化对象的资源版本号,与所述全量资源版本缓存模块中存储的资源数据的关键信息中的资源版本号进行比较,以判断所述资源对象变化队列中存储的资源数据变化对象是否比所述数据库中存储的资源数据更新,如果是,则将资源对象变化队列中存储的资源数据变化对象存入相应的所述去重压力队列中,并在所述全量资源版本缓存模块中删除与该资源数据变化对象相应的关键信息。
所述数据库同步器定期读取每个所述去重压力队列中存储的资源数据变化对象,更新所述数据库中存储的资源数据。
三、非因平台原因导致数据传输通道断开——集群重启或者网络断开重连
(一)集群重启
当多个所述集群中发生个别集群重启的情况,集群重启后,所述资源监视器立即恢复与所述集群的API Server之间建立的长期稳定的数据传输通道。
所述全量资源版本缓存模块中存储有集群重启前该集群最新的资源数据的存储版本号,存储版本号与时间点相关,所述资源监视器从所述全量资源版本缓存模块获得存储版本号后,向重启后的所述集群发送资源数据变化对象请求,请求中包括存储版本号。重启后的集群根据存储版本号,获知所述数据库中存储的最新的资源数据对应的时间点,仅将该时间点之后生成的资源数据变化对象发送至所述资源监视器,所述资源监视器获取该集群上新产生的资源数据变化对象后,存入相应的所述资源对象变化队列中,之后进行相应的资源数据变化对象的比较和存储更新工作,此处不再赘述。
(二)网络断开重连
当多个所述集群中发生个别集群网络断开的情况,网络重连后,所述资源监视器立即恢复模块与所述集群的API Server之间建立的长期稳定的数据传输通道;
所述全量资源版本缓存模块中存储有网络断开前该集群最新的资源数据的存储版本号,该存储版本号与时间点相关,所述资源监视器从所述全量资源版本缓存模块获得存储版本号后,向网络重连后的所述集群发送资源数据变化对象请求,请求中包括存储版本号;网络重连后的集群根据该存储版本号,获知所述数据库中存储的最新的资源数据对应的时间点,仅将该时间点之后生成的资源数据变化对象发送至所述资源监视器,所述资源监视器获取该集群上新产生的资源数据变化对象后,存入相应的资源对象变化队列中,之后进行相应的资源数据变化对象的比较和存储更新工作,此处不再赘述。
四、因平台原因导致数据传输通道断开——平台重启
当多集群资源数据查看和搜索平台发生重启的情况,平台重启后,所述全量资源版本缓存模块立即获取所述数据库中存储的所有资源数据的关键信息以及每个所述集群对应的存储版本号,之后所述资源监视器再恢复与所述集群的API Server之间建立的长期稳定的数据传输通。
所述全量资源版本缓存模块中存储有平台重启前每个所述集群最新的资源数据对应的存储版本号,存储版本号与时间点相关,所述资源监视器从所述全量资源版本缓存模块获得存储版本号后,向全部集群发送资源数据变化对象请求,每个请求中包括该集群对应的存储版本号。每个集群根据存储版本号,获知所述数据库中存储的最新的资源数据对应的时间点,仅将该时间点之后生成的资源数据变化对象发送至所述资源监视器,所述资源监视器获取全部集群上新产生的资源数据变化对象后,存入相应的所述资源对象变化队列中,之后进行相应的资源数据变化对象的比较和存储更新工作,此处不再赘述。
第三方面,一种非暂态存储介质,其上存储有计算机程序,其中,该程序被处理器执行时实现第二方面中任一所述的多集群资源数据处理方法。
依据上述本发明一种多集群资源数据处理***与方法提供的技术方案具有以下技术效果:
本发明一种多集群资源数据处理***包含资源收集器、数据库、资源搜索服务器,资源收集器用于获取每个集群的资源数据,并存入数据库中,当集群管理员通过资源搜索服务器查看或者搜索目标资源数据时,由资源搜索服务器访问数据库,从数据库中筛选出目标资源数据,在资源查看和搜索界面展示目标资源数据。由于每个集群的资源数据已被预先存入数据库,资源搜索服务器无需从集群获取资源数据,直接访问平台数据库即可,查询和检索效率高,准确率高。
使用全量资源版本缓存模块和去重压力队列作为数据库的缓存区,减轻了数据库的存取压力。
通过资源对象变化队列对不同集群上的不同类型的资源数据变化对象进行分开处理,以便筛选模块对不同的资源数据进行资源版本号比较。
筛选模块通过集群的API Server建立数据传输通道,以长期获取集群的资源数据变化对象,无需在集群新增组件,对集群现有架构的侵入小。
在无需历史资源数据的情况下,通过去重压力队列对资源数据变化对象的不同版本进行去重,减轻了数据库的存储量压力。
通过统一平台,实现对多个集群的资源数据的查询和检索,操作简便。
预先将每个集群的资源数据存储在平台的数据库中,提升了查询和检索的效率。
实时将发生变化的资源数据对象在平台的数据库中进行更新,一则确保了资源数据的实时性,二则减轻了数据传输量和数据处理量。
附图说明
图1为通过集群管理界面查看和搜索集群资源数据的示意图;
图2为本发明实施例所提出的一种多集群资源数据处理***的结构示意图;
图3为图2中资源收集器的详细结构示意图;
图4为本发明实施例所提出的另一种多集群资源数据处理***的结构示意图;
图5为图4中资源收集器的详细结构示意图;
图6为本发明实施例所提出的一种多集群资源数据处理方法的流程示意图;
图7为一种非暂态存储介质的结构示意图。
其中,附图标记如下:
集群100、资源收集器200、数据库300、资源搜索服务器400、数据库300、主数据库310、副数据库320、非暂态存储介质500、非暂态计算机可读指令600。
具体实施方式
为了使发明实现的技术手段、创造特征、达成目的和功效易于明白了解,下结合具体图示,进一步阐述本发明。
图1为通过集群管理界面查看和搜索集群资源数据的示意图。如图1所示,当集群管理员在集群管理界面请求查看或者搜索集群资源数据时,集群管理界面通过WebSocket或者Ajax实时访问Kubernetes集群的API Server,从Kubernetes集群的ETCD中获取集群的资源数据,并在集群管理界面上进行显示,但该方案无法适用于多集群的场景。
相关技术中,可以通过以下方式实现对Kubernetes集群的资源数据进行统一查看和搜索:
一、多集群管理平台访问每个集群的API-Server,来获取每个集群的资源数据。具体来说,设置多集群管理平台作为多集群的全部资源数据的统一查看和搜索平台,通过多集群管理平台获取全部集群的资源数据,并在多集群管理平台汇总展示。当多集群管理平台接收到集群管理员输入的多集群资源数据的查看或搜索指令后,多集群管理平台实时访问每个集群的API-Server,以获取每个集群最新的资源数据,在多集群管理平台上进行汇总处理,将处理结果展示给集群管理员。但该方案需要实时访问每个集群的API-Server,再对资源数据进行汇总处理,最后对结果展示,整个过程流程复杂,受多集群管理平台与API-Server之间的数据传输效率和通信网络可靠性影响很大,效率低下,且不可靠。
二、多集群管理平台定时访问每个集群的资源数据,并将资源数据进行缓存。具体来说,在多集群管理平台上设置资源数据缓存,多集群管理平台定期访问每个集群的API-Server,以获取每个集群最新的资源数据,并对资源数据缓存进行更新。当多集群管理平台接收到集群管理员输入的多集群资源数据的查看或搜索指令后,将资源数据缓存中存储的资源数据进行展示。但该方案中资源数据缓存中存储的资源数据并非最新的资源数据,每个集群上的资源数据会经常发生变化,定期更新的方式使得多集群管理平台展示的资源数据在时间上滞后。此外,每次对资源数据缓存进行更新时,需要对全部资源数据进行传输和比对,数据传输量、处理量太大。
申请人对多集群场景下的数据资源的查看和搜索问题进行深入分析,并对相关技术的优缺点进行仔细比对后,得出以下结论:
Kubernetes平台提供了成熟的机制对Kubernetes集群内工作负载及容器的资源数据进行记录,供集群管理员查看和搜索。但在多Kubernetes 集群的场景,Kubernetes平台没有提供相应的机制对不同集群的资源数据进行聚合和展示。而且对于运行中的每个集群,资源数据一直处于更新之中,如何让多集群资源数据查看和搜索平台在展示所有集群的最新资源数据时,同时满足实时、准确、可靠的要求成为一个问题。
本发明的第一实施例是提供一种多集群资源数据处理***,目的是基于Kubernetes平台搭建多集群资源数据查看和搜索平台,对多集群的资源数据进行整合和展示,集群管理员可通过资源查看和搜索平台的用户使用界面,查看或者搜索多集群中的任何资源数据,无需分别登录每个集群的管理界面,即能够快速有效地查看目标资源数据,并且资源数据的展示同时满足实时、准确、可靠的要求。
图2为本发明实施例所提出的一种多集群资源数据处理***的结构示意图。
图3为图2中资源收集器的详细结构示意图。
如图2和图3所示,第一方面,第一实施例,一种多集群资源数据处理***,其中,包含多个集群100、资源收集器200、数据库300,多个集群100分别与资源收集器200进行数据传输,资源收集器200与数据库300进行数据传输,数据库300内存储有资源数据。
进一步地,资源收集器200包含资源监视器、资源对象变化队列、筛选模块、全量资源版本缓存模块、去重压力队列、数据库300同步控制器。其中,资源监视器用于获取多个集群100中的资源数据变化对象,并存入资源对象变化队列中。
去重压力队列中存储有资源数据变化对象并对资源数据变化对象进行去重。
资源对象变化队列中存储有资源数据变化对象的资源版本号。
全量资源版本缓存模块用于访问数据库300以获取资源数据,并生成键值对形式的资源数据的关键信息,其中,关键信息包括资源版本号。
筛选模块用于获取资源对象变换队列中的资源数据变化对象的资源版本号与全量资源版本缓存模块中相应资源数据的资源版本号,并判断资源对象变换队列中的资源数据变化对象的资源版本号是否比全量资源版本缓存模块中相应资源数据的资源版本号更新。若是,则将资源对象变化队列中存储的资源数据变化对象存入去重压力队列中,并使用资源数据变化队列中资源数据变化对象的关键信息更新全量资源版本缓存模块中相应的资源数据的关键信息。
数据库300同步控制器用于定期读取去重压力队列中存储的资源数据变化对象并更新数据库300中的资源数据。
本发明实施例使用全量资源版本缓存模块和去重压力队列作为数据库300的缓存区,减轻了数据库300的存取压力。此外,实时将发生变化的资源数据对象在平台的数据库300中进行更新,一则确保了资源数据的实时性,二则减轻了数据传输量和数据处理量。
去重压力队列作为数据库300存储的缓冲区,需要与数据库300中资源数据存储的机制保持一致,由于在数据库300中不同类型的资源数据存储方式存在区别,因此使用不同类型的去重压力队列来存储不同类型的资源数据。此外,如果在数据库300同步器两次读取去重压力队列期间,某资源数据发生了两次或两次以上的变化,可以对资源数据变化对象进行去重处理,以减轻数据库300的存储负担。具体是,当去重压力队列收到筛选模块存入的资源数据变化对象后,与去重压力队列中已有的资源数据变化对象进行比对,如果是同一集群100上的相同类型的同一个资源对象,则使用新的资源数据变化对象覆盖去重压力队列中已有的资源数据变化对象。
本发明实施例通过去重压力队列对资源数据变化对象的不同版本进行去重,减轻了数据库300的存储量压力。
上述的一种多集群资源数据处理***,其中,资源监视器通过集群100的APIServer获取集群100中的资源数据变化对象,并与集群100之间建立数据传输通道,以持续传输集群100中的资源数据变化对象,集群100为Kubernetes集群。
本发明实施例中的筛选模块通过集群100的API Server建立数据传输通道,以长期获取集群100的资源数据变化对象,无需在集群100新增组件,对集群100现有架构的侵入小。
上述的一种多集群资源数据处理***,其中,资源监视器、资源对象变化队列、筛选模块、去重压力队列均设置有多个。
每个资源监视器与一个集群100中的一种资源类型对应设置,每个资源对象变化队列与一个资源监视器对应设置,资源监视器用于获取多个集群100中的每种资源类型的资源数据变化对象,并存入相应的资源对象变化队列中。
每个筛选模块与一个资源对象变化队列对应设置,每个去重压力队列与全部集群100中的一种资源类型对应设置,每个筛选模块与全量资源版本缓存模块、去重压力队列进行数据传输,每个去重压力队列与数据库300同步控制器进行数据传输,全量资源版本缓存模块、数据库300同步控制器分别与数据库300进行数据传输。
本发明实施例通过资源对象变化队列对不同集群100上的不同类型的资源数据变化对象进行分开处理,以便筛选模块对不同的资源数据进行资源版本号比较。
上述的一种多集群资源数据处理***,其中,***还包括资源搜索服务器400,用于获取数据库300中的资源数据,并展示在资源查看与搜索界面上。
本发明实施例通过统一平台,实现对多个集群100的资源数据的查询和检索,操作简便,并且预先将每个集群100的资源数据存储在平台的数据库300中,提升了查询和检索的效率。
为了让多集群100资源数据查看和搜索平台能够查询到资源数据的历史变化情况,本发明实施例还提出了另一种多集群100数据处理***。
图4为本发明实施例所提出的另一种多集群资源数据处理***的结构示意图。图5为图4中资源收集器的详细结构示意图。
如图4和图5所示,数据库300包括主数据库310和副数据库320,全量资源版本缓存模块与主数据库310进行数据传输,主数据库310与副数据库320进行数据传输,主数据库310用于存储最新资源数据,副数据库320用于存储历史资源数据。
数据库300同步器定期读取每个压力队列中存储的资源数据变化对象,将去重压力队列中的资源数据变化对象存入主数据库310数据库300,定期对主数据库310数据库300中存储的资源数据进行盘点,如果主数据库310数据库300中存在不同版本的同一资源数据时,将旧版本的资源数据移入副数据库320数据库300中进行存储,并建立同一资源数据新旧版本之间的关联关系。
相应地,前述去重压力队列将不再执行去重功能,仅作为数据库300存储的缓冲区,也就是说,当去重压力队列收到筛选模块存入资源数据变化对象后,与去重压力队列中已有的资源数据变化对象进行比对。如果是同一集群100上的同类资源,则将新的资源数据变化对象标记为最新资源数据,将队列中已有的资源数据变化对象标记为历史资源数据。在数据库300同步控制器将去重压力队列中的资源数据变化对象存入主数据库310数据库300时,先存入带有历史资源数据标记的资源数据变化对象,后存入带有最新资源数据标记的资源数据变化对象,从而自动将带有历史资源数据标记的资源数据变化对象移入副数据库320数据库300中进行存储。
当集群管理员查看和搜索平台能够查询到资源数据的全部变化情况时,资源搜索服务器400首先在主数据库310中检索最新资源数据,然后通过最新资源数据在副数据库320中检索历史资源数据,将资源数据的新旧历史版本全部展示给集群管理员。
上述的一种多集群资源数据处理***,其中,资源信息数据的关键信息包含以键值对(ClusterName-ResourceKind-Namespace-ResourceName:ResourceVersion)形式存储的资源数据对应的集群100、资源类型、命名空间、资源名称、资源版本号。
上述的一种多集群资源数据处理***,其中,全量资源版本缓存模块中还存储有存储版本号,每次关键信息更新或者变化的时间点与存储版本号相对应。也就是说,全量资源版本缓存模块中存储的资源数据的关键信息每次进行更新或者产生变化,都会与一个存储版本号相对应,该存储版本号不同于资源版本号,用于标记最新的资源数据变化对象存入数据库300的时间点。
第二方面,第二实施例,一种多集群资源数据处理方法,其中,包含以下步骤:
全量资源版本缓存模块访问数据库300以获取资源数据,并生成键值对形式的资源数据的关键信息,其中,关键信息包括资源版本号。资源监视器获取多个集群100中的资源数据变化对象,并存入资源对象变化队列中。筛选模块获取资源对象变化队列中的资源数据变化对象的资源版本号和全量资源版本缓存模块中相应资源数据的资源版本号,并判断资源对象变换队列中的资源数据变化对象的资源版本号是否比全量资源版本缓存模块中相应资源数据的资源版本号更新。若是,则将资源对象变化队列中存储的资源数据变化对象存入去重压力队列中,并使用资源数据变化队列中资源数据变化对象的关键信息更新全量资源版本缓存模块中相应的资源数据的关键信息。数据库300同步控制器定期读取去重压力队列中存储的资源数据变化对象并更新数据库300中的资源数据。
本发明实施例使用全量资源版本缓存模块和去重压力队列作为数据库300的缓存区,减轻了数据库300的存取压力。此外,实时将发生变化的资源数据对象在平台的数据库300中进行更新,一则确保了资源数据的实时性,二则减轻了数据传输量和数据处理量。
上述的一种多集群资源数据处理方法,其中,资源监视器获取多个集群100中的资源数据变化对象,包括:资源监视器通过集群100的API Server获取集群100中的资源数据变化对象,并与集群100之间建立数据传输通道,以持续传输集群100中的资源数据变化对象。
本发明实施例中的筛选模块通过集群100的API Server建立数据传输通道,以长期获取集群100的资源数据变化对象,无需在集群100新增组件,对集群100现有架构的侵入小。
上述的一种多集群资源数据处理方法,其中,方法还包括:资源搜索服务器400获取数据库300中的资源数据,并展示在资源查看与搜索界面上。
本发明实施例通过统一平台,实现对多个集群100的资源数据的查询和检索,操作简便,并且预先将每个集群100的资源数据存储在平台的数据库300中,提升了查询和检索的效率。
上述的一种多集群资源数据处理方法,其中,数据库300包括主数据库310和副数据库320,主数据库310用于存储最新资源数据,副数据库320用于存储历史资源数据,资源搜索服务器400获取数据库300中的资源数据包括:获取资源数据查看指令或搜索指令,根据查看指令或搜索指令所对应的展示需求,对最新资源数据进行展示,或者对最新资源数据和历史资源数据一起进行展示。
当集群管理员查看和搜索平台能够查询到资源数据的全部变化情况时,资源搜索服务器400首先在主数据库310中检索最新资源数据,然后通过最新资源数据在副数据库320中检索历史资源数据,将资源数据的新旧历史版本全部展示给集群管理员。
上述的一种多集群资源数据处理方法,其中,每个集群100内的每种资源均对应一个资源监视器,为了在数据传输通道出现故障时,资源监视器能够及时采取恢复措施,资源监视器与相对应的集群100的API Server(心跳机制)连接获取该集群100中指定类型的资源数据变化对象,即当集群100的API Server超过预设时间没有向资源监视器发送资源数据变化对象时,需要单独发送一个心跳包,以让资源监视器确定数据传输通道是否畅通。如果资源监视器超过预设时间,既没有收到资源数据变化对象,又没有收到心跳包,可以确定数据传输通道出现故障,则资源监视器主动向集群100的API Server发送请求,恢复数据传输通道。
上述的一种多集群资源数据处理方法,其中,资源监视器、资源对象变化队列、筛选模块、去重压力队列均设置有多个,每个资源监视器与一个集群100中的一种资源类型对应设置;每个资源对象变化队列与一个资源监视器对应设置;资源监视器用于获取多个集群100中的每种资源类型的资源数据变化对象,并存入相应的资源对象变化队列中。每个筛选模块与一个资源对象变化队列对应设置;每个去重压力队列与全部集群100中的一种资源类型对应设置;每个筛选模块与全量资源版本缓存模块、去重压力队列进行数据传输;每个去重压力队列与数据库300同步控制器进行数据传输;全量资源版本缓存模块、数据库300同步控制器分别与数据库300进行数据传输。
上述的一种多集群资源数据处理方法,其中,资源监视器通过API Server连接集群100的ETCD获取该集群100中指定类型的资源数据变化对象;
集群100为Kubernetes集群;
本发明实施例中的筛选模块通过集群100的API Server建立数据传输通道,以长期获取集群100的资源数据变化对象,无需在集群100新增组件,对集群100现有架构的侵入小。
为了让多集群100资源数据查看和搜索平台能够查询到资源数据的历史变化情况,数据库300包含主数据库310与副数据库320,主数据库310用于存储最新资源数据,副数据库320用于存储历史资源数据。
上述的一种多集群资源数据处理方法,其中,资源信息数据的关键信息包含以键值对形式存储的资源数据对应的集群100、资源类型、命名空间、资源名称、资源版本号。
上述的一种多集群资源数据处理方法,其中,全量资源版本缓存模块中还存储有存储版本号,每次关键信息更新或者变化的时间点与存储版本号相对应。也就是说,全量资源版本缓存模块中存储的资源数据的关键信息每次进行更新或者产生变化,都会与一个存储版本号相对应,该存储版本号不同于资源版本号,用于标记最新的资源数据变化对象存入数据库300的时间点。
依据上述的一种多集群资源数据处理***与方法能够实现如下四种场景:
一、首次同步场景
当多集群资源数据查看和搜索平台首次获取每个集群100上的所有资源数据时,每个资源收集器200设置的资源监视器分别向相对应的集群100上的API Server发出请求,以获取每个集群100上每种类型的资源数据,从而建立起资源监视器与集群100之间长期稳定的数据传输通道;数据库300中没有任何资源数据,因此全量资源版本缓存模块、筛选模块无需工作,资源监视器获取相对应的单个集群100上指定类型的资源数据变化对象后,存入相应的资源对象变化队列中,再按照资源类型的不同将资源数据变化对象存入相应的去重压力队列中,数据库300同步器将去重压力队列中的资源数据变化对象存入数据库300。
二、实时同步场景
当多集群资源数据查看和搜索平台实时获取每个集群100上的所有资源数据时,全量资源版本缓存模块获取数据库300中存储的所有资源数据的关键信息,包括资源数据对应的集群100、资源类型、命名空间、资源名称、资源版本号,并以键值对(ClusterName-ResourceKind-Namespace-ResourceName:ResourceVersion)的形式进行存储;集群100的API Server通过访问ETCD来获知当前集群100上的资源数据变化对象,并通过首次同步时建立的长期稳定的数据传输通道向对应的资源监视器传输当前集群100上指定类型的资源数据变化对象,存入相应的资源对象变化队列中;其中,每个资源数据变化对象具有一个属性,用于标注资源变化的类型,具体包括新增、变更、删除等。
(一)资源变化的类型为新增
与资源对象变化队列对应设置的筛选模块将直接新增的资源对象存入相应的去重压力队列中,并将该资源数据变化对象对应的关键信息***全量资源版本缓存模块。
(二)资源变化的类型为变更
与资源对象变化队列对应设置的筛选模块将其对应的资源对象变化队列中存储的资源数据变化对象的资源版本号,与全量资源版本缓存模块中存储的资源数据的关键信息中的资源版本号进行比较,以判断资源对象变化队列中存储的资源数据变化对象是否比数据库300中存储的资源数据更新,如果是,则将资源对象变化队列中存储的资源数据变化对象存入相应的去重压力队列中,并使用该资源数据变化对象对应的关键信息覆盖全量资源版本缓存模块中相应的关键信息;去重压力队列将筛选模块存入资源数据变化对象与去重压力队列中已有的资源数据变化对象进行比对,如果是同一集群100上的相同类型的同一个资源对象,则使用新的资源数据变化对象覆盖队列中已有的资源数据变化对象。
(三)资源变化的类型为删除
与资源对象变化队列对应设置的筛选模块将其对应的资源对象变化队列中存储的资源数据变化对象的资源版本号,与全量资源版本缓存模块中存储的资源数据的关键信息中的资源版本号进行比较,以判断资源对象变化队列中存储的资源数据变化对象是否比数据库300中存储的资源数据更新,如果是,则将资源对象变化队列中存储的资源数据变化对象存入相应的去重压力队列中,并在全量资源版本缓存模块中删除与该资源数据变化对象相应的关键信息。
数据库300同步器定期读取每个去重压力队列中存储的资源数据变化对象,更新数据库300中存储的资源数据。
三、非因平台原因导致数据传输通道断开——集群100重启或者网络断开重连
(一)集群100重启
当多个集群100中发生个别集群100重启的情况,集群100重启后,资源监视器立即恢复与集群100的API Server之间建立的长期稳定的数据传输通道。
全量资源版本缓存模块中存储有集群100重启前该集群100最新的资源数据的存储版本号,存储版本号与时间点相关,资源监视器从全量资源版本缓存模块获得存储版本号后,向重启后的集群100发送资源数据变化对象请求,请求中包括该存储版本号。重启后的集群100根据存储版本号,获知数据库300中存储的最新的资源数据对应的时间点,仅将该时间点之后生成的资源数据变化对象发送至资源监视器,资源监视器获取该集群100上新产生的资源数据变化对象后,存入相应的资源对象变化队列中,之后进行相应的资源数据变化对象的比较和存储更新工作,此处不再赘述。
(二)网络断开重连
当多个集群100中发生个别集群100网络断开的情况,网络重连后,资源监视器立即恢复模块与集群100的API Server之间建立的长期稳定的数据传输通道。
全量资源版本缓存模块中存储有网络断开前该集群100最新的资源数据的存储版本号,存储版本号与时间点相关,资源监视器从全量资源版本缓存模块获得存储版本号后,向网络重连后的集群100发送资源数据变化对象请求,请求中包括存储版本号。网络重连后的集群100根据存储版本号,获知数据库300中存储的最新的资源数据对应的时间点,仅将该时间点之后生成的资源数据变化对象发送至资源监视器,资源监视器获取该集群100上新产生的资源数据变化对象后,存入相应的资源对象变化队列中,之后进行相应的资源数据变化对象的比较和存储更新工作,此处不再赘述。
四、因平台原因导致数据传输通道断开——平台重启
当多集群100资源数据查看和搜索平台发生重启的情况,平台重启后,全量资源版本缓存模块立即获取数据库300中存储的所有资源数据的关键信息以及每个集群100对应的存储版本号,之后资源监视器再恢复与集群100的API Server之间建立的长期稳定的数据传输通。
全量资源版本缓存模块中存储有平台重启前每个集群100最新的资源数据对应的存储版本号,存储版本号与时间点相关,资源监视器从全量资源版本缓存模块获得存储版本号后,向全部集群100发送资源数据变化对象请求,每个请求中包括该集群100对应的存储版本号。每个集群100根据存储版本号,获知数据库300中存储的最新的资源数据对应的时间点,仅将该时间点之后生成的资源数据变化对象发送至资源监视器,资源监视器获取全部集群100上新产生的资源数据变化对象后,存入相应的资源对象变化队列中,之后进行相应的资源数据变化对象的比较和存储更新工作,此处不再赘述。
图7为一种非暂态存储介质的结构示意图。如图7所示,第三方面,一种非暂态存储介质,根据本发明实施例的非暂态存储介质500,其上存储有非暂态计算机可读指令600。当该非暂态计算机可读指令600由处理器运行时,执行前述的本发明各实施例的多集群资源数据处理方法的全部或部分步骤。
综上,本发明的一种多集群资源数据处理***与数据处理方法,能够基于Kubernetes平台搭建多集群资源数据查看和搜索平台,对多集群的资源数据进行整合和展示,集群管理员可通过资源查看和搜索平台的用户使用界面,查看或者搜索多集群中的任何资源数据,无需分别登录每个集群的管理界面,即能够快速有效地查看目标资源数据。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件。基于这样的理解,上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在非暂态存储介质中,如磁碟、光盘、只读存储记忆体(ROM)或随机存储记忆体(RAM)等等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
以上对发明的具体实施例进行了描述。需要理解的是,发明并不局限于上述特定实施方式,其中未尽详细描述的设备和结构应该理解为用本领域中的普通方式予以实施;本领域技术人员可以在权利要求的范围内做出各种变形或修改做出若干简单推演、变形或替换,这并不影响发明的实质内容。
Claims (10)
1.一种多集群资源数据处理***,其特征在于,包含多个集群、资源收集器、数据库,所述多个集群分别与所述资源收集器进行数据传输,所述资源收集器与所述数据库进行数据传输,所述数据库内存储有资源数据;
所述资源收集器包含资源监视器、资源对象变化队列、筛选模块、全量资源版本缓存模块、去重压力队列、数据库同步控制器;
所述资源监视器用于获取所述多个集群中的资源数据变化对象,并存入资源对象变化队列中;
所述去重压力队列中存储有资源数据变化对象并对所述资源数据变化对象进行去重;
所述资源对象变化队列中存储有资源数据变化对象的资源版本号;
所述全量资源版本缓存模块用于访问数据库以获取资源数据,并生成键值对形式的所述资源数据的关键信息;其中,所述关键信息包括资源版本号;
所述筛选模块用于获取所述资源对象变换队列中的资源数据变化对象的资源版本号与所述全量资源版本缓存模块中相应资源数据的资源版本号,并判断所述资源对象变换队列中的资源数据变化对象的资源版本号是否比所述全量资源版本缓存模块中相应资源数据的资源版本号更新,若是,则将所述资源对象变化队列中存储的资源数据变化对象存入所述去重压力队列中,并使用所述资源数据变化队列中资源数据变化对象的关键信息更新所述全量资源版本缓存模块中相应的资源数据的关键信息;
所述数据库同步控制器用于定期读取所述去重压力队列中存储的资源数据变化对象并更新所述数据库中的资源数据。
2.如权利要求1所述的一种多集群资源数据处理***,其特征在于,所述资源监视器通过所述集群的API Server获取所述集群中的资源数据变化对象,并与所述集群之间建立数据传输通道,以持续传输所述集群中的资源数据变化对象。
3.如权利要求1所述的一种多集群资源数据处理***,其特征在于,所述资源监视器、所述资源对象变化队列、所述筛选模块、所述去重压力队列均设置有多个,每个所述资源监视器与一个所述集群中的一种资源类型对应设置;
每个所述资源对象变化队列与一个所述资源监视器对应设置;所述资源监视器用于获取所述多个集群中的每种资源类型的资源数据变化对象,并存入相应的所述资源对象变化队列中;
每个所述筛选模块与一个所述资源对象变化队列对应设置;
每个所述去重压力队列与全部所述集群中的一种资源类型对应设置;
每个所述筛选模块与所述全量资源版本缓存模块、所述去重压力队列进行数据传输;
每个所述去重压力队列与所述数据库同步控制器进行数据传输;
所述全量资源版本缓存模块、所述数据库同步控制器分别与所述数据库进行数据传输。
4.如权利要求1-3任一项所述的一种多集群资源数据处理***,其特征在于,所述***还包括资源搜索服务器,用于获取所述数据库中的资源数据,并展示在资源查看与搜索界面上。
5.如权利要求4所述的一种多集群资源数据处理***,其特征在于,所述数据库包括主数据库和副数据库,所述全量资源版本缓存模块与所述主数据库进行数据传输,所述主数据库与所述副数据库进行数据传输,所述主数据库用于存储最新资源数据,所述副数据库用于存储历史资源数据。
6.一种多集群资源数据处理方法,其特征在于,包含以下步骤:
全量资源版本缓存模块访问数据库以获取资源数据,并生成键值对形式的所述资源数据的关键信息;其中,所述关键信息包括资源版本号;
资源监视器获取多个集群中的资源数据变化对象,并存入资源对象变化队列中;
筛选模块获取资源对象变化队列中的资源数据变化对象的资源版本号和所述全量资源版本缓存模块中相应资源数据的资源版本号,并判断所述资源对象变换队列中的资源数据变化对象的资源版本号是否比所述全量资源版本缓存模块中相应资源数据的资源版本号更新;
若是,则将所述资源对象变化队列中存储的资源数据变化对象存入所述去重压力队列中,并使用所述资源数据变化队列中资源数据变化对象的关键信息更新所述全量资源版本缓存模块中相应的资源数据的关键信息;
数据库同步控制器定期读取所述去重压力队列中存储的资源数据变化对象并更新所述数据库中的资源数据。
7.如权利要求6所述的一种多集群资源数据处理方法,其特征在于,所述资源监视器获取多个集群中的资源数据变化对象,包括:所述资源监视器通过所述集群的API Server获取所述集群中的资源数据变化对象,并与所述集群之间建立数据传输通道,以持续传输所述集群中的资源数据变化对象。
8.如权利要求6或7所述的一种多集群资源数据处理方法,其特征在于,所述方法还包括:资源搜索服务器获取所述数据库中的资源数据,并展示在资源查看与搜索界面上。
9.如权利要求8所述的一种多集群资源数据处理方法,其特征在于,所述数据库包括主数据库和副数据库,所述主数据库用于存储最新资源数据,所述副数据库用于存储历史资源数据,所述资源搜索服务器获取所述数据库中的资源数据包括:
获取资源数据查看指令或搜索指令;
根据所述查看指令或搜索指令所对应的展示需求,对所述最新资源数据进行展示,或者对所述最新资源数据和所述历史资源数据一起进行展示。
10.一种非暂态存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时实现如权利要求6-9中任一所述的多集群资源数据处理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110989470.5A CN113703917B (zh) | 2021-08-26 | 2021-08-26 | 一种多集群资源数据处理***与方法、非暂态存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110989470.5A CN113703917B (zh) | 2021-08-26 | 2021-08-26 | 一种多集群资源数据处理***与方法、非暂态存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113703917A true CN113703917A (zh) | 2021-11-26 |
CN113703917B CN113703917B (zh) | 2022-10-14 |
Family
ID=78655331
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110989470.5A Active CN113703917B (zh) | 2021-08-26 | 2021-08-26 | 一种多集群资源数据处理***与方法、非暂态存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113703917B (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114328102A (zh) * | 2021-12-24 | 2022-04-12 | 浪潮(北京)电子信息产业有限公司 | 设备状态监控方法、装置、设备及计算机可读存储介质 |
CN115495202A (zh) * | 2022-11-17 | 2022-12-20 | 成都盛思睿信息技术有限公司 | 一种异构集群下的大数据任务实时弹性调度方法 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015146355A1 (ja) * | 2014-03-28 | 2015-10-01 | 株式会社Nttドコモ | 更新管理システムおよび更新管理方法 |
CN109753289A (zh) * | 2019-01-14 | 2019-05-14 | 网易(杭州)网络有限公司 | 一种美术资源合并方法、装置、电子设备和存储介质 |
CN110247812A (zh) * | 2019-07-22 | 2019-09-17 | 深信服科技股份有限公司 | 一种多集群管理方法、装置、***及相关组件 |
CN110389836A (zh) * | 2019-07-17 | 2019-10-29 | 腾讯科技(深圳)有限公司 | 一种多集群管理方法、装置、服务器及存储介质 |
CN110572464A (zh) * | 2019-09-12 | 2019-12-13 | 北京浪潮数据技术有限公司 | 底层资源状态同步方法、装置、云平台***及存储介质 |
WO2020231039A1 (ko) * | 2019-05-14 | 2020-11-19 | 아콘소프트 주식회사 | 분산 연합형 컨테이너 플랫폼 시스템 |
US10922284B1 (en) * | 2017-09-25 | 2021-02-16 | Cloudera, Inc. | Extensible framework for managing multiple Hadoop clusters |
-
2021
- 2021-08-26 CN CN202110989470.5A patent/CN113703917B/zh active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015146355A1 (ja) * | 2014-03-28 | 2015-10-01 | 株式会社Nttドコモ | 更新管理システムおよび更新管理方法 |
US10922284B1 (en) * | 2017-09-25 | 2021-02-16 | Cloudera, Inc. | Extensible framework for managing multiple Hadoop clusters |
CN109753289A (zh) * | 2019-01-14 | 2019-05-14 | 网易(杭州)网络有限公司 | 一种美术资源合并方法、装置、电子设备和存储介质 |
WO2020231039A1 (ko) * | 2019-05-14 | 2020-11-19 | 아콘소프트 주식회사 | 분산 연합형 컨테이너 플랫폼 시스템 |
CN110389836A (zh) * | 2019-07-17 | 2019-10-29 | 腾讯科技(深圳)有限公司 | 一种多集群管理方法、装置、服务器及存储介质 |
CN110247812A (zh) * | 2019-07-22 | 2019-09-17 | 深信服科技股份有限公司 | 一种多集群管理方法、装置、***及相关组件 |
CN110572464A (zh) * | 2019-09-12 | 2019-12-13 | 北京浪潮数据技术有限公司 | 底层资源状态同步方法、装置、云平台***及存储介质 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114328102A (zh) * | 2021-12-24 | 2022-04-12 | 浪潮(北京)电子信息产业有限公司 | 设备状态监控方法、装置、设备及计算机可读存储介质 |
CN114328102B (zh) * | 2021-12-24 | 2024-02-09 | 浪潮(北京)电子信息产业有限公司 | 设备状态监控方法、装置、设备及计算机可读存储介质 |
CN115495202A (zh) * | 2022-11-17 | 2022-12-20 | 成都盛思睿信息技术有限公司 | 一种异构集群下的大数据任务实时弹性调度方法 |
Also Published As
Publication number | Publication date |
---|---|
CN113703917B (zh) | 2022-10-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10691722B2 (en) | Consistent query execution for big data analytics in a hybrid database | |
CN109547512B (zh) | 一种基于NoSQL的分布式Session管理的方法及装置 | |
US8914404B1 (en) | Techniques for performing view indication management | |
US7653668B1 (en) | Fault tolerant multi-stage data replication with relaxed coherency guarantees | |
CN113703917B (zh) | 一种多集群资源数据处理***与方法、非暂态存储介质 | |
CN102411598B (zh) | 一种实现数据一致性的方法及其*** | |
US10891302B2 (en) | Scalable synchronization with cache and index management | |
CA2896865A1 (en) | Method and system for using a recursive event listener on a node in hierarchical data structure | |
CN114116613A (zh) | 基于分布式文件***的元数据查询方法、设备和存储介质 | |
US20150142845A1 (en) | Smart database caching | |
CN103501319A (zh) | 一种低延迟的面向小文件的分布式存储*** | |
CN110837423A (zh) | 一种自动导引运输车数据采集的方法和装置 | |
CN113094430B (zh) | 一种数据处理方法、装置、设备以及存储介质 | |
US20230385287A1 (en) | Real-time dashboards, alerts and analytics for a log intelligence system | |
CN115640110A (zh) | 分布式云计算***调度方法和装置 | |
CN107436904B (zh) | 数据获取方法、数据获取设备和计算机可读存储介质 | |
US11526516B2 (en) | Method, apparatus, device and storage medium for generating and processing a distributed graph database | |
KR20140047448A (ko) | 트랜잭션 재시작 가능한 클라이언트 장치와 데이터베이스 서버 및 방법 | |
CN106897316B (zh) | 一种信令数据的处理方法和装置 | |
CN109165078B (zh) | 一种虚拟分布式服务器及其访问方法 | |
WO2014199568A1 (ja) | 永続記憶装置へのデータ書込制御方法 | |
KR20220054683A (ko) | 궁극적으로 일관된 데이터베이스 복제로의 스위칭 | |
US10402373B1 (en) | Filesystem redirection | |
US10621199B2 (en) | Two phase retrieval using named graphs | |
CN115374078A (zh) | 一种数据存储与读取***及其工作方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
CP02 | Change in the address of a patent holder |
Address after: 200433 floor 7, building 6, No. 99, jiangwancheng Road, Yangpu District, Shanghai Patentee after: Shanghai Daoke Network Technology Co.,Ltd. Address before: Room 1305-12, No.6 Weide Road, Yangpu District, Shanghai 200433 Patentee before: Shanghai Daoke Network Technology Co.,Ltd. |
|
CP02 | Change in the address of a patent holder |