CN101252603B - 基于存储区域网络san的集群分布式锁管理方法 - Google Patents
基于存储区域网络san的集群分布式锁管理方法 Download PDFInfo
- Publication number
- CN101252603B CN101252603B CN2008101038091A CN200810103809A CN101252603B CN 101252603 B CN101252603 B CN 101252603B CN 2008101038091 A CN2008101038091 A CN 2008101038091A CN 200810103809 A CN200810103809 A CN 200810103809A CN 101252603 B CN101252603 B CN 101252603B
- Authority
- CN
- China
- Prior art keywords
- node
- cluster
- lock
- state
- server
- 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.)
- Expired - Fee Related
Links
- 238000007726 management method Methods 0.000 title claims abstract description 44
- 238000000034 method Methods 0.000 claims abstract description 37
- 230000008569 process Effects 0.000 claims abstract description 31
- 238000001514 detection method Methods 0.000 claims abstract description 14
- 239000000523 sample Substances 0.000 claims description 29
- 230000001419 dependent effect Effects 0.000 claims description 26
- 238000012546 transfer Methods 0.000 claims description 16
- 230000008859 change Effects 0.000 claims description 10
- 230000008878 coupling Effects 0.000 claims description 9
- 238000010168 coupling process Methods 0.000 claims description 9
- 238000005859 coupling reaction Methods 0.000 claims description 9
- 230000006870 function Effects 0.000 claims description 8
- 238000012423 maintenance Methods 0.000 claims description 7
- 238000012544 monitoring process Methods 0.000 claims description 5
- 230000011218 segmentation Effects 0.000 claims description 5
- 230000004083 survival effect Effects 0.000 claims description 5
- 238000004891 communication Methods 0.000 claims description 4
- 238000012545 processing Methods 0.000 claims description 4
- 230000004044 response Effects 0.000 claims description 4
- 238000004458 analytical method Methods 0.000 claims description 3
- 230000000977 initiatory effect Effects 0.000 claims description 2
- 230000001960 triggered effect Effects 0.000 abstract 1
- 238000004422 calculation algorithm Methods 0.000 description 5
- 239000003795 chemical substances by application Substances 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 3
- 238000012360 testing method Methods 0.000 description 3
- 230000006399 behavior Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 230000015572 biosynthetic process Effects 0.000 description 1
- VQLYBLABXAHUDN-UHFFFAOYSA-N bis(4-fluorophenyl)-methyl-(1,2,4-triazol-1-ylmethyl)silane;methyl n-(1h-benzimidazol-2-yl)carbamate Chemical compound C1=CC=C2NC(NC(=O)OC)=NC2=C1.C=1C=C(F)C=CC=1[Si](C=1C=CC(F)=CC=1)(C)CN1C=NC=N1 VQLYBLABXAHUDN-UHFFFAOYSA-N 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000000739 chaotic effect Effects 0.000 description 1
- 230000006378 damage Effects 0.000 description 1
- 238000000151 deposition Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000000873 masking effect Effects 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 238000012797 qualification Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Landscapes
- Hardware Redundancy (AREA)
Abstract
基于存储区域网络SAN的分布式锁管理方法属于网络存储领域，其特征在于：集群各节点服务器构成多重主从式子集群，即Quorum，子集群中一个节点作为主服务器，其他均为从属服务器；多重子集群包括一个State Quorum和若干个Lock Quorum，分别负责系统节点生灭状态的管理和名字空间中读写访问锁的管理；State Quorum由所有节点构成，Lock Quorum可由任意数量的节点构成，其大小及构成可由用户灵活配置；不论是State Quorum，还是LockQuorum，都遵循子集群侦测协议，通过该协议，各节点能够选举Quorum中的唯一主服务器，构建正常态的Quorum；各个Lock Quorum分管名字空间的不同分段且互不交叠，按照服务能力分别被赋予不同的权值。各Lock Quorum独立统计自己的负载情况，当一个Lock Quorum所负担的锁管理任务过于繁重时，触发负载平衡过程，将本Lock Quorum的部分任务分流给其他Lock Quorum。本发明易于灵活配置，具有良好的性能、高可扩展性以及高可靠性。
Description
技术领域
基于存储区域网络SAN的集群分布式锁管理方法属于网络存储系统领域，锁的管理对于维护系统一致性，保证并发访问的正确性非常重要，该方法尤其涉及集群系统名字空间的访问权限管理、存储网络中的负载调度、集群全局数据快照备份等领域。
背景技术
分布式锁管理系统用来控制对共享资源的并发性访问，提高并发访问的效率，同时保证对共享资源修改操作的原子性，从而也保证了系统的一致性状态。传统的锁管理系统依赖中心锁管理服务器提供对整个数据资源名字空间的访问权限控制，这种方案中，中心锁管理服务器容易成为系统瓶颈，整个系统的可扩展性较差，同时，中心锁管理服务器的单节点故障问题也会影响系统的可靠性；以集群并行文件系统Lustre为代表的面向对象分布式文件系统中采用了分布式锁管理系统，将对象存储服务器OSD名字空间的访问权限控制分布到若干台元数据管理服务器MDS中，这样大大减轻了单台服务器的负担，但这种方案中，名字空间在元数据管理服务器MDS中的分布是静态的，缺乏灵活性，不能适应负载的动态变化，同时，该类锁管理系统采用了热备standby服务器的方案，在一定程度上提高了系统可靠性；以全局文件系统Gloable FS为代表的集群系统采用了基于子集群Quorum的锁管理系统，其好处在于大大提高了系统可靠性，通过Quorum内部的锁更新协议Quorum内的所有服务器保持严格同步，当其中一台或多台出现故障，其他服务器按照协议依然能够形成新的Quorum继续提供服务，但该系统中Quorum内部只有一台节点，称为主服务器Master，能真正对外提供服务，所以存在性能瓶颈。
基于SAN的集群分布式锁管理方法提出了一种应用于大规模存储区域网络系统，能够协同工作的多Quorum锁管理系统结构，设计了子集群Quorum侦测协议来实现各个Quorum的建立、Quorum中领袖的选举，同时，设计了该多Quorum环境下的动态负载平衡机制，基于此方法实现的分布式锁管理系统易于灵活配置，具有良好的性能，高可扩展性以及高可靠性。
发明内容
本发明的目的在于设计一个性能好、可扩展性好并且高可靠的分布式锁服务系统，在存储区域网络环境下，实现对共享数据并发访问的权限管理，并能实现对分布式全局快照的支持。本发明的重点在于：可配置的主从式锁服务器子集群Quorum，锁服务器子集群Quorum的探测流程，锁服务器子集群Quorum的负载均衡。
本发明的特征在于：
所述方法是在集群的各节点服务器上依次按以下步骤实现的：
步骤(1).集群初始化
步骤(1.1).集群的设定初始化
在集群的各节点上设立一个状态服务器State Server，负责包括监测各节点的生灭状态、屏蔽故障节点、维护整个集群在内的各项正常工作，形成一个状态侦测集群State Quorum，负责节点生灭状态的管理；
在所述集群各节点上选择若干节点，各自设立一个锁服务器Lock Server，负责包括对共享数据资源并发访问的控制、保障集群卷管理系统、文件系统或数据库读写查询在内的各项操作的正确执行，维护共享存储系统的一致性并且按照锁更新协议构成每个锁服务子集群Lock Quorum，负责名字空间中读写访问锁的管理，各个与所述锁服务子集群通信的节点必须安装锁代理Lock Agent作为客户端，只有通过锁代理才能申请读写访问锁；
所述包括状态侦测集群和锁服务子集群在内的各个集群Quorum是由设定数量的服务器构成的一个服务单元，所述集群内的各服务器按照功能不同被分为主服务器Master、仲裁服务器Arbitrator，以及从属服务器Slave，其中：
主服务器仅存在于原先由设定数量的服务器构成的集群中，是随机选择的，仅有一个，负责提供状态监测管理或读写访问锁管理服务服务；
仲裁服务器仅在所述集群未达到设定数量时存在，由此时的所有服务器按照选举协议临时选举出来作管理者用的，当接收该服务器加入后，使服务器总数超过设定阈值时，所选仲裁服务器便转换为主服务器，所在的集群转入正常状态，即Quorate状态，提供正常服务；
从属服务器，为所选主服务器的热备，存储重要数据的副本，参与集群中的投票与决策，在当前的主服务器失败后，新的主服务器由各从属服务器投票选出；
所述锁更新协议是指：各个锁服务子集群分管名字空间的不同分段且互不交叠，独立统计本锁服务子集群的负载情况，并按照服务分别被赋予不同权重值条件下，当一个锁服务子集群所负担的锁管理任务过于繁重时，则向其他锁服务子集群分流即更新名字空间的分段；
步骤(1.2)配置初始化
步骤(1.2.1)配置节点的IP地址、主机名，以及相应的XML配置文件，其中，包括版本、根元素的版本，所述根元素代表整个锁集群，其版本及其名称，用<cluster_version>及<name>表示，根元素具体内容包括：
<cluster_nodes>标签，内容包括：
集群中每个节点的标签及其内容，其中包括节点名name、节点优先级rank、节点投票时的权重votes，所述各节点的权重必须满足以下条件：对于进入正常状态，即Quorate状态的集群，已经加入其中的所有节点的权重和必须大于整个集群系统中所有节点权重和的一半，在缺省情况下，设各节点的权重为1，则Quorate状态成立的条件为当前已加入集群的节点必须多于半数；
<thudlm_dom>标签，包括：
锁服务子集群中节点的权重weight，描述该锁服务子集群的锁处理能力；代表该锁服务子集群中一个节点的标签<lock_server>，以及每个节点的名称name；
步骤(1.2.2).把配置文件分发到集群中的各个节点；
步骤(1.3).状态初始化，按以下步骤建立状态侦测集群：
步骤(1.3.1).对集群内各节点同时运行以下操作：
步骤(1.3.1.1).读取并分析配置文件，脚本参数，初始化各内存的数据结构，包括：节点当前状态、状态侦测集群和锁服务子集群的链表；
步骤(1.3.1.2).开放本节点的服务端口，侦听集群内其他节点的消息；
步骤(1.3.1.3).按以下步骤执行集群探测流程：
步骤(1.3.1.3.1).定义节点在本集群中的四种状态为：初始化状态Beginner，仲裁服务器状态Arbitrator，主服务器状态Master，以及从属服务器状态Slave；
步骤(1.3.1.3.2).把本集群中的所有节点读入节点链表，并设定一个游标指针指向该链表的首节点；
步骤(1.3.1.3.3).若本节点的当前状态为开始状态或仲裁服务器状态，则把游标指针指向节点链表的首节点，并发起探测游标所指向的首节点的操作，发起连接申请，侦听本节点在本集群中的服务端口，持续侦听，直到有事件到来；
步骤(1.3.1.3.4).若被探测节点发出同意连接的响应，则登录所探测节点，向所探测节点发出本节点的基本信息，并根据不同情况，作以下处理：
若：锁探测节点当前处于初始状态，且本节点的优先级低于被探测节点，则退出在所探测节点上的登录，重置游标指针，重新探测，转步骤(1.3.1.3.3)；
若：锁探测节点为从属服务器则退出在所探测节点上的登录，转步骤(1.3.1.3.3)；
若：锁探测节点当前为仲裁服务器状态，且本节点也为仲裁服务器状态，则根据优先级确定最终候选者，一旦本节点候选失败，则遣散所有本节点上的登录者并勒令登录者转换为初始状态，而本节点转为从属服务器状态，结束本节点的探测流程；
若：所探测节点当前为主服务器状态，则遣散所有在本节点上的登录者，并勒令所有登录者转为初始状态重新探测，而本节点则转为从属服务器状态，结束本节点的探测流程；
若：所探测的节点其状态为未知，则退出在所探测节点上的登录；
若本节点探测到节点链表末尾且仍然为初始状态，将本节点转换为Arbitrator状态，重新探测，转步骤(1.3.1.3.3)；
步骤(1.3.1.3.5).
若：本节点收到其他节点的探测请求，则建立连接，发回同意连接的消息；
若：本节点处于初始状态或从属服务器状态下，收到其他节点的登录信息，则向对方节点发回本节点的具体信息；
若：本节点处于仲裁服务器状态，且本集群中的权重已足够使本集群转为Quorate时收到其他节点的登录信息，则记录对方节点在本集群中的权重，本节点转为主服务器状态，结束本节点的探测流程；
步骤(1.3.1.3.6).把事件内容记录入日志，转步骤(1.3.1.3.3)；
步骤(1.3.1.3.7).确定各节点在状态侦测集群中是主服务器，还是从属服务器状态的最终形式，由全部或多数存活节点构成状态侦测集群；
步骤(1.3.1.4).作为主服务器的节点轮询检测集群中各节点的心跳信息，确认节点生灭状态，若有新节点加入，则更新本地状态侦测集群的节点链表，同时发送广播消息通知状态侦测集群中其他节点同步更新，若有节点出现故障，则主动屏蔽故障节点；
步骤(1.3.1.5).各节点启动锁代理进程，通过作为锁服务子集群的客户端的锁代理把本地锁请求发送到对应的锁服务子集群；
步骤(1.4).锁服务初始化，建立锁服务子集群，其步骤如下：
步骤(1.4.1).根据所述初始化时读入内存的配置文件信息、节点生灭状态，建立各个锁服务子集群的节点链表；
步骤(1.4.2).查询本节点是否在锁服务子集群中，若属于某个锁服务子集群，则按步骤(1.3.1.3)所述的探测流程，确定本节点是主服务器还是从属服务器，若不属于任何一个锁服务子集群，则退出；
步骤(1.4.3).按以下步骤初始化一个资源表RT：
步骤(1.4.3.1).在锁服务子集群中，把整个名字空间映射到一个水平的哈希地址空间，设哈希值有n位，把整个哈希地址空间表示为{i|0≤i≤2n}；
步骤(1.4.3.2).把各个锁服务子集群锁管理的名字空间分段信息都记录在各个锁服务子集群自己的资源表RT中，其表项为：哈希地址hash_addr，对应名字空间某数据资源；锁服务子集群标识lqid，取值为1、2、3......m，共有m个锁服务子集群，令RTi表示隶属于第i个锁服务子集群LQi的表项组成的集合，用RTi＝{p|p∈RT∧p.lqid＝i}表示，p为RTi中的某个表项，则整个集群系统包含m个锁服务子集群，用LQ1、LQ2、……、LQm表示，各自的权重分别为w1、w2、……、wm；
步骤(2).状态侦测集群按以下步骤在各个锁服务子集群中进行负载均衡：
步骤(2.1).各锁服务器子集群中的主服务器每隔间隔T为每个锁服务子集群LQi对应的资源表RTi的每一项按下式计算负载loadp：loadp(T)＝(1-a)*arp+a*loadp(T-1)；
其中：
arp为当前间隔T计算得到的单位时间内接收的锁请求数；
a为历史因子，表示(T-1)周期的负载值loadp(T-1)在T周期中新计算得到的负载loadp(T)中的比例；
步骤(2.2).状态侦测集群的主服务器通过锁代理收集各个锁服务子集群在同期T内的负载量，进而求出各锁服务子集群按各自权重所应负担的理论负载量，同时，求出各锁服务子集群的过载负载量，该过载负载量为现实负载量与理论负载量之差；
步骤(2.3).根据所述过载负载量的正负，把各个锁服务子集群分别划分到过载集合和轻载集合；
步骤(2.4).按以下步骤使负载量近似均衡分布：
步骤(2.4.1).结束条件判断：当过载集合或轻载集合中其中任何一个为空，或最大过载量低于设定的阈值时则转步骤(2.4.5)，否则，执行步骤(2.4.2)；
步骤(2.4.2).对于过载集合中的每一个元素，在轻载集合中寻求最佳分流匹配，把已匹配成对的从相应集合中去除，并把要分流的负载量记录到相应的过载集合的元素上；
步骤(2.4.3).对于轻载集合中的每一个元素，在过载集合中寻求最佳负载与分流匹配，并把已匹配的从相应集合中去除，把要分流的负载量仍然记录在过载集合的元素上；
步骤(2.4.4).结束一轮匹配，转步骤(2.4.1)；
步骤(2.4.5).负载分流，遍历过载集合中的每个节点，根据记录的分流信息把相应的流量分流到相应的轻载集合中。
对于所述状态侦测集群，初始化时，应选择集群中一个不属于任何锁服务子集群的服务器为主服务器。
本发明的优点如下：
(1)多Quorum架构，一个State Quorum用来探测所有存活节点，维护集群的结构，检测各节点状态，多个Lock Quorum负责维护读写访问锁信息，是系统核心服务单元，各个Quorum的结构、节点构成都通过xml配置文件配置，维护和修改灵活；
(2)各Quorum采用主从结构，从服务器作为主服务器的热备，提供高可靠的服务，主服务器的选举、从服务的数量等都可以灵活配置；
(3)各Quorum中节点独立发起探测，根据预设的rank级别确定本节点的优先顺序，因为Quorum中级别的唯一性，Quorum中各节点能够选举出唯一的Master，即当前存活的具有最高级别的节点；
(4)各Quorum采用投票机制确立Quorum的合法地位，当目前加入Quorum的节点投票数超过理论总票数的一半时，Quorum才被宣布为合法且能正常对外提供服务，通过该机制，避免了由于多个子Quorum同时成立而对共享数据管理带来的混乱以及对数据一致性的破坏；
(5)多Lock Quorum，彼此协同处理，各个Quorum分管全局名字空间的一部分且互不交叠，各节点在访问相应资源全会查询资源表，按照表中记录的Quorum id值向相应Lock Quorum发送锁申请，无中心瓶颈；
(6)各个Lock Quorum间的负载能够实现动态平衡，通过配置文件中的数据确定各Lock Quorum的权重，并以此为根据均分负载，负责平衡首先将各Lock Quorum归入两个集合，过载集合和轻载集合，通过两个集合间寻求最优匹配的算法进行负载分流，当最大过载Quorum的过载量低于指定阈值时负责平衡流程结束。
本发明在清华大学计算机系高性能计算技术研究所进行了模拟与测试。测试环境如图2所示，测试首先对比了不使用锁管理系统的单机卷管理软件与依赖锁管理系统的集群卷管理软件在执行相同操作时的性能差异，其次，通过在本所实际使用依赖于该锁管理系统的集群文件系统来检验本发明的可靠性以及可扩展性；最后，使用程序模拟估算负载平衡算法的性能；结果表明，基于SAN的集群分布式锁管理方法能够灵活配置多个主从式Lock Quorum，分别针对名字空间的不同区域提供锁服务，无中心瓶颈，具有良好的性能，高可扩展性以及高可靠性。
附图说明
图1.分布式锁系统中各服务器之间的关系；
图2.分布式锁系统的实现与应用；
图3.Quorum侦测流程；
图4.负责平衡过程；
具体实施方式
基于SAN的集群分布式锁管理方法主要应用于基于共享存储的集群环境。在集群的各节点上设立一个状态服务器State Server，负责包括监测各节点的生灭状态、屏蔽故障节点、维护整个集群在内的各项正常工作，形成一个状态侦测集群State Quorum，负责节点生灭状态的管理；在集群各节点中选择若干节点，各自设立一个锁服务器Lock Server，负责包括对共享数据资源并发访问的控制、保障集群卷管理系统、文件系统或数据库读写查询在内的各项操作的正确执行，维护共享存储系统的一致性并且按照锁更新协议构成每个锁服务子集群Lock Quorum，负责名字空间中读写访问锁的管理。整个分布式锁系统中各服务器之间的关系如图1。
图1为该系统的典型实现，该实现由6个节点形成一个State Quorum，其中共包含两个锁服务子集群Lock Quorum，一个由3个节点构成，另一个由2个节点构成，这两个Lock Quorum分管整个名字空间的不同分区。软件结构如图2，内核态的SCSI驱动、适配卡驱动、目标器模拟驱动构成了一个软件实现的存储区域网络系统，将I/O目标器端的存储资源通过光纤线路，如图中灰线所示，共享给所有节点使用；用户态软件中，State Server负责构成整个StateQuorum，Lock Server负责维护Lock Quorum结构，各个节点通过使用Lock Proxy向LockQuorum提交锁申请；用户态的集群卷管理软件、内核态的集群文件系统为集群锁管理系统的应用，通过统一的接口向Lock Quorum中的Master发起锁请求。
Quorum是由指定数量的Server构成的服务单元，如果Quorum中Server数量高于某阈值，称该Quorum转为正常状态，即Quorate，否则称为探测状态，即Inquorate。Inquorate状态为中间状态，并不向外提供服务，此时Quorum中各Server会继续侦听，接收新Server的加入，直到Server数量达到阈值为止。
本方法中，各节点在State Quorum内分别扮演如下角色：State Master，主服务器，仅存在于Quorate的Quorum中，负责提供相关服务，同步Quorum中各Server的状态和数据，接收其他节点的加入，一个State Quorum有且仅有一个State Master；State Arbitrator，仲裁服务器，仅存在于Inquorate的State Quorum中，为Quorum中所有节点按照选举协议临时选举出来的管理者，其功能与State Master相似，当Quorum中节点数量超过阈值时，State Arbitrator转换为State Master；State Slave，从属服务器，State Quorum中的成员服务器，作为State Master的热备，存储重要数据的副本，参与State Quorum中的投票与决策，如果当前State Master失效，各State Slave能够重新投票，选举出新的StateMaster，保证服务的无缝转移。同理，各节点在Lock Quorum内也分别担任：Lock Master，有且仅有一个；Lock Arbitrator，仅存在与Inquorate的Lock Quorum中；Lock Slave，作为Lock Master的热备。集群中的所有节点，无论是否属于Lock Quorum，都能够向Lock Quorum发起锁请求。
两类Quorum的功能不相同。State Quorum只负责维护集群的结构，检测各节点状态，并不向Quorum外开放服务；Lock Quorum负责维护读写访问锁信息，是本系统中的核心服务单元，向外部提供锁管理服务。与Lock Quorum通信的节点必须安装Lock Agent作为客户端，只有通过Lock Agent节点才能申请读写访问锁。
整个分布式锁系统中只有一个State Quorum，系统中的所有存活节点都是该Quorum的一员。State Quorum中的State Master的功能主要包括：(1)接受其他节点的加入，实时向各State Slave广播State Quorum的信息变更，例如：当前状态是否是Quorate，共有哪些节点已经成为State Quorum成员；(2)State Master会监听各State Slave发送过来的心跳，处理各State Slave的发来的消息，监控其状态，维护集群结构，当一个节点故障时，StateMaster会发起屏蔽操作将该节点从State Quorum中清除；(3)State Master接受本节点其他进程的注册与注销，并负责与各注册单元的通信，及时向其通告本机状态的改变，例如，如果本节点也隶属于某个Lock Quorum，则State Master需要及时响应本节点Lock Server进程的注册，将本节点所在Lock Quorum中其他节点的生灭状态及时传递给该Lock Server。State Quorum中的State Slave的主要功能包括：(1)保持与State Master的同步，监听StateMaster在State Quorum中的广播，在本机维护State Quorum的相关信息；(2)定期向StateMaster发送心跳，报告自己的状态；(3)接受本机其他进程的注册与注销，并负责与各注册单元的通信，及时向其通告本机状态的改变。
系统中的Lock Quorum可以有多个，分别管理名字空间中互不交叠的区域，例如，分管文件系统某目录下的不同的文件集合。Lock Quorum的具体信息是可配置的，例如：系统中一共设立多少个Lock Quorum，每个Lock Quorum具体由哪几个节点构成。Lock Quorum在稳定状态下有且仅有一个Lock Master，有若干个Lock Slave。Lock Quorum中的Lock Master的主要功能是：(1)维护锁持有信息，将名字空间的每个元素看作是一个共享数据资源单位，为每个这样的资源维护一个锁链表，链表中包含所有对该资源已经持有的锁，Lock Master接收来自Lock Agent的锁请求，遍历所请求资源的锁链表，根据锁的兼容性，申请节点对该资源已持有锁的种类、粒度等不同情况作相应处理，例如，分配新的锁、将申请节点已持有的锁与新申请的锁合并、将申请转移到冲突链表，延迟后再处理，等等；(2)负责管理其他节点的登陆，生成并维护Quorate的Lock Quorum，将锁状态的更新实时广播给各个Lock Slave，做到锁更新的同步；(3)随时监听本机的节点相关状态的变化，并对Lock Quorum作出相应调整。Lock Quorum中的Lock Slave的主要功能是：(1)监听Lock Master在本Lock Quorum中的广播，同步维护Lock Master资源锁链表的一个副本，当Lock Master故障时，系统当前资源的锁持有信息依然可以在Lock Slave中找到，通过重新选举流程，新的Lock Master会从Lock Slave中产生并实现服务的无缝迁移；(2)监听本机的节点相关状态的变化，并对Lock Quorum作相应调整。
整个系统，不论是State Quorum，还是Lock Quorum都是可配置的，其配置文件采用Xml的语法。
配置文件的内容包括：
版本、根元素的版本；所述根元素代表整个锁集群，其版本及其名称，用<cluster_version>及<name>表示，根元素的具体内容包括：
<cluster_nodes>标签，其内容包括：
集群中每个节点的标签及其内容，其中包括节点名name、节点优先级rank、节点投票时的权重votes，所述各节点的权重必须满足以下条件：对于进入正常状态，即Quorate状态的State Quorum或Lock Quorum，已经加入其中的节点的权重和必须大于应该加入其中的所有节点权重和的一半，该条件用公式表示为
上式中，集合QUORUM代表当前已经加入State Quorum或Lock Quorum的节点集，集合ALL代表应加入的节点的全集；在缺省情况下，设各节点的权重为1，则Quorate状态成立的条件为当前已加入StateQuorum或Lock Quorum的节点必须多于半数，上述公式退化为
<thudlm_dom>标签，包括：
构成锁服务子集群的所有节点，其属性为：权重weight，描述该锁服务子集群的锁处理能力；代表该锁服务子集群中一个节点的标签<lock_server>，以及每个节点的名称name。
无论是State Quorum，还是Lock Quorum，都采用了主从式结构。因此，当一个节点启动时，都必须进行侦测，如果当前状态为Inquorate的探测状态，大家还必须发起投票选举出仲裁服务器State Arbitrator或Lock Arbitrator，投票的基本思想是比较各节点的rank，各节点分别统计当前能够探测到的Quorum内其他节点的rank，如果其他节点的rank都低于自己，则可以自升级为仲裁服务器，否则，主动放弃候选人资格。一旦投票数超过一个阈值，则Quorum转入正常状态，即Quorate状态，仲裁服务器升级为主服务器。
以State Quorum为例，其中的各节点启动后侦测流程的简易步骤如图3，具体步骤如下：
步骤(1).状态初始化，对集群内各节点同时运行以下操作：
步骤(1.1).读取并分析配置文件，脚本参数，初始化各内存的数据结构，包括：节点当前状态、状态侦测集群的节点链表；
步骤(1.2).开放本节点的服务端口，侦听集群内其他节点的消息；
步骤(1.3).定义节点在本集群中的四种状态为：初始化状态Beginner，仲裁服务器状态Arbitrator，主服务器状态Master，以及从属服务器状态Slave；
步骤(2).把集群中的所有节点读入节点链表，并设定一个游标指针指向该链表的首节点；
步骤(3).若本节点的当前状态为开始状态Beginner或仲裁服务器状态Arbitrator，则执行如下操作：
步骤(3.1).若当前游标指向节点链表的末尾，则把游标指针指向节点链表的首节点
步骤(3.2).发起探测游标所指向的节点的操作，发起连接申请，侦听本节点在集群中的服务端口，持续侦听，直到有事件到来；
步骤(4).若被探测节点发出同意连接的响应，则登录所探测节点，向所探测发出本节点的基本信息，并请求对方的基本信息；
步骤(5).若被探测节点返回其基本信息，则根据不同情况，作以下处理：
若：锁探测节点当前处于初始状态，且本节点的优先级低于被探测节点，则退出在所探测节点上的登录，重置游标指针，重新探测，转步骤(7)；
若：所探测节点为从属服务器则退出在所探测节点上的登录，转步骤(7)；
若：所探测节点当前为仲裁服务器状态，且本节点也为仲裁服务器状态，则根据优先级确定最终候选者，一旦本节点候选失败，则遣散所有本节点上的登录者并勒令登录者转换为初始状态，而本节点转为从属服务器，同时结束本节点的探测流程；
若：所探测节点当前为主服务器状态，则遣散所有在本节点上的登录者，并勒令所有登录者转为初始状态重新探测，而本节点则转为从属服务器状态，结束本节点的探测流程；
若：所探测的节点其状态为未知，则退出在所探测节点上的登录，转步骤(6)；
步骤(6).若本节点探测到节点链表末尾且仍然为初始状态，检查本节点的权重，将本节点转换为Arbitrator；
步骤(7).转步骤(3)，开始下一轮探测；
步骤(8).若本节点收到其他节点的探测请求，则建立连接，发回同意连接的消息；
步骤(9).若本节点收到其他节点的登录信息，则向对方节点发回本节点的具体信息，并作以下处理：
步骤(9.1).若本节点处于初始状态或从属服务器状态下，则转步骤(3)，否则接受对方登录；
步骤(9.2).若本节点已经处于主服务器状态，则结束本节点的探测流程，否则执行步骤(9.3)；
步骤(9.3).若本节点处于仲裁服务器状态，且本集群中的权重已足够使本集群转为Quorate状态，则记录对方节点在本集群中的权重，本节点转为主服务器状态，结束本节点的探测流程；
步骤(10).把事件内容记录入日志，转步骤(3)；
对于Lock Quorum，探测一个节点前还必须确认该节点已经存在于State Quorum中，否则说明该被探测节点为不可用节点，可能已出故障或者由于通信链路问题被隔绝于集群之外。
各个Lock Quorum分管名字空间的不同分段，其服务能力由配置文件中<thudlm_dom>标签的weight属性记录，在系统启动时被读入内存。
整个名字空间在Lock Quorum中被映射到一个水平的哈希地址空间，设哈希值有n位，则整个哈希地址空间可表示为{i|0≤i≤2n}。各个Lock Quorum所管理的名字空间分段信息都记录在资源表RT中。每个RT表项主要包含两个域：(1)哈希地址hash_addr，对应名字空间某数据资源；(2)Lock Quorum的标识lqid，例如，整个集群系统中包含m个Lock Quorum，其lqid分别为1、2、……、m。通过这样的表项，RT才能够将哈希地址空间映射到各个LockQuorum。下文中，令RTi代表RT中由隶属于LQi的表项组成的集合，即RTi＝{p|p∈RT∧p.lqid＝i}；设整个集群系统包含m个Lock Quorum，分别为LQ1、LQ2、……、LQm，各Quorum的权重分别为w1、w2、……、Wm。
各Lock Quorum的Master负责统计本Quorum的负载情况。以LQi为例，每隔周期T为RTi中的每个表项，例如表项p，计算负载值loadp。loadp反应了单位时间内接收到的对p所代表数据资源的锁请求数，计算公式为loadp(T)＝(1-α)×arp+α×loadp(T-1)。其中，arp为当前周期计算得到的单位时间内接收锁请求数；α为历史因子，用于表示loadp历史数值在新计算得到的loadp数值中所占的比例。当一个Lock Quorum所负担的锁管理任务过于繁重时，会触发负载平衡过程，将本Quorum的部分任务分流给其他Quorum，其主要步骤如图4。
负载平衡过程由State Quorum中的State Master完成，它负责接收各Lock Quorum的负载信息，在负载平衡过程完成后，State Master会广播新的RT给State Quorum的所有成员。负载平衡过程按照各Lock Quorum的处理能力，即权重，均衡分布资源，将过载Lock Quorum中的部分RT资源表项分流给轻负载的Lock Quorum。该问题可以看作是装箱问题的扩展，过载服务器中的过载服务量可看成是各个物品，轻载服务器的剩余容量可看作是空箱，当然这里的空箱体积各不相同，而且物品可以分割，增加了复杂度，我们采用贪婪法求其近似解，力求使各物品能够装在最合适的箱子中，减少装箱次数，也就减少了负载平衡任务中的请求消息数。
负载平衡过程如下文所示。其中，我们为每个Lock Quorum维护一个目标链表target_list，用来存放本Lock Quorum过载时分流负载的对方Lock Quorum的lqid，以及分流的负载量，链表元素结构target_info包含三个域：id、loadvalue、next，分别对应lqid，负载量和指向下一个链表元素的指针。要使各个Lock Quorum达到完全的平衡是非常耗费资源的，因此，算法中引入了一个阈值参量Threshold，当过载Lock Quorum的最大过载量低于该阈值时，我们就认为系统达到了一个可接受的近似平衡状态而结束平衡算法；该值越小，平衡结果越精确，但算法耗费的时间也越多，各个Lock Quorum之间为平衡流量而传递的消息也越多。
步骤(1).各锁服务器子集群中的主服务器在时刻T为每个锁服务子集群LQi对应的资源表RTi的每一项按下式计算负载loadp(T)，公式为loadp(T)＝(1-α)×arp+α×loadp(T-1)；
其中：
p为RTi中的某个表项，1≤i≤m，m为锁子集群数；
arp为当前间隔T计算得到的单位时间内接收的锁请求数；
a为历史因子，表示(T-1)周期的负载值loadp(T-1)在T周期中新计算得到的负载loadp(T)中的比例；
步骤(2).各锁服务子集群计算各自的现实负载
1≤i≤m；
步骤(3).状态侦测集群的主服务器通过锁代理收集各个锁服务子集群在同期T内的负载量，进而求出各锁服务子集群按各自权重所应负担的理论负载量post_load_lqi(T)，同时，求出各锁服务子集群的过载负载量delta_lqi(T)，该过载负载量为现实负载量与理论负载量之差，即：delta_lqi(T)＝post_load_lqi(T)-current_load_lqi(T)；
步骤(4).根据所述过载负载量delta_lqi(T)的正负，把各个锁服务子集群分别划分到轻载集合和过载集合；
步骤(5).按以下步骤使负载量近似均衡分布：
步骤(5.1).结束条件判断：当过载集合或轻载集合中其中任何一个为空，或最大过载量低于设定的阈值时则转步骤(5.5)，否则，执行步骤(5.2)；
步骤(5.2).对于过载集合中的每一个元素，在轻载集合中寻求最佳分流匹配，把已匹配成对的从相应集合中去除，并把要分流的负载量记录到相应的过载集合的元素上；
步骤(5.3).对于轻载集合中的每一个元素，在过载集合中寻求最佳负载与分流匹配，并把已匹配的从相应集合中去除，把要分流的负载量仍然记录在过载集合的元素上；
步骤(5.4).结束一轮匹配，转步骤(5.1)；
步骤(5.5).负载分流，遍历过载集合中的每个节点，根据记录的分流信息把相应的流量分流到相应的轻载集合中。
Claims (2)
1.基于存储区域网络SAN的集群分布式锁管理方法，其特征在于，所述方法是在集群的各节点服务器上依次按以下步骤实现的：
步骤(1).集群初始化
步骤(1.1).集群的设定初始化
在集群的各节点上设立一个状态服务器State Server，负责包括监测各节点的生灭状态、屏蔽故障节点、维护整个集群在内的各项正常工作，形成一个状态侦测集群State Quorum，负责节点生灭状态的管理；
在所述集群各节点上选择若干节点，各自设立一个锁服务器Lock Server，负责包括对共享数据资源并发访问的控制、保障集群卷管理系统、文件系统或数据库读写查询在内的各项操作的正确执行，维护共享存储系统的一致性并且按照锁更新协议构成每个锁服务子集群Lock Quorum，负责名字空间中读写访问锁的管理，各个与所述锁服务子集群通信的节点必须安装锁代理Lock Agent作为客户端，只有通过锁代理才能申请读写访问锁；
所述包括状态侦测集群和锁服务子集群在内的各个集群Quorum是由设定数量的服务器构成的一个服务单元，所述集群内的各服务器按照功能不同被分为主服务器Master、仲裁服务器Arbitrator，以及从属服务器Slave，其中：
主服务器仅存在于原先由设定数量的服务器构成的集群中，是随机选择的，仅有一个，负责提供状态监测管理或读写访问锁管理服务服务；
仲裁服务器仅在所述集群未达到设定数量时存在，由此时的所有服务器按照选举协议临时选举出来作管理者用的，当接收该服务器加入后，使服务器总数超过设定阈值时，所选仲裁服务器便转换为主服务器，所在的集群转入正常状态，即Quorate状态，提供正常服务；
从属服务器，为所选主服务器的热备，存储重要数据的副本，参与集群中的投票与决策，在当前的主服务器失败后，新的主服务器由各从属服务器投票选出；
所述锁更新协议是指：各个锁服务子集群分管名字空间的不同分段且互不交叠，独立统计本锁服务子集群的负载情况，并按照服务分别被赋予不同权重值条件下，当一个锁服务子集群所负担的锁管理任务过于繁重时，则向其他锁服务子集群分流即更新名字空间的分段；
步骤(1.2)配置初始化
步骤(1.2.1)配置节点的IP地址、主机名，以及相应的XML配置文件，其中，包括版本、根元素的版本，所述根元素代表整个锁集群，其版本及其名称，用<cluster_version>及<name>表示，根元素具体内容包括：
<cluster_nodes>标签，内容包括：
集群中每个节点的标签及其内容，其中包括节点名name、节点优先级rank、节点投票时的权重votes，所述各节点的权重必须满足以下条件：对于进入正常状态，即Quorate状态的集群，已经加入其中的所有节点的权重和必须大于整个集群系统中所有节点权重和的一半，在缺省情况下，设各节点的权重为1，则Quorate状态成立的条件为当前已加入集群的节点必须多于半数；
<thudlm_dom>标签，包括：
锁服务子集群中节点的权重weight，描述该锁服务子集群的锁处理能力；代表该锁服务子集群中一个节点的标签<lock_server>，以及每个节点的名称name；
步骤(1.2.2).把配置文件分发到集群中的各个节点；
步骤(1.3).状态初始化，按以下步骤建立状态侦测集群：
步骤(1.3.1).对集群内各节点同时运行以下操作：
步骤(1.3.1.1).读取并分析配置文件，脚本参数，初始化各内存的数据结构，包括：节点当前状态、状态侦测集群和锁服务子集群的链表；
步骤(1.3.1.2).开放本节点的服务端口，侦听集群内其他节点的消息；
步骤(1.3.1.3).按以下步骤执行集群探测流程：
步骤(1.3.1.3.1).定义节点在本集群中的四种状态为：初始化状态Beginner，仲裁服务器状态Arbitrator，主服务器状态Master，以及从属服务器状态Slave；
步骤(1.3.1.3.2).把本集群中的所有节点读入节点链表，并设定一个游标指针指向该链表的首节点；
步骤(1.3.1.3.3).若本节点的当前状态为开始状态或仲裁服务器状态，则把游标指针指向节点链表的首节点，并发起探测游标所指向的首节点的操作，发起连接申请，侦听本节点在本集群中的服务端口，持续侦听，直到有事件到来；
步骤(1.3.1.3.4).若被探测节点发出同意连接的响应，则登录所探测节点，向所探测节点发出本节点的基本信息，并根据不同情况，作以下处理：
若：所探测节点当前处于初始状态，且本节点的优先级低于被探测节点，则退出在所探测节点上的登录，重置游标指针，重新探测，转步骤(1.3.1.3.3)；
若：所探测节点为从属服务器则退出在所探测节点上的登录，转步骤(1.3.1.3.3)；
若：所探测节点当前为仲裁服务器状态，且本节点也为仲裁服务器状态，则根据优先级确定最终候选者，一旦本节点候选失败，则遣散所有本节点上的登录者并勒令登录者转换为初始状态，而本节点转为从属服务器状态，结束本节点的探测流程；
若：所探测节点当前为主服务器状态，则遣散所有在本节点上的登录者，并勒令所有登录者转为初始状态重新探测，而本节点则转为从属服务器状态，结束本节点的探测流程；
若：所探测的节点其状态为未知，则退出在所探测节点上的登录；
若本节点探测到节点链表末尾且仍为初始状态，将本节点转换为Arbitrator状态，重新探测，转步骤(1.3.1.3.3)；
步骤(1.3.1.3.5).
若：本节点收到其他节点的探测请求，则建立连接，发回同意连接的消息；
若：本节点处于初始状态或从属服务器状态下，收到其他节点的登录信息，则向对方节点发回本节点的具体信息；
若：本节点处于仲裁服务器状态，且本集群中的权重已足够使本集群转为Quorate时收到其他节点的登录信息，则记录对方节点在本集群中的权重，本节点转为主服务器状态，结束本节点的探测流程；
步骤(1.3.1.3.6).把事件内容记录入日志，转步骤(1.3.1.3.3)；
步骤(1.3.1.3.7).确定各节点在状态侦测集群中是主服务器，还是从属服务器状态的最终形式，由全部或多数存活节点构成状态侦测集群；
步骤(1.3.1.4).作为主服务器的节点轮询检测集群中各节点的心跳信息，确认节点生灭状态，若有新节点加入，则更新本地状态侦测集群的节点链表，同时发送广播消息通知状态侦测集群中其他节点同步更新，若有节点出现故障，则主动屏蔽故障节点；
步骤(1.3.1.5).各节点启动锁代理进程，通过作为锁服务子集群的客户端的锁代理把本地锁请求发送到对应的锁服务子集群；
步骤(1.4).锁服务初始化，建立锁服务子集群，其步骤如下：
步骤(1.4.1).根据所述初始化时读入内存的配置文件信息、节点生灭状态，建立各个锁服务子集群的节点链表；
步骤(1.4.2).查询本节点是否在锁服务子集群中，若属于某个锁服务子集群，则按步骤(1.3.1.3)所述的探测流程，确定本节点是主服务器还是从属服务器，若不属于任何一个锁服务子集群，则退出；
步骤(1.4.3).按以下步骤初始化一个资源表RT：
步骤(1.4.3.1).在锁服务子集群中，把整个名字空间映射到一个水平的哈希地址空间，设哈希值有n位，把整个哈希地址空间表示为{i|0≤i≤2n}；
步骤(1.4.3.2).把各个锁服务子集群锁管理的名字空间分段信息都记录在各个锁服务子集群自己的资源表RT中，其表项为：哈希地址hash_addr，对应名字空间某数据资源；锁服务子集群标识lqid，取值为1、2、3......m，共有m个锁服务子集群，令RTi表示隶属于第i个锁服务子集群LQi的表项组成的集合，用RTi＝{p|p∈RT∧p.lqid＝i}表示，p为RTi中的某个表项，则整个集群系统包含m个锁服务子集群，用LQ1、LQ2、……、LQm表示，各自的权重分别为w1、w2、……、wm；
步骤(2).状态侦测集群按以下步骤在各个锁服务子集群中进行负载均衡：
步骤(2.1).各锁服务器子集群中的主服务器每隔间隔T为每个锁服务子集群LQi对应的资源表RTi的每一项按下式计算负载loadp：loadp(T)＝(1-a)*arp+a*loadp(T-1)；
其中：
arp为当前间隔T计算得到的单位时间内接收的锁请求数；
a为历史因子，表示(T-1)周期的负载值loadp(T-1)在T周期中新计算得到的负载loadp(T)中的比例；
步骤(2.2).状态侦测集群的主服务器通过锁代理收集各个锁服务子集群在同期T内的负载量，进而求出各锁服务子集群按各自权重所应负担的理论负载量，同时，求出各锁服务子集群的过载负载量，该过载负载量为现实负载量与理论负载量之差；
步骤(2.3).根据所述过载负载量的正负，把各个锁服务子集群分别划分到过载集合和轻载集合；
步骤(2.4).按以下步骤使负载量近似均衡分布：
步骤(2.4.1).结束条件判断：当过载集合或轻载集合中其中任何一个为空，或最大过载量低于设定的阈值时则转步骤(2.4.5)，否则，执行步骤(2.4.2)；
步骤(2.4.2).对于过载集合中的每一个元素，在轻载集合中寻求最佳分流匹配，把已匹配成对的从相应集合中去除，并把要分流的负载量记录到相应的过载集合的元素上；
步骤(2.4.3).对于轻载集合中的每一个元素，在过载集合中寻求最佳负载与分流匹配，并把已匹配的从相应集合中去除，把要分流的负载量仍然记录在过载集合的元素上；
步骤(2.4.4).结束一轮匹配，转步骤(2.4.1)；
步骤(2.4.5).负载分流，遍历过载集合中的每个节点，根据记录的分流信息把相应的流量分流到相应的轻载集合中。
2.根据权利要求1所述的基于存储区域网络SAN的集群分布式锁管理方法，其特征在于，对于所述状态侦测集群，初始化时，应选择集群中一个不属于任何锁服务子集群的服务器为主服务器。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2008101038091A CN101252603B (zh) | 2008-04-11 | 2008-04-11 | 基于存储区域网络san的集群分布式锁管理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2008101038091A CN101252603B (zh) | 2008-04-11 | 2008-04-11 | 基于存储区域网络san的集群分布式锁管理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101252603A CN101252603A (zh) | 2008-08-27 |
| CN101252603B true CN101252603B (zh) | 2011-03-30 |
Family
ID=39955785
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2008101038091A Expired - Fee Related CN101252603B (zh) | 2008-04-11 | 2008-04-11 | 基于存储区域网络san的集群分布式锁管理方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101252603B (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102624911A (zh) * | 2012-03-14 | 2012-08-01 | 中山大学 | 一种基于集群的可视媒体存储系统 |
Families Citing this family (70)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101674257B (zh) * | 2008-09-10 | 2014-03-05 | 阿里巴巴集团控股有限公司 | 一种消息存储方法、装置及一种消息处理系统 |
| US8443062B2 (en) | 2008-10-23 | 2013-05-14 | Microsoft Corporation | Quorum based transactionally consistent membership management in distributed storage systems |
| CN101610287B (zh) * | 2009-06-16 | 2012-03-14 | 浙江大学 | 一种应用于分布式海量存储系统的负载均衡方法 |
| US8428612B2 (en) * | 2009-07-09 | 2013-04-23 | Via Telecom, Inc. | Apparatuses, systems, and methods for prioritized load balancing |
| CN101631328B (zh) * | 2009-08-14 | 2011-11-16 | 北京星网锐捷网络技术有限公司 | 一种对共享资源互斥访问的同步方法、装置和网络设备 |
| CN101702721B (zh) * | 2009-10-26 | 2011-08-31 | 北京航空航天大学 | 一种多集群系统的可重组方法 |
| US8359293B2 (en) * | 2010-04-19 | 2013-01-22 | Nec Corporation | Processing procedure management device, processing procedure management method, processing procedure management system, and processing procedure management program |
| CN101853269B (zh) * | 2010-04-29 | 2012-01-11 | 中国人民解放军国防科学技术大学 | 分布数据更新的一致性处理方法 |
| CN102339283A (zh) * | 2010-07-20 | 2012-02-01 | 中兴通讯股份有限公司 | 集群文件系统访问控制方法及集群节点 |
| US8443078B2 (en) * | 2010-08-20 | 2013-05-14 | International Business Machines Corporation | Method of determining equivalent subsets of agents to gather information for a fabric |
| CN102455991B (zh) * | 2010-10-28 | 2013-11-27 | 无锡江南计算技术研究所 | 计算机状态更新方法、装置及分布式系统 |
| CN102025550A (zh) * | 2010-12-20 | 2011-04-20 | 中兴通讯股份有限公司 | 一种分布式集群中数据管理的系统和方法 |
| CN102298539A (zh) * | 2011-06-07 | 2011-12-28 | 华东师范大学 | 一种用于分布式并行处理的共享资源调度方法及系统 |
| CN102308559B (zh) * | 2011-07-26 | 2014-04-02 | 华为技术有限公司 | 一种用于集群计算机系统的投票仲裁方法及装置 |
| CN102955801B (zh) * | 2011-08-25 | 2017-06-16 | 中兴通讯股份有限公司 | 基于分布式数据库系统的数据控制方法及系统 |
| CN102340543B (zh) * | 2011-10-18 | 2013-12-04 | 华为技术有限公司 | 选择系统主节点的方法和设备 |
| JP5927871B2 (ja) * | 2011-11-30 | 2016-06-01 | 富士通株式会社 | 管理装置、情報処理装置、管理プログラム、管理方法、プログラムおよび処理方法 |
| CN102546652B (zh) * | 2012-01-29 | 2015-05-13 | 沈文策 | 一种服务器负载平衡系统及方法 |
| WO2013116979A1 (zh) * | 2012-02-06 | 2013-08-15 | 华为技术有限公司 | 一种在分布式集群系统中传播节点状态信息的方法及系统 |
| CN102681892B (zh) * | 2012-05-15 | 2014-08-20 | 西安热工研究院有限公司 | Key-Value型单写多读锁池软件模块及其运行方法 |
| CN103023992A (zh) * | 2012-11-28 | 2013-04-03 | 江苏乐买到网络科技有限公司 | 海量数据的分布式存储方法 |
| CN103117878A (zh) * | 2013-01-30 | 2013-05-22 | 浪潮电子信息产业股份有限公司 | 一种基于Nagios的分布式监控系统的设计方法 |
| CN103347086B (zh) * | 2013-07-11 | 2016-06-29 | 南京大学 | 基于分布式协商算法的协同内核构建方法 |
| CN103458045B (zh) * | 2013-09-13 | 2017-04-19 | 汉柏科技有限公司 | 分布式集群的动态部署方法和系统 |
| CN103501338B (zh) * | 2013-09-30 | 2017-04-05 | 华为技术有限公司 | 一种锁恢复方法、设备及网络文件系统 |
| CN103516556A (zh) * | 2013-10-23 | 2014-01-15 | 北京国双科技有限公司 | 分布式系统及其控制方法和装置 |
| CN103634401B (zh) * | 2013-12-03 | 2015-11-25 | 北京京东尚科信息技术有限公司 | 一种存储数据副本的方法和终端装置以及服务器装置 |
| CN103647820B (zh) * | 2013-12-09 | 2016-11-23 | 华为数字技术（苏州）有限公司 | 用于分布式集群系统的仲裁方法及仲裁装置 |
| CN104753987B (zh) * | 2013-12-26 | 2019-03-01 | 北京东方通科技股份有限公司 | 一种分布式会话管理方法及系统 |
| CN104954411A (zh) * | 2014-03-31 | 2015-09-30 | 腾讯科技（深圳）有限公司 | 分布式系统共享网络资源的方法、终端及系统 |
| CN105354108B (zh) * | 2014-08-22 | 2020-01-07 | 中兴通讯股份有限公司 | 一种数据备份方法及节点 |
| CN104320464B (zh) * | 2014-10-27 | 2017-10-10 | 华为技术有限公司 | 分布式集群重配方法和装置 |
| HUE042424T2 (hu) * | 2014-11-12 | 2019-07-29 | Huawei Tech Co Ltd | Zárolás kiszolgáló meghibásodásának feldolgozási eljárása és rendszere egy elosztott rendszerben |
| CN104391901B (zh) * | 2014-11-14 | 2017-07-14 | 北京网视通联科技有限公司 | 一种存储单元网络大数据基础构架平台及其文件存取方法 |
| CN104796958B (zh) * | 2015-03-12 | 2016-04-20 | 中南大学 | 基于Quorum系统的无线传感器网络的介质访问控制方法 |
| CN106155780B (zh) | 2015-04-02 | 2020-01-31 | 阿里巴巴集团控股有限公司 | 一种基于时间的节点选举方法及装置 |
| CN105007233B (zh) * | 2015-07-13 | 2018-02-27 | 互联网域名系统北京市工程研究中心有限公司 | 一种基于dhcp服务器集群负载分配地址的方法 |
| CN105069019B (zh) * | 2015-07-14 | 2018-07-06 | 惠龙易通国际物流股份有限公司 | 数据库无间断更新方法及系统 |
| CN106375359B (zh) * | 2015-07-23 | 2019-11-26 | 腾讯科技（深圳）有限公司 | 一种应用数据的处理方法、装置和系统 |
| CN105511966B (zh) * | 2015-12-22 | 2019-08-16 | 深圳供电局有限公司 | 一种用于数据库集群业务分割优化的方法和系统 |
| CN105653406B (zh) * | 2015-12-31 | 2019-05-24 | 华为技术有限公司 | 一种管理分布式存储系统的方法及分布式存储系统 |
| CA2963365C (en) | 2015-12-31 | 2019-02-05 | Lei Chen | Data write method, apparatus, and system |
| CN106991008B (zh) * | 2016-01-20 | 2020-12-18 | 华为技术有限公司 | 一种资源锁管理方法、相关设备及系统 |
| CN107347084B (zh) * | 2016-05-05 | 2020-08-25 | 华为技术有限公司 | 分布式锁管理的方法、装置及系统 |
| CN106027634B (zh) | 2016-05-16 | 2019-06-04 | 白杨 | 消息端口交换服务系统 |
| CN105915644B (zh) * | 2016-06-17 | 2019-12-06 | 北京汉唐自远技术股份有限公司 | 一种服务器负载均衡方法 |
| US10432531B2 (en) * | 2016-06-28 | 2019-10-01 | Paypal, Inc. | Tapping network data to perform load balancing |
| CN106293934B (zh) * | 2016-07-19 | 2019-02-01 | 浪潮(北京)电子信息产业有限公司 | 一种集群系统管理优化方法及平台 |
| CN107547252B (zh) * | 2017-06-29 | 2020-12-04 | 新华三技术有限公司 | 一种网络故障处理方法和装置 |
| CN109905286B (zh) * | 2017-12-11 | 2021-10-12 | 北京京东乾石科技有限公司 | 一种监控设备运行状态的方法和系统 |
| CN108134712B (zh) * | 2017-12-19 | 2020-12-18 | 海能达通信股份有限公司 | 一种分布式集群脑裂的处理方法、装置及设备 |
| CN108037930A (zh) * | 2017-12-25 | 2018-05-15 | 郑州云海信息技术有限公司 | 一种Lustre文件系统的部署方法、装置及设备 |
| CN108234637A (zh) * | 2017-12-29 | 2018-06-29 | 广州品唯软件有限公司 | 一种基于zookeeper实现负载均衡的方法和系统 |
| CN108415951B (zh) * | 2018-02-02 | 2022-01-11 | 广东睿江云计算股份有限公司 | 一种数据库控制方法和系统 |
| CN108717379B (zh) * | 2018-05-08 | 2023-07-25 | 平安证券股份有限公司 | 电子装置、分布式任务调度方法及存储介质 |
| CN108650320B (zh) * | 2018-05-15 | 2021-05-11 | 北京中创腾锐技术有限公司 | 一种集群环境下同构级联设备配置文件同步方法 |
| CN108881489A (zh) * | 2018-08-03 | 2018-11-23 | 高新兴科技集团股份有限公司 | 一种分布式服务的协调系统及方法 |
| KR20200019420A (ko) | 2018-08-14 | 2020-02-24 | 에스케이하이닉스 주식회사 | 입력데이터를 분산저장하기 위한 메모리 시스템 및 데이터 처리 시스템 |
| CN109766324A (zh) * | 2018-12-14 | 2019-05-17 | 东软集团股份有限公司 | 分布式锁的控制方法、装置、可读存储介质及电子设备 |
| CN110719504A (zh) * | 2019-09-19 | 2020-01-21 | 天脉聚源(杭州)传媒科技有限公司 | 虚拟观众席的数据处理系统和方法 |
| CN112583626B (zh) * | 2019-09-30 | 2023-02-28 | 阿里巴巴集团控股有限公司 | 基于分布式锁的信息处理方法、设备及计算机可读介质 |
| CN111045950B (zh) * | 2019-12-16 | 2023-06-30 | 上海钧正网络科技有限公司 | 性能问题点确定方法、装置、数据分析系统及存储介质 |
| CN113127210B (zh) * | 2019-12-31 | 2024-03-29 | 阿里巴巴集团控股有限公司 | 一种分布式系统的存储管理方法、装置及存储介质 |
| CN111309549B (zh) * | 2020-02-03 | 2023-04-21 | 北京字节跳动网络技术有限公司 | 监控方法、系统、可读介质及电子设备 |
| CN111735976B (zh) * | 2020-08-20 | 2020-11-20 | 武汉生之源生物科技股份有限公司 | 基于检测设备的数据结果自动展示方法 |
| CN112637268B (zh) * | 2020-11-30 | 2022-03-18 | 广州大学 | 射电天文数据存储一致性保障方法、装置、系统及存储介质 |
| CN112835982B (zh) * | 2021-02-26 | 2023-03-24 | 浪潮云信息技术股份公司 | 一种基于分布式数据库的表锁实现方法 |
| CN114285865B (zh) * | 2021-12-28 | 2023-08-08 | 天翼云科技有限公司 | 共享云硬盘的访问权限控制系统 |
| CN114039978B (zh) * | 2022-01-06 | 2022-03-25 | 天津大学四川创新研究院 | 一种去中心化的PoW算力集群部署方法 |
| CN115827757B (zh) * | 2022-11-30 | 2024-03-12 | 西部科学城智能网联汽车创新中心(重庆)有限公司 | 一种对多HBase集群的数据操作方法及装置 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1786918A (zh) * | 2004-12-10 | 2006-06-14 | 惠普开发有限公司 | 分布式锁 |
| CN101013381A (zh) * | 2007-01-26 | 2007-08-08 | 华中科技大学 | 基于对象存储系统的分布式锁 |
-
2008
- 2008-04-11 CN CN2008101038091A patent/CN101252603B/zh not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1786918A (zh) * | 2004-12-10 | 2006-06-14 | 惠普开发有限公司 | 分布式锁 |
| CN101013381A (zh) * | 2007-01-26 | 2007-08-08 | 华中科技大学 | 基于对象存储系统的分布式锁 |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102624911A (zh) * | 2012-03-14 | 2012-08-01 | 中山大学 | 一种基于集群的可视媒体存储系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101252603A (zh) | 2008-08-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101252603B (zh) | 基于存储区域网络san的集群分布式锁管理方法 | |
| US9201742B2 (en) | Method and system of self-managing nodes of a distributed database cluster with a consensus algorithm | |
| US11113150B2 (en) | Distributing data on distributed storage systems | |
| Kakivaya et al. | Service fabric: a distributed platform for building microservices in the cloud | |
| CN106233264B (zh) | 使用可变条带大小的文件存储装置 | |
| US20180096045A1 (en) | Large distributed database clustering systems and methods | |
| US8484510B2 (en) | Enhanced cluster failover management | |
| CN103399894A (zh) | 一种基于共享存储池的分布式事务处理方法 | |
| US11263270B1 (en) | Heat balancing in a distributed time-series database | |
| CN109189855A (zh) | 基于分布存储技术的数据同步方法及终端设备 | |
| US11409771B1 (en) | Splitting partitions across clusters in a time-series database | |
| CN115080436B (zh) | 测试指标确定方法、装置、电子设备及存储介质 | |
| Lakhani et al. | Fault administration by load balancing in distributed SDN controller: A review | |
| Guo et al. | Fast replica recovery and adaptive consistency preservation for edge cloud system | |
| US10970177B2 (en) | Methods and systems of managing consistency and availability tradeoffs in a real-time operational DBMS | |
| Lima et al. | A geographical-aware state deployment service for Fog Computing | |
| US11366598B1 (en) | Dynamic lease assignments in a time-series database | |
| CN115934819A (zh) | 一种工业时序数据库通用分布式扩展方法 | |
| US10666724B1 (en) | Geo-replicated IoT hub | |
| Dongo et al. | Distributed file system for ndn: an iot application | |
| Rajaei et al. | SBDC: smart building data center for IoT, EDGE, and 5G | |
| Shen | Distributed storage system model design in internet of things based on hash distribution | |
| Lin et al. | An optimized multi-Paxos protocol with centralized failover mechanism for cloud storage applications | |
| Tripathy et al. | A comparative analysis of performance of shared memory cluster computing interconnection systems | |
| Chockler et al. | Aquarius: A data-centric approach to corba fault-tolerance |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20110330 Termination date: 20160411 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |