CN112948128A - Target端的选择方法、系统及计算机可读介质 - Google Patents
Target端的选择方法、系统及计算机可读介质 Download PDFInfo
- Publication number
- CN112948128A CN112948128A CN202110338565.0A CN202110338565A CN112948128A CN 112948128 A CN112948128 A CN 112948128A CN 202110338565 A CN202110338565 A CN 202110338565A CN 112948128 A CN112948128 A CN 112948128A
- Authority
- CN
- China
- Prior art keywords
- node
- client
- target
- zookeeper
- nodes
- 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
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/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5083—Techniques for rebalancing the load in a distributed system
-
- 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/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
Abstract
本发明涉及计算机技术领域并提供了Target端的选择方法、分布式集群系统及计算机可读介质,该Target端的选择方法用以对分布式集群系统中节点自客户端发起访问请求予以响应的节点中的运行Target进程的Target端予以选择;选择方法包括监控节点的使用状态并保存,接收自客户端的Initiator进程下发的配置策略,调用节点的使用状态并根据节点选择策略确定匹配与自客户端发起访问请求相适应的Target端。本发明能够在分布式集群系统中各个节点与客户端之间断开时,从分布式集群系统中自动选取可用的Target端,避免了在选取可用的Target端后对整个分布式集群系统各个节点间资源配置不均衡的问题。
Description
技术领域
本发明涉及计算机技术领域,尤其涉及一种Target端的选择方法、分布式集群系统及计算机可读介质。
背景技术
iSCSI(Internet Small Computer System Interface)协议是一种协议族,指小型计算机系统接口,属于iSCSI协议族中的传输层协议,在iSCST协议基础上增加一层封装,将iSCSI命令与协议数据单元(Protoclo Data Unit,PDU)中,通过TCP/IP网络,使得Initiator端与Target端进行通信。启动器(Initiator端)是与支持iSCSI协议的存储设备连接的应用客户端。Target端是iSCSI的存储设备,其包括设备服务器和队列管理,如iSCSI磁盘阵列柜、iSCSI磁带柜等。
Initiator端部署于客户端(Client),响应Initiator端的Target端部署于组成分布式存储系统的各个节点(Node)中。Initiator端通过VIP(虚拟IP地址)访问分布式存储系统的各个节点,并与某个节点建立连接后通过该节点进行数据读写操作。然而,当分布式存储系统中各个及节点与客户端之间发生网络故障或者存储故障(例如某个节点不可用或者被人为移除)时,Target端会中断与分布式存储系统的连接,并由此导致Target端发生重定向(Redirect)的事件。在发生重定向的事件后,在现有技术中通常依靠后台管理人员以人工手动方式选择新的用以响应客户端请求的Target端,因此现有技术存在发生前述故障时不可自动选择Target端的技术缺陷。
同时,如果基于人工方式予以重新选择Target端的话,会导致整个分布式存储系统中各个节点的权重与负载发生不均衡,甚至出现重定向所选定的Target端所属节点不符合用户所发起的访问请求的情形。
有鉴于此,有必要对现有技术中的分布式存储系统中各个及节点与客户端之间发生网络故障或者存储故障时如何选择Target端的选择方法予以改进,以解决上述问题。
发明内容
本发明的目的在于揭示一种Target端的选择方法、分布式集群系统及计算机可读介质,用以解决现有技术中分布式集群系统所存在的上述技术问题,尤其是为了在分布式集群系统中各个节点与客户端之间断开时,从分布式集群系统中自动选取可用的Target端,避免在选取可用的Target端后对整个分布式集群系统各个节点间资源配置不均衡的问题,并避免采用人工选择Target端所可能发生的错误。
为实现上述第一个发明目的,本发明提供了一种Target端的选择方法,用以对分布式集群系统中节点自客户端发起访问请求予以响应的节点中的运行Target进程的Target端予以选择;
所述选择方法包括:
监控节点的使用状态并保存,接收自客户端的Initiator进程下发的配置策略,调用节点的使用状态并根据节点选择策略确定匹配与自客户端发起访问请求相适应的Target端;其中,所述配置策略至少由节点权重、剩余可用资源率及Target连接数的一种或者几种共同定义。
作为本发明的进一步改进,所述调用节点的使用状态并根据节点选择策略确定匹配与自客户端发起访问请求相适应的Target端的操作由独立部署于每个节点的Target端中的Target选择进程独立执行。
作为本发明的进一步改进,所述节点的使用状态保存至Zookeeper服务端,分布式集群系统中的Zookeeper客户端被Zookeeper服务端纳管,所述Zookeeper客户端接收并存储配置策略至Zookeeper服务端,并在所述Zookeeper客户端与Zookeeper服务端之间建立长连接,并在Target进程与Zookeeper服务端之间建立长连接。
作为本发明的进一步改进,由Zookeeper客户端在Zookeeper服务端中建立包含节点名称的持久节点及临时节点,若当前状态的主节点发生故障时,由分布式集群系统中剩余节点的VIP进程通过判断临时节点是否存在,以将临时节点加入待选择队列。
作为本发明的进一步改进,所述剩余可用资源率中的资源至少由节点在当前状态中的内存资源和/或存储资源定义;
所述节点选择策略至少由Initiator进程与Target端所形成的部署层级及各个节点在分布式集群系统中的权重予以单独或者共同定义。
作为本发明的进一步改进,所述选择方法还包括:
定期监测设定时间段内节点的负载并将负载监测结果保存至Zookeeper服务端,将脱离连接分布式集群系统的节点标记为异常节点,Initiator进程监测到异常节点后触发恢复机制;所述恢复机制具体为:根据设定时间间隔轮询确定每个节点的节点权重、剩余可用资源率及Target连接数,对配置策略进行更新,并将更新后的配置策略写入Zookeeper服务端,以对Zookeeper服务端中的配置策略予以更新。
作为本发明的进一步改进,所述部署层级根据Initiator进程与响应Initiator进程的Target端之间所形成的拓扑关系,以确定彼此所形成的部署层级,所述Initiator进程运行于客户端的Initiator端,
作为本发明的进一步改进,所述选择方法还包括:
遍历待选择队列,在剔除持久节点后更新所述待选择队列;
将待选择队列中Target端所在节点的权重从高至低排序并更新至待选择队列中;
从待选择队列中剔除剩余内存小于第一设定阈值的节点;
从待选择队列中剔除连接数大于第二设定阈值的节点;
输出待选择队列中位于对队首的Target端所在的节点,以将队首的Target端所在的节点中的Target端响应自客户端发起访问请求;
其中,所述第一设定阈值为节点所具有内存的25%,所述第二设定阈值为节点所形成的连接数为10。
基于相同发明思想,本发明还提供了一种分布式集群系统,包括:
多个节点,由部署于每个节点中的分布式存储节点所组成的分布式存储系统,每个节点中部署运行Target进程的Target端、负载检测单元、Zookeeper客户端及Zookeeper服务端;
所述Target端部署运行Target选择进程的Target端选择模块,用以对分布式集群系统中节点自客户端发起访问请求予以响应的节点中的Target端予以选择;
负载检测单元监控节点的使用状态并保存;
Zookeeper客户端接收自客户端中运行Initiator进程的Initiator端下发的配置策略,调用节点的使用状态并由Target端选择模块根据节点选择策略确定匹配与自客户端发起访问请求相适应的Target端;其中,所述配置策略至少由节点权重、剩余可用资源率及Target连接数的一种或者几种共同定义。
作为本发明的进一步改进,所述节点的使用状态保存至Zookeeper服务端,分布式集群系统中的Zookeeper客户端被Zookeeper服务端纳管,所述Zookeeper客户端接收并存储配置策略;所述Target端、负载检测单元及分布式存储节点均分别通过Zookeeper客户端与Zookeeper服务端建立长连接。
最后,基于相同发明思想,本发明还提供了一种计算机可读介质,所述计算机可读介质中存储有计算机程序指令,所述计算机程序指令被一处理器读取并运行时,执行如上述任一项发明创造所述的Target端的选择方法中的步骤。
与现有技术相比,本发明的有益效果是:
通过本发明所揭示的一种Target端的选择方法、分布式集群系统及计算机可读介质,通过调用节点的使用状态并根据节点选择策略确定匹配与自客户端发起访问请求相适应的Target端,从而能够在分布式集群系统中各个节点与客户端之间断开时,从分布式集群系统中自动选取可用的Target端,从而避免了在选取可用的Target端后对整个分布式集群系统各个节点间资源配置不均衡的问题,并避免了采用人工选择Target端所可能发生的错误。
附图说明
图1为本发明一种Target端的选择方法的整体流程示意图;
图2为采用图1中的一种Target端的选择方法对分布式集群系统中的各个节点执行权重设置的示意图;
图3为对分布式集群系统中的Target端所在节点根据不同部署层级设置不同节点权重的示意图;
图4为对分布式集群系统中各个节点以循环方式进行负载检测的详细流程图;
图5为部署于每个节点的Target端中的Target端选择模块从分布式集群系统中自动选取可用的Target端的详细流程图;
图6为Target端选择策略进一步优选的实例图;
图7为分布式集群系统中的节点1宕机离线后通过本发明一种Target端选择方法重定向至节点2,并最终选定节点2作为响应客户端发起访问请求的示意图;
图8为本发明一种计算机可读介质的拓扑图。
具体实施方式
下面结合附图所示的各实施方式对本发明进行详细说明,但应当说明的是,这些实施方式并非对本发明的限制,本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代,均属于本发明的保护范围之内。
实施例一:
参图1至图7所揭示的本发明一种Target端的选择方法的一种具体实施方式。本实施例所揭示的Target端的选择方法(以下简称“选择方法”)旨在从分布式集群系统中选择出最合适的Target端及部署该Target端所在的节点。
分布式集群系统中各个节点与客户端100之间断开时并导致当前节点中的Target端不可用的原因包括网络故障或者存储故障或者当前节点的剩余内存不足等诸多原因,并最终从分布式集群系统中选取最合适的节点,以在选取的最合适的节点所配置的Target端与客户端100中的Initiator端20建立数据链路,Initiator端通过VIP(虚拟IP地址)访问分布式集群系统的各个节点,从分布式集群系统中自动选取可用的Target端,并与某个节点建立连接后通过该节点进行数据读写操作。在本申请各个实施例中,构成分布式集群系统单的各个节点中部署的Target端即iSCSI Target端,并iSCSI命令通过TCP/IP网络,使得Initiator端20与Target端14(或者图7所示出的节点2中的Target端24或者节点3中的Target端34)进行通信。
结合图2与图7所示,申请人以节点1发生宕机或者网络故障等原因无法响应逻辑上位于客户端100发起的访问请求,从而在Initiator端20与节点1的Target端14中断连接,并根据节点选择策略确定匹配与自客户端100发起访问请求相适应的Target端(即节点2的Target端24)为范例予以示范性说明。客户端100中的Initiator端20断开与节点1的Target端14的连接,并转由与节点2的Target端建立连接的过程称之为“重定向”。所有节点及Zookeeper服务端30逻辑上位于服务端400。在实施例中,服务端400可被理解为运行分布式存储系统40及Zookeeper服务端30的服务器或者数据中心。客户端100逻辑上独立于服务端400,并可被理解为供用户发起访问请求并可视化显示服务端400反馈结果的一种物理态/虚拟态的计算机装置。
同时,基于iSCSI协议的分布式集群系统中,每个节点均提供一个VIP(虚拟IP),VIP可以在所在节点宕机后将VIP漂移到其他正常节点并继续向客户端100提供响应服务。
参图1所示,该选择方法用以对分布式集群系统中节点自客户端100发起访问请求予以响应的节点中的运行Target进程的Target端予以选择。选择方法包括步骤S1~步骤S2。
步骤S1、监控节点的使用状态并保存,接收自客户端的Initiator进程下发的配置策略。
节点的使用状态保存至Zookeeper服务端30,分布式集群系统中的Zookeeper客户端12,22,32均被Zookeeper服务端30纳管,所述Zookeeper客户端12,22,32接收并存储配置策略至Zookeeper服务端30,并在Zookeeper客户端12,22,32与Zookeeper服务端30之间建立长连接,并在Target进程与Zookeeper服务端30之间建立长连接。配置策略由用户在客户端100以手动或者自动方式向Zookeeper客户端12下发权重配置参数。具体的,节点1中部署Target端14,用以检测节点的使用状态的负载检测单元13,Zookeeper客户端12及分布式存储节点11;同理所示,节点2也部署Target端14,负载检测单元23,Zookeeper客户端22及分布式存储节点21,节点3也部署Target端34,负载检测单元33,Zookeeper客户端32及分布式存储节点31。全部节点的所有分布式存储节点11,21,31共同组成分布式存储系统40。
以节点1为范例予以详述,其他节点相同。节点1中负载检测单元13包含一个对其所部署节点(即节点1)负载状态进行监测并将监测结果通过Zookeeper客户端12最终发送至Zookeeper服务端30的监测进程。该监测进程可按照用户自行设定的时间间隔对节点1进行监测。监测内容包括节点1的剩余内存,Target端14的连接数,磁盘剩余空间,VIP进程,磁盘IO及文件系统等进行监测,以实时反映出该节点1所具有的当前状态是否满足用户发起的访问请求。图6所示出的Target端选择策略142中VIP进程监测策略1421,磁盘IO监测策略1422,文件系统监测策略1423,剩余磁盘容量监测策略1424,剩余内存监测策略1425及连接数监测策略1426分别对应前述负载检测单元13对其所属节点进行监测的监测对象,且默认的监测间隔时间为10分钟。前述六个策略(即VIP进程监测策略1421,磁盘IO监测策略1422,文件系统监测策略1423,剩余磁盘容量监测策略1424,剩余内存监测策略1425及连接数监测策略1426)所得到的监测结果均可独立地或者部分地或者整体地作为负载监测结果。
引入VIP进程监测策略1421,可使得如果节点1发生宕机后,节点2及节点3上的VIP进程会监测到节点1已经发生宕机。
引入磁盘IO监测策略1422可对同一节点发生磁盘读写错误(即IO error)时,Target端选择模块会对部署该Target端选择模块的节点中的一个或者全部磁盘进行全盘扫描,扫描次数可为1~60次,最大设置为60次,直到返回成功;若60次扫描都没有返回成功,则证明该节点所挂载的磁盘存在故障,此种故障可为磁盘的硬件故障和/或软件故障。
引入文件系统监测策略1423可对Target端所在节点的文件系统(File System)是否存在访问错误予以检测,如果节点的文件系统返回错误提示,则在重定向过程中不会选择该节点。
引入剩余磁盘容量监测策略1424可对每个节点所属的分布式存储节点中剩余磁盘容量进行检测;如果已经使用超过75%(即仅剩下25%的剩余磁盘空间),则则在重定向过程中不会选择该节点。之所以将剩余磁盘容量设定为75%是考虑到如果某个节点中磁盘使用量已经超过80%会导致磁盘的IOPS性能急剧下降,因此对于此种使用量超过80%的磁盘所在的节点不能被选用。当然,如果一个分布式集群系统存在多个节点时,需要综合考虑节点的剩余磁盘率、剩余内存率等多个维度。
引入剩余内存监测策略1425与剩余磁盘容量监测策略1424的目的相同。如果待选择队列中的某个节点即使不发生磁盘读写错误、不存在文件系统访问错误且剩余磁盘率大于25%,则即使被选定,则也依然会因为内存不足导致IO读写操作存在较大时延。因此需要剔除内存使用率较高的节点。
引入连接数监测策略1426,并将连接数大于第二设定阈值的节点予以剔除,以防止过高连接数的Target端与Initiator端20连接时存在时延,提高对用户在客户端100发起的访问请求的响应效率。
因此,在本实施例中,通过引入VIP进程监测策略1421,磁盘IO监测策略1422及文件系统监测策略1423对重定向时对待选择队列中的多个节点进行定性筛选,如果不符合则立刻剔除。通过引入剩余磁盘容量监测策略1424,剩余内存监测策略1425及连接数监测策略1426,对剔除部分不合适的节点的待选择队列按照图5所示出的步骤,确定出最优化的Target端所在的节点,以最终确定出最合适的节点并将该节点中的Target端响应自客户端发起访问请求并连接客户端100中的Initiator端20,以为Initiator端20提供最优的iSCSITarget访问路径。因此,整个选择方法的实现过程不需要介入人工干预,并能够减少人工选择Target端所可能存在的选定错误或者选出的节点根本有效地响应用户发起的访问请求的情形,并且整个选定节点的过程充分考虑到了各个节点在设定时间段内的负载情况,还有效地避免了待选择队列中的某个节点被选定从而作为主节点后,对分布式集群系统的其他未发生宕机或者未发生网络断开的节点造成不利影响,避免节点间业务冲突。
如果节点1中的Target端14与分布式存储节点11因为网络堵塞或者存储异常或者剩余内存不足等诸多原因导致Target端14与分布式存储节点11断开连接时,则表示节点1的分布式存储节点11出现故障,此时Target端选择模块141通知部署于Initiator端20的Initiator进程,并触发恢复机制。当Initiator端20中运行的Initiator进程与Target端14中运行的Target进程断开后,Initiator进程会持续地发送重试请求,默认重试请求持续时间可设置为120秒。
由Zookeeper客户端12在Zookeeper服务端30中建立包含节点名称的持久节点及临时节点,若当前状态的主节点(即节点1)发生故障时,由分布式集群系统40中剩余节点(假设选定节点2作为下一个主节点)的VIP进程通过判断临时节点是否存在,以将临时节点加入待选择队列。Target端14与Zookeeper服务端30正常连接时,通过建立以节点1的节点名称命名的临时节点,以判定该节点是否正常,如果存在临时节点则认定该节点正常,如果不存在临时节点则认定该节点不正常。
节点选择策略至少由Initiator进程与Target端所形成的部署层级及各个节点在分布式集群系统中的权重予以单独或者共同定义。具体的,该部署层级根据Initiator进程与响应Initiator进程的Target端14(或者Target端24或者Target端34或者Target端44)之间所形成的拓扑关系,以确定彼此所形成的部署层级,所述Initiator进程运行于客户端100的Initiator端20。
参图3所示,部署层级是指每个节点在整个分布式集群系统中的拓扑关系。机房201与机房202共同组成该分布式集群系统。机房201部署机架A与机架B,机房202部署机架C与机架D。当然每个机架中还部署一个或者多个物理服务器,物理服务器或者前述任何一个机架均视为一个节点。
节点的权重设置原则具体为如下所示。Initiator端20与Target端24位于机架B,则将机架B的权重设置为100。Initiator端20与Target端14位于同一个机房但位于机架A中,则将机架A的权重设置为90。Target端34与Target端44位于机房202中,并可将机架C的权重设置为80,将机架D的权重设置为70。各个机架的权重还可根据分布式存储系统40的网络环境设置不同的权重,以保证部署Initiator端20的客户端100能够在最短时间内与各个分布式存储节点通信,减少通信延迟。各个节点的权重被保存至所属节点的Zookeeper客户端并最终通过Zookeeper客户端与Zookeeper服务端30所建立的长连接同步保存至Zookeeper服务端30。
该选择方法还包括:定期监测设定时间段内节点的负载并将负载监测结果保存至Zookeeper服务端30,将脱离连接分布式集群系统的节点标记为异常节点,部署并运行Initiator进程的Initiator端20监测到异常节点后触发恢复机制。在本实施例中,若节点1的Target端14与分布式存储节点11断开连接,则将节点1标记为异常节点。
参图4所示,对分布式集群系统中各个节点以循环方式进行负载检测的详细过程如下所述,对节点以设定时间周期的方式进行定期循环监测由负载检测单元13中的监测进程予以执行。申请人以节点1为范例予以简要阐述。
开始。
对每个节点的Zookeeper客户端与Zookeeper服务端之间建立长连接,以确定该节点的健康状态。
判断长连接是否成功建立。长连接是指客户端100与服务端400之间建立的TCP/IP连接。若是,则执行下一步骤;若否,则跳转下一次监测并结束。
计算节点的剩余内存并将剩余内存更新至节点的Zookeeper客户端12,以对Zookeeper客户端12中记录节点1的剩余内存进行同步更新。
判断节点1的Zookeeper客户端12是否更新成功。
若是,计算节点1的Target端14与客户端100之间所形成的Target连接数;若否,跳转下一次监测并结束。
步骤S2、调用节点的使用状态并根据节点选择策略确定匹配与自客户端发起访问请求相适应的Target端;其中,所述配置策略至少由节点权重、剩余可用资源率及Target连接数的一种或者几种共同定义。其中,调用节点的使用状态并根据节点选择策略确定匹配与自客户端发起访问请求相适应的Target端的操作由独立部署于每个节点的Target端中的Target选择进程独立执行。
在本实施例中,当Initiator端20与节点1的Target端14中断连接的事件发生后,Target端选择模块141通知部署于Initiator端20的Initiator进程,并触发恢复机制,以由节点1中的Target端选择模块141调用节点的使用状态并根据节点选择策略确定匹配与自客户端100发起访问请求相适应的Target端,在本实施例中选用节点2中的Target端24。
恢复机制具体为:根据设定时间间隔轮询确定每个节点的节点权重、剩余可用资源率及Target连接数,对配置策略进行更新,并将更新后的配置策略写入Zookeeper服务端30,以对Zookeeper服务端30中的配置策略予以更新。
参图5所示,该选择方法中重新选定节点2中的Target端24的具体过程如下所示。
开始。
连接Zookeeper服务端30。
从Zookeeper服务端30获取存储正常的节点。所谓存储正常的节点是指未脱离连接分布式集群系统的节点。
将正常的节点加入待选择队列,例如图6中的待选择队列中的Target端14、24及34。图6中的虚线箭头表示在当前状态中,节点2中的Target端24被选中,并与Initiator端20连接。
遍历待选择队列并判断是否存在临时节点。
剔除持久节点而仅保留被标记为临时节点的节点,并在剔除持久节点后更新待选择队列。
将待选择队列中Target端所在节点的权重从高至低排序并更新至待选择队列中。
从待选择队列中剔除剩余内存小于第一设定阈值的节点;具体的,第一设定阈值为节点所具有内存的25%。例如节点3中内存总容量是4GB,第一设置阈值则是1GB,当节点3中的剩余内存小于1GB时,则需要剔除节点3。
从待选择队列中剔除连接数大于第二设定阈值的节点;具体的,第二设定阈值为节点所形成的连接数为10。如果某个节点的Target端所形成的连接数过大,会极大影响后续由该节点响应客户端100所发起的访问请求。
输出待选择队列中位于对队首的Target端所在的节点,以将队首的Target端所在的节点中的Target端响应自客户端发起访问请求。
结束。
综上,当位于服务端400的节点1中的Target端14与位于客户端100的Initiator端20发生网络断开或者节点1发生宕机或者分布式存储系统40发生故障时,可基于Zookeeper所具有的开源分布式协调服务,并根据各个节点的负载情况,自动地切换能够有效地响应用户所发起的访问请求的Target端,避免了在人工盲目地选取可用节点的Target端后,对整个分布式集群系统各个节点间资源造成配置不均衡的问题,并有效地避免了采用人工选择Target端所可能发生的错误。
实施例二:
基于实施例一所揭示的一种Target端的选择方法所揭示的技术方案,本实施例还揭示了一种分布式集群系统的一种具体实施方式。
在本实施例中,一种分布式集群系统,包括:多个节点(即节点1~节点3),由部署于每个节点中的分布式存储节点所组成的分布式存储系统,每个节点中部署运行Target进程的Target端、负载检测单元、Zookeeper客户端及Zookeeper服务端30。
具体的,节点1部署Target端14、负载检测单元13、Zookeeper客户端12及分布式存储节点11;节点2部署Target端24、负载检测单元23、Zookeeper客户端22及分布式存储节点21;节点3部署Target端34、负载检测单元33、Zookeeper客户端32及分布式存储节点31。Zookeeper客户端12、Zookeeper客户端22及Zookeeper客户端32均连接Zookeeper服务端30。所有节点的分布式存储节点构成分布式存储系统40。Target端14中运行Target进程并部署Target端选择模块141,节点2与节点3的Target端中也设置相同的Target端选择模块(未示出)。
Target端部署运行Target选择进程的Target端选择模块(例如图2中节点1中的Target端选择模块141),用以对分布式集群系统中节点自客户端发起访问请求予以响应的节点中的Target端予以选择。负载检测单元监控节点的使用状态并保存。Zookeeper客户端接收自客户端中运行Initiator进程的Initiator端下发的配置策略,调用节点的使用状态并由Target端选择模块根据节点选择策略确定匹配与自客户端发起访问请求相适应的Target端;其中,配置策略至少由节点权重、剩余可用资源率及Target连接数的一种或者几种共同定义。
节点的使用状态保存至Zookeeper服务端30,分布式集群系统中的Zookeeper客户端被Zookeeper服务端纳管,Zookeeper客户端接收并存储配置策略。Target端、负载检测单元及分布式存储节点均分别通过每个节点中所属的Zookeeper客户端与Zookeeper服务端30建立长连接。
本实施例所揭示的一种分布式集群系统与实施例一中具有相同部分的技术方案,请参实施例一所示,在此不再赘述。
实施例三:
参图8所示,本实施例揭示了一种计算机可读介质900的一种具体实施方式。计算机可读介质900中存储有计算机程序指令901,所述计算机程序指令901被一处理器902读取并运行时,执行如实施例一所述的Target端的选择方法中的步骤。
本实施例所揭示的Target端的选择方法与实施例一中具有相同部分的技术方案,请参实施例一所述,在此不再赘述。
本发明实施例中所描述的各种说明性的逻辑块,或单元都可以通过通用处理器,数字信号处理器,专用集成电路(ASIC),现场可编程门阵列或其它可编程逻辑装置,离散门或晶体管逻辑,离散硬件部件,或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器,可选地,该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现,例如数字信号处理器和微处理器,多个微处理器,一个或多个微处理器联合一个数字信号处理器核,或任何其它类似的配置来实现。
上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明,它们并非用以限制本发明的保护范围,凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。
对于本领域技术人员而言,显然本发明不限于上述示范性实施例的细节,而且在不背离本发明的精神或基本特征的情况下,能够以其他的具体形式实现本发明。因此,无论从哪一点来看,均应将实施例看作是示范性的,而且是非限制性的,本发明的范围由所附权利要求而不是上述说明限定,因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。
此外,应当理解,虽然本说明书按照实施方式加以描述,但并非每个实施方式仅包含一个独立的技术方案,说明书的这种叙述方式仅仅是为清楚起见,本领域技术人员应当将说明书作为一个整体,各实施例中的技术方案也可以经适当组合,形成本领域技术人员可以理解的其他实施方式。
Claims (11)
1.一种Target端的选择方法,用以对分布式集群系统中节点自客户端发起访问请求予以响应的节点中的运行Target进程的Target端予以选择;
其特征在于,所述选择方法包括:
监控节点的使用状态并保存,接收自客户端的Initiator进程下发的配置策略,调用节点的使用状态并根据节点选择策略确定匹配与自客户端发起访问请求相适应的Target端;其中,所述配置策略至少由节点权重、剩余可用资源率及Target连接数的一种或者几种共同定义。
2.根据权利要求1所述的选择方法,其特征在于,所述调用节点的使用状态并根据节点选择策略确定匹配与自客户端发起访问请求相适应的Target端的操作由独立部署于每个节点的Target端中的Target选择进程独立执行。
3.根据权利要求2所述的选择方法,其特征在于,所述节点的使用状态保存至Zookeeper服务端,分布式集群系统中的Zookeeper客户端被Zookeeper服务端纳管,所述Zookeeper客户端接收并存储配置策略至Zookeeper服务端,并在所述Zookeeper客户端与Zookeeper服务端之间建立长连接,并在Target进程与Zookeeper服务端之间建立长连接。
4.根据权利要求3所述的选择方法,其特征在于,由Zookeeper客户端在Zookeeper服务端中建立包含节点名称的持久节点及临时节点,若当前状态的主节点发生故障时,由分布式集群系统中剩余节点的VIP进程通过判断临时节点是否存在,以将临时节点加入待选择队列。
5.根据权利要求4所述的选择方法,其特征在于,所述剩余可用资源率中的资源至少由节点在当前状态中的内存资源和/或存储资源定义;
所述节点选择策略至少由Initiator进程与Target端所形成的部署层级及各个节点在分布式集群系统中的权重予以单独或者共同定义。
6.根据权利要求4或者5所述的选择方法,其特征在于,所述选择方法还包括:
定期监测设定时间段内节点的负载并将负载监测结果保存至Zookeeper服务端,将脱离连接分布式集群系统的节点标记为异常节点,Initiator进程监测到异常节点后触发恢复机制;所述恢复机制具体为:根据设定时间间隔轮询确定每个节点的节点权重、剩余可用资源率及Target连接数,对配置策略进行更新,并将更新后的配置策略写入Zookeeper服务端,以对Zookeeper服务端中的配置策略予以更新。
7.根据权利要求6所述的选择方法,其特征在于,所述部署层级根据Initiator进程与响应Initiator进程的Target端之间所形成的拓扑关系,以确定彼此所形成的部署层级,所述Initiator进程运行于客户端的Initiator端。
8.根据权利要求6所述的选择方法,其特征在于,所述选择方法还包括:
遍历待选择队列,在剔除持久节点后更新所述待选择队列;
将待选择队列中Target端所在节点的权重从高至低排序并更新至待选择队列中;
从待选择队列中剔除剩余内存小于第一设定阈值的节点;
从待选择队列中剔除连接数大于第二设定阈值的节点;
输出待选择队列中位于对队首的Target端所在的节点,以将队首的Target端所在的节点中的Target端响应自客户端发起访问请求;
其中,所述第一设定阈值为节点所具有内存的25%,所述第二设定阈值为节点所形成的连接数为10。
9.一种分布式集群系统,其特征在于,包括:
多个节点,由部署于每个节点中的分布式存储节点所组成的分布式存储系统,每个节点中部署运行Target进程的Target端、负载检测单元、Zookeeper客户端及Zookeeper服务端;
所述Target端部署运行Target选择进程的Target端选择模块,用以对分布式集群系统中节点自客户端发起访问请求予以响应的节点中的Target端予以选择;
负载检测单元监控节点的使用状态并保存;
Zookeeper客户端接收自客户端中运行Initiator进程的Initiator端下发的配置策略,调用节点的使用状态并由Target端选择模块根据节点选择策略确定匹配与自客户端发起访问请求相适应的Target端;其中,所述配置策略至少由节点权重、剩余可用资源率及Target连接数的一种或者几种共同定义。
10.根据权利要求9所述的分布式集群系统,其特征在于,所述节点的使用状态保存至Zookeeper服务端,分布式集群系统中的Zookeeper客户端被Zookeeper服务端纳管,所述Zookeeper客户端接收并存储配置策略;所述Target端、负载检测单元及分布式存储节点均分别通过Zookeeper客户端与Zookeeper服务端建立长连接。
11.一种计算机可读介质,其特征在于,
所述计算机可读介质中存储有计算机程序指令,所述计算机程序指令被一处理器读取并运行时,执行如权利要求1至8中任一项所述的Target端的选择方法中的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110338565.0A CN112948128A (zh) | 2021-03-30 | 2021-03-30 | Target端的选择方法、系统及计算机可读介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110338565.0A CN112948128A (zh) | 2021-03-30 | 2021-03-30 | Target端的选择方法、系统及计算机可读介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN112948128A true CN112948128A (zh) | 2021-06-11 |
Family
ID=76227467
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110338565.0A Pending CN112948128A (zh) | 2021-03-30 | 2021-03-30 | Target端的选择方法、系统及计算机可读介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112948128A (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113472886A (zh) * | 2021-06-30 | 2021-10-01 | 华云数据控股集团有限公司 | 分布式集群系统及其控制方法 |
CN113568753A (zh) * | 2021-07-30 | 2021-10-29 | 北京天融信网络安全技术有限公司 | 访问路径确定方法、装置、电子设备及可读存储介质 |
WO2022095638A1 (zh) * | 2020-11-09 | 2022-05-12 | 苏州浪潮智能科技有限公司 | 基于分组的分布式存储scsi目标服务管理方法、系统 |
CN115378962A (zh) * | 2022-08-18 | 2022-11-22 | 北京志凌海纳科技有限公司 | 一种基于iSCSI协议的存储集群的高可用性连通方法和系统 |
WO2024045879A1 (zh) * | 2022-08-30 | 2024-03-07 | 华为云计算技术有限公司 | 一种数据访问方法和系统 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101719082A (zh) * | 2009-12-24 | 2010-06-02 | 中国科学院计算技术研究所 | 虚拟化计算平台中应用请求调度的方法及其系统 |
CN101808119A (zh) * | 2010-03-04 | 2010-08-18 | 杭州华三通信技术有限公司 | 一种多存储阵列负载均衡的方法和设备 |
CN108228393A (zh) * | 2017-12-14 | 2018-06-29 | 浙江航天恒嘉数据科技有限公司 | 一种可扩展的大数据高可用的实现方法 |
CN111124662A (zh) * | 2019-11-07 | 2020-05-08 | 北京科技大学 | 一种雾计算负载均衡方法及系统 |
-
2021
- 2021-03-30 CN CN202110338565.0A patent/CN112948128A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101719082A (zh) * | 2009-12-24 | 2010-06-02 | 中国科学院计算技术研究所 | 虚拟化计算平台中应用请求调度的方法及其系统 |
CN101808119A (zh) * | 2010-03-04 | 2010-08-18 | 杭州华三通信技术有限公司 | 一种多存储阵列负载均衡的方法和设备 |
CN108228393A (zh) * | 2017-12-14 | 2018-06-29 | 浙江航天恒嘉数据科技有限公司 | 一种可扩展的大数据高可用的实现方法 |
CN111124662A (zh) * | 2019-11-07 | 2020-05-08 | 北京科技大学 | 一种雾计算负载均衡方法及系统 |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2022095638A1 (zh) * | 2020-11-09 | 2022-05-12 | 苏州浪潮智能科技有限公司 | 基于分组的分布式存储scsi目标服务管理方法、系统 |
CN113472886A (zh) * | 2021-06-30 | 2021-10-01 | 华云数据控股集团有限公司 | 分布式集群系统及其控制方法 |
CN113472886B (zh) * | 2021-06-30 | 2024-03-22 | 华云数据控股集团有限公司 | 分布式集群系统及其控制方法 |
CN113568753A (zh) * | 2021-07-30 | 2021-10-29 | 北京天融信网络安全技术有限公司 | 访问路径确定方法、装置、电子设备及可读存储介质 |
CN113568753B (zh) * | 2021-07-30 | 2024-02-09 | 北京天融信网络安全技术有限公司 | 访问路径确定方法、装置、电子设备及可读存储介质 |
CN115378962A (zh) * | 2022-08-18 | 2022-11-22 | 北京志凌海纳科技有限公司 | 一种基于iSCSI协议的存储集群的高可用性连通方法和系统 |
WO2024045879A1 (zh) * | 2022-08-30 | 2024-03-07 | 华为云计算技术有限公司 | 一种数据访问方法和系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112948128A (zh) | Target端的选择方法、系统及计算机可读介质 | |
US11223690B2 (en) | Service management modes of operation in distributed node service management | |
US6986076B1 (en) | Proactive method for ensuring availability in a clustered system | |
US6823382B2 (en) | Monitoring and control engine for multi-tiered service-level management of distributed web-application servers | |
US7225356B2 (en) | System for managing operational failure occurrences in processing devices | |
US6983324B1 (en) | Dynamic modification of cluster communication parameters in clustered computer system | |
US7234073B1 (en) | System and methods for failover management of manageable entity agents | |
US7529822B2 (en) | Business continuation policy for server consolidation environment | |
US20130151888A1 (en) | Avoiding A Ping-Pong Effect On Active-Passive Storage | |
US6675199B1 (en) | Identification of active server cluster controller | |
US20040003082A1 (en) | System and method for prevention of boot storms in a computer network | |
WO2004036344A2 (en) | System and method for the optimization of database | |
JPWO2008126325A1 (ja) | クラスタシステム、ソフトウェア更新方法、サービス提供ノード、およびサービス提供用プログラム | |
CN103581276A (zh) | 集群管理装置、系统、业务客户端及相应方法 | |
CN112416594A (zh) | 一种微服务分配方法、电子设备和计算机存储介质 | |
CN115396291A (zh) | 一种基于kubernetes托管的redis集群故障自愈方法 | |
EP3593516B1 (en) | Method and control node for managing cloud resources in a communications network | |
CN108200151B (zh) | 一种分布式存储系统中ISCSI Target负载均衡方法和装置 | |
CN109474694A (zh) | 一种基于san存储阵列的nas集群的管控方法及装置 | |
CN115378962B (zh) | 一种基于iSCSI协议的存储集群的高可用性连通方法和系统 | |
CN116455830A (zh) | 实现存储网关高可用分布式qos的方法 | |
CN116886286A (zh) | 大数据认证服务自适应方法、装置和设备 | |
JP2006100906A (ja) | ネットワークシステムの運用管理方法及びストレージ装置 | |
JP4485560B2 (ja) | コンピュータ・システム及びシステム管理プログラム | |
JP2022166934A (ja) | 情報処理装置、過負荷制御プログラムおよび過負荷制御方法 |
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 |