CN115794499B - 一种用于分布式块存储集群间双活复制数据的方法和系统 - Google Patents
一种用于分布式块存储集群间双活复制数据的方法和系统 Download PDFInfo
- Publication number
- CN115794499B CN115794499B CN202310053755.7A CN202310053755A CN115794499B CN 115794499 B CN115794499 B CN 115794499B CN 202310053755 A CN202310053755 A CN 202310053755A CN 115794499 B CN115794499 B CN 115794499B
- Authority
- CN
- China
- Prior art keywords
- gateway cluster
- slave
- master
- cluster
- request
- 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
Images
Abstract
本发明提供了一种用于分布式块存储集群间双活复制数据的方法和系统，属于计算机存储领域，包括：应用服务器A和B同时访问主、从网关集群；主网关集群接收应用服务器A的IO请求后，先在本地预写日志，然后把日志项复制到从网关集群；从网关集群接收到应用服务器B的IO请求后，先把IO请求重定向到主网关集群，然后等待主网关集群按照和处理自身接收的IO请求相同的方式来处理重定向请求；当主网关集群向在和从网关集群同步预写日志过程中，或者读写自身的本地逻辑卷过程中遇到故障时，请求仲裁节点，由仲裁节点协助完成IO处理和盘对的状态转换。本发明可在两套不同的存储集群之间建立同步复制关系，提高了系统的稳定性和可靠性。
Description
技术领域
本发明属于计算机技术领域，具体涉及一种用于分布式块存储集群间双活复制数据的方法和系统。
背景技术
块存储系统往往用于支撑关键业务的生产系统，如数据库、虚拟化软件等，且保存着核心业务数据。为保证系统稳定可靠，块存储系统往往需要在不同的机房或数据中心部署两套，并在两套存储系统的块设备之间建立同步复制关系。所谓同步复制关系，是指当其中一套存储系统上的块设备有IO操作时，这个IO操作也被复制到另一套存储系统的块设备上，两个IO操作都成功完成后，再向客户端报告IO完成事件。两套存储系统之间建立数据同步链路，实时复制数据，并且保证链路两端块设备上的数据在任一时刻都是完全一致的。
建立了同步复制关系之后，上层的应用服务器操作系统（如Linux）就可以同时维护两条IO链路，分别连接到这两套存储系统上，两条IO链路可以是主-主或主-备的关系。当一条IO链路发生故障，自动切换到另外一条链路上，从而保证上层应用的业务连续性和高可用性。
目前，传统的集中式SAN存储一般都有比较成熟的双活复制方案，但是分布式块存储的双活复制方案还不多见。由于分布式块存储的集群本身都是由多个节点构成的，所以在两套分布式块存储之间建立双活复制关系，比集中式SAN存储要复杂。现有的主要技术有两种：
第一类技术在两套分布式块存储集群之间建立主从式的同步或异步复制关系。主从式的异步复制技术在主存储端发生故障时，可能有数据尚未复制到从存储端，从而造成数据丢失，无法满足关键业务连续性要求。主从式的同步复制技术虽然可以满足系统连续性需求，但是所有的应用在同一时刻都只能访问其中的一套主存储，无法满足应用优先访问就近存储的需求。
第二类技术采用把一套集群的不同节点分布到多个数据中心的做法。这种方式仅仅在物理上部署到多个机房或数据中心，但是从内部工作机制上，仍然是一个集群。如果由于集群内部的逻辑错误、系统bug等导致系统故障，则整个集群失效，难以达到通过多个集群的冗余性来防止系统服务中断的问题。
发明内容
为了克服上述现有技术存在的不足，本发明提供了一种用于分布式块存储集群间双活复制数据的方法和系统。
为了实现上述目的，本发明提供如下技术方案：
一种用于分布式块存储集群间双活复制数据的方法，应用于分布式存储系统，所述存储系统包括主网关集群、从网关集群及连接所述主网关集群和从网关集群的仲裁节点，所述方法包括以下步骤：
所述主网关集群和从网关集群中各自提供一个虚拟卷，形成一个盘对；
应用服务器A和应用服务器B同时访问所述主网关集群和从网关集群；
所述主网关集群接收应用服务器A的IO请求后，先在本地预写日志，然后把日志项复制到所述从网关集群；
所述从网关集群接收到应用服务器B的IO请求后，先把IO请求重定向到主网关集群，然后等待主网关集群按照和处理自身接收的IO请求相同的方式来处理重定向请求；
当主网关集群在和从网关集群同步预写日志过程中，或者读写自身的本地逻辑卷过程中遇到故障时，请求仲裁节点，由仲裁节点协助完成IO处理和盘对的状态转换。
优选地，应用服务器A通过建立的主IO路径和从IO路径分别访问所述主网关集群和从网关集群，所述主IO路径和从IO路径是主备关系，正常情况下应用服务器A使用主IO路径访问主网关集群；当主IO路径故障时，自动切换到从IO路径访问从网关集群。
优选地，所述盘对的状态转换过程具体包括：
初始态下，选择存储集群A中一个逻辑卷，映射成一个主虚拟卷；选择存储集群B中一个逻辑卷，映射成一个从虚拟卷，创建盘对，主虚拟卷和从虚拟卷之间建立同步复制关系；
在同步中状态下，主虚拟卷和从虚拟卷分别进行格式化、数据初始化，保证两方数据一致；对于两侧预写日志有差异的情况，由主网关集群控制从预写日志多的一侧，向预写日志少的一侧复制预写日志项，并执行日志项，直到两侧的预写日志无差异；之后，主网关集群在确认同步完成后，把主网关集群和从网关集群中该盘对的状态同时变成已同步；
在已同步状态下，主虚拟卷和从虚拟卷以先主后从的方式，通过预写日志来同步预写日志；同步之后，执行当前日志项指定的RPC请求；
在已同步状态下发生单侧盘或网络连接故障时，利用仲裁节点的帮助，使得盘对的状态转换为主卷有新数据或从卷有新数据；在数据不同步的状态下，只有单侧的虚拟卷为应用服务器提供服务，而无法同步数据；此时，主网关集群中的数据同步系统服务不断尝试向从网关集群，以及仲裁节点发送健康检查请求，当发现三者之间的数据同步链路恢复正常之后，则把主网关集群的盘对状态改为同步中；
在盘对恢复过程中，如果继续发生磁盘或网络故障；或者在已同步状态下，主网关集群和从网关集群同时发生故障，则进入盘对故障状态；此时，整个盘对都无法对外提供服务，手工删除盘对之后，利用其他工具对磁盘手工修复后，再重新同步数据。
优选地，所述主网关集群在已同步状态下，对主虚拟卷上的IO操作处理流程具体包括：
步骤301，应用服务器A通过已经建立的主IO路径向主网关集群发送IO命令；
步骤302，主网关集群接收到IO消息，解析成IO命令，然后把IO命令转换成存储集群A的RPC远程调用请求；
步骤303，主网关集群生成一个新的日志项编号，将RPC远程调用请求序列化到预写日志中；
步骤304，主网关集群向从网关集群发送同步日志请求；
步骤305，日志请求同步成功后，则转到步骤306，执行当前日志项；同步失败，则转到步骤311，请求仲裁节点；
步骤306，同步成功后，则执行当前日志项中的RPC远程调用请求；主网关集群把RPC远程调用请求发到存储集群A，完成IO动作，并等待RPC调用返回；调用成功后，主网关集群记录当前已执行成功的日志编号，作为currApplyID；
步骤307，主网关集群把currApplyID发送到从网关集群，等待从网关集群也执行到这个ID对应的日志项，从网关集群在执行完成后，返回响应；
步骤308，等待由从网关集群返回执行状态的响应，如果成功接收到该响应，则转向步骤309；如果等待超时，或从网关集群返回执行失败响应，则转向步骤321，请求仲裁；
步骤309，主网关集群和主从网关集群均执行完成IO命令，因此向应用服务器A回复IO完成事件，IO命令执行成功，之后转到步骤310，流程执行结束；
步骤311，当同步预写日志失败之后，请求仲裁节点；
步骤312，当仲裁节点返回主卷有新数据，则仲裁成功，转到步骤313；当仲裁节点返回从卷有新数据，则仲裁失败，转到步骤315；
步骤313，接收到仲裁节点返回的主卷有新数据响应后，把本盘对的状态由已同步变更为主卷有新数据；变更状态之后转到步骤314；
步骤314，和步骤306相同，执行日志项所含的IO命令；此后转到步骤309；
步骤315，接收到仲裁节点返回从卷有新数据响应后，把本盘对的状态由已同步变更为从卷有新数据；变更状态之后转到步骤316；
步骤316，因为仲裁失败，所以本次的日志项无法执行，需要把当前的日志项清除掉，并把currLogID回退1，之后转到步骤317；
步骤317，向应用服务器A响应IO失败事件，之后转到步骤310，流程执行结束；
步骤321，由于从网关集群执行IO命令失败，或者等待从网关的响应消息超时，则主网关集群把currLogID发送到仲裁节点，由仲裁节点判断哪一侧的数据更新；
步骤322，当仲裁节点返回主卷有新数据，则仲裁成功，转到步骤323；当仲裁节点返回从卷有新数据，则仲裁失败，转到步骤318；
步骤323，仲裁成功后，把盘对的状态从已同步变更为主卷有新数据，之后转到步骤324；
步骤324，按日志项执行操作，和步骤306相同；之后转到步骤309；
步骤318，接收到仲裁节点返回从卷有新数据响应后，把本盘对的状态由已同步变更为从卷有新数据；变更状态之后转到步骤319；
步骤319，和步骤316相同，执行完毕转入步骤320；
步骤320，向应用服务器A响应IO失败事件，之后转到步骤310，流程执行结束。
优选地，所述从网关集群在已同步状态下，对从虚拟卷上的IO操作处理流程具体包括：
步骤401，应用服务器B通过已经建立的IO路径向从网关集群发送IO命令；
步骤402，从网关集群接收到IO消息，解析成IO命令，然后把IO命令转换成存储集群B的RPC远程调用请求；
步骤403，从网关集群把RPC远程调用请求重定向到主网关集群上，等待主网关集群处理请求；
步骤404，如果得到重定向成功响应，则转向步骤405；如果得到IO失败，或请求超时，则转向步骤407；
步骤405，向应用服务器B响应IO完成事件后，转到步骤406，流程结束；
步骤407，请求仲裁节点时，把currLogID发送到仲裁节点，由仲裁节点判断哪一侧的数据更新，等待仲裁节点返回响应；
步骤408，如果仲裁成功，即仲裁节点返回从卷有新数据，则转向步骤409，否则转向步骤411；
步骤409，因为仲裁节点返回从卷有新数据，所以把自身盘对的状态从已同步变更为从卷有新数据；
步骤410，执行当前日志项currLogID中的RPC请求；从网关集群把RPC请求发到存储集群B，完成IO动作，并等待RPC调用返回；调用成功后，从网关集群会记录当前已执行成功的日志编号，作为currApplyID；之后转到步骤405，流程结束；
步骤411，因为仲裁节点返回主卷有新数据，所以把自身盘对的状态从已同步变更为主卷有新数据；之后转到步骤412，向客户端响应IO失败事件后，流程结束。
优选地，所述从网关集群在已同步状态下，对来自于主网关集群的预写日志同步请求的处理流程具体包括：
步骤501，主网关集群向从网关集群发送了同步预写日志的请求；
步骤502，从网关集群接收主网关集群发送的同步预写日志的请求；
步骤503，从网关集群查看接收到的同步请求是否顺序正确，即请求消息中的prevLogID字段，是否等于本地维护的currLogID；
如果相等，则转至步骤504，将IO请求录入到本地预写日志中，然后转至步骤505；如果不相等，则转至步骤510；
步骤505，向主网关集群回复同步预写日志成功响应，之后转至步骤506；
步骤506，执行当前日志项currLogID中的RPC请求，从网关集群把RPC请求发到存储集群B，完成IO动作，并等待RPC调用返回；调用成功后，从网关集群记录当前已执行成功的日志编号，作为currApplyID，之后转到步骤507；
步骤507，需等待主网关集群发送的询问执行状态的消息；如果收到这个消息，则说明主虚拟卷和从虚拟卷均已落盘成功，此时转至步骤508；如果等待超时，未收到主网关集群消息，则转到步骤515；
步骤508，向主网关集群回复执行完成；之后转入步骤509，流程结束；
步骤510，由于此刻接收到的日志请求和本地保存的日志顺序是错序的，此时需要用从网关集群的currLogID来请求仲裁节点，并转入步骤511；
步骤511，如果收到仲裁节点返回仲裁成功，即从网关集群的currLogID是最新的，则转到步骤512，否则转到步骤513；
步骤512，把自身盘对的状态从已同步变更为主卷有新数据，并转到步骤514；
步骤513，把自身盘对的状态从已同步变更为从卷有新数据，并转到步骤514；
步骤514，向主网关集群回复同步失败响应；之后转到步骤509，流程结束；
步骤515，请求仲裁节点，看哪边的日志是新的；
步骤516，如果仲裁节点返回仲裁成功，即从网关集群的日志是最新的，则转到步骤517；否则转到步骤518；
步骤517，从网关集群把自身的状态从已同步变更为主卷有新数据，之后转到步骤509，流程结束；
步骤518，把从网关集群的状态设置成盘对故障；之后转到步骤509，流程结束。
优选地，所述主网关集群在主卷有新数据状态下，对主虚拟卷上的IO操作的处理流程具体包括：
步骤601，应用服务器A通过主IO路径向主网关集群发送IO命令；
步骤602，主网关集群接收到IO消息，解析成IO命令，然后把IO命令转换成存储集群A的RPC远程调用请求；
步骤603，主网关集群生成一个新的日志项编号，将RPC请求序列化到预写日志中；
步骤604，执行当前日志项currLogID中的RPC请求；主网关集群把RPC请求发到存储集群A，完成IO动作，并等待RPC调用返回；调用成功后，主网关集群会记录当前已执行成功的日志编号，作为currApplyID；
步骤605，向应用服务器A响应IO完成事件，之后转入步骤606，流程结束。
优选地，所述仲裁节点处理仲裁请求的过程具体为：
当一个网关集群访问另一个集群出现故障时，将请求仲裁节点，由仲裁节点辅助实现状态变更；
仲裁节点在接收到请求后，通过判断哪一方的预写日志号更新，来确定哪方获胜；
获胜的一方在随后的过程中，将单独处理外部IO请求，而不再进行数据同步；而失败的一方，则不再响应外部IO请求；
发生上述数据不同步之后，主网关集群的同步系统服务持续检查到从网关集群和仲裁节点的数据同步链路恢复；
发现数据同步链路恢复后，由同步系统服务根据主从两侧预写日志的差异，以同步预写日志的方式缩小两侧的差异，直到差异缩小为0之后，两侧系统状态值再次进入已同步状态。
本发明的另一目的在于提供一种用于分布式块存储集群间双活复制数据的系统，包括主网关集群、从网关集群及连接所述主网关集群和从网关集群的仲裁节点；
所述主网关集群和从网关集群均与应用服务器A、应用服务器B连接；
所述主网关集群与存储集群A连接，从网关集群与存储集群B连接；
所述主网关集群和从网关集群上分别存在主虚拟卷和从虚拟卷，所述主虚拟卷和从虚拟卷构成一个盘对；
所述主网关集群接收应用服务器A的IO请求后，先在本地预写日志，然后把日志项复制到所述从网关集群；
所述从网关集群接收到应用服务器B的IO请求后，先把IO请求重定向到主网关集群，然后等待主网关集群按照和处理自身接收的IO请求相同的方式来处理重定向请求；
当主网关集群和从网关集群在同步预写日志，或者读写本地的逻辑卷中遇到故障时，请求仲裁节点，由仲裁节点协助完成IO处理和盘对的状态转换。
优选地，所述主网关集群和从网关集群分别由多台服务器构成，为上层应用服务器提供基于块存储协议的服务端程序，作为前端；并且把独立的存储集群A的逻辑卷和存储集群B的逻辑卷分别映射成自身的主虚拟卷和从虚拟卷，作为后端；由主网关集群和从网关集群中分别提供一个逻辑卷，形成一个盘对。
本发明提供的用于分布式块存储集群间双活复制数据的方法和系统具有以下有益效果：
本发明提出了在两套存储集群之间建立双活复制关系的机制，两套集群都可以为上层应用提供存储服务，从而解决了在两套分布式块存储集群之间建立主从式的同步或异步复制关系技术无法满足应用优先访问就近存储的需求。同时，本发明可以在两套不同的存储集群之间建立同步复制关系，两套存储集群本身是完全独立和异构的存储系统，和采用把一套集群的不同节点分布到多个数据中心的做法相比，在系统的稳定性和可靠性方面有显著提高和增强。
附图说明
为了更清楚地说明本发明实施例及其设计方案，下面将对本实施例所需的附图作简单地介绍。下面描述中的附图仅仅是本发明的部分实施例，对于本领域普通技术人员来说，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例1的用于分布式块存储集群间双活复制系统的总体架构图；
图2为本发明实施例1的用于分布式块存储集群间双活复制数据的方法的盘对的状态转换过程；
图3为主网关集群在已同步状态下，对主虚拟卷上的IO操作处理流程；
图4为从网关集群在已同步状态下，对从虚拟卷上的IO操作处理流程；
图5为从网关集群在已同步状态下，对从虚拟卷上的预写日志同步请求的处理流程；
图6为主网关集群在主卷有新数据状态下，对主虚拟卷上的IO操作的处理流程；
图7为仲裁节点处理仲裁请求的流程图。
具体实施方式
为了使本领域技术人员更好的理解本发明的技术方案并能予以实施，下面结合附图和具体实施例对本发明进行详细说明。以下实施例仅用于更加清楚地说明本发明的技术方案，而不能以此来限制本发明的保护范围。
实施例1
本发明提供了一种用于分布式块存储集群间双活复制系统，应用于分布式存储系统，具体如图1所示，该系统包括主网关集群103，从网关集群104和仲裁节点113三部分。主网关集群103和从网关集群104中各自提供一个虚拟卷，形成一个盘对，作为建立同步复制关系的基础；两个应用服务器能同时访问主网关集群103和从网关集群104。
主网关集群103和从网关集群104组合起来，为应用服务器A101、应用服务器B102提供了虚拟的块设备。这种虚拟的块设备称之为盘对，由主网关集群103上的主虚拟卷105和从网关集群104上的从虚拟卷106构成。盘对中的主/主/从虚拟卷105/106之间建立了同步复制关系，也就是说，两块盘上的数据在任意时刻都是一致的，因此应用服务器A101可以随时访问其中任意一方，就像访问一块虚拟的块设备一样。
应用服务器A101通过块存储协议（如FC-SAN，iSCSI，或NVMe-OV等协议）与主/从网关集群103/104分别建立IO路径116/117。IO路径建立之后，应用服务器A101操作系统如Linux内核就把IO路径上发现的虚拟块设备映射成本地操作系统上的IO设备。当应用程序对这些IO设备读写数据时，驱动程序把这些IO命令转换成块存储协议的消息，通过块存储协议栈，把消息发送到主/从网关集群103/104上，并等待IO响应事件。
主/从网关集群103/104分别由多台服务器构成，为应用服务器A101提供块存储协议的服务端程序。服务端程序在IO路径上接收到消息后，首先把消息还原成IO命令，然后把IO命令转换成对分布式存储集群A111和存储集群B112的RPC远程调用，并将RPC请求发送到相应的盘对上。分布式集群一般提供一个简单的RPC远程调用接口集合，主要包括对数据块的读、写，以及对块设备元数据的操作等。
盘对中，总是主虚拟卷105首先处理RPC请求，然后把RPC请求序列化到预写日志中，把日志项同步到从虚拟卷106。数据在两个卷上同步更新之后，向应用服务器响应IO完成事件。
应用服务器A101可以同时建立两条IO路径116/117，分别连接到盘对中的主/主/从虚拟卷105/106，两条IO路径可以以主-主或主-从的关系工作。当应用服务器A101发现其中的一条IO路径故障时，通过自身的多路径软件如Linux multipathd，可以实时切换到另外一条IO路径上。这个过程发生在操作系统内核，对应用服务器A101中运行的应用是无感知的，从而保证了应用服务器的业务连续性，和块设备的高可用性。
主网关集群103和从网关集群104维护了多个盘对，每个盘对逻辑上以自动状态机的模型运行。也就是说，盘对在任一时刻有一个状态值，不同的系统状态值下，盘对对接收到的RPC请求有不同的处理流程，并返回不同的响应结果，同时，在处理过程中，也可能会更新盘对的状态值。
当一个网关集群访问另一个集群出现故障时，它将请求仲裁节点113，由仲裁节点113辅助实现状态变更，以防止竞争条件出现而导致脑裂。仲裁节点113在接收到请求后，通过判断哪一方的预写日志号更新，来确定哪方获胜。获胜的一方在随后的过程中，将单独处理外部IO请求，而不再进行数据同步。而失败的一方，则不再响应外部IO请求。
发生上述数据不同步之后，主网关集群103的同步系统服务持续检查到从网关集群104和仲裁节点113的数据同步链路115。发现数据同步链路115恢复后，由同步系统服务根据主从两侧预写日志的差异，以同步预写日志的方式缩小两侧的差异，直到差异缩小为0之后，两侧系统状态值再次进入已同步状态。
基于同一个发明构思，本实施例还提供了一种用于分布式块存储集群间双活复制数据的方法，包括以下步骤：
主网关集群103接收至少两个应用服务器、即应用服务器A和应用服务器B的IO请求后，先写本地日志，然后复制到从网关集群104；
从网关集群104接收到IO请求后，先把IO请求重定向到主网关集群103，然后等待主网关集群103按照写日志的方式来处理请求；
当主网关集群103和从网关集群104在同步预写日志，或者读写本地的逻辑卷中遇到故障时，请求仲裁节点113，由仲裁节点113协助完成IO处理和盘对的状态转换。
进一步地，图2描述了盘对114的状态转换过程，具体步骤为：
初始态201下，盘对还未建立。此时，用户可以选择从存储集群A111中一个逻辑卷109映射成一个主虚拟卷105；从存储集群B112中一个逻辑卷110，映射成一个从虚拟卷106，逻辑卷109和逻辑卷110分别构成存储资源池107和存储资源池108。这里，主/从虚拟卷的容量、磁盘类型如SSD，或HDD必须相同。之后，可以通过工具或GUI图形化界面创建盘对207。
创建盘对后，主网关集群103负责把主网关集群103和从网关集群104中该盘对114的状态修改为同步中202，此时即在盘对的主/主/从虚拟卷105/106之间建立了同步复制关系。
在同步中202状态下，由主网关集群103控制，进行数据同步工作。对于新建立的盘对，主/主/从虚拟卷105/106分别进行格式化、数据初始化，保证两方数据一致。对于两侧预写日志有差异的情况，由主网关集群103控制从预写日志多的一侧，向预写日志少的一侧复制预写日志项，并执行日志项，直到两侧的预写日志无差异。之后，主网关集群103在确认同步完成208后，把主/从网关集群103/104中，该盘对的状态同时变成已同步203。
在已同步203状态下，主/主/从虚拟卷105/106以先主后从的方式，通过预写日志来同步预写日志；同步之后，执行当前日志项指定的RPC请求，具体的处理流程在下文中详述。
在已同步203状态下发生单侧盘或网络连接故障时，利用仲裁节点的帮助，使得盘对的状态转换为主卷有新数据204或从卷有新数据205，这两个状态都是数据不同步的状态。
在数据不同步的状态下204/205，只有单侧的虚拟卷为应用服务器提供服务，而无法同步数据。此时，主网关集群103中的数据同步系统服务不断尝试向从网关集群104，以及仲裁节点113发送健康检查请求，当发现三者之间的数据同步链路115恢复正常之后，则把主网关集群103的盘对状态改为同步中202。
在已同步203状态下，写磁盘故障209到主卷有新数据204，写磁盘故障210到从卷有新数据205。在盘对恢复过程217/218中，如果继续发生磁盘或网络故障；或者在已同步203状态下，主从盘同时发生故障215，则进入盘对故障206状态。此时，整个盘对都无法对外提供服务，只能手工删除盘对216之后，利用其他工具对磁盘手工修复后，再重新同步数据。在主卷有新数据204或从卷有新数据205下，盘对自恢复211到同步中202状态。在同步中202状态下，同步从盘故障231到主卷有新数据204，同步主盘故障214到从卷有新数据205。
进一步地，图3是主网关集群103在已同步203状态下，对主虚拟卷105上的IO操作处理流程，具体步骤为：
流程开始时，步骤301，应用服务器A101通过已经建立的主IO路径116向主网关集群103发送IO命令；之后转到步骤302。
步骤302，主网关集群103接收到IO消息，解析成IO命令，然后把IO命令转换成存储集群111的RPC远程调用请求，之后转到步骤303。
步骤303，主网关集群103生成一个新的日志项编号，将RPC远程调用请求序列化到预写日志中。预写日志是日志项序列，每个日志项有顺序编号，且只能以在末尾追加的方式更新内容。预写日志可以在内存中维护，也可以写入到持久化存储设备中，优选地，采用PM，NVMe等高性能存储介质。
写入预写日志后，转到步骤304。
步骤304，主网关集群103向从网关集群104发送同步日志请求，包含当前日志编号currLogID，和上一个已经执行成功的日志编号prevLogID。之后，转到步骤305，判断是否同步成功。
这里，同步失败包括三种可能情况：发送同步请求失败；从网关返回同步失败响应；以及接收同步响应超时等。导致同步失败的因素可能是主/从网关集群间的数据同步链路115故障，也可能是从虚拟卷自身故障。
同步成功305-Y后，则转到步骤306，执行当前日志项。同步失败305-N，则转到步骤311，请求仲裁节点。
步骤306，同步成功后，则执行当前日志项currLogID中的RPC远程调用请求。主网关集群103把RPC远程调用请求发到存储集群A111，完成IO动作，并等待RPC调用返回。调用成功后，主网关集群103会记录当前已执行成功的日志编号，作为currApplyID。之后转到步骤307。
事实上，步骤306的动作在从网关集群104上也在并行执行。从网关集群104执行结束后，等待主网关集群103同步执行状态。
步骤307，主网关集群103把currApplyID发送到从网关集群104，等待从网关集群也执行到这个ID对应的日志项。从网关集群104会在执行完成后，返回响应。
步骤308，等待由从网关集群104返回执行状态的响应，如果成功接收到该响应，则转向步骤309。如果等待超时，或从网关集群104返回执行失败响应，则转向步骤321，请求仲裁。
步骤309，主/从网关集群103/104均执行完成IO命令，因此向应用服务器A101回复IO完成事件。之后转到步骤310，表示IO命令执行成功。
步骤311，当同步预写日志失败之后，请求仲裁节点113。仲裁节点113的详情在后文图7中详述。等仲裁节点113返回仲裁响应之后，转到步骤312。
此处请求仲裁的目的是防止脑裂。假定主/从虚拟卷105/106之间数据同步链路115出现故障，这是主/从虚拟卷105/106都以为对方出现故障而无法同步数据后，自己单方面执行日志项，这时就出现了数据不一致的情况，也就是所谓的脑裂。通过仲裁节点来解决脑裂问题。
步骤312，当仲裁节点113返回主卷有新数据，则仲裁成功，转到步骤313。当仲裁节点113返回从卷有新数据，则仲裁失败，转到步骤315。
步骤313，接收到仲裁节点113返回的主卷有新数据响应后，把本盘对的状态由已同步203变更为主卷有新数据204，变更状态之后转到步骤314。
当盘对的状态变更之后，实际上主网关集,103已经知道两侧的数据已经不同步了，主网关集群103在以后的IO处理过程中，将按图6所示的流程处理。
步骤314，和步骤306相同，执行日志项所含的IO命令，此后转到步骤309。
步骤315，接收到仲裁节点113返回从卷有新数据响应后，把本盘对的状态由已同步203变更为从卷有新数据205。变更状态之后转到步骤316。
对于主网关集群103来说，如果盘对状态为从卷有新数据，则不能再处理任何IO请求，否则将导致两侧数据不一致。只有当数据同步系统服务把两侧数据再次同步之后，才能继续处理IO请求。
步骤316，因为仲裁失败，所以本次的日志项无法执行，需要把当前的日志项清除掉，并把currLogID回退1，之后转到步骤317。
步骤317，向应用服务器A101响应IO失败事件。之后转到步骤310，流程执行结束。
应用服务器在收到IO失败事件后，多路径软件将把块设备的IO路径从主IO路径116切换到从IO路径117上，然后重试这条IO命令。这样，就把这条IO命令发往从网关集群104重新执行。而从网关集群104可以随后在单侧执行此IO命令。
步骤321，由于从网关集群104执行IO命令失败，或者等待从网关的响应消息超时，则主网关集群103把currLogID发送到仲裁节点113，由仲裁节点113判断哪一侧的数据更新。
步骤322，当仲裁节点113返回主卷有新数据，则仲裁成功，转到步骤323。当仲裁节点返回从卷有新数据，则仲裁失败，转到步骤318。
步骤323，仲裁成功后，把盘对114的状态从已同步203变更为主卷有新数据204，之后转到步骤324。
步骤324，按日志项执行操作，和步骤306相同。之后转到步骤309。
步骤318，接收到仲裁节点113返回从卷有新数据响应后，把本盘对的状态由已同步203变更为从卷有新数据205。变更状态之后转到步骤319。
步骤319，和步骤316相同，执行完毕转入步骤320。
步骤320，向应用服务器A101响应IO失败事件。之后转到步骤310，流程执行结束。
进一步地，图4是从网关集群104在已同步203状态下，对从虚拟卷106上的IO操作处理流程，具体步骤为：
流程开始时，步骤401，应用服务器B102通过已经建立的IO路径118向从网关集群104发送IO命令。之后转到步骤402。
步骤402，从网关集群104接收到IO消息，解析成IO命令，然后把IO命令转换成存储集群B112的RPC远程调用请求，之后转到步骤403。
步骤403，从网关集群104把RPC远程调用请求重定向到主网关集群103上，等待主网关集群103处理请求。对主网关集群103而言，这种重定向过来的请求，和来自于应用服务器的IO命令没有区别。当主网关集群103返回响应，或者等待超时之后，转向步骤404。
步骤404，如果得到重定向成功响应，则转向步骤405；如果得到IO失败，或请求超时，则转向步骤407。
步骤405，向应用服务器B响应IO完成事件后，转到步骤406，流程结束。
步骤407，请求仲裁节点时，把currLogID发送到仲裁节点，由仲裁节点113判断哪一侧的数据更新，等待仲裁节点返回响应，之后转到步骤408。
步骤408，如果仲裁成功，即仲裁节点113返回从卷有新数据205，则转向步骤409，否则转向步骤411。
步骤409，因为仲裁节点113返回从卷有新数据205，所以把自身盘对的状态从已同步203变更为从卷有新数据205，之后转向步骤410。
步骤410，执行当前日志项currLogID中的RPC请求。从网关集群104把RPC请求发到存储集群B112，完成IO动作，并等待RPC调用返回。调用成功后，从网关集群104会记录当前已执行成功的日志编号，作为currApplyID。之后转到步骤405，流程结束。
步骤411，因为仲裁节点113返回主卷有新数据204，所以把自身盘对的状态从已同步203变更为主卷有新数据204。之后转到步骤412，向客户端响应IO失败事件后，流程结束。
进一步地，图5是从网关集群104在已同步203状态下，对从虚拟卷106上的预写日志同步请求的处理流程，具体步骤为：
流程开始时，步骤501，主网关集群103向从网关集群104发送了同步预写日志的请求。
步骤502，从网关集群（104）接收主网关集群（103）发送的同步预写日志的请求。
步骤503，从网关集群104查看接收到的同步请求是否顺序正确，即请求消息中的prevLogID字段，是否等于本地维护的currLogID。
如果相等503-Y，则转至步骤504，将IO请求录入到本地预写日志中，转至步骤505；如果不相等，则转至步骤510。
步骤505，向主网关集群103回复同步预写日志成功响应，之后转至步骤506。
步骤506，执行当前日志项currLogID中的RPC请求。从网关集群104把RPC请求发到存储集群B112，完成IO动作，并等待RPC调用返回。调用成功后，从网关集群104会记录当前已执行成功的日志编号，作为currApplyID。之后转到步骤507。
步骤507需等待主网关集群103发送的询问执行状态的消息参考图3的步骤307。如果收到这个消息507-Y，则说明主/从虚拟卷105/106均已落盘成功，此时转至步骤508。如果等待超时，未收到主网关集群103消息，则转到步骤515。
步骤508，向主网关集群103回复执行完成。之后转入步骤509，流程结束。
步骤510，由于此刻接收到的日志请求和本地保存的日志顺序是错序的，此时需要用从网关集群的currLogID来请求仲裁节点，并转入步骤511。
步骤511，如果收到仲裁节点返回仲裁成功，即从网关集群104的currLogID是最新的，则转到步骤512，否则转到步骤513。
步骤512，把自身盘对的状态从已同步203变更为主卷有新数据204，并转到步骤514。
步骤513，把自身盘对的状态从已同步203变更为从卷有新数据205，并转到步骤514。
步骤514，无论仲裁结果如何，此时主网关集群103和从网关集群104的状态都已经处于不同步的状态，而无法再同步数据了，因此向主网关集群103回复同步失败响应。之后转到步骤509，流程结束。
步骤515，由于长时间未收到主网关集群103发送的执行状态询问消息，只能请求仲裁节点，看哪边的日志是新的。
步骤516，如果仲裁节点返回仲裁成功，即从网关集群104的日志是最新的，则转到步骤517；否则转到步骤518。
步骤517，此时主卷长时间未发送执行状态，而仲裁节点又认为主卷的数据是最新的，因此从网关集群104只能把自身的状态从已同步203变更为主卷有新数据204，之后转到步骤509，流程结束。
步骤518，此时仲裁节点认为从卷的数据是最新的，但是这个请求是由主网关集群103接收的，主网关集群103未能落盘成功，而从网关集群104虽然落盘成功的，但是自己无法回复应用服务器IO响应事件。因此，这里只能把从网关集群的状态设置成盘对故障206，之后转到步骤509，流程结束。
进一步地，图6是主网关集群103在主卷有新数据204状态下，对主虚拟卷105上的IO操作的处理流程，具体步骤为：
流程开始时，步骤601，应用服务器A101通过已经建立的IO路径116向主网关集群103发送IO命令，之后转到步骤602。
步骤602，主网关集群103接收到IO消息，解析成IO命令，然后把IO命令转换成存储集群A111的RPC远程调用请求，之后转到步骤603。
步骤603，主网关集群103生成一个新的日志项编号，将RPC请求序列化到预写日志中，之后转到步骤604。
步骤604，执行当前日志项currLogID中的RPC请求。主网关集群103把RPC请求发到存储集群A111，完成IO动作，并等待RPC调用返回。调用成功后，主网关集群会记录当前已执行成功的日志编号，作为currApplyID。之后转到步骤605。
步骤605，向应用服务器A101响应IO完成事件后，转到步骤606，流程结束。
从网关集群104在从卷有新数据205状态下，对从虚拟卷106上的IO操作处理流程和图6是一种的。
表1是仲裁节点维护的仲裁信息表
表1是仲裁节点维护的仲裁信息表。仲裁节点113为主/从网关集群103/104提供仲裁服务RPC接口处理流程在图7详述，这个RPC接口围绕图7所示的仲裁信息表提供仲裁服务。
仲裁信息表包含了盘对ID、主网关集群logID、从网关集群logID，以及从虚拟卷的故障位。
仲裁节点113为仲裁信息表的每一行维护一把互斥锁。对于给定的一个盘对，当多个RPC请求并行访问仲裁信息表中该盘对的行的时候，通过互斥锁，保证同一时刻只能有一个线程访问到该行。而其他线程处于等待状态，等互斥锁释放之后，去抢锁的控制权。
可选地，仲裁节点113可以采用zookeeper，或etcd等分布式系统实现上述功能。
初始状态下，仲裁节点中，盘对的结构体中，主/从虚拟卷105/106的logID均为-1，表示它们都未被置位。
进一步地，图7是仲裁节点113处理仲裁请求的流程图，具体步骤为：
流程开始时，步骤801，主网关集群103或从网关集群104向仲裁节点113发送冲裁请求。这个请求通过RPC请求的方式发送。
步骤802，仲裁节点113接收到仲裁请求，转到步骤803。
步骤803，根据请求的盘对ID，尝试获取仲裁信息表相应行的行锁；转到步骤804。
步骤804，如果未获得锁，则继续等待。如果获取到锁，则转到步骤805。
步骤805，判断仲裁请求的发送方，如果是主网关集群103，则转到步骤806；否则，转到步骤811。
步骤806，首先看从网关集群104是否有磁盘的故障置位，如果有置位，说明从网关集群104已经出现故障，则直接转到步骤808；否则转到步骤807继续判断。
步骤807，看仲裁请求中的logID是否大于仲裁信息表中对应行的从网关集群logID，如果是，则仲裁成功，转到步骤808；否则仲裁失败，转到步骤814。
步骤808，设置仲裁信息表的主网关logID，转到步骤809。
步骤809，返回主网关有新数据，仲裁结束。
步骤811，看主网关集群103是否有磁盘的故障置位，如果有置位，说明主网关集群103已经出现故障，则直接转到步骤813；否则转到步骤812继续判断。
步骤812，看仲裁请求中的logID是否大于仲裁信息表中对应行的主网关集群logID，如果是，则仲裁成功，转到步骤813。否则仲裁失败，转到步骤809。
步骤813，设置仲裁信息表的从网关logID，转到步骤814。
步骤814，返回从网关有新数据，仲裁结束。
本发明提出了在两套存储集群之间建立双活复制关系的机制，两套集群都可以为上层应用提供存储服务，从而解决了在两套分布式块存储集群之间建立主从式的同步或异步复制关系技术无法满足应用优先访问就近存储的需求。同时，本发明可以在两套不同的存储集群之间建立同步复制关系，两套存储集群本身是完全独立和异构的存储系统，和采用把一套集群的不同节点分布到多个数据中心的做法相比，在系统的稳定性和可靠性方面有显著提高和增强。
应当理解，以上一种用于分布式块存储集群间双活复制数据的系统包括的集群仅为根据该系统实现的功能进行的逻辑划分，实际应用中，可以进行上述单元的叠加或拆分。并且该实施例提供的一种用于分布式块存储集群间双活复制数据的系统所实现的功能与上述实施例提供的一种用于分布式块存储集群间双活复制数据的方法一一对应，对于该系统所实现的更为详细的处理流程，在上述方法实施例一中已做详细描述，此处不再详细描述。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
Claims (8)
1.一种用于分布式块存储集群间双活复制数据的方法，应用于分布式存储系统，所述存储系统包括主网关集群(103)、从网关集群(104)及连接所述主网关集群(103)和从网关集群(104)的仲裁节点(113)，其特征在于，所述方法包括以下步骤：
所述主网关集群(103)和从网关集群(104)中各自提供一个虚拟卷，形成一个盘对(114)；
应用服务器A(101)和应用服务器B(102)同时访问所述主网关集群(103)和从网关集群(104)；
所述主网关集群(103)接收应用服务器A(101)的IO请求后，先在本地预写日志，然后把日志项复制到所述从网关集群(104)；
所述从网关集群(104)接收到应用服务器B(102)的IO请求后，先把IO请求重定向到主网关集群(103)，然后等待主网关集群(103)按照和处理自身接收的IO请求相同的方式来处理重定向请求；
当主网关集群(103)在和从网关集群(104)同步预写日志过程中，或者读写自身的本地逻辑卷过程中遇到故障时，请求仲裁节点(113)，由仲裁节点(113)协助完成IO处理和盘对(114)的状态转换；
应用服务器A(101)通过建立的主IO路径(116)和从IO路径(117)分别访问所述主网关集群(103)和从网关集群(104)，所述主IO路径(116)和从IO路径(117)是主备关系，正常情况下应用服务器A(101)使用主IO路径(116)访问主网关集群(103)；当主IO路径(116)故障时，自动切换到从IO路径(117)访问从网关集群(104)；
所述盘对(114)的状态转换过程具体包括：
初始态下，选择存储集群A(111)中一个逻辑卷(109)，映射成一个主虚拟卷(105)；选择存储集群B(112)中一个逻辑卷(110)，映射成一个从虚拟卷(106)，创建盘对，主虚拟卷(105)和从虚拟卷(106)之间建立同步复制关系；
在同步中状态下，主虚拟卷(105)和从虚拟卷(106)分别进行格式化、数据初始化，保证两方数据一致；对于两侧预写日志有差异的情况，由主网关集群(103)控制从预写日志多的一侧，向预写日志少的一侧复制预写日志项，并执行日志项，直到两侧的预写日志无差异；之后，主网关集群(103)在确认同步完成后，把主网关集群(103)和从网关集群(104)中该盘对(114)的状态同时变成已同步；
在已同步状态下，主虚拟卷(105)和从虚拟卷(106)以先主后从的方式，通过预写日志来同步预写日志；同步之后，执行当前日志项指定的RPC请求；
在已同步状态下发生单侧盘或网络连接故障时，利用仲裁节点(113)的帮助，使得盘对(114)的状态转换为主卷有新数据或从卷有新数据；在数据不同步的状态下，只有单侧的虚拟卷为应用服务器提供服务，而无法同步数据；此时，主网关集群(103)中的数据同步系统服务不断尝试向从网关集群(104)，以及仲裁节点(113)发送健康检查请求，当发现三者之间的数据同步链路(115)恢复正常之后，则把主网关集群(103)的盘对(114)状态改为同步中；
在盘对(114)恢复过程中，如果继续发生磁盘或网络故障；或者在已同步状态下，主网关集群(103)和从网关集群(104)同时发生故障，则进入盘对故障状态；此时，整个盘对(114)都无法对外提供服务，手工删除盘对之后，利用其他工具对磁盘手工修复后，再重新同步数据。
2.根据权利要求1所述的用于分布式块存储集群间双活复制数据的方法，其特征在于，所述主网关集群(103)在已同步状态下，对主虚拟卷(105)上的IO操作处理流程具体包括：
步骤301，应用服务器A(101)通过已经建立的主IO路径(116)向主网关集群(103)发送IO命令；
步骤302，主网关集群(103)接收到IO消息，解析成IO命令，然后把IO命令转换成存储集群A(111)的RPC远程调用请求；
步骤303，主网关集群(103)生成一个新的日志项编号，将RPC远程调用请求序列化到预写日志中；
步骤304，主网关集群(103)向从网关集群(104)发送同步日志请求；
步骤305，日志请求同步成功后，则转到步骤306，执行当前日志项；同步失败，则转到步骤311，请求仲裁节点；
步骤306，同步成功后，则执行当前日志项中的RPC远程调用请求；主网关集群(103)把RPC远程调用请求发到存储集群A(111)，完成IO动作，并等待RPC调用返回；调用成功后，主网关集群(103)记录当前已执行成功的日志编号，作为currApplyID；
步骤307，主网关集群(103)把currApplyID发送到从网关集群(104)，等待从网关集群(104)也执行到这个ID对应的日志项，从网关集群(104)在执行完成后，返回响应；
步骤308，等待由从网关集群(104)返回执行状态的响应，如果成功接收到该响应，则转向步骤309；如果等待超时，或从网关集群(104)返回执行失败响应，则转向步骤321，请求仲裁；
步骤309，主网关集群(103)和从网关集群(104)均执行完成IO命令，因此向应用服务器A(101)回复IO完成事件，IO命令执行成功，之后转到步骤(310)；
步骤310，流程执行结束；
步骤311，当同步预写日志失败之后，请求仲裁节点(113)；
步骤312，当仲裁节点(113)返回主卷有新数据，则仲裁成功，转到步骤313；当仲裁节点(113)返回从卷有新数据，则仲裁失败，转到步骤315；
步骤313，接收到仲裁节点(113)返回的主卷有新数据响应后，把本盘对的状态由已同步变更为主卷有新数据；变更状态之后转到步骤314；
步骤314，和步骤306相同，执行日志项所含的IO命令；此后转到步骤309；
步骤315，接收到仲裁节点(113)返回从卷有新数据响应后，把本盘对的状态由已同步变更为从卷有新数据；变更状态之后转到步骤316；
步骤316，因为仲裁失败，所以本次的日志项无法执行，需要把当前的日志项清除掉，并把currLogID回退1，之后转到步骤317；
步骤317，向应用服务器A(101)响应IO失败事件，之后转到步骤310；
步骤321，由于从网关集群(104)执行IO命令失败，或者等待从网关的响应消息超时，则主网关集群(103)把currLogID发送到仲裁节点(113)，由仲裁节点(113)判断哪一侧的数据更新；
步骤322，当仲裁节点(113)返回主卷有新数据，则仲裁成功，转到步骤323；当仲裁节点返回从卷有新数据，则仲裁失败，转到步骤318；
步骤323，仲裁成功后，把盘对(114)的状态从已同步变更为主卷有新数据，之后转到步骤324；
步骤324，按日志项执行操作，和步骤306相同；之后转到步骤309；
步骤318，接收到仲裁节点(113)返回从卷有新数据响应后，把本盘对的状态由已同步变更为从卷有新数据；变更状态之后转到步骤319；
步骤319，和步骤316相同，执行完毕转入步骤320；
步骤320，向应用服务器A(101)响应IO失败事件，之后转到步骤310。
3.根据权利要求2所述的用于分布式块存储集群间双活复制数据的方法，其特征在于，所述从网关集群(104)在已同步状态下，对从虚拟卷(106)上的IO操作处理流程具体包括：
步骤401，应用服务器B(102)通过已经建立的IO路径(118)向从网关集群(104)发送IO命令；
步骤402，从网关集群(104)接收到IO消息，解析成IO命令，然后把IO命令转换成存储集群B(112)的RPC远程调用请求；
步骤403，从网关集群(104)把RPC远程调用请求重定向到主网关集群(103)上，等待主网关集群(103)处理请求；
步骤404，如果得到重定向成功响应，则转向步骤405；如果得到IO失败，或请求超时，则转向步骤407；
步骤405，向应用服务器B响应IO完成事件后，转到步骤406；
步骤406，流程结束；
步骤407，请求仲裁节点时，把currLogID发送到仲裁节点，由仲裁节点(113)判断哪一侧的数据更新，等待仲裁节点返回响应；
步骤408，如果仲裁成功，即仲裁节点(113)返回从卷有新数据，则转向步骤409，否则转向步骤411；
步骤409，因为仲裁节点(113)返回从卷有新数据，所以把自身盘对的状态从已同步变更为从卷有新数据；
步骤410，执行当前日志项currLogID中的RPC请求；从网关集群(104)把RPC请求发到存储集群B(112)，完成IO动作，并等待RPC调用返回；调用成功后，从网关集群(104)会记录当前已执行成功的日志编号，作为currApplyID；之后转到步骤405；
步骤411，因为仲裁节点(113)返回主卷有新数据，所以把自身盘对的状态从已同步变更为主卷有新数据；之后转到步骤412；
步骤412，向客户端响应IO失败事件，之后转到步骤406。
4.根据权利要求3所述的用于分布式块存储集群间双活复制数据的方法，其特征在于，所述从网关集群(104)在已同步状态下，对来自于主网关集群(103)的预写日志同步请求的处理流程具体包括：
步骤501，主网关集群(103)向从网关集群(104)发送了同步预写日志的请求；
步骤502，从网关集群(104)接收主网关集群(103)发送的同步预写日志的请求；
步骤503，从网关集群(104)查看接收到的同步请求是否顺序正确，即请求消息中的prevLogID字段，是否等于本地维护的currLogID；
如果相等，则转至步骤504；如果不相等，则转至步骤510；
步骤504，将IO请求录入到本地预写日志中；
步骤505，向主网关集群(103)回复同步预写日志成功响应，之后转至步骤506；
步骤506，执行当前日志项currLogID中的RPC请求，从网关集群(104)把RPC请求发到存储集群B(112)，完成IO动作，并等待RPC调用返回；调用成功后，从网关集群(104)记录当前已执行成功的日志编号，作为currApplyID，之后转到步骤507；
步骤507，需等待主网关集群(103)发送的询问执行状态的消息；如果收到这个消息，则说明主虚拟卷(105)和从虚拟卷(106)均已落盘成功，此时转至步骤508；如果等待超时，未收到主网关集群(103)消息，则转到步骤515；
步骤508，向主网关集群(103)回复执行完成；之后转入步骤509；
步骤509，流程结束；
步骤510，由于此刻接收到的日志请求和本地保存的日志顺序是错序的，此时需要用从网关集群的currLogID来请求仲裁节点，并转入步骤511；
步骤511，如果收到仲裁节点返回仲裁成功，即从网关集群(104)的currLogID是最新的，则转到步骤512，否则转到步骤513；
步骤512，把自身盘对的状态从已同步变更为主卷有新数据，并转到步骤514；
步骤513，把自身盘对的状态从已同步变更为从卷有新数据，并转到步骤514；
步骤514，向主网关集群(103)回复同步失败响应；之后转到步骤509；
步骤515，请求仲裁节点，看哪边的日志是新的；
步骤516，如果仲裁节点返回仲裁成功，即从网关集群(104)的日志是最新的，则转到步骤517；否则转到步骤518；
步骤517，从网关集群(104)把自身的状态从已同步变更为主卷有新数据，之后转到步骤509；
步骤518，把从网关集群的状态设置成盘对故障(206)；之后转到步骤509。
5.根据权利要求4所述的用于分布式块存储集群间双活复制数据的方法，其特征在于，所述主网关集群(103)在主卷有新数据状态下，对主虚拟卷(105)上的IO操作的处理流程具体包括：
步骤601，应用服务器A(101)通过主IO路径(116)向主网关集群(103)发送IO命令；
步骤602，主网关集群(103)接收到IO消息，解析成IO命令，然后把IO命令转换成存储集群A(111)的RPC远程调用请求；
步骤603，主网关集群(103)生成一个新的日志项编号，将RPC请求序列化到预写日志中；
步骤604，执行当前日志项currLogID中的RPC请求；主网关集群(103)把RPC请求发到存储集群A(111)，完成IO动作，并等待RPC调用返回；调用成功后，主网关集群会记录当前已执行成功的日志编号，作为currApplyID；
步骤605，向应用服务器A(101)响应IO完成事件，之后转入步骤606；
步骤606，流程结束。
6.根据权利要求5所述的用于分布式块存储集群间双活复制数据的方法，其特征在于，所述仲裁节点(113)处理仲裁请求的过程具体为：
当一个网关集群访问另一个集群出现故障时，将请求仲裁节点(113)，由仲裁节点(113)辅助实现状态变更；
仲裁节点(113)在接收到请求后，通过判断哪一方的预写日志号更新，来确定哪方获胜；
获胜的一方在随后的过程中，将单独处理外部IO请求，而不再进行数据同步；而失败的一方，则不再响应外部IO请求；
发生上述数据不同步之后，主网关集群(103)的同步系统服务持续检查到从网关集群(104)和仲裁节点(113)的数据同步链路恢复；
发现数据同步链路恢复后，由同步系统服务根据主从两侧预写日志的差异，以同步预写日志的方式缩小两侧的差异，直到差异缩小为0之后，两侧系统状态值再次进入已同步状态。
7.一种用于分布式块存储集群间双活复制数据的系统，其特征在于，包括主网关集群(103)、从网关集群(104)及连接所述主网关集群(103)和从网关集群(104)的仲裁节点(113)；
所述主网关集群(103)和从网关集群(104)均与应用服务器A(101)、应用服务器B(102)连接；
所述主网关集群(103)与存储集群A(111)连接，从网关集群(104)与存储集群B(112)连接；
所述主网关集群(103)和从网关集群(104)上分别存在主虚拟卷(105)和从虚拟卷(106)，所述主虚拟卷(105)和从虚拟卷(106)构成一个盘对(114)；
所述主网关集群(103)接收应用服务器A(101)的IO请求后，先在本地预写日志，然后把日志项复制到所述从网关集群(104)；
所述从网关集群(104)接收到应用服务器B(102)的IO请求后，先把IO请求重定向到主网关集群(103)，然后等待主网关集群(103)按照和处理自身接收的IO请求相同的方式来处理重定向请求；
当主网关集群(103)和从网关集群(104)在同步预写日志，或者读写本地的逻辑卷中遇到故障时，请求仲裁节点(113)，由仲裁节点(113)协助完成IO处理和盘对(114)的状态转换；
应用服务器A(101)通过建立的主IO路径(116)和从IO路径(117)分别访问所述主网关集群(103)和从网关集群(104)，所述主IO路径(116)和从IO路径(117)是主备关系，正常情况下应用服务器A(101)使用主IO路径(116)访问主网关集群(103)；当主IO路径(116)故障时，自动切换到从IO路径(117)访问从网关集群(104)；
所述盘对(114)的状态转换过程具体包括：
初始态下，选择存储集群A(111)中一个逻辑卷(109)，映射成一个主虚拟卷(105)；选择存储集群B(112)中一个逻辑卷(110)，映射成一个从虚拟卷(106)，创建盘对，主虚拟卷(105)和从虚拟卷(106)之间建立同步复制关系；
在同步中状态下，主虚拟卷(105)和从虚拟卷(106)分别进行格式化、数据初始化，保证两方数据一致；对于两侧预写日志有差异的情况，由主网关集群(103)控制从预写日志多的一侧，向预写日志少的一侧复制预写日志项，并执行日志项，直到两侧的预写日志无差异；之后，主网关集群(103)在确认同步完成后，把主网关集群(103)和从网关集群(104)中该盘对(114)的状态同时变成已同步；
在已同步状态下，主虚拟卷(105)和从虚拟卷(106)以先主后从的方式，通过预写日志来同步预写日志；同步之后，执行当前日志项指定的RPC请求；
在已同步状态下发生单侧盘或网络连接故障时，利用仲裁节点(113)的帮助，使得盘对(114)的状态转换为主卷有新数据或从卷有新数据；在数据不同步的状态下，只有单侧的虚拟卷为应用服务器提供服务，而无法同步数据；此时，主网关集群(103)中的数据同步系统服务不断尝试向从网关集群(104)，以及仲裁节点(113)发送健康检查请求，当发现三者之间的数据同步链路(115)恢复正常之后，则把主网关集群(103)的盘对(114)状态改为同步中；
在盘对(114)恢复过程中，如果继续发生磁盘或网络故障；或者在已同步状态下，主网关集群(103)和从网关集群(104)同时发生故障，则进入盘对故障状态；此时，整个盘对(114)都无法对外提供服务，手工删除盘对之后，利用其他工具对磁盘手工修复后，再重新同步数据。
8.根据权利要求7所述的用于分布式块存储集群间双活复制数据的系统，其特征在于，所述主网关集群(103)和从网关集群(104)分别由多台服务器构成，为上层应用服务器提供基于块存储协议的服务端程序，作为前端；并且把独立的存储集群A(111)的逻辑卷(109)和存储集群B(112)的逻辑卷(110)分别映射成自身的主虚拟卷(105)和从虚拟卷(106)，作为后端；由主网关集群(103)和从网关集群(104)中分别提供逻辑卷(109)和逻辑卷(110)，形成一个盘对(114)。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310053755.7A CN115794499B (zh) | 2023-02-03 | 2023-02-03 | 一种用于分布式块存储集群间双活复制数据的方法和系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310053755.7A CN115794499B (zh) | 2023-02-03 | 2023-02-03 | 一种用于分布式块存储集群间双活复制数据的方法和系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115794499A CN115794499A (zh) | 2023-03-14 |
| CN115794499B true CN115794499B (zh) | 2023-05-16 |
Family
ID=85429657
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310053755.7A Active CN115794499B (zh) | 2023-02-03 | 2023-02-03 | 一种用于分布式块存储集群间双活复制数据的方法和系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115794499B (zh) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116737634A (zh) * | 2023-07-12 | 2023-09-12 | 北京鲸鲨软件科技有限公司 | 一种drbd双主模式下基于仲裁的脑裂快速处理方法和装置 |
| CN116610499B (zh) * | 2023-07-19 | 2023-11-03 | 联想凌拓科技有限公司 | 文件系统中的集群角色切换方法、装置、设备及介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111130835A (zh) * | 2018-11-01 | 2020-05-08 | 中国移动通信集团河北有限公司 | 数据中心双活系统、切换方法、装置、设备及介质 |
| CN114579532A (zh) * | 2022-02-21 | 2022-06-03 | 阿里巴巴（中国）有限公司 | 处理预写日志的方法、装置及系统 |
| CN115599747A (zh) * | 2022-04-22 | 2023-01-13 | 北京志凌海纳科技有限公司（Cn） | 一种分布式存储系统的元数据同步方法、系统及设备 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104838367A (zh) * | 2013-03-14 | 2015-08-12 | 株式会社日立制作所 | 灾难恢复虚拟化的方法和装置 |
| CN104331254A (zh) * | 2014-11-05 | 2015-02-04 | 浪潮电子信息产业股份有限公司 | 一种基于双活逻辑卷的存储双活系统设计方法 |
| CN107577564A (zh) * | 2017-07-24 | 2018-01-12 | 杭州沃趣科技股份有限公司 | 一种基于块同步技术实现双活系统的方法 |
| CN111770139A (zh) * | 2020-06-05 | 2020-10-13 | 苏州浪潮智能科技有限公司 | 一种分布式存储系统远程同步数据的方法、装置及系统 |
| CN113489784A (zh) * | 2021-07-05 | 2021-10-08 | 深圳市杉岩数据技术有限公司 | 分布式存储的非对称逻辑单元访问多路径实现方法及系统 |
-
2023
- 2023-02-03 CN CN202310053755.7A patent/CN115794499B/zh active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111130835A (zh) * | 2018-11-01 | 2020-05-08 | 中国移动通信集团河北有限公司 | 数据中心双活系统、切换方法、装置、设备及介质 |
| CN114579532A (zh) * | 2022-02-21 | 2022-06-03 | 阿里巴巴（中国）有限公司 | 处理预写日志的方法、装置及系统 |
| CN115599747A (zh) * | 2022-04-22 | 2023-01-13 | 北京志凌海纳科技有限公司（Cn） | 一种分布式存储系统的元数据同步方法、系统及设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115794499A (zh) | 2023-03-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN115794499B (zh) | 一种用于分布式块存储集群间双活复制数据的方法和系统 | |
| AU2005207573B2 (en) | Geographically distributed clusters | |
| EP1704480B1 (en) | Cluster database with remote data mirroring | |
| US20140244578A1 (en) | Highly available main memory database system, operating method and uses thereof | |
| CN106776121B (zh) | 一种数据灾备装置、系统及方法 | |
| CN111368002A (zh) | 一种数据处理方法、系统、计算机设备和存储介质 | |
| GB2484086A (en) | Reliability and performance modes in a distributed storage system | |
| US20190052709A1 (en) | Clustered storage system synchronization | |
| CN113254275A (zh) | 一种基于分布式块设备的MySQL高可用架构方法 | |
| CN115098229A (zh) | 事务处理方法、装置、节点设备及存储介质 | |
| CN107357800A (zh) | 一种数据库高可用零丢失解决方法 | |
| CN112783694B (zh) | 一种高可用Redis的异地灾备方法 | |
| WO2015196692A1 (zh) | 一种云计算系统以及云计算系统的处理方法和装置 | |
| CN111708843A (zh) | 一种基于MGR的跨数据中心MySQL多活实现方法 | |
| CN113905054B (zh) | 基于RDMA的Kudu集群数据同步方法、装置、系统 | |
| CN114363350A (zh) | 一种服务治理系统及方法 | |
| JP2004272318A (ja) | 系切り替えシステムおよびその処理方法並びにその処理プログラム | |
| CN112667440A (zh) | 一种高可用MySQL的异地灾备方法 | |
| CN111400098A (zh) | 一种副本管理方法、装置、电子设备及存储介质 | |
| CN111130896A (zh) | 一种nfs故障的切换方法、系统及双控存储系统 | |
| CN115905270B (zh) | 数据库中主用数据节点的确定方法、装置及存储介质 | |
| US20240126783A1 (en) | Recovery from loss of leader during asynchronous database transaction replication | |
| WO2023155706A1 (zh) | 一种数据存储系统及方法 | |
| CN116910147A (zh) | 基于组复制的MySQL同城多中心的多活实现方法和系统 | |
| CN115080661A (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 |