CN115460089A - 开放、多云、多集群联邦实现的方法及系统 - Google Patents

开放、多云、多集群联邦实现的方法及系统 Download PDF

Info

Publication number
CN115460089A
CN115460089A CN202211046691.XA CN202211046691A CN115460089A CN 115460089 A CN115460089 A CN 115460089A CN 202211046691 A CN202211046691 A CN 202211046691A CN 115460089 A CN115460089 A CN 115460089A
Authority
CN
China
Prior art keywords
cluster
module
resource
work
state
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.)
Pending
Application number
CN202211046691.XA
Other languages
English (en)
Inventor
郭进
王畅
刘清
宫婷
王汝珅
赵文川
聂子璇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Industrial Bank Co Ltd
CIB Fintech Services Shanghai Co Ltd
Original Assignee
Industrial Bank Co Ltd
CIB Fintech Services Shanghai Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Industrial Bank Co Ltd, CIB Fintech Services Shanghai Co Ltd filed Critical Industrial Bank Co Ltd
Priority to CN202211046691.XA priority Critical patent/CN115460089A/zh
Publication of CN115460089A publication Critical patent/CN115460089A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0654Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0668Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0893Assignment of logical groups to network elements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明提供了一种开放、多云、多集群联邦实现的方法及系统,包括:步骤S1:新集群加入联邦集群;步骤S2:应用通过联邦集群下发;步骤S3:应用下发后,当成员集群发生故障时,应用自动转移到健康集群。本发明设计了集群调度器SchedulerController,不仅实现了负载均衡负载感知调度,而且发明了故障转移流程,当集群故障后,可自动转移负载到健康成员集群。

Description

开放、多云、多集群联邦实现的方法及系统
技术领域
本发明涉及网络通信技术领域,具体地,涉及开放、多云、多集群联邦实现的方法及系统。
背景技术
kubernetes开发社区提供了kubernetes federation联邦集群方案,该技术方案将成员集群作为一种资源进行管理,但并未添加新的资源定义,以至于每当创建一种新资源都要新增Adapter,并无法有效的在多个集群管理权限,不支持RBAC,没有独立的API,版本迭代不好演进,联邦层级的设定与策略API资源的Annotations内容,使得弹性能力不佳,而且在当成员集群发生故障后,没有故障转移过程。
专利文献CN113742033A(申请号:202111048076.8)公开了一种kubernetes集群联邦实现方法,涉及网络通信技术领域,解决kubernetes的跨集群资源的服务发现和编排问题,方法为:设置集群控制器、状态控制器、同步控制器、调度器、命令控制器;初始化集群控制器、状态控制器、同步控制器、调度器、命令控制器至kubernetes系统中,使该kubernetes成为联邦集群的主集群,集群控制器、状态控制器、同步控制器、调度器、命令控制器可以运行至少1个副本。本发明还公开了一种kubernetes集群联邦系统。本发明在kubernetes系统中运行集群控制器、状态控制器、同步控制器、调度器、命令控制器,利用kubernetes内置的CRD资源和admission webhook准入控制,达到完整的集群联邦功能,实现单一集群统一管理多个Kubernetes集群,可以有效解决kubernetes的跨集群资源的服务发现和编排问题。
发明内容
针对现有技术中的缺陷,本发明的目的是提供一种开放、多云、多集群联邦实现的方法及系统。
根据本发明提供的一种开放、多云、多集群联邦实现的方法,包括:
步骤S1:新集群加入联邦集群;
步骤S2:应用通过联邦集群下发;
步骤S3:应用下发后,当成员集群发生故障时,应用自动转移到健康集群。
优选地,所述步骤S1采用:
步骤S1.1:调用聚合层API服务,传入待加入集群证书,访问入口地址,成员集群名称member;
步骤S1.2:控制集群在member集群中创建service account,并为serviceaccount配置clusterrole和clusterrolebinding,通过配置上述SA,授权控制集群可访问成员集群member的/readyz或/healthz URL,从而判断集群的健康状态;
步骤S1.3:控制集群在控制集群中创建cluster对象,保存访问入口地址以及访问证书,并以预设时间间隔启动集群状态更新流程;
步骤S1.4:更新流程中访问cluster对象中保存的访问入口地址,获取/readyz或healthz接口,若能得到200的http响应,则表示集群健康,否则表示集群不健康,并将状态更新到cluster对象中。
优选地,所述步骤S2采用:
步骤S2.1:在控制集群侧提交传播策略PropagationPolicy,分区重载策略OverridePolicy以及KubernetesObject;
步骤S2.2:传播策略PropagationPolicy及KubernetesObject资源被控制器ResourcesController监听,ResourcesController监听到源生KubernetesObject和PropagationPolicy资源,完成资源绑定,并生成ResourcesBinding对象;
步骤S2.3:BindingController观察到ResourcesBinding对象后,找到关联的分区重载策略OverridePolicy,实现ResourcesBinding对象和OverridePolicy绑定,并设置ResourcesBinding为可被调度;
步骤S2.4:SchedulerController启动后,循环获取所有可被调度ResourcesBinding,根据动态负载,设置每个集群、区域副本数量,结合OverridePolicy重载差异化策略,生成Work对象;
步骤S2.5:ExecutionController启动后,当Work对象被创建后,负责同步Work对象到集群,完成应用下发。
优选地,所述步骤S2.2采用:
步骤S2.2.1:传播策略PropagationPolicy被提交到控制集群后,ResourcesController提取PropagationPolicy信息中被传播的资源名称;
步骤S2.2.2:通过被提取的资源名称去等待队列中查找关联KubernetesObject是否已经被用户提交,如果没提交,该PropagationPolicy传播策略被丢入等待队列,等待下一次处理,如果匹配到,那么创建ResourcesBinding对象。
优选地,所述步骤S2.4采用:
步骤S2.4.1:SchedulerController启动后,通过读取cluster对象,获取每个集群的入口地址以及访问证书;并启动集群状态探测流程;状态探测流程实时访问/ready接口,更新被管理集群的状态以及剩余可分配的资源,并同步监听ResourcesBinding对象事件;
步骤S2.4.2:ResourcesBinding被ResourcesController派生后,SchedulerController首先通过ResourcesBinding对象获取被关联集群的名称,然后在获取需要被传播的资源;
步骤S2.4.3:获取集群名称后,和健康集群匹配,匹配成功后,计算传播集群可以调度节点数量,可以被调度的资源,然后计算被传播对象的资源要求,最终得到一个集群真正调度的Pod数量;
步骤S2.4.4:获取实现可被调度Pod数量,和期望副本数量对比,若可被调度Pod数量小于期望副本数量,则动态调整副本数量,将无法满足调度的副本数量,调整到资源充足的集群之上,调整成功后,修改ResourcesBinding对象,设置每个集群的副本数量,同时标注该ResourcesBinding调度完成;
步骤S2.4.5:调度完成后,SchedulerController得到被关联重载策略OverridePolicy,读取需要被重载的内容,然后对每一个被传播集群生成Work对象,Work对象spec.data字段被填写了被传播资源的内容。
优选地,所述步骤S3采用:
步骤S3.1:新集群被添加为联邦的成员集群后,SchedulerController启动状态探测流程及资源计算流程;
步骤S3.2:探测流程访问集群的/healthy接口,获取成员集群所有工作节点,包含成员集群的控制节点、工作节点,并间隔时间探测节点,成员集群的节点状态通过探测kubelet服务端口实现,并在控制集群记录成员集群及节点状态;
步骤S3.3:成员集群状态从可用变成不可用时,先判断所属节点状态,所属节点半数以上变成不可用时,故障转移流程;
步骤S3.4:故障转移流程启动后,再次判断故障集群上需超过半数节点不可用,且有比例容器因为资源不够而导致容器无法启动,满足上述条件后,获取故障集群上所有的Work对象;
步骤S3.5:遍历保存的故障集群的work对象,统计所有work对象资源总和,包括内存以及CPU数据,作为筛选集群的重要依据;
步骤S3.6:获取所有健康状态的成员,利用获取的故障集群统计的资源综合作为筛选条件,筛选所有满足条件的集群,得到初步匹配的集群列表;
步骤S3.7:对初步匹配的集群列表打分,分别根据资源剩余情况、节点数、节点延迟综合评分,选出评分最高的集群;
步骤S3.8:选出评分最高集群后,得到集群地址,访问证书后,得到待部署集群所所有的work对象;
步骤S3.9:从故障集群得到所有的work对象works1,从评分最高集群中得到原生work集群已经部署的work对象works2,得到两个集群的work列表;
步骤S3.10:对比两个work对象,循环遍历works2依次对比works1,查找重名的work对象,遇到重名work对象后,修改重名work的对象,并同步修改work对象中cluster字段,填写新集群的地址以及访问令牌,下发状态修改为未下发;
步骤S3.11:ExecutionController检查到新的未下发work对象后,取出work中待下发集群集群地址,令牌,待下发资源后,依次创建资源,并启动更新线程;
步骤S3.12:更新线程通过work对象,依次同步每一个work对象的状态,从被下发集群中收集被下发资源的状态,同步work状态,至此完成集群故障转移流程。
根据本发明提供的一种开放、多云、多集群联邦实现的系统,包括:
模块M1:新集群加入联邦集群;
模块M2:应用通过联邦集群下发;
模块M3:应用下发后,当成员集群发生故障时,应用自动转移到健康集群。
优选地,所述模块M1采用:
模块M1.1:调用聚合层API服务,传入待加入集群证书,访问入口地址,成员集群名称member;
模块M1.2:控制集群在member集群中创建service account,并为serviceaccount配置clusterrole和clusterrolebinding,通过配置上述SA,授权控制集群可访问成员集群member的/readyz或/healthz URL,从而判断集群的健康状态;
模块M1.3:控制集群在控制集群中创建cluster对象,保存访问入口地址以及访问证书,并以预设时间间隔启动集群状态更新流程;
模块M1.4:更新流程中访问cluster对象中保存的访问入口地址,获取/readyz或healthz接口,若能得到200的http响应,则表示集群健康,否则表示集群不健康,并将状态更新到cluster对象中。
优选地,所述模块M2采用:
模块M2.1:在控制集群侧提交传播策略PropagationPolicy,分区重载策略OverridePolicy以及KubernetesObject;
模块M2.2:传播策略PropagationPolicy及KubernetesObject资源被控制器ResourcesController监听,ResourcesController监听到源生KubernetesObject和PropagationPolicy资源,完成资源绑定,并生成ResourcesBinding对象;
模块M2.3:BindingController观察到ResourcesBinding对象后,找到关联的分区重载策略OverridePolicy,实现ResourcesBinding对象和OverridePolicy绑定,并设置ResourcesBinding为可被调度;
模块M2.4:SchedulerController启动后,循环获取所有可被调度ResourcesBinding,根据动态负载,设置每个集群、区域副本数量,结合OverridePolicy重载差异化策略,生成Work对象;
模块M2.5:ExecutionController启动后,当Work对象被创建后,负责同步Work对象到集群,完成应用下发;
所述模块M2.2采用:
模块M2.2.1:传播策略PropagationPolicy被提交到控制集群后,ResourcesController提取PropagationPolicy信息中被传播的资源名称;
模块M2.2.2:通过被提取的资源名称去等待队列中查找关联KubernetesObject是否已经被用户提交,如果没提交,该PropagationPolicy传播策略被丢入等待队列,等待下一次处理,如果匹配到,那么创建ResourcesBinding对象;
所述模块M2.4采用:
模块M2.4.1:SchedulerController启动后,通过读取cluster对象,获取每个集群的入口地址以及访问证书;并启动集群状态探测流程;状态探测流程实时访问/ready接口,更新被管理集群的状态以及剩余可分配的资源,并同步监听ResourcesBinding对象事件;
模块M2.4.2:ResourcesBinding被ResourcesController派生后,SchedulerController首先通过ResourcesBinding对象获取被关联集群的名称,然后在获取需要被传播的资源;
模块M2.4.3:获取集群名称后,和健康集群匹配,匹配成功后,计算传播集群可以调度节点数量,可以被调度的资源,然后计算被传播对象的资源要求,最终得到一个集群真正调度的Pod数量;
模块M2.4.4:获取实现可被调度Pod数量,和期望副本数量对比,若可被调度Pod数量小于期望副本数量,则动态调整副本数量,将无法满足调度的副本数量,调整到资源充足的集群之上,调整成功后,修改ResourcesBinding对象,设置每个集群的副本数量,同时标注该ResourcesBinding调度完成;
模块M2.4.5:调度完成后,SchedulerController得到被关联重载策略OverridePolicy,读取需要被重载的内容,然后对每一个被传播集群生成Work对象,Work对象spec.data字段被填写了被传播资源的内容。
优选地,所述模块M3采用:
模块M3.1:新集群被添加为联邦的成员集群后,SchedulerController启动状态探测流程及资源计算流程;
模块M3.2:探测流程访问集群的/healthy接口,获取成员集群所有工作节点,包含成员集群的控制节点、工作节点,并间隔时间探测节点,成员集群的节点状态通过探测kubelet服务端口实现,并在控制集群记录成员集群及节点状态;
模块M3.3:成员集群状态从可用变成不可用时,先判断所属节点状态,所属节点半数以上变成不可用时,故障转移流程;
模块M3.4:故障转移流程启动后,再次判断故障集群上需超过半数节点不可用,且有比例容器因为资源不够而导致容器无法启动,满足上述条件后,获取故障集群上所有的Work对象;
模块M3.5:遍历保存的故障集群的work对象,统计所有work对象资源总和,包括内存以及CPU数据,作为筛选集群的重要依据;
模块M3.6:获取所有健康状态的成员,利用获取的故障集群统计的资源综合作为筛选条件,筛选所有满足条件的集群,得到初步匹配的集群列表;
模块M3.7:对初步匹配的集群列表打分,分别根据资源剩余情况、节点数、节点延迟综合评分,选出评分最高的集群;
模块M3.8:选出评分最高集群后,得到集群地址,访问证书后,得到待部署集群所所有的work对象;
模块M3.9:从故障集群得到所有的work对象works1,从评分最高集群中得到原生work集群已经部署的work对象works2,得到两个集群的work列表;
模块M3.10:对比两个work对象,循环遍历works2依次对比works1,查找重名的work对象,遇到重名work对象后,修改重名work的对象,并同步修改work对象中cluster字段,填写新集群的地址以及访问令牌,下发状态修改为未下发;
模块M3.11:ExecutionController检查到新的未下发work对象后,取出work中待下发集群集群地址,令牌,待下发资源后,依次创建资源,并启动更新线程;
模块M3.12:更新线程通过work对象,依次同步每一个work对象的状态,从被下发集群中收集被下发资源的状态,同步work状态,至此完成集群故障转移流程。
与现有技术相比,本发明具有如下的有益效果:
1、通过配置PropagationPolicy策略实现资源的统一下发,无需每个集群单独定义,解决了集群分散管理问题。
2、通过配置OverridePolicy策略实现成员集群的差异化配置,解决集群差异化部署的问题。
3、通过配置cluster对象,一个cluster对象和一个集群绑定,通过定义cluster对象,实现集群配置管理。
4、设计了集群调度器SchedulerController,不仅实现了负载均衡负载感知调度,而且发明了故障转移流程,当集群故障后,可自动转移负载到健康成员集群。
附图说明
通过阅读参照以下附图对非限制性实施例所作的详细描述,本发明的其它特征、目的和优点将会变得更明显:
图1为多云环境应用下发、差异化设置示意图。
图2为负载感知调度示意图。
图3为集群状态感知示意图。
图4为多集群统一访问入口示意图。
图5为集群故障转移流程图。
具体实施方式
下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明,但不以任何形式限制本发明。应当指出的是,对本领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干变化和改进。这些都属于本发明的保护范围。
本发明提供了多云环境应用下发、差异化设置以及负载感知调度,解决了多集群统一访问入口问题,实现了集群故障转移。
实施例1
根据本发明提供的一种开放、多云、多集群联邦实现的方法,如图1至5所示,包括:
步骤S1:新集群加入联邦集群;
具体地,所述步骤S1采用:
步骤S1.1:调用聚合层API服务,传入待加入集群证书,访问入口地址,成员集群名称member;
步骤S1.2:控制集群在member集群中创建service account,并为serviceaccount配置clusterrole和clusterrolebinding,通过配置上述SA,授权控制集群可访问成员集群member的/readyz或/healthz URL,从而判断集群的健康状态;
步骤S1.3:控制集群在控制集群中创建cluster对象,保存访问入口地址以及访问证书,并以10s间隔启动集群状态更新流程;
步骤S1.4:更新流程中访问cluster对象中保存的访问入口地址,获取/readyz或healthz接口,若能得到200的http响应,则表示集群健康,否则表示集群不健康,并将状态更新到cluster对象中。
步骤S2:应用通过联邦集群下发;
具体地,所述步骤S2采用:
步骤S2.1:在控制集群侧提交传播策略PropagationPolicy,分区重载策略OverridePolicy以及KubernetesObject;
步骤S2.2:传播策略PropagationPolicy及KubernetesObject资源被控制器ResourcesController监听,ResourcesController监听到源生KubernetesObject和PropagationPolicy资源,完成资源绑定,并生成ResourcesBinding对象;
步骤S2.3:BindingController观察到ResourcesBinding对象后,找到关联的分区重载策略OverridePolicy,实现ResourcesBinding对象和OverridePolicy绑定,并设置ResourcesBinding为可被调度;
步骤S2.4:SchedulerController启动后,循环获取所有可被调度ResourcesBinding,根据动态负载,设置每个集群、区域副本数量,结合OverridePolicy重载差异化策略,生成Work对象;
步骤S2.5:ExecutionController启动后,当Work对象被创建后,负责同步Work对象到集群,完成应用下发;
所述PropagationPolicy传播策略是一种基于Customer Resources Definitions技术实现的声明式资源,PropagationPolicy声明被下发的KubernetesObject以及被下发的集群,实现应用的统一下发;
所述OverridePolicy分区重载策略是一种基于Customer ResourcesDefinitions技术实现的声明式资源,OverridePolicy声明需要差异化的配置,重载策略包含有以下三种方式:PlaintextOverridder,CommandOverridder,以及ArgsOverride;分别对应spec重载,命名重载,参数重载;
所述ResourcesBinding绑定策略是一种基于Customer Resources Definitions技术实现的声明式资源,ResourcesBinding负责PropagationPolicy与KubernetesObject的绑定,只有绑定关系建立后,才能集群调度;
所述Work策略是一种基于Customer Resources Definitions技术实现的声明式资源,一个Work对象和一个集群对用,Work对象记录了被下发集群的状态信息,被下发的资源;Work对象负责每个集群上容器资源的调和;
所述ResourcesController服务,包含了通用controller负责kubernetes资源对象调和处理逻辑,以及匹配PropagationPolicy传播策略,并根据传播策略派生出资源对象对应的ResourcesBinding对象;
所述BindingController服务,主要处理ResourcesBinding资源对象的增删查改逻辑,实现ResourcesBinding和OverridePolicy绑定关系,设置集群绑定初始状态等;
所述SchedulerController服务,是整个多云管理的调度器,负责完成资源对象调度,对于需要计算副本比例的资源对象,会根据filter和score选择一些集群,然后再对需要分配副本的资源对象类型计算每一个集群应用分发的副本数,最终生成Work对象,SchedulerController同时还负责集群故障转移调度;
所述ExecutionController服务,用于处理Work对象,负责将Work中设置的资源在对应的集群上创建出来,并负责后续的状态同步,故障修复工作。
具体地,所述步骤S2.2采用:
步骤S2.2.1:传播策略PropagationPolicy被提交到控制集群后,ResourcesController提取PropagationPolicy信息中被传播的资源名称;
步骤S2.2.2:通过被提取的资源名称去等待队列中查找关联KubernetesObject是否已经被用户提交,如果没提交,该PropagationPolicy传播策略被丢入等待队列,等待下一次处理,如果匹配到,那么创建ResourcesBinding对象。
具体地,所述步骤S2.4采用:
步骤S2.4.1:SchedulerController启动后,通过读取cluster对象,获取每个集群的入口地址以及访问证书;并启动集群状态探测流程;状态探测流程实时访问/ready接口,更新被管理集群的状态以及剩余可分配的资源,并同步监听ResourcesBinding对象事件;
步骤S2.4.2:ResourcesBinding被ResourcesController派生后,SchedulerController首先通过ResourcesBinding对象获取被关联集群的名称,然后在获取需要被传播的资源;
步骤S2.4.3:获取集群名称后,和健康集群匹配,匹配成功后,计算传播集群可以调度节点数量,可以被调度的资源,然后计算被传播对象的资源要求,最终得到一个集群真正调度的Pod数量;
步骤S2.4.4:获取实现可被调度Pod数量,和期望副本数量对比,若可被调度Pod数量小于期望副本数量,则动态调整副本数量,将无法满足调度的副本数量,调整到资源充足的集群之上,调整成功后,修改ResourcesBinding对象,设置每个集群的副本数量,同时标注该ResourcesBinding调度完成;
步骤S2.4.5:调度完成后,SchedulerController得到被关联重载策略OverridePolicy,读取需要被重载的内容,然后对每一个被传播集群生成Work对象,Work对象spec.data字段被填写了被传播资源的内容。
步骤S3:应用下发后,当成员集群发生故障时,应用自动转移到健康集群。
具体地,所述步骤S3采用:
步骤S3.1:新集群被添加为联邦的成员集群后,SchedulerController启动状态探测流程及资源计算流程;
步骤S3.2:探测流程访问集群的/healthy接口,获取成员集群所有工作节点,包含成员集群的控制节点、工作节点,并间隔时间探测节点,成员集群的节点状态通过探测kubelet服务端口实现,并在控制集群记录成员集群及节点状态;
步骤S3.3:成员集群状态从可用变成不可用时,先判断所属节点状态,所属节点半数以上变成不可用时,故障转移流程;
步骤S3.4:故障转移流程启动后,再次判断故障集群上需超过半数节点不可用,且有比例容器因为资源不够而导致容器无法启动,满足上述条件后,获取故障集群上所有的Work对象;
步骤S3.5:遍历保存的故障集群的work对象,统计所有work对象资源总和,包括内存以及CPU数据,作为筛选集群的重要依据;
步骤S3.6:获取所有健康状态的成员,利用获取的故障集群统计的资源综合作为筛选条件,筛选所有满足条件的集群,得到初步匹配的集群列表;
步骤S3.7:对初步匹配的集群列表打分,分别根据资源剩余情况、节点数、节点延迟综合评分,选出评分最高的集群;
步骤S3.8:选出评分最高集群后,得到集群地址,访问证书后,得到待部署集群所所有的work对象;
步骤S3.9:从故障集群得到所有的work对象works1,从评分最高集群中得到原生work集群已经部署的work对象works2,得到两个集群的work列表;
步骤S3.10:对比两个work对象,循环遍历works2依次对比works1,查找重名的work对象,遇到重名work对象后,修改重名work的对象,并同步修改work对象中cluster字段,填写新集群的地址以及访问令牌,下发状态修改为未下发;
步骤S3.11:ExecutionController检查到新的未下发work对象后,取出work中待下发集群集群地址,令牌,待下发资源后,依次创建资源,并启动更新线程;
步骤S3.12:更新线程通过work对象,依次同步每一个work对象的状态,从被下发集群中收集被下发资源的状态,同步work状态,至此完成集群故障转移流程。
根据本发明提供的一种开放、多云、多集群联邦实现的系统,包括:
模块M1:新集群加入联邦集群;
具体地,所述模块M1采用:
模块M1.1:调用聚合层API服务,传入待加入集群证书,访问入口地址,成员集群名称member;
模块M1.2:控制集群在member集群中创建service account,并为serviceaccount配置clusterrole和clusterrolebinding,通过配置上述SA,授权控制集群可访问成员集群member的/readyz或/healthz URL,从而判断集群的健康状态;
模块M1.3:控制集群在控制集群中创建cluster对象,保存访问入口地址以及访问证书,并以10s间隔启动集群状态更新流程;
模块M1.4:更新流程中访问cluster对象中保存的访问入口地址,获取/readyz或healthz接口,若能得到200的http响应,则表示集群健康,否则表示集群不健康,并将状态更新到cluster对象中。
模块M2:应用通过联邦集群下发;
具体地,所述模块M2采用:
模块M2.1:在控制集群侧提交传播策略PropagationPolicy,分区重载策略OverridePolicy以及KubernetesObject;
模块M2.2:传播策略PropagationPolicy及KubernetesObject资源被控制器ResourcesController监听,ResourcesController监听到源生KubernetesObject和PropagationPolicy资源,完成资源绑定,并生成ResourcesBinding对象;
模块M2.3:BindingController观察到ResourcesBinding对象后,找到关联的分区重载策略OverridePolicy,实现ResourcesBinding对象和OverridePolicy绑定,并设置ResourcesBinding为可被调度;
模块M2.4:SchedulerController启动后,循环获取所有可被调度ResourcesBinding,根据动态负载,设置每个集群、区域副本数量,结合OverridePolicy重载差异化策略,生成Work对象;
模块M2.5:ExecutionController启动后,当Work对象被创建后,负责同步Work对象到集群,完成应用下发;
所述PropagationPolicy传播策略是一种基于Customer Resources Definitions技术实现的声明式资源,PropagationPolicy声明被下发的KubernetesObject以及被下发的集群,实现应用的统一下发;
所述OverridePolicy分区重载策略是一种基于Customer ResourcesDefinitions技术实现的声明式资源,OverridePolicy声明需要差异化的配置,重载策略包含有以下三种方式:PlaintextOverridder,CommandOverridder,以及ArgsOverride;分别对应spec重载,命名重载,参数重载;
所述ResourcesBinding绑定策略是一种基于Customer Resources Definitions技术实现的声明式资源,ResourcesBinding负责PropagationPolicy与KubernetesObject的绑定,只有绑定关系建立后,才能集群调度;
所述Work策略是一种基于Customer Resources Definitions技术实现的声明式资源,一个Work对象和一个集群对用,Work对象记录了被下发集群的状态信息,被下发的资源;Work对象负责每个集群上容器资源的调和;
所述ResourcesController服务,包含了通用controller负责kubernetes资源对象调和处理逻辑,以及匹配PropagationPolicy传播策略,并根据传播策略派生出资源对象对应的ResourcesBinding对象;
所述BindingController服务,主要处理ResourcesBinding资源对象的增删查改逻辑,实现ResourcesBinding和OverridePolicy绑定关系,设置集群绑定初始状态等;
所述SchedulerController服务,是整个多云管理的调度器,负责完成资源对象调度,对于需要计算副本比例的资源对象,会根据filter和score选择一些集群,然后再对需要分配副本的资源对象类型计算每一个集群应用分发的副本数,最终生成Work对象,SchedulerController同时还负责集群故障转移调度;
所述ExecutionController服务,用于处理Work对象,负责将Work中设置的资源在对应的集群上创建出来,并负责后续的状态同步,故障修复工作。
具体地,所述模块M2.2采用:
模块M2.2.1:传播策略PropagationPolicy被提交到控制集群后,ResourcesController提取PropagationPolicy信息中被传播的资源名称;
模块M2.2.2:通过被提取的资源名称去等待队列中查找关联KubernetesObject是否已经被用户提交,如果没提交,该PropagationPolicy传播策略被丢入等待队列,等待下一次处理,如果匹配到,那么创建ResourcesBinding对象。
具体地,所述模块M2.4采用:
模块M2.4.1:SchedulerController启动后,通过读取cluster对象,获取每个集群的入口地址以及访问证书;并启动集群状态探测流程;状态探测流程实时访问/ready接口,更新被管理集群的状态以及剩余可分配的资源,并同步监听ResourcesBinding对象事件;
模块M2.4.2:ResourcesBinding被ResourcesController派生后,SchedulerController首先通过ResourcesBinding对象获取被关联集群的名称,然后在获取需要被传播的资源;
模块M2.4.3:获取集群名称后,和健康集群匹配,匹配成功后,计算传播集群可以调度节点数量,可以被调度的资源,然后计算被传播对象的资源要求,最终得到一个集群真正调度的Pod数量;
模块M2.4.4:获取实现可被调度Pod数量,和期望副本数量对比,若可被调度Pod数量小于期望副本数量,则动态调整副本数量,将无法满足调度的副本数量,调整到资源充足的集群之上,调整成功后,修改ResourcesBinding对象,设置每个集群的副本数量,同时标注该ResourcesBinding调度完成;
模块M2.4.5:调度完成后,SchedulerController得到被关联重载策略OverridePolicy,读取需要被重载的内容,然后对每一个被传播集群生成Work对象,Work对象spec.data字段被填写了被传播资源的内容。
模块M3:应用下发后,当成员集群发生故障时,应用自动转移到健康集群。
具体地,所述模块M3采用:
模块M3.1:新集群被添加为联邦的成员集群后,SchedulerController启动状态探测流程及资源计算流程;
模块M3.2:探测流程访问集群的/healthy接口,获取成员集群所有工作节点,包含成员集群的控制节点、工作节点,并间隔时间探测节点,成员集群的节点状态通过探测kubelet服务端口实现,并在控制集群记录成员集群及节点状态;
模块M3.3:成员集群状态从可用变成不可用时,先判断所属节点状态,所属节点半数以上变成不可用时,故障转移流程;
模块M3.4:故障转移流程启动后,再次判断故障集群上需超过半数节点不可用,且有比例容器因为资源不够而导致容器无法启动,满足上述条件后,获取故障集群上所有的Work对象;
模块M3.5:遍历保存的故障集群的work对象,统计所有work对象资源总和,包括内存以及CPU数据,作为筛选集群的重要依据;
模块M3.6:获取所有健康状态的成员,利用获取的故障集群统计的资源综合作为筛选条件,筛选所有满足条件的集群,得到初步匹配的集群列表;
模块M3.7:对初步匹配的集群列表打分,分别根据资源剩余情况、节点数、节点延迟综合评分,选出评分最高的集群;
模块M3.8:选出评分最高集群后,得到集群地址,访问证书后,得到待部署集群所所有的work对象;
模块M3.9:从故障集群得到所有的work对象works1,从评分最高集群中得到原生work集群已经部署的work对象works2,得到两个集群的work列表;
模块M3.10:对比两个work对象,循环遍历works2依次对比works1,查找重名的work对象,遇到重名work对象后,修改重名work的对象,并同步修改work对象中cluster字段,填写新集群的地址以及访问令牌,下发状态修改为未下发;
模块M3.11:ExecutionController检查到新的未下发work对象后,取出work中待下发集群集群地址,令牌,待下发资源后,依次创建资源,并启动更新线程;
模块M3.12:更新线程通过work对象,依次同步每一个work对象的状态,从被下发集群中收集被下发资源的状态,同步work状态,至此完成集群故障转移流程。
本领域技术人员知道,除了以纯计算机可读程序代码方式实现本发明提供的系统、装置及其各个模块以外,完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统、装置及其各个模块以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同程序。所以,本发明提供的系统、装置及其各个模块可以被认为是一种硬件部件,而对其内包括的用于实现各种程序的模块也可以视为硬件部件内的结构;也可以将用于实现各种功能的模块视为既可以是实现方法的软件程序又可以是硬件部件内的结构。
以上对本发明的具体实施例进行了描述。需要理解的是,本发明并不局限于上述特定实施方式,本领域技术人员可以在权利要求的范围内做出各种变化或修改,这并不影响本发明的实质内容。在不冲突的情况下,本申请的实施例和实施例中的特征可以任意相互组合。

