CN104765661B - 一种云存储服务中元数据服务节点的多节点热备方法 - Google Patents
一种云存储服务中元数据服务节点的多节点热备方法 Download PDFInfo
- Publication number
- CN104765661B CN104765661B CN201410843823.0A CN201410843823A CN104765661B CN 104765661 B CN104765661 B CN 104765661B CN 201410843823 A CN201410843823 A CN 201410843823A CN 104765661 B CN104765661 B CN 104765661B
- Authority
- CN
- China
- Prior art keywords
- host node
- metadata
- standby host
- caching
- lsn
- 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
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请公开了一种云存储服务中元数据服务节点的多节点热备方法，包括：A、在云存储系统中设置至少3台元数据服务节点，从中选出一台作为主机节点，其他的作为备机节点；B、主机节点提供元数据更新服务，并将更新后的元数据同步到备机节点；C、当主机节点发生故障时，从备机节点中选举出一台作为新的主机节点。本申请方案可以有效防止元数据服务节点的单点故障，从而提高整个系统的数据安全性。
Description
技术领域
本申请涉及计算机网络技术领域，特别涉及云存储技术，尤其涉及一种云存储服务中元数据服务节点的多节点热备方法。
背景技术
随着信息化程度的不断提高，全球数据日益膨胀。面对当前海量数据存储需求，传统的存储系统在容量和性能的扩展上存在瓶颈。云存储以其扩展性强、性价比高、容错性好等优势得到了业界的广泛认同。云存储是通过集群应用、网格技术、分布式文件系统等，将网络中大量类型各异的存储设备整合起来，并对外提供数据存储和业务访问功能的系统。简单来说，云存储是对虚拟化存储资源的管理和使用。云存储是存储领域一个新的概念，其目前已成为学术界和工业界的一个研究热点。
区别于传统的存储技术，云存储提供了更好的可扩展性，当需增加存储能力时，只需添加服务器即可实现，而不需要对存储系统的结构进行重新设计；同时随着存储能力的增加，云存储系统的性能不会下降。目前，云存储的兴起正在颠覆传统的存储系统架构，其正以良好的可扩展性、性价比和容错性等优势得到业界的广泛认同。
为提高云存储系统的访问能力，在云存储服务端将元数据和数据分开存储，其中元数据集中存储在元数据服务节点，而数据按一定大小分块的组织方式存储于多个存储服务节点(Chunk)，该组织方式提供高效数据访问的基础，同一文件不同数据块可以并发访问。由于元数据与数据分离，实际对于数据的读写操作不会直接通过元数据服务节点，这就降低了元数据服务节点的负载。
元数据服务节点存储着文件大小，存放位置等文件属性信息。元数据服务节点对实际存放在存储服务节点中的数据起着组织，控制的作用，一旦元数据丢失，文件找回十分麻烦，甚至数据丢失不能找回。特别是对于一些实时性比较强，数据可靠性比较高的领域运用的云存储系统，需要加强元数据服务节点的容灾能力。
发明内容
本申请提供了一种云存储服务中元数据服务节点的多节点热备方法，可以有效防止元数据服务节点的单点故障，从而提高整个系统的数据安全性。
本申请实施例提供的一种云存储服务中元数据服务节点的多节点热备方法，包括：
A、在云存储系统中设置至少3台元数据服务节点，从中选出一台作为主机节点，其他的作为备机节点；
B、主机节点提供元数据更新服务，并将更新后的元数据同步到备机节点；
C、当主机节点发生故障时，从备机节点中选举出一台作为新的主机节点。
较佳地，步骤B包括：
B1、主机节点正确处理该数据更新请求后，将需要更新的元数据保存在第一缓存中；将需要更新的元数据包装成一个个的对象，形成对象列表；将形成的对象列表放入一个待办理业务中，生成一个远程调用请求也放入所述待办理业务中，并给所述待办理业务分配一个顺序增长的待办理业务标识；所述远程调用请求中除了包含数据更新请求的所有信息，还包括分配给文件的存储位置信息；
B2、当第一缓存中的元数据的量超过第一阈值或者经过预定时间后，触发主机节点处理待办理业务：将对象列表中的内容加入到相对于第一缓存更大的第二缓存中；将远程调用请求加入链表T-link中，并将对象列表中的内容加入到相对于第一缓存更大的第二缓存中；更新cur_lsn的值为待办理业务标识；
B3、主机节点将T-link中的远程调用请求以异步的方式广播到集群中的所有备机节点；
B4、当第二缓存中的元数据的量超过第二阈值或者经过预定时间后，将第二缓存中的所有待更新元数据以及cur_lsn刷新到本地磁盘。
较佳地，步骤B3进一步包括：主机节点将远程调用请求以异步方式保存到本地日志文件中。
较佳地，步骤B4之后进一步包括：
B5、备机节点接收到主机节点广播过来的远程调用请求；
B6、备机节点对所述远程调用请求进行处理，将处理后生成的需要更新的元数据将保存在第三缓存中；将需要更新的元数据包装成一个个的对象，形成对象列表，将形成的对象列表放入一个待办理业务中，生成一个远程调用请求也放入所述待办理业务中，并给所述待办理业务分配一个顺序增长的待办理业务标识；
B7、当第三缓存中的元数据的量超过第三阈值或者经过预定时间后，触发备机节点处理待办理业务：将对象列表中的内容加入到相对于第三缓存更大的第四缓存中；
B8、当第四缓存中的元数据的量超过第四阈值或者经过预定时间后，将第四缓存中的所有待更新元数据以及cur_lsn刷新到本地磁盘。
较佳地，步骤B4进一步包括：备机节点将远程调用请求以异步方式写入到本地日志文件中。
较佳地，所述备机节点将远程调用请求以异步方式写入到本地日志文件中包括：备机节点检查待办理业务标识是否为备机节点下的cur_lsn+1，如果是，备机节点将远程调用请求以异步方式写入到本地日志文件中，否则备机节点报错。
较佳地，所述步骤A中，将cur_lsn的值最大的元数据服务节点作为主机节点，其他的元数据服务节点作为备机节点。
较佳地，步骤A进一步包括：每一个元数据服务节点分配判断本地日志文件中是否存在大于本地cur_lsn的远程调用请求标识，若是，将本地日志文件中的所有远程调用请求标识大于cur_lsn的远程调用请求在本机重做一次数据同步操作。
较佳地，该方法进一步包括：主机节点发现任一个备机节点的cur_lsn比自己的最大远程调用请求标识小，进行如下操作：将所述备机节点从异步广播队列中剔除，添加到同步队列中；通过专门的同步线程，将大于备机节点的cur_lsn的所有请求同步到备机节点；
较佳地，该方法进一步包括：如果主机节点发现本地日志文件中最小的序列号大于备机节点的cur_lsn+1，那么报错，将备机节点中的本地日志文件截断至主机节点的序列号的地方，并使该备机节点退出该服务进程。
从以上技术方案可以看出，主机节点提供元数据更新服务，并将更新后的元数据同步到备机节点。当主机节点发生故障时，从备机节点中选举出一台作为新的主机节点。本申请还提供了数据同步异常的处理方法。通过多节点热备，可以有效防止元数据服务节点的单点故障，从而提高整个系统的数据安全性。
附图说明
图1为本申请实施例提供的一种云存储服务中元数据服务节点的多节点热备方法流程示意图；
图2为图1所示流程中步骤102的具体执行过程示意图。
具体实施方式
本申请技术方案的设计思想是：在云存储系统中设置至少3台元数据服务节点，从中选出一台作为主机节点(命名为master节点)，其他的作为备机节点(命名为slave节点)。主机节点提供元数据更新服务，例如创建文件夹，删除文件夹，修改文件夹名字，创建文件，修改文件，修改文件等服务(读取文件夹属性，读取文件属性等操作不涉及数据更新)。多节点热备就是将更新后的元数据同步到备机节点。当主机节点发生故障时，从备机节点中选举出一台作为新的主机节点。
为使本申请技术方案的技术原理、特点以及技术效果更加清楚，以下结合具体实施例对本申请技术方案进行详细阐述。
云存储系统是实时系统，针对单一元数据服务节点而言，数据访问频率非常高，因此对于正在运行中的元数据服务节点，接收到请求，正确处理完毕后，将需要更新的元数据保存在第一缓存中。待第一缓存中数据达到第一阈值或者经过一段时间后，第一缓存中的数据才会刷新到本地硬盘。
元数据服务端接收到一个数据更新请求(request)，主机节点正确处理该数据更新请求后，将脏数据(需要更新的元数据)包装成一个个的对象(object)，形成对象列表(object_list)，放入一个待办理业务中。对于接收到的request，结合一个顺序增长的待办理业务标识序列号(lsn)，组成一个远程调用请求(rpc_request)(rpc_request中除了包含request所有的信息，还包括一些必要附加信息，如分配给文件的存储位置信息等，这些信息在主机节点确定后，只需要同步到备机节点就可以了。)也放在transaction中。待第一缓存中数据达到一定数量或者经过一段时间后，元数据服务节点触发处理当前待办理业务，在处理transaction时，一方面将rpc_request加入链表T-link中，另一方面将object_list中的内容加入到相对于第一缓存更大的第二缓存中。更新cur_lsn的值为该请求的序列号。其中，cur_lsn表示最后一次已经写入磁盘(或数据库)的lsn。
在另一个线程中，主机节点将T-link中的rpc_request以异步的方式广播到集群中的所有备机节点。然后将rpc_request以异步方式保存到本地日志文件(log)中(对于传统机械式硬盘,日志文件在初始化时直接设置为8的倍数大小，以得到一个在磁盘中物理位置连续的文件。读写时采用顺序性，这样提升访问磁盘的效率.然而对于新式的固态硬盘(SSD)硬盘，则不用这一步。一个文件大约8M大小的样子，写完一个文件后继续生成一个新的文件)。等到一定时间(这里指的是第二缓存中有脏数据的情况下)或者第二缓存中的脏数据达到第二阈值，将触发脏数据的刷新操作：将第二缓存中的所有脏数据刷新到本地磁盘(元数据存储可以以二进制文件的形式存放，也可以以数据库存放)，同时需要刷新到本地磁盘的还有cur_lsn。
对于备机节点而言，接收到主机节点广播过来的rpc_request请求，首先将rpc_request以异步方式写入到本地日志文件中(写入的时候需要检查lsn_id是否刚好是备机节点下的cur_lsn+1(备机节点的cur_lsn表示上一次数据同步的业务标识)，如果是，写入，如果不是将报错)。然后对rpc_request请求处理。处理后生成的脏数据同样包装成一个个的object，形成object_list。包装成transaction。同时还包含在transaction中的还有rpc_request。在备机节点处理transaction时，object_list中的object加入到更大的缓存cache。当cache中的脏数据达到一定数量或者经过一段时间后(这里指的在cache中有脏数据的情况下)，将cache中的脏数据全部flush到本地磁盘。同时flush到本地磁盘的还有cur_lsn。
针对多个元数据服务节点，系统启动后第一件事就是多台元数据服务节点中选出主机节点和备机节点。主机节点和备机节点的选举过程不是本申请的重点，可以采用现有技术中任意一种从多台可互换节点中选举主机节点的方法。例如，可以参考cur_lsn的值，将cur_lsn的值最大的元数据服务节点作为主机节点，其他的作为备机节点。本申请实施例中，选出一台主机节点(命名为master节点)，其他的为备机节点(命名为slave节点)。待主机节点和备机节点身份决定后，考虑可能会因为rpc_request和脏数据同步时机不一致而导致本地log和元数据不一致。因此，必须根据元数据中的cur_lsn和本地log的rpc_request中的序列号比较。将本地log中所有序列号大于cur_lsn的rpc_request在本机重做一次。待集群中所有的节点都做完这个操作后，系统开始正常工作。
如果主机节点发现(例如，主机节点可以通过发送请求到备机询问备机cur_lsn是多少)备机节点的cur_lsn比自己的最大序列号小，表明该备机节点的数据不同步，应当进行同步处理。这时将备机节点从异步广播队列中剔除，添加到同步队列中。通过专门的同步线程，将大于备机节点的cur_lsn的所有rpc_request同步到备机节点。如果发现本地log中最小的序列号大于备机节点的cur_lsn+1，那么报错，这个时候需要将备机节点中的本地log截断至主机节点的序列号的地方，退出该服务进程并由其他的进程再将元数据服务拉起来。
如果本地log文件太多(超过1000个)，需要删除旧的本地log。
本申请实施例提供的一种云存储服务中元数据服务节点的多节点热备方法流程如图1所示，包括如下步骤：
步骤101：在云存储系统中设置至少3台元数据服务节点，从中选出一台作为主机节点，其他的作为备机节点；
步骤102：主机节点提供元数据更新服务，并将更新后的元数据同步到备机节点；
步骤103：当主机节点发生故障时，从备机节点中选举出一台作为新的主机节点。
根据本申请的另一实施例，步骤102的具体执行过程如图2所示，包括如下步骤：
步骤102-1：主机节点正确处理该数据更新请求后，将需要更新的元数据保存在第一缓存中；将需要更新的元数据包装成一个个的对象，形成对象列表；将形成的对象列表放入一个待办理业务中，生成一个远程调用请求也放入所述待办理业务中，并给所述待办理业务分配一个顺序增长的待办理业务标识。
所述远程调用请求中除了包含数据更新请求的所有信息，还包括分配给文件的存储位置信息。
步骤102-2：当第一缓存中的元数据的量超过第一阈值或者经过预定时间后，触发主机节点处理待办理业务：将对象列表中的内容加入到相对于第一缓存更大的第二缓存中；将远程调用请求加入链表T-link中，并将对象列表中的内容加入到相对于第一缓存更大的第二缓存中；更新cur_lsn的值为待办理业务标识；
步骤102-3：主机节点将T-link中的远程调用请求以异步的方式广播到集群中的所有备机节点；
步骤102-4：当第二缓存中的元数据的量超过第二阈值或者经过预定时间后，将第二缓存中的所有待更新元数据以及cur_lsn刷新到本地磁盘。
根据本申请的另一实施例，步骤102-3进一步包括：主机节点将远程调用请求以异步方式保存到本地日志文件中。
根据本申请的另一实施例，步骤102-4之后进一步包括：
步骤102-5：备机节点接收到主机节点广播过来的远程调用请求；
步骤102-6：备机节点对所述远程调用请求进行处理，将处理后生成的需要更新的元数据将保存在第三缓存中；将需要更新的元数据包装成一个个的对象，形成对象列表，将形成的对象列表放入一个待办理业务中，生成一个远程调用请求也放入所述待办理业务中，并给所述待办理业务分配一个顺序增长的待办理业务标识；
步骤102-7：当第三缓存中的元数据的量超过第三阈值或者经过预定时间后，触发备机节点处理待办理业务：将对象列表中的内容加入到相对于第三缓存更大的第四缓存中；
步骤102-8：当第四缓存中的元数据的量超过第四阈值或者经过预定时间后，将第四缓存中的所有待更新元数据以及cur_lsn刷新到本地磁盘。
根据本申请的另一实施例，步骤102-4进一步包括：备机节点将远程调用请求以异步方式写入到本地日志文件中。
根据本申请的另一实施例，所述备机节点将远程调用请求以异步方式写入到本地日志文件中包括：备机节点检查待办理业务标识是否为备机节点下的cur_lsn+1，如果是，备机节点将远程调用请求以异步方式写入到本地日志文件中，否则备机节点报错。
根据本申请的另一实施例，所述步骤101中，将cur_lsn的值最大的元数据服务节点作为主机节点，其他的元数据服务节点作为备机节点。
根据本申请的另一实施例，步骤101进一步包括：每一个元数据服务节点分配判断本地日志文件中是否存在大于本地cur_lsn的远程调用请求标识，若是，将本地日志文件中的所有远程调用请求标识大于cur_lsn的远程调用请求在本机重做一次数据同步操作。
根据本申请的另一实施例，该方法进一步包括：主机节点发现任一个备机节点的cur_lsn比自己的最大远程调用请求标识小，进行如下操作：将所述备机节点从异步广播队列中剔除，添加到同步队列中；通过专门的同步线程，将大于备机节点的cur_lsn的所有rpc_request同步到备机节点；
根据本申请的另一实施例，该方法进一步包括：如果主机节点发现本地日志文件中最小的序列号大于备机节点的cur_lsn+1，那么报错，将备机节点中的本地日志文件截断至主机节点的序列号的地方，并使该备机节点退出该服务进程。
以上所述仅为本申请的较佳实施例而已，并不用以限制本申请的保护范围，凡在本申请技术方案的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。
Claims (9)
1.一种云存储服务中元数据服务节点的多节点热备方法，其特征在于，包括：
A、在云存储系统中设置至少3台元数据服务节点，从中选出一台作为主机节点，其他的作为备机节点；
B、主机节点提供元数据更新服务，并将更新后的元数据同步到备机节点；
C、当主机节点发生故障时，从备机节点中选举出一台作为新的主机节点；
步骤B包括：
B1、主机节点正确处理数据更新请求后，将需要更新的元数据保存在第一缓存中；将需要更新的元数据包装成一个个的对象，形成对象列表；将形成的对象列表放入一个待办理业务中，生成一个远程调用请求也放入所述待办理业务中，并给所述待办理业务分配一个顺序增长的待办理业务标识；所述远程调用请求中除了包含数据更新请求的所有信息，还包括分配给文件的存储位置信息；
B2、当第一缓存中的元数据的量超过第一阈值或者经过预定时间后，触发主机节点处理待办理业务：将对象列表中的内容加入到相对于第一缓存更大的第二缓存中；将远程调用请求加入链表T-link中，并将对象列表中的内容加入到相对于第一缓存更大的第二缓存中；更新cur_lsn的值；所述cur_lsn表示最后一次写入的待办理业务标识；
B3、主机节点将T-link中的远程调用请求以异步的方式广播到集群中的所有备机节点；
B4、当第二缓存中的元数据的量超过第二阈值或者经过预定时间后，将第二缓存中的所有待更新元数据以及cur_lsn刷新到本地磁盘。
2.根据权利要求1所述的方法，其特征在于，步骤B3进一步包括：主机节点将远程调用请求以异步方式保存到本地日志文件中。
3.根据权利要求2所述的方法，其特征在于，步骤B4之后进一步包括：
B5、备机节点接收到主机节点广播过来的远程调用请求；
B6、备机节点对所述远程调用请求进行处理，将处理后生成的需要更新的元数据将保存在第三缓存中；将需要更新的元数据包装成一个个的对象，形成对象列表，将形成的对象列表放入一个待办理业务中，生成一个远程调用请求也放入所述待办理业务中，并给所述待办理业务分配一个顺序增长的待办理业务标识；
B7、当第三缓存中的元数据的量超过第三阈值或者经过预定时间后，触发备机节点处理待办理业务：将对象列表中的内容加入到相对于第三缓存更大的第四缓存中；
B8、当第四缓存中的元数据的量超过第四阈值或者经过预定时间后，将第四缓存中的所有待更新元数据以及cur_lsn刷新到本地磁盘。
4.根据权利要求3所述的方法，其特征在于，步骤B4进一步包括：备机节点将远程调用请求以异步方式写入到本地日志文件中。
5.根据权利要求4所述的方法，其特征在于，所述备机节点将远程调用请求以异步方式写入到本地日志文件中包括：备机节点检查待办理业务标识是否为备机节点下的cur_lsn+1，如果是，备机节点将远程调用请求以异步方式写入到本地日志文件中，否则备机节点报错。
6.根据权利要求4或5所述的方法，其特征在于，所述步骤A中，所述从中选出一台作为主机节点，其他的作为备机节点包括：将cur_lsn的值最大的元数据服务节点作为主机节点，其他的元数据服务节点作为备机节点。
7.根据权利要求6所述的方法，其特征在于，步骤A进一步包括：每一个元数据服务节点分配判断本地日志文件中是否存在大于本地cur_lsn的远程调用请求标识，若是，将本地日志文件中的所有远程调用请求标识大于cur_lsn的远程调用请求在本机重做一次数据同步操作。
8.根据权利要求6所述的方法，其特征在于，该方法进一步包括：主机节点发现任一个备机节点的cur_lsn比自己的最大远程调用请求标识小，进行如下操作：将所述备机节点从异步广播队列中剔除，添加到同步队列中；通过专门的同步线程，将大于备机节点的cur_lsn的所有请求同步到备机节点。
9.根据权利要求6所述的方法，其特征在于，该方法进一步包括：如果主机节点发现本地日志文件中最小的序列号大于备机节点的cur_lsn+1，那么报错，将备机节点中的本地日志文件截断至主机节点的序列号的地方，并使该备机节点退出服务进程。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410843823.0A CN104765661B (zh) | 2014-12-30 | 2014-12-30 | 一种云存储服务中元数据服务节点的多节点热备方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410843823.0A CN104765661B (zh) | 2014-12-30 | 2014-12-30 | 一种云存储服务中元数据服务节点的多节点热备方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN104765661A CN104765661A (zh) | 2015-07-08 |
| CN104765661B true CN104765661B (zh) | 2018-04-13 |
Family
ID=53647506
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201410843823.0A Active CN104765661B (zh) | 2014-12-30 | 2014-12-30 | 一种云存储服务中元数据服务节点的多节点热备方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN104765661B (zh) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105278877A (zh) * | 2015-09-30 | 2016-01-27 | 成都华为技术有限公司 | 一种对象存储方法和装置 |
| CN107046552B (zh) * | 2016-02-05 | 2020-10-23 | 华为技术有限公司 | 基于心跳的数据同步装置、方法及分布式存储系统 |
| CN107343012B (zh) * | 2016-04-28 | 2019-12-03 | 杭州海康威视数字技术股份有限公司 | 视频存储系统及其视频数据发送方法 |
| CN107832138B (zh) * | 2017-09-21 | 2021-09-14 | 南京邮电大学 | 一种扁平化的高可用namenode模型的实现方法 |
| CN107491271A (zh) * | 2017-09-25 | 2017-12-19 | 郑州云海信息技术有限公司 | 一种缓存数据管理的方法及装置 |
| CN107729178A (zh) * | 2017-09-28 | 2018-02-23 | 郑州云海信息技术有限公司 | 一种元数据服务进程接替方法及装置 |
| CN109462640B (zh) * | 2018-10-29 | 2021-07-20 | 上海掌门科技有限公司 | 一种元数据同步方法、数据端、交互系统及介质 |
| CN111240899B (zh) * | 2020-01-10 | 2023-07-25 | 北京百度网讯科技有限公司 | 状态机复制方法、装置、系统及存储介质 |
| US11223681B2 (en) | 2020-04-10 | 2022-01-11 | Netapp, Inc. | Updating no sync technique for ensuring continuous storage service in event of degraded cluster state |
| CN114115718B (zh) * | 2021-08-31 | 2024-03-29 | 济南浪潮数据技术有限公司 | 分布式块存储系统服务质量控制方法、装置、设备及介质 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101902498A (zh) * | 2010-07-02 | 2010-12-01 | 广州鼎甲计算机科技有限公司 | 一种基于网络技术的存储云备份方法 |
| CN102414673A (zh) * | 2009-04-24 | 2012-04-11 | 微软公司 | 智能的备份数据分层 |
| CN102571968A (zh) * | 2012-01-17 | 2012-07-11 | 华中科技大学 | 云备份系统中的数据定向转发方法 |
| CN104104739A (zh) * | 2014-08-08 | 2014-10-15 | 成都致云科技有限公司 | 一种云存储系统元数据服务集群的数据同步方法 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7159150B2 (en) * | 2002-12-31 | 2007-01-02 | International Business Machines Corporation | Distributed storage system capable of restoring data in case of a storage failure |
-
2014
- 2014-12-30 CN CN201410843823.0A patent/CN104765661B/zh active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102414673A (zh) * | 2009-04-24 | 2012-04-11 | 微软公司 | 智能的备份数据分层 |
| CN101902498A (zh) * | 2010-07-02 | 2010-12-01 | 广州鼎甲计算机科技有限公司 | 一种基于网络技术的存储云备份方法 |
| CN102571968A (zh) * | 2012-01-17 | 2012-07-11 | 华中科技大学 | 云备份系统中的数据定向转发方法 |
| CN104104739A (zh) * | 2014-08-08 | 2014-10-15 | 成都致云科技有限公司 | 一种云存储系统元数据服务集群的数据同步方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN104765661A (zh) | 2015-07-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN104765661B (zh) | 一种云存储服务中元数据服务节点的多节点热备方法 | |
| US11340672B2 (en) | Persistent reservations for virtual disk using multiple targets | |
| CN105027070B (zh) | 卷操作的安全性 | |
| CN103294675B (zh) | 一种分布式存储系统中的数据更新方法及装置 | |
| Bronson et al. | {TAO}:{Facebook’s} distributed data store for the social graph | |
| US11995336B2 (en) | Bucket views | |
| CN103929500A (zh) | 一种分布式存储系统的数据分片方法 | |
| CN103312624B (zh) | 一种消息队列服务系统和方法 | |
| CN105224255B (zh) | 一种存储文件管理方法及装置 | |
| CN106446159B (zh) | 一种存储文件的方法、第一虚拟机及名称节点 | |
| CN107798130A (zh) | 一种分布式存储的快照方法 | |
| JP2017531250A (ja) | 粒状同期／半同期アーキテクチャ | |
| CN103186554A (zh) | 分布式数据镜像方法及存储数据节点 | |
| CN104111804A (zh) | 一种分布式文件系统 | |
| CN107179878A (zh) | 基于应用优化的数据存储的方法和装置 | |
| CN109684282A (zh) | 一种构建元数据缓存的方法及装置 | |
| CN105404565B (zh) | 一种双活数据保护方法和装置 | |
| CN104104582B (zh) | 一种数据存储路径管理方法、客户端及服务器 | |
| CN106326239A (zh) | 分布式文件系统及其文件元信息管理方法 | |
| CN106713391A (zh) | 一种session信息的共享方法和共享系统 | |
| KR20140049058A (ko) | 트랜잭션 메모리 시스템 내구성 부여 | |
| CN109144406A (zh) | 分布式存储系统中元数据存储方法、系统及存储介质 | |
| US20210109827A1 (en) | Connectivity-aware witness for active-active storage | |
| CN108431815A (zh) | 在处理器网格中的分布式数据的去重复数据 | |
| US11231862B1 (en) | Localized lookups for efficient database service request processing |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| EXSB | Decision made by sipo to initiate substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C41 | Transfer of patent application or patent right or utility model | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20160913 Address after: 518057 Guangdong city of Shenzhen province Nanshan District Hing Road two No. 6 Shenzhen building B403 - III University Wuhan University Applicant after: Shenzhen Anyun Information Technology Co., Ltd. Address before: 518057 Guangdong city of Shenzhen province Nanshan District Hing Road two No. 6 Wuhan University Shenzhen research building B403-III Applicant before: Shenzhen Anyun Information Technology Co., Ltd. Applicant before: Beijing Xin Kean cloud Information Technology Co., Ltd |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |