CN113568749B - 基于Elasticsearch集群的shard分配方法 - Google Patents
基于Elasticsearch集群的shard分配方法 Download PDFInfo
- Publication number
- CN113568749B CN113568749B CN202110859660.5A CN202110859660A CN113568749B CN 113568749 B CN113568749 B CN 113568749B CN 202110859660 A CN202110859660 A CN 202110859660A CN 113568749 B CN113568749 B CN 113568749B
- Authority
- CN
- China
- Prior art keywords
- node
- slave node
- card
- slave
- allocable
- 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.)
- Active
Links
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/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
- G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
-
- 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/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
-
- 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
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
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
本申请提供一种基于Elasticsearch集群的shard分配方法,在创建新索引时,主节点在分配一个新的shard时,先考虑当前每一个可分配从节点的CPU状态和内存状态再进行分配,可以实现将新的shard分配在当前CPU利用率和内存利用率综合最小的可分配从节点上,避免将新的shard创建在已经负载很高的可分配从节点上,从而使得Elasticsearch集群运行更均衡,更稳定。
Description
技术领域
本申请涉及基于Elasticsearch集群技术领域,特别是涉及一种基于Elasticsearch集群的shard分配方法。
背景技术
shard,也称分片。单台服务器无法存储大量数据,由于Elasticsearch集群具有分布式存储的特点,因此Elasticsearch集群可以将一个索引(index)中的数据切分为多个shard,分布在多个节点上存储。
传统Elasticsearch集群的shard分配规则主要针对的是非存储计算分离模式下的shard分配,主要在于新建索引(index)时的shard分配、节点失联时的shard分配、以及整个Elasticsearch集群重启时的shard分配。非存储计算分离模式下,各个节点的shard数据独立存储在各个节点上,互相独立,无法互相调取。传统shard分配规则中,分配是根据每个索引(index)在每个节点(node)上的shard数量决定的,其中夹杂着一些用户的自定义规则以及Elasticsearch集群自己的存储阈值限制。新建索引时,非存储计算分离模式单纯考虑每个节点(node)上的shard数、自定义规则和Elasticsearch集群的存储阈值,而未考虑节点(node)的状态,例如内存状态、CPU状态等,可能因各个索引(index)的使用情况不同最终导致最终集群存在不均衡性和不稳定性。而在存储计算分离模式下,各个节点的shard数据存储在共享存储器中,并且可以互相共享,那么此时各个节点(node)的内存状态、CPU状态就变得非常重要。
发明内容
基于此,有必要针对传统基于Elasticsearch集群的shard分配方法用于存储计算分离模式下,容易导致Elasticsearch集群存在不均衡性和不稳定性的问题,提供一种基于Elasticsearch集群的shard分配方法。
本申请提供一种基于Elasticsearch集群的shard分配方法,应用于Elasticsearch集群的存储计算分离模式,所述方法包括:
判断是否接收到客户端发送的创建索引请求;
若接收到客户端发送的创建索引请求,则依据所述创建索引请求构建shard分配规则;
依据shard分配规则获取从节点中的可分配从节点;
依据每一个可分配从节点的CPU利用状态和内存利用状态,计算每一个可分配从节点的权重,并选取权重最小的可分配从节点作为shard分配节点;
在所述shard分配节点处创建一个shard;
返回所述依据每一个可分配从节点的CPU利用状态和内存利用状态的步骤,创建下一个shard,直至创建的shard总数达到预设shard数量,完成索引的创建。
本申请涉及一种基于Elasticsearch集群的shard分配方法,在创建新索引时,主节点在分配一个新的shard时,先考虑当前每一个可分配从节点的CPU状态和内存状态再进行分配,可以实现将新的shard分配在当前CPU利用率和内存利用率综合最小的可分配从节点上,避免将新的shard创建在已经负载很高的可分配从节点上,从而使得Elasticsearch集群运行更均衡,更稳定。
附图说明
图1为本申请一实施例提供的基于Elasticsearch集群的shard分配方法的流程示意图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。
本申请提供一种基于Elasticsearch集群的shard分配方法。
此外,本申请提供的基于Elasticsearch集群的shard分配方法不限制其执行主体。可选地,本申请提供的基于Elasticsearch集群的shard分配方法的执行主体可以为一种基于Elasticsearch集群的shard分配系统。所述shard分配系统包括主节点服务器,多个从节点服务器和共享存储器。每一个从节点服务器均与主节点服务器通信连接。每一个从节点服务器均与共享存储器通信连接。主节点服务器和多个从节点服务器构成Elasticsearch集群。
如图1所示,在本申请一实施例中,所述基于Elasticsearch集群的shard分配方法包括如下S100至S600:
S100,判断是否接收到客户端发送的创建索引请求。
具体地,shard分配系统中的主节点服务器(以下主节点服务器简称“主节点”)判断是否接收到客户端发送的创建索引请求。Elasticsearch集群可以包括一个主节点服务器(以下简称“主节点”)和多个从节点服务器(以下从节点服务器简称“从节点”)。Elasticsearch集群还包括一个共享存储器,用于存储所有节点的shard数据。shard数据是以文件形式存储的数据。
客户端和Elasticsearch集群是连接的,即客户端和每一个从节点服务器连接。客户端可以通过其他从节点服务器录入数据。客户端向主节点去发起创建索引请求,主节点判断是否接收到客户端发送的创建索引请求。
S200,若接收到客户端发送的创建索引请求,则依据所述创建索引请求构建shard分配规则。
具体地,主节点若接收到客户端发送的创建索引请求,则依据所述创建索引请求构建shard分配规则。可选地,主节点依据Elasticsearch集群自身的Allocation策略和用户自定义的规则创建shard分配规则。shard分配规则决定了哪些从节点是可以分配该新建索引的shard,哪些从节点无法或者不适合分配该新建索引的shard。
S300,依据shard分配规则获取从节点中的可分配从节点。
具体地,依据shard分配规则,主节点可以获知在从节点中哪些从节点是可以分配该新建索引的shard,这些从节点被定义为可分配从节点。
S400,依据每一个可分配从节点的CPU利用状态和内存利用状态,计算每一个可分配从节点的权重,并选取权重最小的可分配从节点作为shard分配节点。
具体地,可分配从节点的CPU利用状态可以为可分配从节点的可分配从节点的CPU利用率。可分配从节点的内存利用状态可以为可分配从节点的内存利用率。可以根据可分配从节点的CPU利用率和内存利用率计算权重。可分配从节点的权重越小,代表可分配从节点的CPU利用率和内存利用率综合越小,代表可分配从节点的负载越低。主节点将权重最小的可分配从节点作为shard分配节点。
S500,在所述shard分配节点处创建一个shard。
具体地,在shard分配节点创建shard是最优的,因为此时shard分配节点一定是当前所有可分配节点中负载最小的。
S600,返回所述S400,创建下一个shard,直至创建的shard总数达到预设shard数量,完成索引的创建。
具体地,创建一个新索引时,可能会需要创建多个shard,创建shard的数量由具体索引创建的需求决定,这个数量定义为预设shard数量。由于在shard分配节点处创建一个shard后,该shard分配节点的CPU利用状态和内存利用状态也会产生变化,创建下一个shard时,就需要返回S400,重新获取各个可分配从节点的CPU利用状态和内存利用状态,再去计算权重进行下一个shard的分配,如此循环往复。
本实施例中,在创建新索引时,主节点在分配一个新的shard时,先考虑当前每一个可分配从节点的CPU状态和内存状态再进行分配,可以实现将新的shard分配在当前CPU利用率和内存利用率综合最小的可分配从节点上,避免将新的shard创建在已经负载很高的可分配从节点上,从而使得Elasticsearch集群运行更均衡,更稳定。
在本申请一实施例中,所述S400包括如下S410至S492:
S410,选取一个可分配从节点。
具体地,本实施例中S410至S491阐述了一个shard分配的过程。一个shard分配的过程包括了多个可分配从节点的权重计算过程。本步骤为第一步,选取一个可分配从节点,进行后续的权重计算。
S420,获取预设索引权重平衡因子、预设节点权重平衡因子、所述索引在所述可分配从节点上的shard总数、以及所述索引在所有可分配从节点上的shard平均数。
具体地,预设索引权重平衡因子和预设节点权重平衡因子由用户设定或者查阅历史资料设定,也可以直接提取历史计算权重的数据记录中的数据进行使用。
所述索引在所述可分配从节点上的shard总数,所述索引在所有可分配从节点上的shard平均数,这两个数据是和索引相关的数据。初始状态下,这两个数据是0,因为还没有任何shard已分配完毕,而在后续shard不断分配的过程中,这两个数据的值都可能会上升。
例如,可分配从节点包括从节点A,从节点B,从节点C和从节点D,S410中选取的可分配从节点为从节点A,那么本步骤中获取的就是索引在从节点A上的shard总数,以及索引在所有可分配从节点(从节点A,从节点B,从节点C和从节点D)上的shard平均数。
S430,获取所述可分配从节点上当前已有的shard总数、以及所有可分配从节点上当前已有的shard平均数。
具体地,所述可分配从节点上当前已有的shard总数,所有可分配从节点上当前已有的shard平均数,这两个数据是和索引无关的数据。由于不同的业务会创建不同的索引,因此在本次创建索引之前,可能存在其他索引已经在一些可分配从节点上创建了shard。
例如,可分配从节点包括从节点A,从节点B,从节点C和从节点D,S410中选取的可分配从节点为从节点A,那么本步骤中获取的就是从节点A上的shard总数,以及所有可分配从节点(从节点A,从节点B,从节点C和从节点D)上的shard平均数。
S440,依据公式1分别计算所述可分配从节点的索引权重和节点权重。
其中,WEIGHTindex(node,index)为所述可分配从节点的索引权重。WEIGHTnode(node,index)为所述可分配从节点的节点权重。indexBalance为预设索引权重平衡因子。shardBalance为预设节点权重平衡因子。Node.numShards(index)为所述索引在所述可分配从节点上的shard总数。avgShardsPerNode(index)为所述索引在所有可分配从节点上的shard平均数。Node.numShards为所述可分配从节点上当前已有的shard总数。avgShardsPerNode为所有可分配从节点上当前已有的shard平均数。
具体地,公式1使用了S420和S430中所获取的参数。
S450,获取所述可分配从节点的当前CPU利用率和当前内存利用率,以及第一配置参数、第二配置参数和第三配置参数。
具体地,可以使用CPU的处理能力基准计算实时CPU利用率,或者运行CPU测试程序获取CPU利用率。
linux系统下,可以调取/proc/meminfo或者更直观的free命令来获取当前内存利用率,或者运行内存测试程序获取内存利用率。
S460,依据公式2计算所述可分配从节点的CPU权重和内存权重。
其中,WEIGHTcpu为所述可分配从节点的CPU权重。WEIGHTmem为所述可分配从节点的内存权重。RATIOcpu为所述可分配从节点的当前CPU利用率。RATIOmem为所述可分配从节点的当前内存利用率。θ0为第一配置参数。θ1为第二配置参数。θ2为第三配置参数。
具体地,第一配置参数、第二配置参数和第三配置参数在设置时,需要保证三者的和为1。
S470,依据公式3计算所述可分配从节点的平衡权重。
WEIGHTnode,index=[WEIGHTindex(node,index)+WEIGHTinode(node,index)]×θ2 公式3
其中,WEIGHTnode,index为所述可分配从节点的平衡权重。WEIGHTindex(node,index)为所述可分配从节点的索引权重。WEIGHTinode(node,index)为所述可分配从节点的节点权重。θ2为第三配置参数。
S480,依据公式4计算所述可分配从节点的权重。
其中,WEIGHTnode为所述可分配从节点的权重。WEIGHTcpu为所述可分配从节点的CPU权重。WEIGHTmem为所述可分配从节点的内存权重。WEIGHTnode,index为所述可分配从节点的平衡权重。
具体地,通过公式4最终计算出所述S410选出的可分配从节点的权重,可选地,可以将该可分配从节点的权重置入一个权重列表中。
S491,返回S410,直至所有可分配从节点的权重均计算完毕。
具体地,反复执行S410直至S480,直至创建的shard总数达到预设shard数量为止。由于shard创建了预设shard数量个,那么权重也相应的计算出预设shard数量个。此时,权重列表中的权重数量就等于预设shard数量。
S492,选取权重最小的可分配从节点作为shard分配节点。
具体地,可以将权重列表中的所有权重按从小到大的顺序排序,最终筛选出最小权重。将最小权重对应的可分配从节点作为shard分配节点。
本实施例中,通过索引在所述可分配从节点上的shard总数,索引在所有可分配从节点上的shard平均数,可分配从节点上当前已有的shard总数,以及所有可分配从节点上当前已有的shard平均数这四个参数计算当前的可分配节点的权重,考虑了CPU利用和内存利用的实时变化性,使得每一个新的shard分配在当前CPU利用率和内存利用率综合最小的可分配从节点上,避免将新的shard创建在已经负载很高的可分配从节点上。
在本申请一实施例中,在S400之后,在S500之前,所述基于Elasticsearch集群的shard分配方法还包括如下步骤:
S493,向各个可分配从节点下发分配状态信息。所述分配状态信息包括shard分配规则。
具体地,本步骤S493包括:
S493a,依据所述shard分配节点,更新分配状态信息。分配状态信息包括shard分配规则,
S493b,向各个可分配从节点下发更新后的分配状态信息。
在S400步骤之后,已经选取权重最小的可分配从节点作为shard分配节点,那么需要更新分配状态信息。更新分配状态信息最主要的是更新shard分配规则,这样做的目的是让其他从节点知晓本次shard分配的结果,从而让其他从节点知晓本次shard将会创建在哪一个从节点,便于其他从节点后续的数据调度。后续主节点向各个可分配从节点下发更新后的分配状态信息。更新的时候还会更新Elasticsearch集群的其他信息
本实施例中,向各个可分配从节点下发分配状态信息,有助于其他从节点知晓本次shard将会创建在哪一个从节点,便于其他从节点后续的数据调度。后续主节点向各个可分配从节点下发更新后的分配状态信息。
在本申请一实施例中,所述S400包括如下步骤:
S410,依据所述shard分配规则,在所述shard分配节点处创建一个shard。在创建该shard时,写入shard状态元数据。所述shard状态元数据包括所述shard分配节点的节点ID。
具体地,shard状态元数据又称为shard state,主要用作Elasticsearch重启时的shard分配判断依据。节点ID又称为node id,在从节点第一次启动的时候会生成一个节点ID,并记录下来,再次启动该从节点时节点ID不会变更,是一个从节点的唯一标识符。
本实施例中,通过在创建shard时,同步写入shard状态元数据,使得节点ID和shard分配建立映射关系,使得在Elasticsearch集群重启后,Elasticsearch可以保留记忆,记住当时分配该shard时具体分配在哪一个从节点了。
在本申请一实施例中,在S600之后,所述基于Elasticsearch集群的shard分配方法还包括如下S710至S772:
S710,判断Elasticsearch集群是否正在重启。
具体地,S100至S600介绍了本申请的创建索引时的shard分配流程。在S600之后,通过执行S710判断Elasticsearch集群是否正在重启。如果Elasticsearch集群正在重启,则需要执行后续S720至S772的集群重启时的shard分配流程。
S720,若Elasticsearch集群正在重启,则在Elasticsearch集群重启时,主节点获取各个可分配从节点的索引信息。
具体地,反之,若Elasticsearch集群没有正在重启,则返回S710,继续监控Elasticsearch集群是否正在重启。
S730,依据各个从节点的索引信息,获取各个从节点的shard信息。所述shard信息包括shard状态元数据。
具体地,通过获取一个从节点的索引信息,可以获知该从节点的shard信息。而shard信息包括shard状态元数据,shard状态元数据又可能包括节点ID,因此可以通过是否包括节点ID后续确定是否在该节点上分配过shard。
S740,选取一个从节点,读取所述从节点的shard状态元数据。
具体地,shard信息包括shard状态元数据。
S750,判断所述从节点的shard状态元数据是否包含节点ID。
具体地,shard状态元数据可能包括节点ID,也可能不包括节点ID。
S760,若所述从节点的shard状态元数据包含节点ID,则进一步判断与该节点ID对应的从节点是否处于可用状态。
具体地,若所述从节点的shard状态元数据包含节点ID,则表明该从节点之前被分配过shard(或者换言之在这个从节点上创建过shard),留下了节点ID,那么进一步判断与该节点ID对应的从节点是否处于可用状态。
反之,若所述从节点的shard状态元数据未包含节点ID,则表明该从节点之前未被分配过shard,或者存在极端情况是该从节点的shard状态元数据损坏丢失了节点ID的数据,但是,无论是这两种中的哪一种情况,实际上结果是一样的,该从节点的shard状态元数据未包含节点ID。此时,返回S740,读取下一个从节点的shard状态元数据。
S771,若与该节点ID对应的从节点处于可用状态,则更新shard分配规则,向所述从节点下发分配状态信息,以控制所述从节点从共享存储器中加载所述从节点上已分配shard的shard数据。
具体地,若与该节点ID对应的从节点处于可用状态,则表示节点ID不但存在,且该从节点处于可用状态,一切正常,无需重新分配shard。本步骤中的分配状态信息的过程和前述S493b的原理是一样,此时只需要从共享存储器中加载所述从节点上已分配的所有shard的shard数据即可。
S772,返回S740直至所有从节点的shard信息均被读取完毕。
具体地,返回S740,直至所有从节点的shard信息均被读取并处理完毕。
本实施例中,通过整个Elasticsearch集群的分配状态信息下发时,将节点ID和shard的映射关系存放至shard信息中,并实时监控Elasticsearch集群重启状态。当Elasticsearch集群重启时,则根据shard信息在shard对应的从节点处恢复shard的shard数据,保证Elasticsearch集群重启后的集群状态和上次Elasticsearch集群停止前的集群状态一致,最大化保证了Elasticsearch集群的稳定性和均衡性。
在本申请一实施例中,在S760之后,所述基于Elasticsearch集群的shard分配方法还包括如下S781至S782:
S781,若与该节点ID对应的从节点处于不可用状态,则返回所述S300,重新分配处于不可用状态的从节点的shard。
具体地,若与该节点ID对应的从节点处于不可用状态,则这个从节点可能出现某些数据错误,无法再使用,此时需要将该处于不可用状态的从节点的所有shard进行重新分配。重新分配时,返回S300,执行S300至S500来分配每一个shard。
S782,更新shard分配规则,向所述从节点下发分配状态信息,以控制重新分配到所述shard的从节点从共享存储器中加载所述shard的shard数据。
具体地,由于shard进行了重新分配,因此shard分配规则需要更新并重新向各个从节点下发分配状态信息,以让各个从节点知晓这些shard重新分配到了哪些从节点上。并且从共享存储器中加载这些重新分配的shard的shard数据。
S783,返回S740直至所有从节点的shard信息均被读取完毕。
具体地,本从节点的shard重分配处理完毕,返回S740读取下一个从节点的shard信息。
本实施例中,当Elasticsearch集群重启时,若shard对应的从节点不可用,通过重新分配shard,尽量保证Elasticsearch集群重启后的集群状态和上次Elasticsearch集群停止前的集群状态接近一致,最大化保证了Elasticsearch集群的稳定性和均衡性。
在本申请一实施例中,在S600之后,所述基于Elasticsearch集群的shard分配方法还包括如下S810至S840:
S810,实时监控每一个从节点和主节点的通信状态。
S820,当一个从节点和主节点的通信状态处于失联状态时,将该从节点定义为失联从节点。
S830,该失联从节点向任意一个备用主节点发送ping请求,判断是否可以和任意一个备用主节点建立通信连接。
S840,若该失联从节点可以和任意一个备用主节点建立通信连接,则维持该失联从节点所持有的shard的数据锁。
具体地,本实施例S810至S840介绍了S600之后的另一个监控从节点失联状态的流程。需要注意的是,本实施例中的S810至S840是和S710至S772的监控集群重启状态和当集群重启时的shard分配流程是异步进行的,即可以同时进行监控集群重启和监控从节点失联状态。
因为shard目录存在数据锁机制,当一个线程占用,其他线程无法对该shard目录进行写入操作。因此,本实施例在主节点和从节点失联的情况下,先判断是该失联从节点存在问题,还是其他问题导致失联。如果该失联从节点可以和另一个备用主节点正常通行,则认为失联从节点是正常的,是其他问题导致失联。
由于此时认为失联主节点是正常的,因此无需解开该失联从节点所持有的shard的数据锁,维持该失联从节点所持有的shard的数据锁。此时可能是由于网络抖动等其他问题导致失联,可以重新启动Elasticsearch集群来重新建立主节点和从节点的通信连接。
在本申请一实施例中,在所述S830之后,所述基于Elasticsearch集群的shard分配方法还包括如下S850至S860:
具体地,若该失联从节点无法和任何一个备用主节点建立通信连接,则表明就是这个失联从节点存在问题,此时需要将该失联从节点的shard进行转移。
S850,若该失联从节点无法和任何一个备用主节点建立通信连接,则释放该失联从节点所持有的shard的数据锁。
具体地,先释放失联从节点数据锁。
S860,主节点返回所述S300,将该失联从节点所持有的shard重新分配到其他通信状态正常的可分配从节点上。
具体地,重新分配shard时,还是执行S300至S500的步骤。
本实施例中,在主节点和从节点失联时,通过排查失联从节点是否有通信状态问题,并在确定失联从节点有通信状态问题时释放shard的数据锁,并将失联从节点所持有的shard重新分配到其他通信状态正常的可分配从节点上,保证了Elasticsearch集群的正常运行和shard数据的正常调取。
在本申请一实施例中,在S600之后,所述基于Elasticsearch集群的shard分配方法还包括如下S910至S930:
S910,判断是否接收到客户端发送的集群路由请求。
本实施例S910至S930介绍了S600之后的另一个监控流程,即监控集群路由请求的流程。前述S710至S772介绍了监控集群重启状态的流程,前述S810至S840介绍了监控从节点失联状态的流程。需要注意的是,本实施例中的S910至S930,和S810至S840,S710至S772三者可以异步进行的,即在索引创建后,可以同时进行监控集群重启状态,监控从节点失联状态和监控集群路由请求。
集群路由请求又称为shard reroute请求,是由客户端发起的。主节点接受集群路由请求后,开始执行集群路由过程。集群路由就是将一个指定shard由一个指定源从节点至另一个指定从节点。简言之,就是shard在两个从节点之间的转移。
S920,若接收到客户端发送的集群路由请求,则进一步判断是否可以将指定shard由指定源从节点至指定从节点。
具体地,由于存在shard转移的障碍的可能性,因此需要在本步骤中进行判断是否可以移动该shard。是否可以将指定shard由指定源从节点至指定从节点的判断,也是通过集群的Allocation策略和集群的自定义策略来确定。
S930,若不可以将指定shard转移至指定从节点,则向客户端返回无法转移所述指定shard的消息,终止后续步骤。
在非存储计算分离模式下,传统的shard分配方法中,由于传统的集群结构shard数据是不共享的,从节点之间的shard转移需要远程先将数据拷贝,本身相当于要预留存储两份shard数据的存储空间,而本实施例中,shard数据是存在共享存储器中的,无需数据拷贝,只需要一份shard数据的存储空间,大大节省了存储空间。
在本申请一实施例中,在S920之后,所述基于Elasticsearch集群的shard分配方法还包括如下:
S941,若可以将指定shard转移至指定从节点,则更新shard转移之后的shard分配规则。
具体地,shard分配规则更新的流程和目的前述多个实施例已经提及,这里不再赘述。
S942,将更新后的shard分配规则存储于shard状态元数据中,并下发至各个从节点。
具体地,这个步骤也是和前述多个实施例中提及的下发步骤同理,为了让各个从节点知晓本次shard的转移,便于后续的shard数据的调取方便。
S943,当指定目标从节点收到shard状态元数据时,向指定源从节点发送转移请求。
具体地,当指定目标从节点收到shard状态元数据时,知晓了它是转移的被动方,触发向指定源从节点,即转移的主动方发送转移请求的步骤。
S944,指定源从节点释放shard的数据锁,并向指定目标从节点返回释放数据锁成功的消息。
具体地,转移前需要释放shard的数据锁,否则无法转移shard。
S945,在指定目标从节点收到释放数据锁成功的消息后,从共享存储器读取所述指定shard的shard数据并加载,并向主节点发送转移完成消息。
具体地,注意到,此时不需要远程拷贝shard数据,由于所有shard数据都是在共享存储器存储,因此,直接从共享存储器读取所述指定shard的shard数据并加载即可,大大节省时间。
S946,主节点收到转移完成消息后,更新整个Elasticsearch集群的shard分配状态信息,生成新的shard分配状态信息,以广播的形式下发到各个从节点。
具体地,更新整个Elasticsearch集群的shard分配状态信息,以更新整个Elasticsearch集群的集群状态,广播至各个从节点让各个从节点知晓。
在非存储计算分离模式下,传统的shard分配方法中,由于传统的集群结构shard数据是不共享的,从节点之间的shard转移需要远程先将数据拷贝,速度慢消耗时间长,而本实施例中,shard数据是存在共享存储器中的,无需数据拷贝,速度快消耗的时间短。
本申请还提供一种基于Elasticsearch集群的shard分配系统。
在本申请一实施例中,所述基于Elasticsearch集群的shard分配系统包括主节点服务器,多个从节点服务器和共享存储器。每一个从节点服务器均与主节点服务器通信连接。每一个从节点服务器均与共享存储器通信连接。主节点服务器和多个从节点服务器构成Elasticsearch集群。
以上所述实施例的各技术特征可以进行任意的组合,各方法步骤也并不做执行顺序的限制,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对本申请专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干变形和改进,这些都属于本申请的保护范围。因此,本申请的保护范围应以所附权利要求为准。
Claims (9)
1.一种基于Elasticsearch集群的shard分配方法,其特征在于,应用于Elasticsearch集群的存储计算分离模式,所述方法包括:
判断是否接收到客户端发送的创建索引请求;
若接收到客户端发送的创建索引请求,则依据所述创建索引请求构建shard分配规则;
依据shard分配规则获取从节点中的可分配从节点;
依据每一个可分配从节点的CPU利用状态和内存利用状态,计算每一个可分配从节点的权重,并选取权重最小的可分配从节点作为shard分配节点;
在所述shard分配节点处创建一个shard;
返回所述依据每一个可分配从节点的CPU利用状态和内存利用状态的步骤,创建下一个shard,直至创建的shard总数达到预设shard数量,完成索引的创建;
其中,所述依据每一个可分配从节点的CPU利用状态和内存利用状态,计算每一个可分配从节点的权重,并选取权重最小的可分配从节点作为shard分配节点,包括:
选取一个可分配从节点;
获取预设索引权重平衡因子、预设节点权重平衡因子、所述索引在所述可分配从节点上的shard总数、以及所述索引在所有可分配从节点上的shard平均数;
获取所述可分配从节点上当前已有的shard总数、以及所有可分配从节点上当前已有的shard平均数;
依据公式1分别计算所述可分配从节点的索引权重和节点权重;
其中,WEIGHTindex(node,index)为所述可分配从节点的索引权重,WEIGHTnode(node,index)为所述可分配从节点的节点权重,indexBalance为预设索引权重平衡因子,shardBalance为预设节点权重平衡因子,Node.numShards(index)为所述索引在所述可分配从节点上的shard总数,avgShardsPerNode(index)为所述索引在所有可分配从节点上的shard平均数;Node.numShards为所述可分配从节点上当前已有的shard总数,avgShardsPerNode为所有可分配从节点上当前已有的shard平均数;
获取所述可分配从节点的当前CPU利用率和当前内存利用率,以及第一配置参数、第二配置参数和第三配置参数;
依据公式2计算所述可分配从节点的CPU权重和内存权重;
其中,WEIGHTcpu为所述可分配从节点的CPU权重,WEIGHTmem为所述可分配从节点的内存权重,RATIOcpu为所述可分配从节点的当前CPU利用率,RATIOmem为所述可分配从节点的当前内存利用率,θ0为第一配置参数,θ1为第二配置参数,θ2为第三配置参数;
依据公式3计算所述可分配从节点的平衡权重;
WEIGHTnode,index=[WEIGHTindex(node,index)+WEIGHTinode(node,index)]×θ2 公式3;
其中,WEIGHTnode,index为所述可分配从节点的平衡权重,WEIGHTindex(node,index)为所述可分配从节点的索引权重,WEIGHTinode(node,index)为所述可分配从节点的节点权重,θ2为第三配置参数;
依据公式4计算所述可分配从节点的权重;
其中,WEIGHTnode为所述可分配从节点的权重,WEIGHTcpu为所述可分配从节点的CPU权重,WEIGHTmem为所述可分配从节点的内存权重,WEIGHTnode,index为所述可分配从节点的平衡权重;
返回选取一个可分配从节点的步骤,直至所有可分配从节点的权重均计算完毕;
选取权重最小的可分配从节点作为shard分配节点。
2.根据权利要求1所述的基于Elasticsearch集群的shard分配方法,其特征在于,在所述shard分配节点处创建一个shard之前,还包括:
向各个可分配从节点下发分配状态信息;所述分配状态信息包括shard分配规则。
3.根据权利要求2所述的基于Elasticsearch集群的shard分配方法,其特征在于,所述在所述shard分配节点处创建一个shard包括:
依据所述shard分配规则,在所述shard分配节点处创建一个shard;在创建该shard时,写入shard状态元数据;所述shard状态元数据包括所述shard分配节点的节点ID。
4.根据权利要求3所述的基于Elasticsearch集群的shard分配方法,其特征在于,在完成索引的创建之后,所述方法还包括:
判断Elasticsearch集群是否正在重启;
若Elasticsearch集群正在重启,则在Elasticsearch集群重启时,获取各个可分配从节点的索引信息;
依据各个从节点的索引信息,获取各个从节点的shard信息;shard信息包括shard状态元数据;
选取一个从节点,读取所述从节点的shard状态元数据;
判断所述从节点的shard状态元数据是否包含节点ID;
若所述从节点的shard状态元数据包含节点ID,则进一步判断与该节点ID对应的从节点是否处于可用状态;
若与该节点ID对应的从节点处于可用状态,则更新shard分配规则,向所述从节点下发分配状态信息,以控制所述从节点从共享存储器中加载所述从节点上已分配shard的shard数据;
返回所述选取一个从节点的步骤直至所有从节点的shard信息均被读取完毕。
5.根据权利要求4所述的基于Elasticsearch集群的shard分配方法,其特征在于,在判断与该节点ID对应的从节点是否处于可用状态之后,还包括:
若与该节点ID对应的从节点处于不可用状态时,则返回所述依据shard分配规则获取从节点中的可分配从节点的步骤,重新分配处于不可用状态的从节点的shard;
更新shard分配规则,向所述从节点下发分配状态信息,以控制重新分配到所述shard的从节点从共享存储器中加载所述shard的shard数据;
返回所述选取一个从节点的步骤直至所有从节点的shard信息均被读取完毕。
6.根据权利要求5所述的基于Elasticsearch集群的shard分配方法,其特征在于,在完成索引的创建之后,所述方法还包括:
实时监控每一个从节点和主节点的通信状态;
当一个从节点和主节点的通信状态处于失联状态时,将该从节点定义为失联从节点;
该失联从节点向任意一个备用主节点发送ping请求,判断是否可以和任意一个备用主节点建立通信连接;
若该失联从节点可以和任意一个备用主节点建立通信连接,则维持该失联从节点所持有的shard的数据锁。
7.根据权利要求6所述的基于Elasticsearch集群的shard分配方法,其特征在于,在判断是否可以和任意一个备用主节点建立通信连接之后,还包括:
若该失联从节点无法和任何一个备用主节点建立通信连接,则释放该失联从节点所持有的shard的数据锁;
主节点返回所述依据shard分配规则获取从节点中的可分配从节点的步骤,将该失联从节点所持有的shard重新分配到其他通信状态正常的可分配从节点上。
8.根据权利要求7所述的基于Elasticsearch集群的shard分配方法,其特征在于,在所述完成索引的创建之后,所述方法还包括:
判断是否接收到客户端发送的集群路由请求;
若接收到客户端发送的集群路由请求,则进一步判断是否可以将指定shard由指定源从节点至指定从节点;
若不可以将指定shard转移至指定从节点,则向客户端返回无法转移所述指定shard的消息,终止后续步骤。
9.根据权利要求8所述的基于Elasticsearch集群的shard分配方法,其特征在于,在判断是否可以将指定shard由指定源从节点转移至指定目标从节点之后,还包括:
若可以将指定shard转移至指定从节点,则更新shard转移之后的shard分配规则;
将更新后的shard分配规则存储于shard状态元数据中,并下发至各个从节点;
当指定目标从节点收到shard状态元数据时,向指定源从节点发送转移请求;
指定源从节点释放shard的数据锁,并向指定目标从节点返回释放数据锁成功的消息;
在指定目标从节点收到释放数据锁成功的消息后,从共享存储器读取所述指定shard的shard数据并加载,并向主节点发送转移完成消息;
主节点收到转移完成消息后,更新整个Elasticsearch集群的shard分配状态信息,生成新的shard分配状态信息,以广播的形式下发到各个从节点。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110859660.5A CN113568749B (zh) | 2021-07-28 | 2021-07-28 | 基于Elasticsearch集群的shard分配方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110859660.5A CN113568749B (zh) | 2021-07-28 | 2021-07-28 | 基于Elasticsearch集群的shard分配方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113568749A CN113568749A (zh) | 2021-10-29 |
CN113568749B true CN113568749B (zh) | 2023-09-05 |
Family
ID=78168682
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110859660.5A Active CN113568749B (zh) | 2021-07-28 | 2021-07-28 | 基于Elasticsearch集群的shard分配方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113568749B (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114443057B (zh) * | 2022-01-25 | 2023-03-24 | 北京百度网讯科技有限公司 | 对话模型的部署和对话方法、装置、电子设备及存储介质 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2018000991A1 (zh) * | 2016-06-30 | 2018-01-04 | 华为技术有限公司 | 一种数据均衡方法和装置 |
CN107566531A (zh) * | 2017-10-17 | 2018-01-09 | 厦门市美亚柏科信息股份有限公司 | 一种支持均衡资源的Elasticsearch集群扩展方法 |
CN109582758A (zh) * | 2018-12-06 | 2019-04-05 | 重庆邮电大学 | 一种Elasticsearch索引分片优化方法 |
CN110569302A (zh) * | 2019-08-16 | 2019-12-13 | 苏宁云计算有限公司 | 一种基于lucene的分布式集群的物理隔离的方法及装置 |
CN111176818A (zh) * | 2019-12-31 | 2020-05-19 | 北京金山云网络技术有限公司 | 分布式预测的方法、装置、系统、电子设备及存储介质 |
CN111428114A (zh) * | 2020-03-27 | 2020-07-17 | 中国工商银行股份有限公司 | Elasticsearch搜索引擎的索引创建方法及装置 |
CN111949736A (zh) * | 2020-08-25 | 2020-11-17 | 北京明略昭辉科技有限公司 | 一种数据库负载均衡方法、装置、电子设备和存储介质 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11138199B2 (en) * | 2019-09-30 | 2021-10-05 | Sap Se | Throughput optimization in distributed database systems using hypergraph partitioning |
-
2021
- 2021-07-28 CN CN202110859660.5A patent/CN113568749B/zh active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2018000991A1 (zh) * | 2016-06-30 | 2018-01-04 | 华为技术有限公司 | 一种数据均衡方法和装置 |
CN107566531A (zh) * | 2017-10-17 | 2018-01-09 | 厦门市美亚柏科信息股份有限公司 | 一种支持均衡资源的Elasticsearch集群扩展方法 |
CN109582758A (zh) * | 2018-12-06 | 2019-04-05 | 重庆邮电大学 | 一种Elasticsearch索引分片优化方法 |
CN110569302A (zh) * | 2019-08-16 | 2019-12-13 | 苏宁云计算有限公司 | 一种基于lucene的分布式集群的物理隔离的方法及装置 |
CN111176818A (zh) * | 2019-12-31 | 2020-05-19 | 北京金山云网络技术有限公司 | 分布式预测的方法、装置、系统、电子设备及存储介质 |
CN111428114A (zh) * | 2020-03-27 | 2020-07-17 | 中国工商银行股份有限公司 | Elasticsearch搜索引擎的索引创建方法及装置 |
CN111949736A (zh) * | 2020-08-25 | 2020-11-17 | 北京明略昭辉科技有限公司 | 一种数据库负载均衡方法、装置、电子设备和存储介质 |
Non-Patent Citations (1)
Title |
---|
基于云计算环境的蚁群优化计算资源分配算法;华夏渝等;《华东师范大学学报(自然科学版)》(第1期);第127-134页 * |
Also Published As
Publication number | Publication date |
---|---|
CN113568749A (zh) | 2021-10-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7620698B2 (en) | File distribution system in which partial files are arranged according to various allocation rules associated with a plurality of file types | |
JP3859994B2 (ja) | ストレージ・デバイス上でのスペースの割振りを管理する方法、システム、およびプログラム記憶媒体 | |
EP1055172B1 (en) | Object hashing with incremental changes | |
US7065526B2 (en) | Scalable database management system | |
JP4377369B2 (ja) | リソース割当調停装置およびリソース割当調停方法 | |
US8583756B2 (en) | Dynamic configuration and self-tuning of inter-nodal communication resources in a database management system | |
US20100138540A1 (en) | Method of managing organization of a computer system, computer system, and program for managing organization | |
US20050234867A1 (en) | Method and apparatus for managing file, computer product, and file system | |
JP2007520783A (ja) | データストレージシステムにおける冗長データ割り当て | |
KR100936238B1 (ko) | 파일 입출력과 복제의 균형적 수행을 위한 지연복제 시스템및 방법 | |
CN112162846B (zh) | 事务处理方法、设备及计算机可读存储介质 | |
CN116150160B (zh) | 数据库集群处理节点的调整方法、装置及存储介质 | |
CN113568749B (zh) | 基于Elasticsearch集群的shard分配方法 | |
CN111291062B (zh) | 数据同步写入方法、装置、计算机设备及存储介质 | |
CN112000285A (zh) | 强一致存储系统、数据强一致存储方法、服务器及介质 | |
CN113190619B (zh) | 分布式kv数据库的数据读写方法、系统、设备和介质 | |
CN109005071B (zh) | 一种决策部署方法和调度设备 | |
CN112261097B (zh) | 用于分布式存储系统的对象定位方法及电子设备 | |
CN113055448B (zh) | 一种元数据管理方法及装置 | |
CN111400110B (zh) | 数据库访问管理系统 | |
CN115102961A (zh) | 一种高并发网络访问分流方法及装置 | |
CN109787899B (zh) | 一种数据分区路由方法、装置及系统 | |
CN109040214B (zh) | 一种云环境下可靠性增强的服务部署方法 | |
CN116896543B (zh) | 一种ip地址的分配方法、装置、电子设备及存储介质 | |
CN115878046B (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 |