Claims (10)

1.一种开放、多云、多集群联邦实现的方法,其特征在于,包括:
步骤S1:新集群加入联邦集群;
步骤S2:应用通过联邦集群下发;
步骤S3:应用下发后,当成员集群发生故障时,应用自动转移到健康集群。
2.根据权利要求1所述的开放、多云、多集群联邦实现的方法,其特征在于,所述步骤S1采用:
步骤S1.1:调用聚合层API服务,传入待加入集群证书,访问入口地址,成员集群名称member;
步骤S1.2:控制集群在member集群中创建service account,并为service account配置clusterrole和clusterrolebinding,通过配置上述SA,授权控制集群可访问成员集群member的/readyz或/healthz URL,从而判断集群的健康状态;
步骤S1.3:控制集群在控制集群中创建cluster对象,保存访问入口地址以及访问证书,并以预设时间间隔启动集群状态更新流程;
步骤S1.4:更新流程中访问cluster对象中保存的访问入口地址,获取/readyz或healthz接口,若能得到200的http响应,则表示集群健康,否则表示集群不健康,并将状态更新到cluster对象中。
3.根据权利要求1所述的开放、多云、多集群联邦实现的方法,其特征在于,所述步骤S2采用:
步骤S2.1:在控制集群侧提交传播策略PropagationPolicy,分区重载策略OverridePolicy以及KubernetesObject;
步骤S2.2:传播策略PropagationPolicy及KubernetesObject资源被控制器ResourcesController监听,ResourcesController监听到源生KubernetesObject和PropagationPolicy资源,完成资源绑定,并生成ResourcesBinding对象;
步骤S2.3:BindingController观察到ResourcesBinding对象后,找到关联的分区重载策略OverridePolicy,实现ResourcesBinding对象和OverridePolicy绑定,并设置ResourcesBinding为可被调度;
步骤S2.4:SchedulerController启动后,循环获取所有可被调度ResourcesBinding,根据动态负载,设置每个集群、区域副本数量,结合OverridePolicy重载差异化策略,生成Work对象;
步骤S2.5:ExecutionController启动后,当Work对象被创建后,负责同步Work对象到集群,完成应用下发。
4.根据权利要求3所述的开放、多云、多集群联邦实现的方法,其特征在于,所述步骤S2.2采用:
步骤S2.2.1:传播策略PropagationPolicy被提交到控制集群后,ResourcesController提取PropagationPolicy信息中被传播的资源名称;
步骤S2.2.2:通过被提取的资源名称去等待队列中查找关联KubernetesObject是否已经被用户提交,如果没提交,该PropagationPolicy传播策略被丢入等待队列,等待下一次处理,如果匹配到,那么创建ResourcesBinding对象。
5.根据权利要求3所述的开放、多云、多集群联邦实现的方法,其特征在于,所述步骤S2.4采用:
步骤S2.4.1:SchedulerController启动后,通过读取cluster对象,获取每个集群的入口地址以及访问证书;并启动集群状态探测流程;状态探测流程实时访问/ready接口,更新被管理集群的状态以及剩余可分配的资源,并同步监听ResourcesBinding对象事件;
步骤S2.4.2:ResourcesBinding被ResourcesController派生后,SchedulerController首先通过ResourcesBinding对象获取被关联集群的名称,然后在获取需要被传播的资源;
步骤S2.4.3:获取集群名称后,和健康集群匹配,匹配成功后,计算传播集群可以调度节点数量,可以被调度的资源,然后计算被传播对象的资源要求,最终得到一个集群真正调度的Pod数量;
步骤S2.4.4:获取实现可被调度Pod数量,和期望副本数量对比,若可被调度Pod数量小于期望副本数量,则动态调整副本数量,将无法满足调度的副本数量,调整到资源充足的集群之上,调整成功后,修改ResourcesBinding对象,设置每个集群的副本数量,同时标注该ResourcesBinding调度完成;
步骤S2.4.5:调度完成后,SchedulerController得到被关联重载策略OverridePolicy,读取需要被重载的内容,然后对每一个被传播集群生成Work对象,Work对象spec.data字段被填写了被传播资源的内容。
6.根据权利要求1所述的开放、多云、多集群联邦实现的方法,其特征在于,所述步骤S3采用:
步骤S3.1:新集群被添加为联邦的成员集群后,SchedulerController启动状态探测流程及资源计算流程;
步骤S3.2:探测流程访问集群的/healthy接口,获取成员集群所有工作节点,包含成员集群的控制节点、工作节点,并间隔时间探测节点,成员集群的节点状态通过探测kubelet服务端口实现,并在控制集群记录成员集群及节点状态;
步骤S3.3:成员集群状态从可用变成不可用时,先判断所属节点状态,所属节点半数以上变成不可用时,故障转移流程;
步骤S3.4:故障转移流程启动后,再次判断故障集群上需超过半数节点不可用,且有比例容器因为资源不够而导致容器无法启动,满足上述条件后,获取故障集群上所有的Work对象;
步骤S3.5:遍历保存的故障集群的work对象,统计所有work对象资源总和,包括内存以及CPU数据,作为筛选集群的重要依据;
步骤S3.6:获取所有健康状态的成员,利用获取的故障集群统计的资源综合作为筛选条件,筛选所有满足条件的集群,得到初步匹配的集群列表;
步骤S3.7:对初步匹配的集群列表打分,分别根据资源剩余情况、节点数、节点延迟综合评分,选出评分最高的集群;
步骤S3.8:选出评分最高集群后,得到集群地址,访问证书后,得到待部署集群所所有的work对象;
步骤S3.9:从故障集群得到所有的work对象works1,从评分最高集群中得到原生work集群已经部署的work对象works2,得到两个集群的work列表;
步骤S3.10:对比两个work对象,循环遍历works2依次对比works1,查找重名的work对象,遇到重名work对象后,修改重名work的对象,并同步修改work对象中cluster字段,填写新集群的地址以及访问令牌,下发状态修改为未下发;
步骤S3.11:ExecutionController检查到新的未下发work对象后,取出work中待下发集群集群地址,令牌,待下发资源后,依次创建资源,并启动更新线程;
步骤S3.12:更新线程通过work对象,依次同步每一个work对象的状态,从被下发集群中收集被下发资源的状态,同步work状态,至此完成集群故障转移流程。
7.一种开放、多云、多集群联邦实现的系统,其特征在于,包括:
模块M1:新集群加入联邦集群;
模块M2:应用通过联邦集群下发;
模块M3:应用下发后,当成员集群发生故障时,应用自动转移到健康集群。
8.根据权利要求7所述的开放、多云、多集群联邦实现的系统,其特征在于,所述模块M1采用:
模块M1.1:调用聚合层API服务,传入待加入集群证书,访问入口地址,成员集群名称member;
模块M1.2:控制集群在member集群中创建service account,并为service account配置clusterrole和clusterrolebinding,通过配置上述SA,授权控制集群可访问成员集群member的/readyz或/healthz URL,从而判断集群的健康状态;
模块M1.3:控制集群在控制集群中创建cluster对象,保存访问入口地址以及访问证书,并以预设时间间隔启动集群状态更新流程;
模块M1.4:更新流程中访问cluster对象中保存的访问入口地址,获取/readyz或healthz接口,若能得到200的http响应,则表示集群健康,否则表示集群不健康,并将状态更新到cluster对象中。
9.根据权利要求7所述的开放、多云、多集群联邦实现的系统,其特征在于,所述模块M2采用:
模块M2.1:在控制集群侧提交传播策略PropagationPolicy,分区重载策略OverridePolicy以及KubernetesObject;
模块M2.2:传播策略PropagationPolicy及KubernetesObject资源被控制器ResourcesController监听,ResourcesController监听到源生KubernetesObject和PropagationPolicy资源,完成资源绑定,并生成ResourcesBinding对象;
模块M2.3:BindingController观察到ResourcesBinding对象后,找到关联的分区重载策略OverridePolicy,实现ResourcesBinding对象和OverridePolicy绑定,并设置ResourcesBinding为可被调度;
模块M2.4:SchedulerController启动后,循环获取所有可被调度ResourcesBinding,根据动态负载,设置每个集群、区域副本数量,结合OverridePolicy重载差异化策略,生成Work对象;
模块M2.5:ExecutionController启动后,当Work对象被创建后,负责同步Work对象到集群,完成应用下发;
所述模块M2.2采用:
模块M2.2.1:传播策略PropagationPolicy被提交到控制集群后,ResourcesController提取PropagationPolicy信息中被传播的资源名称;
模块M2.2.2:通过被提取的资源名称去等待队列中查找关联KubernetesObject是否已经被用户提交,如果没提交,该PropagationPolicy传播策略被丢入等待队列,等待下一次处理,如果匹配到,那么创建ResourcesBinding对象;
所述模块M2.4采用:
模块M2.4.1:SchedulerController启动后,通过读取cluster对象,获取每个集群的入口地址以及访问证书;并启动集群状态探测流程;状态探测流程实时访问/ready接口,更新被管理集群的状态以及剩余可分配的资源,并同步监听ResourcesBinding对象事件;
模块M2.4.2:ResourcesBinding被ResourcesController派生后,SchedulerController首先通过ResourcesBinding对象获取被关联集群的名称,然后在获取需要被传播的资源;
模块M2.4.3:获取集群名称后,和健康集群匹配,匹配成功后,计算传播集群可以调度节点数量,可以被调度的资源,然后计算被传播对象的资源要求,最终得到一个集群真正调度的Pod数量;
模块M2.4.4:获取实现可被调度Pod数量,和期望副本数量对比,若可被调度Pod数量小于期望副本数量,则动态调整副本数量,将无法满足调度的副本数量,调整到资源充足的集群之上,调整成功后,修改ResourcesBinding对象,设置每个集群的副本数量,同时标注该ResourcesBinding调度完成;
模块M2.4.5:调度完成后,SchedulerController得到被关联重载策略OverridePolicy,读取需要被重载的内容,然后对每一个被传播集群生成Work对象,Work对象spec.data字段被填写了被传播资源的内容。
10.根据权利要求7所述的开放、多云、多集群联邦实现的系统,其特征在于,所述模块M3采用:
模块M3.1:新集群被添加为联邦的成员集群后,SchedulerController启动状态探测流程及资源计算流程;
模块M3.2:探测流程访问集群的/healthy接口,获取成员集群所有工作节点,包含成员集群的控制节点、工作节点,并间隔时间探测节点,成员集群的节点状态通过探测kubelet服务端口实现,并在控制集群记录成员集群及节点状态;
模块M3.3:成员集群状态从可用变成不可用时,先判断所属节点状态,所属节点半数以上变成不可用时,故障转移流程;
模块M3.4:故障转移流程启动后,再次判断故障集群上需超过半数节点不可用,且有比例容器因为资源不够而导致容器无法启动,满足上述条件后,获取故障集群上所有的Work对象;
模块M3.5:遍历保存的故障集群的work对象,统计所有work对象资源总和,包括内存以及CPU数据,作为筛选集群的重要依据;
模块M3.6:获取所有健康状态的成员,利用获取的故障集群统计的资源综合作为筛选条件,筛选所有满足条件的集群,得到初步匹配的集群列表;
模块M3.7:对初步匹配的集群列表打分,分别根据资源剩余情况、节点数、节点延迟综合评分,选出评分最高的集群;
模块M3.8:选出评分最高集群后,得到集群地址,访问证书后,得到待部署集群所所有的work对象;
模块M3.9:从故障集群得到所有的work对象works1,从评分最高集群中得到原生work集群已经部署的work对象works2,得到两个集群的work列表;
模块M3.10:对比两个work对象,循环遍历works2依次对比works1,查找重名的work对象,遇到重名work对象后,修改重名work的对象,并同步修改work对象中cluster字段,填写新集群的地址以及访问令牌,下发状态修改为未下发;
模块M3.11:ExecutionController检查到新的未下发work对象后,取出work中待下发集群集群地址,令牌,待下发资源后,依次创建资源,并启动更新线程;
模块M3.12:更新线程通过work对象,依次同步每一个work对象的状态,从被下发集群中收集被下发资源的状态,同步work状态,至此完成集群故障转移流程。
CN202211046691.XA 2022-08-30 2022-08-30 开放、多云、多集群联邦实现的方法及系统 Pending CN115460089A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211046691.XA CN115460089A (zh) 2022-08-30 2022-08-30 开放、多云、多集群联邦实现的方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211046691.XA CN115460089A (zh) 2022-08-30 2022-08-30 开放、多云、多集群联邦实现的方法及系统

