CN116684261A - 集群架构的控制方法及装置、存储介质及电子设备 - Google Patents
集群架构的控制方法及装置、存储介质及电子设备 Download PDFInfo
- Publication number
- CN116684261A CN116684261A CN202310786505.4A CN202310786505A CN116684261A CN 116684261 A CN116684261 A CN 116684261A CN 202310786505 A CN202310786505 A CN 202310786505A CN 116684261 A CN116684261 A CN 116684261A
- Authority
- CN
- China
- Prior art keywords
- management
- management node
- node
- nodes
- candidate
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 72
- 238000007726 management method Methods 0.000 claims description 611
- 230000008569 process Effects 0.000 claims description 23
- 238000004590 computer program Methods 0.000 claims description 16
- 238000012544 monitoring process Methods 0.000 claims description 6
- 238000013523 data management Methods 0.000 claims description 4
- 239000000758 substrate Substances 0.000 claims 1
- 239000000306 component Substances 0.000 description 86
- 238000013461 design Methods 0.000 description 11
- 238000010586 diagram Methods 0.000 description 8
- 230000006870 function Effects 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 5
- 238000012423 maintenance Methods 0.000 description 4
- 230000001360 synchronised effect Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 238000011084 recovery Methods 0.000 description 3
- 230000010076 replication Effects 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 239000008358 core component Substances 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000013501 data transformation Methods 0.000 description 1
- 230000009849 deactivation Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000003449 preventive effect Effects 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0668—Management 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5007—Internet protocol [IP] addresses
Abstract
本申请实施例提供了一种集群架构的控制方法及装置、存储介质及电子设备,该集群架构的控制方法包括:从目标节点集群中的一组候选管理节点中选择第一管理节点作为目标节点集群的管理节点,其中,目标节点集群的管理节点用于对目标节点集群中的一组工作节点进行控制,一组候选管理节点和一组工作节点均用于运行容器化应用;为第一管理节点分配虚拟网际协议IP地址,其中,虚拟IP地址为外部程序访问目标节点集群的管理节点所使用的IP地址;在第一管理节点发生故障的情况下,从一组候选管理节点中除了第一管理节点以外的其他候选管理节点中选择第二管理节点作为目标节点集群的管理节点,并为第二管理节点分配虚拟IP地址。
Description
技术领域
本申请实施例涉及计算机领域,具体而言,涉及一种集群架构的控制方法及装置、存储介质及电子设备。
背景技术
目前,随着新的技术时代的发展,云计算发挥着越来越重要的作用,业务上云已经不是什么新鲜事物,容器云也已在大大小小的公司实现落地。Kubernetes(一个开源的、用于管理云平台中多个主机上的容器化的应用,简称k8s)是一个可移植、可扩展的开源容器编排平台,由于其易于扩展、一致性控制、开源等特点,逐渐成为云计算的事实标准。无论是业务应用还是中间件服务,甚至分布式计算任务,k8s集群都能轻松驾驭。
然而,普通的k8s集群中,只能保证在工作节点发生故障时,k8s集群是高可用的,但是当管理节点故障时,由于k8s的api-server(调用服务)不可用会导致整个集群无领导者,无法进行下一步正常运行,整个k8s集群将会发生崩溃。
由此可见,相关技术中的集群架构的控制方法,存在集群架构的可用性较低的问题。
发明内容
本申请实施例提供了一种集群架构的控制方法及装置、存储介质及电子设备,以至少解决相关技术中的集群架构的控制方法存在集群架构的可用性较低的问题。
根据本申请的一个实施例,提供了一种集群架构的控制方法,包括:从目标节点集群中的一组候选管理节点中选择第一管理节点作为所述目标节点集群的管理节点,其中,所述目标节点集群的管理节点用于对所述目标节点集群中的一组工作节点进行控制,所述一组候选管理节点和所述一组工作节点均用于运行容器化应用;为所述第一管理节点分配虚拟网际协议IP地址,其中,所述虚拟IP地址为外部程序访问所述目标节点集群的管理节点所使用的IP地址;在所述第一管理节点发生故障的情况下,从所述一组候选管理节点中除了所述第一管理节点以外的其他候选管理节点中选择第二管理节点作为所述目标节点集群的管理节点,并为所述第二管理节点分配所述虚拟IP地址。
根据本申请的又一个实施例,提供了一种集群架构的控制装置,包括:选择单元,用于从目标节点集群中的一组候选管理节点中选择第一管理节点作为所述目标节点集群的管理节点,其中,所述目标节点集群的管理节点用于对所述目标节点集群中的一组工作节点进行控制,所述一组候选管理节点和所述一组工作节点均用于运行容器化应用;分配单元,用于为所述第一管理节点分配虚拟网际协议IP地址,其中,所述虚拟IP地址为外部程序访问所述目标节点集群的管理节点所使用的IP地址;第一执行单元,用于在所述第一管理节点发生故障的情况下,从所述一组候选管理节点中除了所述第一管理节点以外的其他候选管理节点中选择第二管理节点作为所述目标节点集群的管理节点,并为所述第二管理节点分配所述虚拟IP地址。
根据本申请的又一个实施例,还提供了一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机程序,其中,所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
根据本申请的又一个实施例,还提供了一种电子设备,包括存储器和处理器,所述存储器中存储有计算机程序,所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。
通过本申请实施例,采用在集群架构中部署多个候选管理节点的方式,通过从目标节点集群中的一组候选管理节点中选择第一管理节点作为目标节点集群的管理节点,其中,目标节点集群的管理节点用于对目标节点集群中的一组工作节点进行控制,一组候选管理节点和一组工作节点均用于运行容器化应用;为第一管理节点分配虚拟网际协议IP地址,其中,虚拟IP地址为外部程序访问目标节点集群的管理节点所使用的IP地址;在第一管理节点发生故障的情况下,从一组候选管理节点中除了第一管理节点以外的其他候选管理节点中选择第二管理节点作为目标节点集群的管理节点,并为第二管理节点分配虚拟IP地址,由于在一个运行的管理节点发生故障时,可以有其他候选的管理节点作为备份,以保证整个集群的正常运行,从而实现提高集群架构的可用性的技术效果,进而解决了相关技术中的集群架构的控制方法存在集群架构的可用性较低的问题。
附图说明
图1是根据本申请实施例的一种集群架构的控制方法的硬件环境示意图;
图2是根据本申请实施例的一种集群架构的控制方法的流程图;
图3是根据本申请实施例的一种集群架构的控制方法的示意图;
图4是根据本申请实施例的另一种集群架构的控制方法的示意图;
图5是根据本申请实施例的又一种集群架构的控制方法的示意图;
图6是根据本申请实施例的又一种集群架构的控制方法的示意图;
图7是根据本申请实施例的又一种集群架构的控制方法的流程图;
图8是根据本申请实施例的一种集群架构的控制装置的结构框图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本申请的实施例。
需要说明的是,本申请实施例的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。
本申请实施例中所提供的方法实施例可以在移动终端、服务器或者类似的运算装置中执行。以运行在服务器上为例,图1是根据本申请实施例的一种集群架构的控制方法的硬件环境示意图。如图1所示,服务器可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)和用于存储数据的存储器104,其中,上述服务器还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解,图1所示的结构仅为示意,其并不对上述服务器的结构造成限定。例如,服务器还可包括比图1中所示更多或者更少的组件,或者具有与图1所示不同的配置。
存储器104可用于存储计算机程序,例如,应用软件的软件程序以及模块,如本申请实施例中的集群架构的控制方法对应的计算机程序,处理器102通过运行存储在存储器104内的计算机程序,从而执行各种功能应用以及数据处理,即实现上述的方法。存储器104可包括高速随机存储器,还可包括非易失性存储器,如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中,存储器104可进一步包括相对于处理器102远程设置的存储器,这些远程存储器可以通过网络连接至移动终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
传输设备106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括服务器的通信供应商提供的无线网络。在一个实例中,传输设备106包括一个网络适配器(Network Interface Controller,简称为NIC),其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中,传输设备106可以为射频(Radio Frequency,简称为RF)模块,其用于通过无线方式与互联网进行通讯。
根据本申请实施例的一个方面,提供了一种集群架构的控制方法,以由服务器来执行本实施例中的集群架构的控制方法为例,图2是根据本申请实施例的一种集群架构的控制方法的流程图,如图2所示,该流程包括如下步骤:
步骤S202,从目标节点集群中的一组候选管理节点中选择第一管理节点作为目标节点集群的管理节点,其中,目标节点集群的管理节点用于对目标节点集群中的一组工作节点进行控制,一组候选管理节点和一组工作节点均用于运行容器化应用。
本实施例中的集群架构的控制方法可以应用到对运维平台的集群架构进行部署的场景中。为了可以确保运维平台能够不受任何干扰地为用户提供服务和产品,从而更好地保留客户并减少客户流失,需要保证运维平台中的服务器集群以及关键组件是高可用的。这里,集群(Cluster)就是一组计算机,它们作为一个整体向用户提供一组网络资源,这些单个的计算机系统就是集群的节点(Node)。集群提供了以下关键的特性:可扩展性、高可用性、负载均衡、错误恢复。高可用是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。而服务器的可用性是指单位时间内(通常一年),服务器可以正常工作的时间比例。单点是系统高可用的大敌,单点往往是系统高可用最大的风险和敌人,应该尽量在系统设计的过程中避免单点。方法论上,高可用保证的原则是“集群化”,或者叫“冗余”。
上述高可用性的目标是以最小的停机时间提供连续的服务。这意味着,如果一个组件发生故障,另一个组件可以立即接管其功能,而不会实质性地中断对系统用户的服务。此外,高可用性有能力检测到一个或多个组件发生故障,然后采取纠正措施使其重新投入使用。高可用性对企业来说是至关重要的。随着企业使用的越来越多的东西变得越来越依赖于持续连接到其他地方的东西,高可用性变得越来越重要。
高可用是个比较复杂的命题,任何日常的变化例如服务升级、硬件更新、数据迁移、流量突增等都可能造成服务受损,甚至不可用。设计并运行一个兼顾可扩展性、可移植性和健壮性的应用是一件很有挑战的事情,尤其是当系统复杂度在不断增长时。应用或系统本身的架构极大的影响着其运行方式、对环境的依赖性,以及与相关组件的耦合强弱。高可用对于底层的IT基础设施来说是基本要求,这意味着云基础设施三个方面的需求:容错(即使出了一些错误,底层系统依旧工作)、服务可用(即,运行在云上的服务必须一直是可用的状态)、数据安全(即,云上的数据确保健全、可用)。
Kubernetes(即,k8s)是一个可移植、可扩展的开源容器编排平台,用于管理容器化的工作负载和服务,方便了声明式配置和自动化,并由于其易于扩展、一致性部署、开源等特点,逐渐成为云计算的事实标准。Kubernetes是典型的主从分布式架构,如图3所示,由集中式的管理节点(Master Node),分布式的工作节点(Worker Node,或者Work Node)组成以及辅助工具组成。无论是业务应用还是中间件服务,甚至分布式计算任务,k8s集群都能轻松驾驭,然而,企业场景下稳定并且高可用的k8s集群部署也并非毫无挑战。例如,如何在架构和能力上去提升我们的可用性,降低系统发生故障的概率和影响面?如何在核心链路性能和架构上做一些突破,能够支撑这么复杂多变的业务场景和业务增长的通用需求?如何让问题不再追身,做好预防工作,避免应急?如何在应急发生时,能够快速发现,快速诊断,快速止损?
为了至少部分解决上述技术问题,可以使用k8s集群对运维平台的服务器进行部署。考虑到在普通的k8s集群中,虽然某个工作节点故障时k8s集群是高可用的,但是当管理节点故障时,由于k8s的api-server(调用服务)不可用会导致整个集群无领导者,无法进行下一步正常运行,整个k8s集群将会发生崩溃。在本实施例中,可以部署有一组管理节点,如图4所示,(虚线表示备用管理节点与工作节点之间的连接)即使一个管理节点出了问题,也不会影响到其他的管理节点。
在本实施例中,可以从目标节点集群中的一组候选管理节点中选择第一管理节点作为目标节点集群的管理节点。目标节点集群可以是前述k8s集群。目标节点集群的管理节点可以用于对目标节点集群中的一组工作节点进行控制。一组候选管理节点和一组工作节点可以均用于运行容器化应用。
考虑到在确定目标节点集群时,一组候选管理节点中的多个候选管理节点之间会出现投票竞选的问题,上述一组候选管理节点中管理节点的总个数可以是单数,从而避免出现票数相同的情况。此外,由于管理节点越多,需要的服务器越多,为了尽可能减少服务器的投入成本,上述一组候选管理节点中管理节点的总个数可以为大于1的较小的单数,如3。
步骤S204,为第一管理节点分配虚拟网际协议IP地址,其中,虚拟IP地址为外部程序访问目标节点集群的管理节点所使用的IP地址。
为了提高集群的可用性和安全性,在选择第一管理节点作为目标管理节点之后,可以为第一管理节点分配虚拟网际协议IP地址(即,为第一管理节点对应的服务器分配虚拟IP地址),从而在第一管理节点的服务器出现故障时,可以由虚拟IP将请求转移到其他服务器上,以实现故障转移,同时,使用虚拟IP可以保护安全访问服务器的真实IP地址,从而提高服务器的安全性。这里,虚拟IP地址可以是外部程序访问目标节点集群的管理节点所使用的IP地址。
步骤S206,在第一管理节点发生故障的情况下,从一组候选管理节点中除了第一管理节点以外的其他候选管理节点中选择第二管理节点作为目标节点集群的管理节点,并为第二管理节点分配虚拟IP地址。
在第一管理节点发生故障的情况下,可以从一组候选管理节点中除了第一管理节点以外的其他候选管理节点中选择第二管理节点作为目标节点集群的管理节点,并为第二管理节点分配虚拟IP地址。
例如,MASTER机器(即,与管理节点对应的服务器)会被分配到一个指定的虚拟ip,外部程序可通过该ip访问这台服务器,如果这台服务器出现故障(断网,重启等),从其他的备份机器(即,服务器)上重选一台机器做MASTER机器,并分配同样的虚拟IP,充当前一台MASTER机器的角色。
由于从在k8s中运行的应用的层面进行的设计就是假设节点是不可靠的,节点越多,发生软、硬件故障,从而导致节点不可用的几率就越高,为了避免在业务服务故障或Node节点故障时,Kubernetes重新调度创建服务的过程中,影响正常服务使用,在本实施例中,可以采用多实例部署原则,即,给服务部署多个副本,根据实际情况调整replicas(副本数量)的值,如果值为1就必然存在单点故障,因此可以按照集群规模、高可用安全级别要求、业务情况等采用不同的多实例的部署方案。此外,如果大于1但所有副本都调度到同一个节点,那还是有单点故障,所以我们不仅要有合理的副本数量,还需要让这些不同副本调度到不同的节点(即,一个服务器上可以部署有多个不同的服务,不同服务器上可以部署有同一服务的副本),打散开来避免单点故障,这个可以利用反亲和性来实现。
通过上述步骤,从目标节点集群中的一组候选管理节点中选择第一管理节点作为目标节点集群的管理节点,其中,目标节点集群的管理节点用于对目标节点集群中的一组工作节点进行控制,一组候选管理节点和一组工作节点均用于运行容器化应用;为第一管理节点分配虚拟网际协议IP地址,其中,虚拟IP地址为外部程序访问目标节点集群的管理节点所使用的IP地址;在第一管理节点发生故障的情况下,从一组候选管理节点中除了第一管理节点以外的其他候选管理节点中选择第二管理节点作为目标节点集群的管理节点,并为第二管理节点分配虚拟IP地址,可以解决相关技术中的集群架构的控制方法存在集群架构的可用性较低的问题,达到提高集群架构的可用性的技术效果。
在一个示范性实施例中,在从目标节点集群中的一组候选管理节点中选择第一管理节点作为目标节点集群的管理节点之后,上述方法还包括:
S11,获取待存储数据,其中,待存储数据为待存储至目标节点集群的管理节点的存储组件的数据;
S12,从一组候选管理节点中选取出至少两个候选管理节点,得到至少两个第三管理节点,并将待存储数据推送给至少两个第三管理节点的存储组件进行保存;或者,
S13,从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将待存储数据推送给第四管理节点的存储组件进行保存,以由第四管理节点的存储组件将待存储数据推送给一组候选管理节点中除了第四管理节点以外的至少部分候选管理节点的存储组件进行保存;
其中,对应的存储组件存储有待存储数据的候选管理节点包括第一管理节点。
考虑到k8s云平台中,为了支撑AI场景下的业务部署与高效运行,集群中的部分关键组件也需要有高可用性,以保证从出生启用和集群准入开始,到每一次变更,到下线整个生命周期控制在系统可承受范围之内。这里,这些关键组件可以是用于存储不同数据的组件,包括但不限于:Harbor(镜像仓库,用于存储AI应用的镜像文件),Mariadb(用于存储AI场景下云平台的元数据,如集群名称、业务名称等),NFS(Network File System,网络文件系统)、Ceph(一种存储系统,与NFS一样,可作为k8s集群中pv对象的存储提供方),ntpd(用于时间同步的组件),Ldap(用于管理用户组、用户信息的组件),hdfs(模型仓库,用于存储AI应用的模型文件(如pytorch、tensorflow模型文件等))。
在本实施例中,目标集群可以实时获取待存储数据。这里,待存储数据可以是待存储至目标节点集群的管理节点的存储组件的数据。
根据不同组件的数据同步方式,对于获取到的待存储数据,可以从一组候选管理节点中选取出至少两个候选管理节点,得到至少两个第三管理节点,并将待存储数据推送给至少两个第三管理节点的存储组件进行保存。
此外,对于获取到的待存储数据,也可以从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将待存储数据推送给第四管理节点的存储组件进行保存,以由第四管理节点的存储组件将待存储数据推送给一组候选管理节点中除了第四管理节点以外的至少部分候选管理节点的存储组件进行保存。
需要说明的是,对应的存储组件存储有待存储数据的候选管理节点可以包括前述第一管理节点,即,选择出的存储有上述待存储数据的存储组件,可以是前述第一管理节点上的存储组件。
通过本实施例,对于获取到的待存储数据,通过选择一个管理节点上的组件进行保存并同步至其他管理节点上的组件的方式,或者直接选择两个管理节点上的同一组件进行数据的同步保存的方式,可以提高集群中组件的可用性,从而提高集群架构的可用性。
在一个示范性实施例中,在选择候选管理节点,以存储获取到的待存储数据的组件的过程中,可以通过负载均衡的方式进行管理节点的选择,也可以随机选择。
S21,从一组候选管理节点中选取出至少两个候选管理节点,得到至少两个第三管理节点,包括:基于负载均衡从一组候选管理节点中选取出至少两个候选管理节点,得到至少两个第三管理节点;或者,
S22,从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,包括:基于负载均衡从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点。
上述负载均衡可以是基于每个候选管理节点对应的服务器的优先级来确定的,也可以是基于每个候选管理节点对应的服务器当前所运行的资源占用率来确定的。如图5所示,负载均衡可以是通过haproxy(一款提供高可用性、负载均衡以及基于TCP(第四层)和HTTP(第七层)应用的代理软件)来实现的。
通过本实施例,通过负载均衡选择先进行待存储数据存储的管理节点的组件,可以提高组件选择的灵活性。
在一个示范性实施例中,从一组候选管理节点中选取出至少两个候选管理节点,得到至少两个第三管理节点,包括:
S31,在待存储数据为待存储至目标节点集群的管理节点的预设存储系统中的待存储资源对象的情况下,从一组候选管理节点中选取出至少两个候选管理节点,得到至少两个第三管理节点。
在待存储数据为待存储至目标节点集群的管理节点的预设存储系统中的待存储资源对象的情况下,可以从一组候选管理节点中选取出至少两个候选管理节点,得到至少两个第三管理节点,并有选择出的至少两个第三管理节点的存储组件对待存储数据进行保存。
上述预设存储系统可以是Ceph。Ceph集群数据副本数量可自行定义并配置,并可以通过Crush算法指定副本的物理存储位置以分割故障域,支持数据强一致性的特性使得Ceph具有了高可靠性,可以本身可忍受多种故障场景并自动尝试并行修复。在本实施例中,对于与Ceph对应的待存储数据,在有3个管理节点对应Ceph集群的情况下,可以选择两个管理节点作为对待存储数据进行保存。
可选地,对于存储系统为NFS的情况,待存储数据也可以是待存储资源对象,但数据保存和同步方式可以与上述Ceph的存储方式不同,可以是从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将待存储资源对象推送给第四管理节点的预设存储系统进行保存,以将待存储资源对象推送给一组候选管理节点中除了第四管理节点以外的至少部分候选管理节点的预设存储系统进行保存。即,由notify(一个Linux特性,用于监控文件系统操作,比如读取、写入和创建)对主机(即,第四管理节点对应的服务器)进行检测,在检测主机的目录中有数据变换后,会自动将变换的目录或者文件使用rsync(数据镜像备份工具)实时同步到备机(即,与一组候选管理节点中除了第四管理节点以外的至少部分候选管理节点的服务器),实现数据的统一,保证数据的完整性。
通过本实施例,根据预设存储系统的特性在不同管理节点的预设存储系统之间,进行相应的数据同步,可以提高预设存储系统的可用性,从而提高集群架构的可用性。
在一个示范性实施例中,从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将待存储数据推送给第四管理节点的存储组件进行保存,包括:
S41,在待存储数据为待存储至目标节点集群的管理节点的镜像仓库的待存储镜像的情况下,从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将待存储镜像推送给第四管理节点的镜像仓库进行保存,其中,待存储镜像被第四管理节点的镜像仓库基于保存的一组候选管理节点中除了第四管理节点以外的所有候选管理节点的镜像仓库的仓库地址,推送给除了第四管理节点以外的所有候选管理节点的镜像仓库进行保存;
S42,在待存储数据为待存储至目标节点集群的管理节点的数据库的待存储元数据的情况下,从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将待存储元数据推送给第四管理节点的数据库进行保存,其中,待存储元数据被第四管理节点的数据库推送给除了第四管理节点以外的所有候选管理节点的数据库进行保存;
S43,在待存储数据为待存储至目标节点集群的管理节点的第二控制组件的待存储对象数据的情况下,从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将待存储对象数据推送给第四管理节点的第二控制组件进行保存,其中,第二控制组件是用于进行对象数据管理的组件,待存储对象数据被第四管理节点的第二控制组件推送给除了第四管理节点以外的一个候选管理节点的第二控制组件进行保存;
S44,在待存储数据为待存储至目标节点集群的管理节点的模型仓库的待存储模型文件的情况下,从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将待存储模型文件推送给第四管理节点的模型仓库进行保存,其中,待存储模型文件被第四管理节点的模型仓库推送给除了第四管理节点以外的一个候选管理节点的模型仓库进行保存。
对于从一组候选管理节点中选取出一个第四管理节点,并将待存储数据推送给第四管理节点的存储组件进行保存的情况,可以分别根据待存储数据的数据类型,进行不同的数据同步操作。此外,考虑到部分类型的数据存在数据脑裂(即,多个副本,同一个文件数据不一样)的可能性,为了在出现管理节点故障时,保证选择的备份管理节点中的数据是完整或准确的,对于与易脑裂的数据对应的组件,可以部署在一组候选管理节点中的每一个候选管理节点上,而对于与不易脑裂的数据对应的组件,可以仅部署在一组候选管理节点中的两个候选管理节点上。
在本实施例中,在待存储数据为待存储至目标节点集群的管理节点的镜像仓库的待存储镜像的情况下,可以从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将待存储镜像推送给第四管理节点的镜像仓库进行保存。再由第四管理节点的镜像仓库基于保存的一组候选管理节点中除了第四管理节点以外的所有候选管理节点的镜像仓库的仓库地址,将待存储镜像推送给除了第四管理节点以外的所有候选管理节点的镜像仓库进行保存。这里,镜像仓库可以部署在每一个候选管理节点上。
例如,以上述镜像仓库为Harbor为例,可以在k8s集群的3台管理节点上分别安装Harbor仓库(共三组,命名为Harbor-1,Harbor-2,Harbor-3),并互相配置同步关系。具体的,在Harbor-1仓库中定义Harbor-2和Harbor-3仓库的目标地址,并创建基于push-based(推送)复制模式、事件驱动触发模式的同步规则。同理,在Harbor-2和Harbor-3仓库中完成类似定义和配置。如此便完成多主复制模式配置,该模式是复用主从同步实现多个Harbor节点之间的双向同步,来保证数据的一致性。然后在多台Harbor前端顶一个负载均衡器将进来的请求分流到不同的实例中去,只要有一个实例中有了新的镜像,就是自动的同步复制到另外的实例中去,这样实现了负载均衡,也避免了单点故障,从而实现了Harbor的高可用性。当有镜像需要推送至Harbor仓库时,haproxy负载均衡从三台管理节点中挑选一台节点完成镜像推送,Harbor仓库的复制模型在三个仓库中完成镜像的同步,即使有1台管理节点甚至两台管理节点发生故障,也不会影响harbor集群的正常运行。
在待存储数据为待存储至目标节点集群的管理节点的数据库的待存储元数据的情况下,可以从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将待存储元数据推送给第四管理节点的数据库进行保存。再由第四管理节点的数据库将待存储元数据推送给除了第四管理节点以外的所有候选管理节点的数据库进行保存。这里,由第四管理节点的数据库将待存储元数据推送给除了第四管理节点以外的所有候选管理节点的数据库进行保存的过程,可以是通过广播实现的。这里,数据库可以部署在每一个候选管理节点上。
例如,以数据库为Mariadb数据库为例,Galera(一种集群)集群是一个针对Mariadb的多主(Multi-Master)高可用方案,该集群具有所有节点可以同时读写数据库、自动成员资格控制(失败节点从群集中删除)、新节点加入数据自动复制真正的并行复制、无延迟复制等特性。集群中每个Mariadb实例都保存数据库的一个完整副本,客户端可用通过任何一个实例读写数据。此外,集群中的每个节点都保存着一份完整的数据副本,数据备份安全性高。其工作原理为:当一个事务在当前写入的节点提交后,将这个事务广播到同集群的其他节点中,其他节点收到写集事务后,对这个事务进行可行性检查,并将事务成功提交的消息返回给客户端。在不同的数据库之间,采用Galera方式进行数据库同步,可以有效避免了单数据故障的问题。
在待存储数据为待存储至目标节点集群的管理节点的第二控制组件的待存储对象数据的情况下,可以从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将待存储对象数据推送给第四管理节点的第二控制组件进行保存。再由第四管理节点的第二控制组件将待存储对象数据推送给除了第四管理节点以外的一个候选管理节点的第二控制组件进行保存。这里,第二控制组件可以是用于进行对象数据管理的组件。对象数据可以包括但不限于用户组、用户信息。这里,第二控制组件可以仅部署在一组候选管理节点中的两个候选管理节点上。
例如,以第二控制组件为Ldap为例,Ldap是轻量目录访问协议,可作为k8s平台中的账号模块,其高可用设计有3种方案实现,一是Mirror模式,二是N-way多主模式。由于Mirror模式是一种active/active的热备模式,具备Master之间数据同步功能,具有更好的故障恢复功能,可以自动完成数据同步、时间同步等功能,同时具有接近于Single Master的性能,本实施例中可以使用Mirror模式(即,两组Ldap组件分别在k8s集群的master1节点和master2节点部署),使用负载均衡分发到Ldap的服务上。此外,需保证:Ldap的两台服务之间需要保持时间同步,节点之间域名可以相互解析。因此,当有新的用户组、用户创建信息需要保存至Ldap时,负载均衡从master1节点和master2节点中挑选一台节点完成数据保存,mirror-mode复制模型在2个Ldap中完成数据的同步,即使有1台管理节点发生故障,也不会影响账号组件的正常运行。
在待存储数据为待存储至目标节点集群的管理节点的模型仓库的待存储模型文件的情况下,可以从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将待存储模型文件推送给第四管理节点的模型仓库进行保存。再由第四管理节点的模型仓库将待存储模型文件推送给除了第四管理节点以外的一个候选管理节点的模型仓库进行保存。这里,模型仓库可以仅部署在一组候选管理节点中的两个候选管理节点上。
例如,以模型仓库为hdfs为例,可在一个集群中配置多个NameNode(元数据节点),分别运行在独立的物理节点上。在任何时间点,只有一个NameNode是处于Active(已激活)状态,其它的是处于Standby(休眠)状态。其中,Active NameNode负责所有的客户端的操作,而Standby NameNode用来同步Active NameNode的状态信息,以提供快速的故障恢复能力。为了保证Active与Standby节点状态同步,即元数据保持一致,需构建一组独立的守护进程用来同步信息与数据。此外,NameNode状态需自动切换,当多个NameNode启动的时候会向状态切换进程中注册一个临时节点,当NameNode down掉(即,节点无法正常工作)的时候,这个临时节点消失,然后会选择另一个节点转为Active,把down掉的节点转为Standby状态。因此,当有模型文件需要推送至hdfs模型仓库时,haproxy负载均衡从master1节点和master2节点中挑选一台节点完成镜像推送,harbor仓库的复制模型在2个模型仓库中完成文件的同步,即使有1台管理节点发生故障,也不会影响AI模型仓库的正常运行。
通过本实施例,根据待存储数据的数据类型,分别进行不同的数据同步操作,可以保证集群中不同节点的同一关键组件上的数据都是相同的,从而提高关键组件的可用性。
在一个示范性实施例中,在从目标节点集群中的一组候选管理节点中选择第一管理节点作为目标节点集群的管理节点之后,上述方法还包括:
S51,通过第一管理节点的第一控制组件将第一管理节点上的增量数据实时同步至除了第一管理节点以外的至少部分候选管理节点,其中,第一控制组件为用于进行数据同步的组件;
S52,通过热备份软件监控第一管理节点的网络文件系统NFS进程;
S53,在第一管理节点的NFS进程启动异常的情况下,确定第一管理节点发生故障。
从目标节点集群中的一组候选管理节点中选择第一管理节点作为目标节点集群的管理节点之后,可以通过第一管理节点的第一控制组件将第一管理节点上的增量数据实时同步至除了第一管理节点以外的至少部分候选管理节点。这里,第一控制组件可以是用于进行数据同步的组件,可以是k8s集群中的etcd(k8s集群中核心组件)组件。
对于NFS组件,可以通过热备份软件监控第一管理节点的网络文件系统NFS进程。在第一管理节点的NFS进程启动异常的情况下,可以确定第一管理节点发生故障。
上述热备份软件可以是keepalived(一种高性能的服务器高可用或热备解决方案),如图6所示,可以用来防止服务器单点故障导致服务中断的问题。keepalived使用主备模式,至少需要两台服务器才能正常工作。比如keepalived将三台服务器搭建成一个集群,对外提供一个唯一IP,正常情况下只有一台服务器上可以看到这个IP的虚拟网卡。如果这台服务异常,那么keepalived会立即将IP移动到剩下的两台服务器中的一台上,使得IP可以正常使用。
在本实施例中,可以由keepalived监控NFS进程,master的NFS主进程宕掉无法启动时,虚拟IP地址从管理节点漂移到slave节点(从节点,可以是本实施例中的其他管理节点),由slave节点的NFS接管继续工作。
可选地,在前述实施例中第一管理节点的其他组件出现异常的情况下,也可以确定第一管理节点发生故障。
通过本实施例,通过第一控制组件实现增量数据的同步,可以提高集群的可用性,而通过热备份软件监控NFS进程,可以避免NFS进程出现异常导致的服务器的短暂停用。
在一个示范性实施例中,上述方法还包括:
S61,从目标节点集群中的一组候选管理节点中选择第一管理节点作为目标节点集群的管理节点,包括:由热备份软件从一组候选管理节点选取第一管理节点作为目标节点集群的管理节点,其中,第一管理节点为一组候选管理节点中,节点权重最高的候选管理节点,一组工作节点对目标节点集群的管理节点的应用程序接口API请求通过应用程序代理软件指向虚拟IP地址分配给的第一管理节点,应用程序代理软件为用于进行负载均衡的代理软件;
S62,在第一管理节点发生故障的情况下,从一组候选管理节点中除了第一管理节点以外的其他候选管理节点中选择第二管理节点作为目标节点集群的管理节点,包括:在第一管理节点发生故障的情况下,由热备份软件从一组候选管理节点中除了第一管理节点以外的其他候选管理节点中选择第二管理节点作为目标节点集群的管理节点,其中,第二管理节点为其他候选管理节点中权重最高的候选管理节点,一组工作节点对目标节点集群的管理节点的API请求通过应用程序代理软件指向虚拟IP地址分配给的第二管理节点。
在本实施例中,可以采用热备份软件和应用程序代理软件实现对目标集群的高可用,即,通过热备份软件对外提供稳定的入口,使用应用程序代理软件对内均衡负载。运行原理可以是,由热备份软件从一组候选管理节点选取第一管理节点作为目标节点集群的管理节点。一组工作节点对目标节点集群的管理节点的应用程序接口API请求可以通过应用程序代理软件指向虚拟IP地址分配给的第一管理节点。应用程序代理软件可以用于进行负载均衡的代理软件。
上述热备份软件可以是前述keepalived,上述应用程序代理软件可以是haproxy是一款提供高可用性、负载均衡以及基于TCP(第四层)和HTTP(第七层)应用的代理软件,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。使用haproxy负载均衡后端服务,达到服务高可用的目的。
考虑到haproxy运行在k8s-管理节点上,当管理节点异常后,haproxy服务也会停止,为了避免这种情况,可以在每一台管理节点都部署haproxy服务,达到haproxy服务高可用的目的。
在第一管理节点发生故障的情况下,可以由热备份软件从一组候选管理节点中除了第一管理节点以外的其他候选管理节点中选择第二管理节点作为目标节点集群的管理节点。这里,第二管理节点可以是其他候选管理节点中权重最高的候选管理节点。一组工作节点可以对目标节点集群的管理节点的API请求通过应用程序代理软件指向虚拟IP地址分配给的第二管理节点。
例如,所有工作节点对master的api请求通过负载均衡(haproxy)指向虚拟IP(keepalived),而此虚拟P由所有master节点通过优先级选举,keepalived通过优先级(即,服务器设置的权重)挑选出一台热备服务器做MASTER机器,MASTER机器会被分配到一个指定的虚拟IP,外部程序可通过该虚拟IP访问这台服务器,如果这台服务器出现故障(断网,重启,或者本机器上的keepalivedcrash等),keepalived会从其他的备份机器上重选(还是看服务器设置的权重)一台机器做MASTER并分配同样的虚拟IP,充当前一台MASTER的角色。
通过本实施例,通过热备份软件和应用程序代理软件管理目标集群中的管理节点的使用,可以提高选取候选管理节点的效率。
下面结合可选示例对本申请实施例中的集群架构的控制方法进行解释说明。
本可选示例中提供了一种k8s集群的高可用架构方案,包含Cluster高可用设计方案和关键组件高可用设计方案,涵盖集群高可用设计方案和全组件高可用设计方案,保证容错、服务可用和数据安全等方面的需求。其中,集群高可用设计方案主要是从性能优化和架构升级的角度来提升整个集群支撑的业务类型和业务量。全组件高可用设计方案主要从规范的角度在组件的整个生命周期去落地,从出生启用和集群准入开始,到每一次变更,到下线整个生命周期控制在系统可承受范围之内。
本可选示例中的集群架构的控制方法的流程可以如图7所示,可以包括以下步骤:
步骤S702,keepalived通过优先级选举挑选出一台热备服务器做MASTER机器。
步骤S704,MASTER机器会被分配到一个指定的虚拟IP。
步骤S706,若选择的MASTER机器出现故障(断网,重启,或者本机器上的keepalivedcrash等),由keepalived从其他的备份机器上重选一台机器做MASTER。
通过本可选示例,从性能优化和架构升级的角度提升整个集群支撑的业务类型和业务量,从规范的角度在组件的整个生命周期去落地,提高了集群及集群架构中各关键的可用性。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请并不受所描述的动作顺序的限制,因为依据本申请,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本申请所必须的。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,或者网络设备等)执行本申请各个实施例的方法。
根据本申请实施例的又一方面,还提供了一种集群架构的控制装置,该装置用于实现上述实施例中所提供的集群架构的控制方法,已经进行过说明的不再赘述。如以下所使用的,术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现,但是硬件,或者软件和硬件的组合的实现也是可能并被构想的。
图8是根据本申请实施例的一种集群架构的控制装置的结构框图,如图8所示,该装置包括:
选择单元802,用于从目标节点集群中的一组候选管理节点中选择第一管理节点作为目标节点集群的管理节点,其中,目标节点集群的管理节点用于对目标节点集群中的一组工作节点进行控制,一组候选管理节点和一组工作节点均用于运行容器化应用;
分配单元804,用于为第一管理节点分配虚拟网际协议IP地址,其中,虚拟IP地址为外部程序访问目标节点集群的管理节点所使用的IP地址;
第一执行单元806,用于在第一管理节点发生故障的情况下,从一组候选管理节点中除了第一管理节点以外的其他候选管理节点中选择第二管理节点作为目标节点集群的管理节点,并为第二管理节点分配虚拟IP地址。
通过本申请实施例,从目标节点集群中的一组候选管理节点中选择第一管理节点作为目标节点集群的管理节点,其中,目标节点集群的管理节点用于对目标节点集群中的一组工作节点进行控制,一组候选管理节点和一组工作节点均用于运行容器化应用;为第一管理节点分配虚拟网际协议IP地址,其中,虚拟IP地址为外部程序访问目标节点集群的管理节点所使用的IP地址;在第一管理节点发生故障的情况下,从一组候选管理节点中除了第一管理节点以外的其他候选管理节点中选择第二管理节点作为目标节点集群的管理节点,并为第二管理节点分配虚拟IP地址,可以解决相关技术中的集群架构的控制方法存在集群架构的可用性较低的问题,提高了集群架构的可用性。
可选地,上述装置还包括:
获取单元,用于在从目标节点集群中的一组候选管理节点中选择第一管理节点作为目标节点集群的管理节点之后,获取待存储数据,其中,待存储数据为待存储至目标节点集群的管理节点的存储组件的数据;
第二执行单元,用于从一组候选管理节点中选取出至少两个候选管理节点,得到至少两个第三管理节点,并将待存储数据推送给至少两个第三管理节点的存储组件进行保存;或者,
第三执行单元,用于从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将待存储数据推送给第四管理节点的存储组件进行保存,以由第四管理节点的存储组件将待存储数据推送给一组候选管理节点中除了第四管理节点以外的至少部分候选管理节点的存储组件进行保存;
其中,对应的存储组件存储有待存储数据的候选管理节点包括第一管理节点。
可选地,第二执行单元包括:第一选取模块,用于基于负载均衡从一组候选管理节点中选取出至少两个候选管理节点,得到至少两个第三管理节点;或者,
第三执行单元包括:第二选取模块,用于基于负载均衡从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点。
可选地,第二执行单元包括:
第三选取模块,用于在待存储数据为待存储至目标节点集群的管理节点的预设存储系统中的待存储资源对象的情况下,从一组候选管理节点中选取出至少两个候选管理节点,得到至少两个第三管理节点。
可选地,第三执行单元包括:
第一执行模块,用于在待存储数据为待存储至目标节点集群的管理节点的镜像仓库的待存储镜像的情况下,从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将待存储镜像推送给第四管理节点的镜像仓库进行保存,其中,待存储镜像被第四管理节点的镜像仓库基于保存的一组候选管理节点中除了第四管理节点以外的所有候选管理节点的镜像仓库的仓库地址,推送给除了第四管理节点以外的所有候选管理节点的镜像仓库进行保存;
第二执行模块,用于在待存储数据为待存储至目标节点集群的管理节点的数据库的待存储元数据的情况下,从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将待存储元数据推送给第四管理节点的数据库进行保存,其中,待存储元数据被第四管理节点的数据库推送给除了第四管理节点以外的所有候选管理节点的数据库进行保存;
第三执行模块,用于在待存储数据为待存储至目标节点集群的管理节点的第二控制组件的待存储对象数据的情况下,从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将待存储对象数据推送给第四管理节点的第二控制组件进行保存,其中,第二控制组件是用于进行对象数据管理的组件,待存储对象数据被第四管理节点的第二控制组件推送给除了第四管理节点以外的一个候选管理节点的第二控制组件进行保存;
第四执行模块,用于在待存储数据为待存储至目标节点集群的管理节点的模型仓库的待存储模型文件的情况下,从一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将待存储模型文件推送给第四管理节点的模型仓库进行保存,其中,待存储模型文件被第四管理节点的模型仓库推送给除了第四管理节点以外的一个候选管理节点的模型仓库进行保存。
可选地,上述装置还包括:
同步单元,用于在从目标节点集群中的一组候选管理节点中选择第一管理节点作为目标节点集群的管理节点之后,通过第一管理节点的第一控制组件将第一管理节点上的增量数据实时同步至除了第一管理节点以外的至少部分候选管理节点,其中,第一控制组件为用于进行数据同步的组件;
监控单元,用于通过热备份软件监控第一管理节点的网络文件系统NFS进程;
确定单元,用于在第一管理节点的NFS进程启动异常的情况下,确定第一管理节点发生故障。
可选地,选择单元包括:第四选取模块,用于由热备份软件从一组候选管理节点选取第一管理节点作为目标节点集群的管理节点,其中,第一管理节点为一组候选管理节点中,节点权重最高的候选管理节点,一组工作节点对目标节点集群的管理节点的应用程序接口API请求通过应用程序代理软件指向虚拟IP地址分配给的第一管理节点,应用程序代理软件为用于进行负载均衡的代理软件;
第一执行单元包括:第五选取模块,用于在第一管理节点发生故障的情况下,由热备份软件从一组候选管理节点中除了第一管理节点以外的其他候选管理节点中选择第二管理节点作为目标节点集群的管理节点,其中,第二管理节点为其他候选管理节点中权重最高的候选管理节点,一组工作节点对目标节点集群的管理节点的API请求通过应用程序代理软件指向虚拟IP地址分配给的第二管理节点。
需要说明的是,上述各个模块是可以通过软件或硬件来实现的,对于后者,可以通过以下方式实现,但不限于此:上述模块均位于同一处理器中;或者,上述各个模块以任意组合的形式分别位于不同的处理器中。
根据本申请实施例的又一方面,还提供了一种计算机可读存储介质,该计算机可读存储介质中存储有计算机程序,其中,该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
在一个示例性实施例中,上述计算机可读存储介质可以包括但不限于:U盘、只读存储器(Read-Only Memory,简称为ROM)、随机存取存储器(Random Access Memory,简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。
根据本申请实施例的又一方面,还提供了一种电子设备,包括存储器和处理器,该存储器中存储有计算机程序,该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。
在一个示例性实施例中,上述电子设备还可以包括传输设备以及输入输出设备,其中,该传输设备和上述处理器连接,该输入输出设备和上述处理器连接。
本实施例中的具体示例可以参考上述实施例及示例性实施方式中所描述的示例,本实施例在此不再赘述。
显然,本领域的技术人员应该明白,上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本申请实施例不限制于任何特定的硬件和软件结合。
以上所述仅为本申请的优选实施例而已,并不用于限制本申请实施例,对于本领域的技术人员来说,本申请实施例可以有各种更改和变化。凡在本申请实施例的原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请实施例的保护范围之内。
Claims (10)
1.一种集群架构的控制方法,其特征在于,包括:
从目标节点集群中的一组候选管理节点中选择第一管理节点作为所述目标节点集群的管理节点,其中,所述目标节点集群的管理节点用于对所述目标节点集群中的一组工作节点进行控制,所述一组候选管理节点和所述一组工作节点均用于运行容器化应用;
为所述第一管理节点分配虚拟网际协议IP地址,其中,所述虚拟IP地址为外部程序访问所述目标节点集群的管理节点所使用的IP地址;
在所述第一管理节点发生故障的情况下,从所述一组候选管理节点中除了所述第一管理节点以外的其他候选管理节点中选择第二管理节点作为所述目标节点集群的管理节点,并为所述第二管理节点分配所述虚拟IP地址。
2.根据权利要求1所述的方法,其特征在于,在所述从目标节点集群中的一组候选管理节点中选择第一管理节点作为所述目标节点集群的管理节点之后,所述方法还包括:
获取待存储数据,其中,所述待存储数据为待存储至所述目标节点集群的管理节点的存储组件的数据;
从所述一组候选管理节点中选取出至少两个候选管理节点,得到至少两个第三管理节点,并将所述待存储数据推送给所述至少两个第三管理节点的存储组件进行保存;或者,
从所述一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将所述待存储数据推送给所述第四管理节点的存储组件进行保存,以由所述第四管理节点的存储组件将所述待存储数据推送给所述一组候选管理节点中除了所述第四管理节点以外的至少部分候选管理节点的存储组件进行保存;
其中,对应的存储组件存储有所述待存储数据的候选管理节点包括所述第一管理节点。
3.根据权利要求2所述的方法,其特征在于,
所述从所述一组候选管理节点中选取出至少两个候选管理节点,得到至少两个第三管理节点,包括:基于负载均衡从所述一组候选管理节点中选取出至少两个候选管理节点,得到所述至少两个第三管理节点;或者,
所述从所述一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,包括:基于负载均衡从所述一组候选管理节点中选取出一个候选管理节点,得到所述第四管理节点。
4.根据权利要求2所述的方法,其特征在于,所述从所述一组候选管理节点中选取出至少两个候选管理节点,得到至少两个第三管理节点,包括:
在所述待存储数据为待存储至所述目标节点集群的管理节点的预设存储系统中的待存储资源对象的情况下,从所述一组候选管理节点中选取出至少两个候选管理节点,得到所述至少两个第三管理节点。
5.根据权利要求2所述的方法,其特征在于,所述从所述一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将所述待存储数据推送给所述第四管理节点的存储组件进行保存,包括:
在所述待存储数据为待存储至所述目标节点集群的管理节点的镜像仓库的待存储镜像的情况下,从所述一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将所述待存储镜像推送给所述第四管理节点的镜像仓库进行保存,其中,所述待存储镜像被所述第四管理节点的镜像仓库基于保存的所述一组候选管理节点中除了所述第四管理节点以外的所有候选管理节点的镜像仓库的仓库地址,推送给除了所述第四管理节点以外的所有候选管理节点的镜像仓库进行保存;
在所述待存储数据为待存储至所述目标节点集群的管理节点的数据库的待存储元数据的情况下,从所述一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将所述待存储元数据推送给所述第四管理节点的数据库进行保存,其中,所述待存储元数据被所述第四管理节点的数据库推送给除了所述第四管理节点以外的所有候选管理节点的数据库进行保存;
在所述待存储数据为待存储至所述目标节点集群的管理节点的第二控制组件的待存储对象数据的情况下,从所述一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将所述待存储对象数据推送给所述第四管理节点的第二控制组件进行保存,其中,所述第二控制组件是用于进行对象数据管理的组件,所述待存储对象数据被所述第四管理节点的第二控制组件推送给除了所述第四管理节点以外的一个候选管理节点的第二控制组件进行保存;
在所述待存储数据为待存储至所述目标节点集群的管理节点的模型仓库的待存储模型文件的情况下,从所述一组候选管理节点中选取出一个候选管理节点,得到第四管理节点,并将所述待存储模型文件推送给所述第四管理节点的模型仓库进行保存,其中,所述待存储模型文件被所述第四管理节点的模型仓库推送给除了所述第四管理节点以外的一个候选管理节点的模型仓库进行保存。
6.根据权利要求1所述的方法,其特征在于,在所述从目标节点集群中的一组候选管理节点中选择第一管理节点作为所述目标节点集群的管理节点之后,所述方法还包括:
通过所述第一管理节点的第一控制组件将所述第一管理节点上的增量数据实时同步至除了所述第一管理节点以外的至少部分候选管理节点,其中,所述第一控制组件为用于进行数据同步的组件;
通过热备份软件监控所述第一管理节点的网络文件系统NFS进程;
在所述第一管理节点的NFS进程启动异常的情况下,确定所述第一管理节点发生故障。
7.根据权利要求1至6中任一项所述的方法,其特征在于,
所述从目标节点集群中的一组候选管理节点中选择第一管理节点作为所述目标节点集群的管理节点,包括:由热备份软件从所述一组候选管理节点选取所述第一管理节点作为所述目标节点集群的管理节点,其中,所述第一管理节点为所述一组候选管理节点中,节点权重最高的候选管理节点,所述一组工作节点对所述目标节点集群的管理节点的应用程序接口API请求通过应用程序代理软件指向所述虚拟IP地址分配给的所述第一管理节点,所述应用程序代理软件为用于进行负载均衡的代理软件;
所述在所述第一管理节点发生故障的情况下,从所述一组候选管理节点中除了所述第一管理节点以外的其他候选管理节点中选择第二管理节点作为所述目标节点集群的管理节点,包括:在所述第一管理节点发生故障的情况下,由所述热备份软件从所述一组候选管理节点中除了所述第一管理节点以外的所述其他候选管理节点中选择所述第二管理节点作为所述目标节点集群的管理节点,其中,所述第二管理节点为所述其他候选管理节点中权重最高的候选管理节点,所述一组工作节点对所述目标节点集群的管理节点的API请求通过所述应用程序代理软件指向所述虚拟IP地址分配给的所述第二管理节点。
8.一种集群架构的控制装置,其特征在于,包括:
选择单元,用于从目标节点集群中的一组候选管理节点中选择第一管理节点作为所述目标节点集群的管理节点,其中,所述目标节点集群的管理节点用于对所述目标节点集群中的一组工作节点进行控制,所述一组候选管理节点和所述一组工作节点均用于运行容器化应用;
分配单元,用于为所述第一管理节点分配虚拟网际协议IP地址,其中,所述虚拟IP地址为外部程序访问所述目标节点集群的管理节点所使用的IP地址;
第一执行单元,用于在所述第一管理节点发生故障的情况下,从所述一组候选管理节点中除了所述第一管理节点以外的其他候选管理节点中选择第二管理节点作为所述目标节点集群的管理节点,并为所述第二管理节点分配所述虚拟IP地址。
9.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有计算机程序,其中,所述计算机程序被处理器执行时实现所述权利要求1至7任一项中所述的方法的步骤。
10.一种电子设备,包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序,其特征在于,所述处理器执行所述计算机程序时实现所述权利要求1至7任一项中所述的方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310786505.4A CN116684261A (zh) | 2023-06-29 | 2023-06-29 | 集群架构的控制方法及装置、存储介质及电子设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310786505.4A CN116684261A (zh) | 2023-06-29 | 2023-06-29 | 集群架构的控制方法及装置、存储介质及电子设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116684261A true CN116684261A (zh) | 2023-09-01 |
Family
ID=87783782
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202310786505.4A Pending CN116684261A (zh) | 2023-06-29 | 2023-06-29 | 集群架构的控制方法及装置、存储介质及电子设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116684261A (zh) |
-
2023
- 2023-06-29 CN CN202310786505.4A patent/CN116684261A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9460183B2 (en) | Split brain resistant failover in high availability clusters | |
US9176823B2 (en) | Data transfer and recovery process | |
CN102404390B (zh) | 高速实时数据库的智能化动态负载均衡方法 | |
AU2006297144B2 (en) | Application of virtual servers to high availability and disaster recovery solutions | |
US10019324B2 (en) | Data transfer and recovery | |
US20120311376A1 (en) | Recovery service location for a service | |
CN101136728A (zh) | 群集系统和用于备份群集系统中的副本的方法 | |
CN103562904A (zh) | 在服务的次要位置重放作业 | |
US20220318104A1 (en) | Methods and systems for a non-disruptive automatic unplanned failover from a primary copy of data at a primary storage system to a mirror copy of the data at a cross-site secondary storage system | |
CN110557413A (zh) | 一种业务服务系统及提供业务服务的方法 | |
CN104660386A (zh) | 一种基于安腾平台下提高db2容灾高可用性的方法 | |
CN105323271B (zh) | 一种云计算系统以及云计算系统的处理方法和装置 | |
US20230004465A1 (en) | Distributed database system and data disaster backup drilling method | |
US7519857B2 (en) | Method, apparatus, and system for a software based business continuity solution for a computing environment | |
US10664190B1 (en) | Geographically dispersed data protection and replication | |
CN116389233A (zh) | 容器云管理平台主备切换系统、方法、装置和计算机设备 | |
CN116684261A (zh) | 集群架构的控制方法及装置、存储介质及电子设备 | |
US20220342775A1 (en) | Storage system, storage node virtual machine restore method, and recording medium | |
JP2008276281A (ja) | データ同期システム、方法、及び、プログラム | |
Wibowo et al. | Building scalable and resilient database system to mitigate disaster and performance risks | |
Solissa et al. | Hadoop high availability with Linux HA | |
US20220229741A1 (en) | Protecting databases in a clusterless availability group | |
CN117692500A (zh) | 运行方法、装置、设备以及存储介质 | |
CN117082069A (zh) | 一种混合云多活容灾系统 | |
CN116775219A (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 |