Publications (1)

Publication Number Publication Date
CN115460089A true CN115460089A (zh) 2022-12-09

Family

ID=84301645

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211046691.XA Pending CN115460089A (zh) 2022-08-30 2022-08-30 开放、多云、多集群联邦实现的方法及系统

Country Status (1)

Country Link
CN (1) CN115460089A (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150201036A1 (en) * 2014-01-16 2015-07-16 Hitachi, Ltd. Gateway device, file server system, and file distribution method
CN109218100A (zh) * 2018-09-21 2019-01-15 郑州云海信息技术有限公司 分布式对象存储集群及其请求响应方法、系统和存储介质
US20210365290A1 (en) * 2020-04-16 2021-11-25 Nanjing University Of Posts And Telecommunications Multidimensional resource scheduling method in kubernetes cluster architecture system
CN113742033A (zh) * 2021-09-08 2021-12-03 广西东信数建信息科技有限公司 一种kubernetes集群联邦系统及其实现方法
CN114003338A (zh) * 2021-10-20 2022-02-01 浪潮云信息技术股份公司 一种实现多cpu架构多云管理服务的系统及方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150201036A1 (en) * 2014-01-16 2015-07-16 Hitachi, Ltd. Gateway device, file server system, and file distribution method
CN109218100A (zh) * 2018-09-21 2019-01-15 郑州云海信息技术有限公司 分布式对象存储集群及其请求响应方法、系统和存储介质
US20210365290A1 (en) * 2020-04-16 2021-11-25 Nanjing University Of Posts And Telecommunications Multidimensional resource scheduling method in kubernetes cluster architecture system
CN113742033A (zh) * 2021-09-08 2021-12-03 广西东信数建信息科技有限公司 一种kubernetes集群联邦系统及其实现方法
CN114003338A (zh) * 2021-10-20 2022-02-01 浪潮云信息技术股份公司 一种实现多cpu架构多云管理服务的系统及方法

Similar Documents

Publication Publication Date Title
CN100418057C (zh) 用于应用程序分布式管理的启用网格的虚拟机的方法和系统
CN104050042B (zh) Etl作业的资源分配方法及装置
CN1906580B (zh) 对于具有可移动对象的启用网格的虚拟机的方法和系统
Wang et al. Pigeon: An effective distributed, hierarchical datacenter job scheduler
CN109582466A (zh) 一种定时任务执行方法、分布式服务器集群及电子设备
CN109558234A (zh) 一种定时任务调度方法和装置
CN106354729B (zh) 一种图数据处理方法、装置和系统
US9659080B1 (en) Categorization for constraint-based placement of object replicas in a distributed storage system
CN109218100A (zh) 分布式对象存储集群及其请求响应方法、系统和存储介质
Zhao et al. Optimizing geo-distributed data analytics with coordinated task scheduling and routing
CN103473696A (zh) 一种收集、分析和分发网络商业信息的方法和系统
CN104077212A (zh) 压力测试系统及方法
CN109992354A (zh) 容器处理方法、装置、主体服务器、系统和存储介质
CN101751288A (zh) 应用进程调度的方法、设备及系统
CN103873534A (zh) 一种应用集群迁移方法及装置
CN107330580A (zh) 电力营销基础数据平台组建方法
CN109788024A (zh) 高可用高并发高性能分布式远程抄表采集服务器解决方法
CN113742033A (zh) 一种kubernetes集群联邦系统及其实现方法
CN111857977B (zh) 弹性伸缩方法、装置、服务器和存储介质
CN110290166A (zh) 跨集群数据交互方法、系统、装置及可读存储介质
CN112395269A (zh) MySQL高可用组的搭建方法及装置
CN106257424B (zh) 一种基于kvm云平台的分布式数据库系统实现自动伸缩负载均衡的方法
CN103279387A (zh) 对相关资源分区重定位
EP1443423A1 (en) Apparatus and method for data replication in a data network
WO2018063723A1 (en) Flexible in-memory column store placement

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